Open johnivdel opened 2 years ago
apasel422
commented
2 years ago One downside to combining the headers is that we expect users to manually set Attribution-Reporting-Eligible on fetch-based requests in order to support event-source registrations, but it is the browser that determines the os and web values. It may complicate the implementation for the browser to have to validate and/or modify the user-specified header to accurately reflect os and web.
csharrison
commented
1 year ago I agree with @apasel422 that it seems really problematic to modify a user set header.
One downside to combining the headers is that we expect users to manually set
Attribution-Reporting-Eligibleonfetch-based requests in order to supportevent-sourceregistrations, but it is the browser that determines theosandwebvalues. It may complicate the implementation for the browser to have to validate and/or modify the user-specified header to accurately reflectosandweb.
I do wonder if this speaks to a problem in the API design where we configure the API using request headers instead of explicit params to fetch / xhr.
johnivdel
commented
1 year ago The API now supports explicit parameters on fetch/xhr, so the concern raised above is less problematic.
The compat risk here is low.
Given that the Attribution-Reporting-Eligible is a structured header, and has "GREASE" parameters, it would be straightforward to add new parameters in a backwards compatible way for OS-Support.
Given the fetch/xhr changes, it seems worthwhile to re-use the eligibility header just for simplicity in the Cross app and web API.
apasel422
commented
3 weeks ago Given that the Attribution-Reporting-Eligible is a structured header, and has "GREASE" parameters, it would be straightforward to add new parameters in a backwards compatible way for OS-Support.
+1 to this. Where we send this today:
Attribution-Reporting-Eligible: event-source, trigger
Attribution-Reporting-Support: web, oswe could instead send
Attribution-Reporting-Eligible: event-source, trigger, registrar=(web os)
Currently, the app_to_web explainer proposes adding a new request header which specifies whether a request can register with either a web or OS provided Attribution Reporting API.
The EVENT.md explainer already adds an outgoing request header, Attribution-Reporting-Eligible, which specifies what type of registrations are possible for the response (event-source, trigger, navigation-source).
To simplify this, we could consider combining the two headers. Because both are already structured dictionary headers, it would simple to allow them to contain all of the boolean keys (event-source, trigger, navigation-source, os, web).