[private-measurement] Strawman: Target privacy constraints (#17)

benjaminsavage has just created a new issue for https://github.com/patcg/private-measurement:

== Strawman: Target privacy constraints ==
# Strawman target privacy constraints

A private measurement API should only return **aggregated, anonymous information**. That means this information:
1. Cannot be linked to a specific individual
2. Cannot be "de-anonymized"

The implications of this is are that:
1. Some amount of random noise must be added to the information to provide a differential privacy guarantee.
2. (tentative) Each breakdown key **b** in the output should be an aggregation across at least K (strawman: 100) people. Specifically, the cardinality of the set of unique match keys appearing across the set of source-events with breakdown key equal to **b** is at least 100)

NOTE: implication 2 is marked as (tentative) because it does not improve privacy in the worst case. This is because an adversary could generate a group of 100 source events comprised of 1 authentic event and 99 fake source events, or 1 authentic event and 99 real source events they know will not generate matches. However, this type of constraint would make it much simpler to explain the system to people (e.g. "Each breakdown is aggregated across a group of at least 100 people, after which a small amount of random noise is added to further protect privacy").

## Regarding information leakage over time

In each "epoch" (strawman: each week), a private measurement API should provide some upper bound, or limit, on the amount of cross-app/cross-site information revealed about a given person to a given app/website. That means that:
1. A private measurement API needs to manage a "privacy budget".
2. There cannot be an unbounded number of independent "privacy budgets" corresponding to a given person, app/website pair.

# Strawman Security constraints

If any entity involved in operating a private measurement API becomes:
- Curious (that is, it tries to learn more information that it is supposed to)
- Compromised (that is, it is taken over by an attacker)
- Compelled (that is, a government forces it to try to break the privacy of the system)

The API should continue to provide the privacy protections outlined above.

## Implications for client-side code

If a private measurement API relies upon Client-side code (in a browser or mobile operating system), it should be the case that:
1. Such code is open-source and auditable, so that independent security experts can validate no back-doors have been added. 
2. Individuals can validate that their installation is running code which matches the open-source specification, so that they can make sure they were not provided with a compromised, or back-door enabled version.

## Implications for server-side code
If a private measurement API relies upon Server-side code, then for every entity operating some portion of that server-side infrastructure it should be the case that:
1. It is not capable of acquiring private user-information, even if it were to deviate from the specification to attack the system in arbitrary ways.
2. It opens itself up to regular audits to validate that the server-side code being run matches the specification.




Please view or discuss this issue at https://github.com/patcg/private-measurement/issues/17 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 June 2022 01:23:54 UTC