Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

[Akash Nadan]

Contact emails

akash...@google.com, lin...@chromium.org, john...@chromium.org

Explainer

Attribution Reporting with event-level reports

Attribution Reporting API with Aggregatable Reports

Aggregation Service for the Attribution Reporting API

Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting

Summary

We are landing the following changes to the Attribution Reporting API focused on:

• additional debugging capabilities by supporting parsing failure debug reports

• improving API ergonomics by supporting a field to specify preferred registration platform

• improving privacy

Explainer/Spec changes

1. Response header errors debug reports
2. Supporting preferred platform for cross app attribution
3. Move source deactivation step after top level filter matching 

Risks
Interoperability and Compatibility

(1) Header errors debug reports and (2) preferred platform are both fully backwards compatible changes and are optional features.  (3) The source deactivation change has very low compatibility risk because it does not require any developer changes and only results in ad techs getting different reports in cases where a user had multiple interactions across different ads when rate limits in the API are hit, which should be very rare.

              

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The attribution reporting feature bundle will be supported on all platforms with the exception of  Android WebView

Is this feature fully tested by web-platform-tests?

Yes

Estimated milestones

This feature bundle is anticipated to ship as part of Chrome 124. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5117902786396160

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API

Intent to Ship: Attribution Reporting features M117

Intent to Ship: Attribution Reporting features M118

Intent to Ship: Attribution Reporting features M119

Intent to Ship: Attribution Reporting features M120

Intent to Ship: Attribution Reporting features M121

Intent to Ship: Attribution Reporting features M123

[Mike Taylor]

On 3/18/24 7:17 PM, 'Akash Nadan' via blink-dev wrote:

Contact emails

akash...@google.com, lin...@chromium.org, john...@chromium.org

Explainer

Attribution Reporting with event-level reports

Attribution Reporting API with Aggregatable Reports

Aggregation Service for the Attribution Reporting API

Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting

Summary

We are landing the following changes to the Attribution Reporting API focused on:

• additional debugging capabilities by supporting parsing failure debug reports

• improving API ergonomics by supporting a field to specify preferred registration platform

• improving privacy

Explainer/Spec changes

1. Response header errors debug reports
2. Supporting preferred platform for cross app attribution
3. Move source deactivation step after top level filter matching 

Risks
Interoperability and Compatibility

(1) Header errors debug reports and (2) preferred platform are both fully backwards compatible changes and are optional features.  (3) The source deactivation change has very low compatibility risk because it does not require any developer changes and only results in ad techs getting different reports in cases where a user had multiple interactions across different ads when rate limits in the API are hit, which should be very rare.

I think I understand why the potential compat issue should be rare based on reading https://github.com/WICG/attribution-reporting-api/issues/842#issuecomment-1612096408, but it's not super clear to me what the implications for "adtechs getting different reports in some circumstances (or not report where they previously would have gotten one)" are. Mind clarifying?

              

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The attribution reporting feature bundle will be supported on all platforms with the exception of  Android WebView

Is this feature fully tested by web-platform-tests?

Yes

Estimated milestones

This feature bundle is anticipated to ship as part of Chrome 124. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5117902786396160

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API

Intent to Ship: Attribution Reporting features M117

Intent to Ship: Attribution Reporting features M118

Intent to Ship: Attribution Reporting features M119

Intent to Ship: Attribution Reporting features M120

Intent to Ship: Attribution Reporting features M121

Intent to Ship: Attribution Reporting features M123

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c691e58e-bfbb-492b-b235-6facc6d12062n%40chromium.org.

[Akash Nadan]

Hi Mike, the implications of an adtech getting different reports in some circumstances (or no report where they previously would have gotten one) are mainly when they are comparing these reports to other mechanisms they may be using for conversion measurement. They may see a slight difference in those comparisons, although given that this scenario is rare, it may not cause any issues or change in comparison.

Let me know if you have any other questions.

Thanks,

Akash

[Mike Taylor]

Thanks Akash. Follow up question: besides reading blink-dev, have we otherwise made relevant ad techs aware of the changes coming to reports?

[Akash Nadan]

Hi Mike, other than the blink-dev and GitHub Issue and PR, we have not yet. But I am planning to post an announcement about the change to the Attribution Reporting API Announcements group as well.

Thanks,

Akash

[Mike Taylor]

Thanks - please do send an announcement.

LGTM1

[Yoav Weiss (@Shopify)]

On Tuesday, March 19, 2024 at 12:18:00 AM UTC+1 Akash Nadan wrote:

Contact emails

akash...@google.com, lin...@chromium.org, john...@chromium.org

Explainer

Attribution Reporting with event-level reports

Attribution Reporting API with Aggregatable Reports

Aggregation Service for the Attribution Reporting API

Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting

Summary

We are landing the following changes to the Attribution Reporting API focused on:

• additional debugging capabilities by supporting parsing failure debug reports

• improving API ergonomics by supporting a field to specify preferred registration platform

• improving privacy

Explainer/Spec changes

1. Response header errors debug reports
2. Supporting preferred platform for cross app attribution
3. Move source deactivation step after top level filter matching 

Can you provide more details on the reasoning and implications of (3)? A lack of explainer or details on the PR itself make it somewhat of an opaque change..

[Akash Nadan]

Hi Yoav, the reasoning behind this change is that there is a privacy gap with the current attribution flow and position of the source deactivation logic. The current position of the source deactivation logic makes it possible for API callers to identify when a source is noise (versus a real source) in certain scenarios. Additional details/example in this Github issue: https://github.com/WICG/attribution-reporting-api/issues/842

Regarding the implications, an ad-tech may get different reports in some circumstances (or no report where they previously would have gotten one) which may have implications when they are comparing these reports to other mechanisms they may be using for conversion measurement. They may see a slight difference in those comparisons, although given that this scenario is rare, it may not cause any issues or change in comparison.

Let me know if you have any other questions.

Thanks,

Akash

[Yoav Weiss (@Shopify)]

LGTM2

On Tuesday, March 26, 2024 at 7:25:13 PM UTC+1 Akash Nadan wrote:

Hi Yoav, the reasoning behind this change is that there is a privacy gap with the current attribution flow and position of the source deactivation logic. The current position of the source deactivation logic makes it possible for API callers to identify when a source is noise (versus a real source) in certain scenarios. Additional details/example in this Github issue: https://github.com/WICG/attribution-reporting-api/issues/842

Regarding the implications, an ad-tech may get different reports in some circumstances (or no report where they previously would have gotten one) which may have implications when they are comparing these reports to other mechanisms they may be using for conversion measurement. They may see a slight difference in those comparisons, although given that this scenario is rare, it may not cause any issues or change in comparison.

Let me know if you have any other questions.

Thanks for the explanation. I'd consider this a (barely) web-exposed bug fix.

[Daniel Bratell]

LGTM3

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e03cf99a-c23e-4569-b371-2c203c8f1742n%40chromium.org.