Review Request for Attribution Reporting API

[johnivdel]

Past review: Event-Level Click Conversion Measurement API (#418)

Braw mornin' TAG!

I'm requesting a TAG review of Attribution Reporting API.

This API measures ad conversions (e.g. purchases) and attributes them to ad interactions without using cross-site persistent identifiers like third-party cookies. The intention is to provide the ability to measure how well campaigns perform - understanding which ads are most effective, and the relative performance of a campaign on different sites. The API allows measurement through both event-level reports sent directly from the browser, and aggregatable reports which can be processed through a trusted service to create summary reports of attribution data.

• Explainer¹ (minimally containing user needs and example code): Event | Aggregate | Aggregation Service
• Security and Privacy self-review²: https://github.com/WICG/conversion-measurement-api/blob/main/attribution_reporting_security_privacy_questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/conversion-measurement-api
• Primary contacts (and their relationship to the specification):
  • John Delaney (@johnivdel), Google
  • Martin Pál (@palenica), Google
• Organization/project driving the design: Google Chrome, Privacy Sandbox
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/6412002824028160

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG currently, the proposal is also being discussed within PATCG
• The group where standardization of this work is intended to be done ("unknown" if not known): PATWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • PATCG Telcon: https://github.com/patcg/meetings/tree/main/2022/02/09-telecon
• Major unresolved issues with or opposition to this design:
  • The aggregate API depends on a trusted aggregation service to process the data.
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[torgo]

Hi folks! We're taking a look at this today. Given that there are other competing specs from other entities that already enjoy implementation (as indicated in your Related Work section of explainers) and that at least one browser has signalled that they do not support this proposal, it seems to us that there is additional work to be done here to converge these proposals and push for a consensus approach. Is there any effort under way to move in this direction? Considering the numerous efforts underway by different parties, it feels like this should be headed towards a proper working group.

cc @wseltzer

[hadleybeeman]

Hello! We discussed this at our W3C TAG breakout.

We are adding this to our agenda for our upcoming face-to-face in London, and we'll come back to this in more detail then.

[linnan-github]

こんにちは TAG-さん!

I’m requesting a TAG review of Cross App and Web Attribution Reporting API, which is an extension to the Attribution Reporting API.

This proposal expands the scope of attribution to allow attributing conversions that happen on the web to events that happen off the browser, within other applications.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md
• Specification URL: https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
• Security and Privacy self-review: See below
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/attribution-reporting-api
• Primary contacts (and their relationship to the specification):
  • John Delaney (@johnivdel), Google
• Organization/project driving the design: Google Chrome, Privacy Sandbox
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/4994430156668928

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG currently, the proposal is also being discussed within PATCG
• The group where standardization of this work is intended to be done ("unknown" if not known): PATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Security and Privacy Questionnaire

This section contains answers to the W3C TAG Security and Privacy Questionnaire.

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

   This feature adds an additional fingerprinting vector letting web sites, and potentially third parties, know if the underlying platform supports attribution reporting, which is low entropy data.

   The purpose of this feature is to allow events that happen on the web to be joinable with events that happen off the browser, within other applications, so it’s necessary to expose this information so that sites can configure their response headers for attribution.

2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

   Yes, we only expose possible web or OS-level support for attribution reporting.

3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

   This API does not directly expose PII or personal information.

4. How do the features in your specification deal with sensitive information?

   This API does not handle sensitive information.

5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?

   The web or OS support does not persist across browsing sessions, but cross app and web registrations may be persisted by the OS across browsing sessions.

6. Do the features in your specification expose information about the underlying platform to origins?

   Yes, but no more than whether attribution is supported on web or OS-level .

7. Does this specification allow an origin to send data to the underlying platform?

   Yes, it allows an origin to send one or more URLs that indicates a desire to use the underlying platform’s attribution API instead of the browser’s.

8. Do features in this specification enable access to device sensors?

   No

9. Do features in this specification enable new script execution/loading mechanisms?

   No

10. Do features in this specification allow an origin to access other devices?

    No

11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

    No

12. What temporary identifiers do the features in this specification create or expose to the web?

    None.

13. How does this specification distinguish between behavior in first-party and third-party contexts?

    Use of this feature in third party contexts requires a Permissions Policy: https://wicg.github.io/attribution-reporting-api/#permission-policy-integration

14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

    The web or OS-support signal is still sent in Incognito mode, but the data is not passed to the underlying platform.

15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

    Attribution Reporting API specification has both sections: Security Considerations, Privacy Considerations.

    Some discussions apply to this feature as well, and we will add additional information concerning this feature if necessary.

16. Do features in your specification enable origins to downgrade default security protections?

    No

17. What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigation back to the document?

    Registrations that occur within the document will continue to be processed before and after the document enters the BFCache.

18. What happens when a document that uses your feature gets disconnected?

    Registrations that occur within the document will continue to be processed before and after the document gets disconnected.

19. What should this questionnaire have asked?

    N/A

[torgo]

Hi @linnan-github can you clarify this? Is this meant to be a new review request or does it in some way replace the existing request for this review? We're still in a kind of hold mode because as noted in PATCG issue 22 we are looking for the group to come to us with a unified proposal. Do you have any further information on that?

[linnan-github]

Hi @linnan-github can you clarify this? Is this meant to be a new review request or does it in some way replace the existing request for this review? We're still in a kind of hold mode because as noted in PATCG issue 22 we are looking for the group to come to us with a unified proposal. Do you have any further information on that?

Hi @torgo, this is meant to be a new review request for an extension to the Attribution Reporting API: Cross App Web Attribution Measurement. It does not replace the existing request for this review. Thanks!

[plinss]

The TAG has general agreement that providing some form of attribution is worth pursuing.

We encourage the proponents of this work to continue engaging in the discussions in PATCG (eventually PATWG).
The work there on aggregated solutions seems to be making significant progress, and we hope that you will succeed in converging on a single, consensus-based approach.

We are formally marking this request as "declined" because of the ongoing work.
We're otherwise supportive.