Strawman: Target Security Constraints

[benjaminsavage]

Strawman Security constraints

If any single 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 it follows the specification, and no back-doors have been added. (Where the browser / OS is operated by an entity which also runs an ads business, this has the added benefit of boosting confidence in competitors that there is no self-preferencing or self-dealing going on.)
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 has undergone an (at this time unspecified) certification process to become authorised to help run the service. This will likely involve being certified by browser vendors and OS operators.

[AramZS]

Would we like to present these in an upcoming meeting?