User-level DP and other notions of DP that are not DAP-friendly

[tholop]

Keeping track of something we discussed with @cjpatton: some notions of DP are not achievable with DAP, at least in the current form of the protocol. For instance:

• User-level DP seems hard to enforce if a given user can contribute from multiple devices or across multiple batches. In some cases we can ask users to bound their own contributions and achieve something similar to group privacy, but this might not always doable (e.g. if a user owns two devices that send measurements automatically without keeping track of the global number of measurements). Here is one reference about contribution bounding for user-level DP: https://arxiv.org/pdf/1909.01917.pdf (in the more general context of DP SQL).
• Deletion-DP is not compatible with the current DAP specification that releases the number of measurements in a batch. Some mitigations have been discussed, e.g. by adding dummy reports (I can't find the relevant Github discussion anymore, but here is a comment from the spec: https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/blob/8fe9e265ea08a14a8aa1aab1d7dcf05498430b15/draft-ietf-ppm-dap.md?plain=1#L2677). Substitution-DP doesn't have this problem.
• More generally, DAP Aggregators have access to some metadata that can pose problems, such as timestamps or Client IPs. Releasing the min/max timestamp of a batch to the Collector is problematic even if Aggregators are honest (unless we use a DP mechanism such as Report Noisy Max to make this timestamp DP).

[wangshan]

For the first problem some client side bound could help, for example the proposal of using rate limiting PAT: https://github.com/cpriebe/draft-priebe-ppm-dap-reportauth. But it is indeed to hard to limit same user data form multiple devices. ClientIPs and timestamps can be mitigated by a anonymous proxy like OHTTP, in DAP there is also a time precision field in task config to avoid revealing exact timestamp.