Add differential privacy as a threat mitigation

[csharrison]

Differential privacy can protect against attacks where a portion of the input data is known a priori, or when the size of a batch is small. This PR adds DP as an optional mitigation for PDA deployments and lists where it helps mitigate various threats.

Additionally:

• Removes a false statement that revealing user input does not compromise other users' privacy. This is not necessarily the case (e.g. imagine if the batch size is 2 or if many users reveal their input).
• Removes a statement that clients revealing their inputs is outside the threat model (is this still relevant?)

[cjpatton]

Excellent! Requested changes are editorial.

[cjpatton]

EDITED: Given that the likely trajectory of this document is an IETF WG draft, it would be better to replace this markdown with a reference to a paper about DP. The most useful reference would be something that describes the distinction between client-side and server-side noise addition.

[cjpatton]

Edited this comment.

[csharrison]

Done, I added a general DP reference in place of the wikipedia link. It discusses central, local, and multi-party DP.

[tgeoghegan]

I have one question about whether we need more explicit protocol support for DP but if so, that can land in a subsequent PR.

[tgeoghegan]

Besides this informal recommendation, do we need explicit protocol support for differential privacy so that collectors can de-noise outputs? We can leave it up to aggregators to decide how they're going to implement DP but I wonder if PDAOutputShare should have a field for the epsilon value that was used by the aggregator. Forgive me if I'm talking nonsense about DP, I am speaking in the terms that we used in Prio v2.

[csharrison]

Hm. I am nervous about being to prescriptive here. In the simplest protocol design nothing is needed since the epsilon is hardcoded into the specific protocol instantiation and won't change.

In practice, some specific instantiations may want to reveal even more information about how noise was applied, e.g.

• The distribution noise is sampled from (Laplace, Gaussian, etc)
• Parameters of the noise distribution
• Any kind of threshold used (for example, if you are using approximate DP)

I think we should make this as opaque to the protocol as possible vs. prescribing some single "epsilon" field which might be too constraining. What do you think?

[csharrison]

However, I still think this current PR is land-able given that a basic instantiation can hardcode everything without requiring any communication.

[cjpatton]

The way to go here, I think, is to document the open question by adding an [OPEN ISSUE: blah blah blah].

[csharrison]

Done

[tgeoghegan]

I put a note about this in #19, which I think is an appropriate issue to track this discussion.

[cjpatton]

The way to go here, I think, is to document the open question by adding an [OPEN ISSUE: blah blah blah].