Stop using no-cors fetch mode where possible

[domfarolino]

The specification has 5 places where we create network requests, and 4/5 of them use no-cors as the request mode, which is unfortunate since it is a highly discouraged request mode to use, and should not be used for any new web platform features without proper justification:

• https://wicg.github.io/turtledove/#check-interest-group-permissions: "cors"
• https://wicg.github.io/turtledove/#fetch-script: "no-cors"
• https://wicg.github.io/turtledove/#fetch-webassembly: "no-cors"
• https://wicg.github.io/turtledove/#fetch-trusted-signals: "no-cors"
• https://wicg.github.io/turtledove/#interest-group-update: "no-cors"

We should evaluate which of these "no-cors" requests could take one of the following paths:

• Use "same-origin" (possibly changing the initiator origin to match the URL, when it is the same for each request)
• Use "cors"

As far as I can tell (going off of memory from internal discussion, not my present evaluation of each request right now), none of the "no-cors" requests would trigger preflights if they switched to CORS, which is good. On the other hand, the initiator of the request would be exposed via the Origin header, which at least for some requests might not be desirable (are there some where this wouldn't be bad though?? I think that needs to be answered). I like the "same-origin" route when possible, so we should try and use it wherever we can. We did this with a similar client-less fetch request in attribution reporting and I think it was a great outcome (https://github.com/WICG/attribution-reporting-api/issues/546, https://github.com/WICG/attribution-reporting-api/pull/817).

[qingxinwu]

@MattMenke2 FYI

[MattMenke2]

The thinking at the time was that the script, web asm, trusted signals, and interest group update URLs are all provided either in 1P contexts, or in 3P contexts where the first party explicitly delegates permission (via a 1P well .known-url), so the URLs themselves are are not being provided by a 3P origin, despite the request nominally using a 3P origin as the "referer".

This request mechanism is novel to the web, and doesn't really fit in existing 1P/3P notions.

[MattMenke2]

Another would be to treat these as same-origin requests, changing the initiator (not sure if we would still want a referrer?)

[MattMenke2]

These used to be CORS requests, but they were sending preflights (due to one of the FLEDGE headers, I believe - X-Allow-FLEDGE, maybe? We do no longer set that). This was constantly leading to problems for everyone experimenting with FLEDGE.

The problem with allowing same-site redirects is at some point we'll likely want a special cache for JS scripts, at least, and if we allow redirects, it opens up more for cross-IG attacks, and requires a more complicated cache architecture.

[domfarolino]

Well we currently already allow same-site redirects anyways, right? This is more about whether we want to explicitly disable cross-origin redirects and/or how to handle cross-origin (with respect to the request initiator origin that we set) responses. I guess the team needs to answer the question of what should the initiator request be, and can we enable CORS or the same-origin request mode? I'd love to be able to resolve the issue in one of those directions, but don't have enough Protected-Audience-specific context to know which to recommend.

[jyasskin]

@domfarolino The 'redirect mode' is always "error", so I think @MattMenke2's right that we ban redirects entirely. Given that, maybe that's support for switching to mode="same-origin" with an updated initiator, since it's not a behavior change and avoids the deprecated "no-cors" mode?

[domfarolino]

Ah yes I missed that. Yes I think that moving to mode="same-origin" would be great, provided whatever changes we'd need to make to the request's initiator origin aren't controversial for other reasons.

[MattMenke2]

So I think we're agreed that requests to all auction URLs that are part of an interest group (worklet scripts, trusted signals) should use CORS + bidders origin (though what NetworkPartitionKey they should use is still an open question - right now, they're using the bidder origin's as if the user was on the bidder site, but that allows cross-site tracking. Ideally, we should probably use, at a minimum an new key restricted to the site the IG was learned, so all same-origin IGs learned on the same site save a cache key, but that key is different from that site's own key). We'll probably do something else for trusted signals once we're using a trusted server, but that's an issue for another day.

That still leaves two other types of requests, though: Seller scripts and trusted seller signals URL. For seller scripts, we're using no-CORS because we sent an additional header, which isn't safe listed. I think for those, we should perhaps safelist the new header, and enable CORS, and use the NetworkPartitionKey of the frame running the auction, though open to other ideas.

The seller signal URL is another issue, though - mostly because reusing the parent page's NetworkPartitionKey allows for cross-site leaks (with or without coordination from the seller), through cache probing attacks, which potentially reveal render URLs of bids. There will likely be enough URLs not to make this practical, but we should try and be safe. We could use a unique partition for each request, but that requires a lot of new connections, so seems a problem. Not sure of a great solution here, until we start requiring trusted servers for signals.

There are update URL fetches - I think we should probably enable CORS and treat them as 1P requests from the IG owner as well, and use a transient/opaque/unique NIK for update fetches, keyed on site where the IG was joined (And on bidder URL?). I think we're already doing the latter, so just need to enable CORS and set the right initiator.

[domfarolino]

Thanks for the analysis @MattMenke2. If the team agrees with this, then of course I'd love to see more requests here start using CORS :)