Standards Position of the Chrome Privacy Sandbox Measurement Team

[csharrison]

This meta issue describes the Chrome Privacy Sandbox Measurement team’s current position on the Interoperable Private Attribution proposal, designed to satisfy similar use cases as the Attribution Reporting API (ARA).

Note: Chrome still plans to ship the Attribution Reporting API as explained in this document. Our engagement with experimental new APIs like IPA doesn’t change those plans.

Overall, we think more exploration is warranted given some beneficial design characteristics of IPA:

• It has structural support for cross-device and cross-platform attribution.
• It removes report delays and background fetches from the client, which improves usability and eliminates a source of unpredictability in the API.
• It places the privacy mechanism entirely server-side, which allows for more efficient privacy/utility trade offs.
• The client-side implementation of IPA is simple, making it easier for independent implementations to be interoperable.

Because of these benefits, we see IPA as a worthwhile direction to explore. We think prototyping code in the Chromium codebase will be valuable for developing and addressing some of our concerns with the proposal, some of which we outline below:

• IPA’s server-side infrastructure will need to process multiple orders of magnitude more data than ARA’s, because it moves the on-device join into the server. We need to be confident that this is feasible and cost-effective for all critical use-cases. See issue 22 on the private-measurement repo for the general scale issue for off-device attribution.
• IPA has been designed to provide only simple aggregates keyed by impression-side information, which doesn’t address fundamental ecosystem use-cases including model training or reporting by conversion type. We will need to ensure that IPA can provide a rich enough set of outputs such that these use-cases and others can be achieved. This may also require investigating alternative privacy mechanisms, e.g. Consider a randomized-response-like privacy mechanism #60.
• Issue 39: IPA’s pervasive sharing of “match keys” means match key providers are forced to share proprietary user data with arbitrary other parties on the web.
• Issue 42: IPA allows for arbitrary linking to off-device and off-web events, as long as they can be annotated with a match key. This potential abuse vector is hard to reason about and may need extra mitigations before we’re confident it’s safe. See also issue 57 which identifies a privacy attack based on this capability. Potential fixes which remove the notion of a match key provider reduce the potential utility of IPA (e.g. to support attribution across platforms).
• Issue 25: IPA currently only specifies a Javascript API, which we don’t think will be tenable for real-world adoption where ad measurement is often at the HTTP layer.
• If sites participating in IPA want to delegate to one (or many) third parties to do their measurement for them, they need an explicit mechanism to advertise to browsers/helper party networks about this delegation. This mechanism is not currently well-defined in the IPA proposal (although a strawman is discussed in issue 6). Our experience with deploying ARA leads us to believe that this mechanism will be a source for issues unless carefully crafted.

We are interested to see if these concerns can be addressed with iteration, and are happy to evaluate and discuss proposals. We also plan on continuing to explore alternative designs apart from IPA within the PATCG, with the goal of converging on a cross-browser standard for attribution measurement.

[benjaminsavage]

@csharrison - thank you so much for this clear, transparent response. All of these issues make a lot of sense to us, and we want to do our best to try to address these challenges you’ve laid out!

We deeply appreciate your openness to collaboration, and your feedback and suggestions for improvement.