Attribution Reporting API

TPAC 2022

Problem overview

• Answering: “Why should I purchase ads on the web?”
• Answering: “Do ads even work?”

​

Generally speaking, we want to understand the relationship between ads shown / clicked by users and their future behavior on advertiser sites (e.g. making purchases)

​

Currently this is done with third party cookies and other cross-site identifiers. Is there a more private way?

Other proposals!

Lots of awesome activity in this space, by many major browser vendors

• Safari: Ships Private Click Measurement (PrivacyCG)
• Edge: Proposed MaskedLARK + Bucketization (WICG)
• Firefox: Proposed IPA jointly with Meta (PATCG)
• Chrome: Origin Trialing Attribution Reporting API (WICG)

​

We are all working together in the PATCG to see if we can align

Attribution Reporting API Overview

Event-level reports

• Local noise via randomized response
• Randomizes the outcome of each event
• Cross site data (relative to the source event) is coarse grained
• Report time
• Number of settable values
• No server-side dependencies

Summary reports

• Aggregatable reports from the client are… aggregated in trusted server infrastructure
• Server adds noise to final output
• Queries are batches of point queries in a large output domain

Current status

• In Origin Trials under the unified “Privacy Sandbox Ads APIs” Origin Trial
• https://developer.chrome.com/blog/privacy-sandbox-unified-origin-trial/
• Currently at 1% of Chrome’s stable channel, and 50% of pre-stable channels
• We are getting tons of feedback from our early testers, a few examples
• Multi Conversion Domain Tracking (549)
• Permissions-Policy limitations (519)
• Misconfigured service workers can cause unexpected behavior on redirect (550)
• [Aggregate API] Tracking multiple trigger types (521)
• Additional Debugging Asks For Attribution Reporting Api (525)

Interesting problem: Permissions policy (& Origin Trials)

• Ad.com wants to use the API
• Needs to convince top-level and transient-iframe to set the Permissions Policy
• Transient iframes come and go in the existing ads ecosystem
• Massive coordination problem, even with top-level opt-in
• Extremely difficult to test!

top-level.example

transient-iframe.example

ad.com

Status: Chromium implementation temporarily moving to * default permission for testing

Interesting bug: Service worker interaction

• ARA doesn’t support fetches from within Service Workers
• Existing bug (1217757)
• Fetches delivered by SW getting the initial URL, not the final URL
• Newly discovered bug (1364447)

Status: Bug bashing

Interesting problem: sensitivity bounds & noise

• Issue 249
• Current design bounds L1 sensitivity of a single event’s contribution on-device
• “Optimal” when reports contribute to a single bucket
• Non-optimal for lots of buckets with a more sophisticated contribution bound
• If we can prove that user contributions are “spread across” many buckets, we can use much less noise
• How to balance the use-cases?

Status: Brainstorming, may require more configuration

Single user contribution

Larger per-bucket noise

L1 bound

L2 bound

Smaller per-bucket noise

Scales with sqrt(num_buckets)

What’s coming

App and web integration

• Direct integration with Android’s Privacy Sandbox
• https://developer.android.com/design-for-safety/privacy-sandbox/attribution-app-to-web

// Registers a source against a native OS attribution API

Attribution-Reporting-Register-OS-Source:

"https://a.test/register-android-source?...";

os-destination=<os destination>; web-destination=<web destination>

​

• Event will simply be handled by the OS instead of the browser via a separate ping to the OS-Source

​

Better debugging support

• https://github.com/WICG/attribution-reporting-api/pull/514
• Designed to be privacy preserving

{

"type": "<report type>", // e.g. "source-destination-limit"

"body": {

"limit": 100, // the browser's limit

"source_event_id": "<source event id in the source registration>",

"source_site": "https://source.example",

"attribution_destination": "https://destination.example"

}

}

Major design dimensions