search

WICG / attribution-reporting-api

Attribution Reporting API
https://wicg.github.io/attribution-reporting-api/
Other
345 stars 161 forks source link

Support Service-Worker fetch registration #550

Open csharrison opened 1 year ago

csharrison commented 1 year ago

Here is a common flow for "default" handling of requests going through service workers that doesn't work with the API. The case is a conversion ping which redirects through two domains.

sequenceDiagram
    participant P as Page
    participant S as Service worker
    participant A1 as Ad server 1
    participant A2 as Ad server 2
    P->>S: 1. Request for ad1.com/conversion-ping
    S->>A1: 2. Request for ad1.com/conversion-ping
    A1->>S: 3. Redirect
    S->>A2: 4. Request for ad2.com/conversion-ping
    A2->>S: 5. Respond with Attribution Reporting headers
    S->>P: 6. Respond to (1) with response from (5)

Currently, the API does not support fetches from within service workers (at least, in the Chromium implementation - the spec is not defined right now on this matter), so there is only a single registration at (6), not one also at (5).

The problem is that the API registration should be associated with ad2.com, but it incorrectly gets associated with ad1.com because the Service Worker is just copying the response wholesale. Worse still, if ad1.com also wanted to register with API headers at (3), they would see very strange behavior indeed because their headers would get replaced with the headers from ad2.com.

The workaround is to avoid the Service Worker URL interception entirely by not calling respondWith for the associated registration fetch events.

Concretely, we should: ~~1. Highlight as a note in the spec the behavior on (6), and reference the workaround.

  1. Consider this case when deciding whether the API should formally support requests from within a Service Worker. Note that supporting this could have bad outcomes in that we may introduce duplicate registrations in the above diagram, especially for non-redirected requests. Let's proceed with caution here.~~
csharrison commented 1 year ago

I chatted with @wanderview about this at TPAC and I think there is a bug in the Chromium implementation. I filed crbug.com/1364447 with more details.

I think the real fix to this is to:

  1. Support fetches from within SW
  2. Stop supporting fetches served by SW (e.g. look at WasFetchedViaServiceWorker)

Note that (2) does stop the duplication issue, but it might break some legit use-cases where SW are actually needed to use the API, it would be good to get feedback if this is the case.

csharrison commented 1 year ago

Given the Chromium bug, renaming this issue to more accurately needs to be done w/in the proposal.

alois-bissuel commented 1 week ago

Do you have any news on the status of the issue? Also, it looks like the bug filing has moved to https://issues.chromium.org/issues/40185335 if I am not mistaken. And that the bug has not been fixed.

apasel422 commented 1 week ago

@agarant