Original text:
malicious client to craft a proof that will fool honest aggregators into accepting invalid input.  6.1.2.3. The linear secret sharing scheme employed by the client ensures shares reveal nothing about either the inputs or the participating clients.  6.1.3. The leader is also an aggregator, and so all the assets, capabilities

Reviewer comments:
Aggregators merely counting the number of input shares could compromise user privacy in some circumstances (namely, it can break differential privacy if the number of records per user is not constant). This attack only applies to aggregators who can count the number of shares, so any protection still holds on the collector side. To address this attack, there are two possible mitigations, which both involve adding noise to the total number of input shares. This should be possible to do with "null" shares that don't affect aggregate output (i.e. inserting 0 into sums).
Specifically, this is about being able to count the number of contributions from an individual client, right? If so, this would also be mitigated by putting an anonymizing proxy between clients and the leader which would scrub identifying information from reports.
An anonymizing proxy mitigates attacks but not in the worst case. I didn't mention in the PR (I could if it is necessary), but the worst case attack involves the attackers having some side knowledge (e.g. via client collusion) such that if N reports arrive, then Tim did not contribute to this batch, and if N+1 reports arrive, then Tim did contribute to the batch. This is related to the Sybil style attacks which do the same thing but with the value embedded in the report. In these kinds of attacks, no auxiliary information in the report (like IP, etc) is needed. In practice, I don't believe this attack does much to meaningfully reduce user privacy. However, I think calling it out is important if we want to make differential privacy claims since DP requires us to think through worst-case attacks.
No this is not what I am talking about. This issue is not necessarily about attacks on , but rather about attacks on revealing to the helpers. In some settings, could be just as sensitive as . In your example you are using some local noise for each input (just one possible way of implementing DP). I don't think we would need this to protect . However, to protect we would only need to add false shares that truly sum to 0 (i.e. no noise embedded in them at all). So that is hard to learn from the total # of input records. Great question. Let's simplify this and say that you know for a fact that the true dataset contains either: records summing to , OR records summing to i.e. each record will always just have value 1. Also let's say that we've properly hidden directly, and the adversary wants to learn from . I think it should be clear that if we can protect the true value of , we can protect the true value of as they are the same. True, will be close to N or N+1, but the noise added to the sum will be enough that both cases are reasonably probable, protecting both and . For example (with Laplace noise with epsilon ln2): () -
Sharpening this a bit more: The concern is not whether the collector learns but whether the aggregators learn . The clients can add bogus reports to hide from the aggregators, or the leader can add bogus reports to hide from the helper. Is that right? This would be a tad inconsistent with the current threat model, which assumes the collector may collude with an aggregator and, in particular, provide it with the final output. That said, I'm fine with adding it as a security consideration. We just want to make it clear that it only appears to be achievable under stronger non-collusion assumptions. I see, thanks for clarifying. I think we need to be careful about what we mean when we say that the number of real (i.e., non-bogus) inputs is "protected". The output of the distributed aggregation function may be differentially private, but it doesn't hide the number of real inputs.
Yes that's right The collector colluding with an aggregator and providing the final output should be OK (similarly, the aggregators providing the noisy count of raw records to the collector). In this case, the adversary has 2 views of the data (noisy count and noisy output). You should still be able to prove DP protections in this case if each view is protected with DP (this comes from the fact that DP composes well: URL). Yes, this is exactly the purpose of this PR. By default, we can't protect from the aggregators unless we add the bogus records. However, if we can directly hide the number of real records (by adding bogus ones), and also_ ensure is DP, we can hide the true values of both and .
NAME take another look. I've tried to keep this short + sweet but let me know if you think it can be compressed further.
This should be ready to go
On the last design call (2021/08/04) we decided to split our work into two (sets of) documents: one for the "core" cryptographic protocols (Prio, Hits, ...) and another for the "wrapper" protocol (basically the protocol bits we've been working on so far). The next step is to specify the "interface" between these (sets of) documents. This is our goal for this issue. So far we've been reasoning about this core-wrapper interface by analogy of HPKE and its applications (ECH, OHTTP, etc.), which may indeed be an apt analogy, but it falls short of a precise definition. To that end, I'd like to suggest that the interface needs to accomplish two things. (1) Specify the syntax of every PDA protocol. The syntax should cover: (1a) generation of input shares from a measurement; (1b) the state machine of the leader and helper and how they respond to messages (in the core protocol); (1c) accumulation of input shares into an output share; and (1d) combination of output shares into the output. (2) Specify the security requirements of every PDA protocol. This has three main components: (2a) The expected communication model, which determines how much control over the network the adversary has. (This may be different from the communication model of the wrapper protocol, as discussed below.) (2b) A baseline notion of privacy in the expected communication model that allows any number of clients and all but one aggregator to be corrupted. (2c) A baseline notion of robustness in the expected communication that allows any number of corrupt clients to be corrupted, but requires all aggregators to be honest. Much of what we need is already worked out, but there are some gaps that require us to make some decisions. Two such gaps are discussed below. As observed in , we've been considering attacks outside the formal model of either Prio or Hits (specifically Sybil and replay attacks). The communication model for the core protocol may therefore differ from (i.e., make stronger assumptions about the adversary than) the communication model for the wrapper protocol. I would argue that this is perfectly reasonable. In fact, the main job of the wrapper protocol should be to "emulate" whatever communication model is expected by the core protocol. We are already well on our way here. The following mechanisms are used to provide properties that are implicit in the communication models of the papers: HPKE encryption creates a confidential channel between the client and each honest aggregator. The report's timestamp and jitter fields define a total ordering on reports, which the aggregators can use to ensure each report is counted in at most one batch. Some bits are still missing, however: Who manages the report queue? It seems simplest if the core protocol can assume in-order, non-repeated reports. The wrapper protocol can then do this enforcement. How are messages authenticated? Currently, the adversary can impersonate the leader since leader->helper messages are not leader authenticated. This may lead to an attack on robustness. We should probably address this in the wrapper protocol such that the core protocol can assume these messages are authenticated. In Prio, the adversary learns nothing beyond the aggregate of the honest clients' inputs. In contrast, in Hits, the adversary doesn't just learn the heavy hitters (HHs); it may also learn the frequency of non-HH inputs that share a common prefix of a non-HH input with some HH. This leakage is inevitable because the aggregators learn each intermediate set of candidate prefixes at the start of each collect request. We've observed that we can mitigate this leakage somewhat . Thus, one way to address this gap between Prio and Hits may be to require that each PDA protocol provide DP. This is probably too high a cost, however, given that not all PDA tasks need it. A simpler alternative might be to limit the syntax so that a single collect request is in scope. This seems natural, since a single round of Hits provides basically the same security properties as Prio. DP could still be added, but this would merely augment whatever the baseline privacy goal aims to provide.
Left a couple of suggestions that I don't think should block merging. NAME let us know when you've rebased or otherwise finished with this and we can merge it for you.

Revised text:
malicious client to craft a proof that will fool honest aggregators into accepting invalid input. <ins> Aggregators can count the total number of input shares, which could compromise user privacy (and differential privacy dp) if the presence or absence of a share for a given user is sensitive. </ins> 6.1.2.3. The linear secret sharing scheme employed by the client ensures shares reveal nothing about either the inputs or the participating clients. <ins> Clients can ensure that aggregate counts are non-sensitive by generating input independently of user behavior.  For example, a client should periodically upload a report even if the event that the task is tracking has not occurred, so that the absence of reports cannot be distinguished from their presence. Bogus inputs can be generated that encode "null" shares that do not affect the aggregate output, but mask the total number of true inputs. Either leaders or clients can generate these inputs to mask the total number from non-leader aggregators or all the aggregators, respectively. In either case, care must be taken to ensure that bogus inputs are indistinguishable from true inputs (metadata, etc), especially when constructing timestamps on reports. [OPEN ISSUE: Define what "null" shares are.  They should be defined such that inserting null shares into an aggregation is effectively a no-op.  See issue#98.] </ins> 6.1.3. The leader is also an aggregator, and so all the assets, capabilities