[Intent to Prototype] Interoperable Private Attribution sent to [email protected]

[email protected] (Richa Jain, Meta) [email protected] (Ben Savage, Meta)

https://github.com/patcg-individual-drafts/ipa/blob/main/IPA-End-to-End.md

Under development at https://github.com/patcg-individual-drafts/ipa

https://docs.google.com/document/d/1LBv-Sg84jyq3Em474kgEbOaJ1GY6XsQKj6TlAlnIkyw

Interoperable Private Attribution (IPA) is an API for privacy-preserving advertising attribution. Attribution means counting the number of "conversions", for example purchases, that follow an ad interaction, for example viewing an ad. IPA preserves privacy by using cryptography and a network of helper parties who are trusted not to collude or be collectively coerced. See https://github.com/patcg-individual-drafts/ipa

Blink > Attribution

Advertising provides critical support for the web. Interoperable Private Attribution (IPA) enables advertisers to measure how their advertising campaigns are performing without relying on signals which identify specific individuals. In IPA, the user agent protects user identity using cryptography which is split across a network of helper parties. The helper parties are trusted not to collude or be collectively coerced. See also https://blog.mozilla.org/en/mozilla/privacy-preserving-attribution-for-advertising/

One of the things we hope to learn by prototyping and conducting experiments, is how much the advertising industry is able to work with noisy data. Most ad reporting systems today do not add random noise to ensure a differential privacy guarantee, or limit the number of breakdowns according to a “privacy budget”. This will likely be a difficult transition. We hope to collect feedback to help us iterate on the techniques for adding random noise, to try to find an optimal balance of privacy and utility.

https://docs.google.com/document/d/1KpdSKD8-Rn0bWPTu4UtK54ks0yv2j22pA5SrAD9av4s/edit

Pending. Issue can be found here

Pending

In the IPA proposal, a user-agent stores a user identifier (the “match key”) and processes it in response to API calls from any secure origin, including cross-site origins. Match keys do not follow the modern patterns of site isolation in web browsers, because while write permissions are partitioned by site, the ability to access an encrypted secret-sharing of the match key is available to all secure origins. We believe that the restrictions on the use of match keys are sufficient because the value returned by the API is a per-origin encryption of shares of the match key. It would take at least two trusted helper parties (see the “Threat Model” document the PAT-CG has put together for details) to decrypt the shares and then collude with one another to recover the underlying identifier.

In our initial prototyping, we intend to make this feature off by default. Developers can turn it on manually for testing.

IPA has two fundamental operations: setMatchKey, which sets a user identifier, and getEncryptedMatchKey, which retrieves an encrypted match key. To preserve user privacy, the side effects of setting a match key are unobservable to sites except in aggregate. This means the API could be effectively disabled, even on a per-person basis, by making setMatchKey a no-op. In addition, getEncryptedMatchKey uses a lazily resolved Promise so the API could be disabled, or return random data, with no compatibility impact for sites.

Gecko: Pending. Issue can be found here

WebKit: Pending. Issue can be found here

Web developers: IPA has been covered by several blog posts and websites e.g. here and here. An anonymous survey of participants in the “Private Advertising Technology Community Group” (link) shows strong preference for the architectural decisions and capabilities of IPA. Let us know if we need to provide more signals to showcase the support.

There may be changes to WebView behavior. We are still discussing the issue here.

We plan to extend DevTools’ storage model to indicate whether an identity provider has a match key set and let developers clear a match key without clearing all site data; to inspect helper networks, their keys, and the epoch clock. These are useful when developing and debugging IPA.

No, but we plan to submit tests to WPT. We might need to extend WPT browser hooks to interact with IPA storage.

Blink feature, interoperable-private-attribution.

True

https://bugs.chromium.org/p/chromium/issues/detail?id=1404067

No milestones specified

This intent message was generated by Chrome Platform Status.