attribution-reporting-api icon indicating copy to clipboard operation
attribution-reporting-api copied to clipboard

Support Service-Worker fetch registration

Open csharrison opened this issue 3 years ago • 4 comments

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. 2. 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 avatar Sep 02 '22 21:09 csharrison

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 avatar Sep 16 '22 06:09 csharrison

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

csharrison avatar Sep 19 '22 14:09 csharrison

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.

alois-bissuel avatar Jun 19 '24 12:06 alois-bissuel

@agarant

apasel422 avatar Jun 20 '24 12:06 apasel422