Re: [whatwg/fetch] Add unsafe-no-cors mode (PR #1533)

I guess we need to make a decision regarding what to do with `client`/`window` in general. I think we don't have the concept of a "snapshotted" ESO at the moment that a user of `unsafe-no-cors` would pass in, but I guess for discussion we could pretend that this exists, and decide whether that would be a suitable input for requests like this, alongside the normal `null`.

### Snapshotting client

If we decide that snapshotting ESO is a good idea, then I think this means every user of these kinds of requests would be responsible for snapshotting some ESO themselves as the request's client (or maybe the Fetch [entrypoint](https://fetch.spec.whatwg.org/#concept-fetch) could try and implicitly do it somehow?). Some concerns:
 1. This means the snapshot could of course get out-of-sync with the true ESO on the main thread right when the fetching is started. That seems unavoidable, but probably we should quantify how many checks/steps this impacts: I suppose it would be all of the checks/steps that Fetch does right before going in parallel (ones that are run on the main thread in the usual case)?
  2. There are probably places in Fetch where we use the client not just as a bag of state, but as some interactive thing with an event loop and thing that can handle tasks etc. We should look for such cases, to see if any would cause problems if they suddently start operating on a state snapshot of ESO, instead of the real thing. Perhaps the 3 client usages you provided above might be on this list.

In any case, this approach is simple in for the `null` client case as you mentioned. We don't have to do anything special that Fetch doesn't already do today, because passing in `null` as your client would be an explicit decision and I guess you better know what you're doing RE other state. A typical `unsafe-no-cors` user would probably not pass in `null` I think, but would use the snapshot.

### Always null client

If we decide against the snapshot ESO idea and instead require `client` and/or `window` to always be `null`, then we have to make decisions about all of client-derived state. While `null` is indeed a valid `client` value today, its implications are likely not what the typical `unsafe-no-cors` would want (no referrer policy, CSP bypass, ...) i.e., a lot of that is centralized in policy container, which gets wiped anew in https://fetch.spec.whatwg.org/#ref-for-concept-request-policy-container%E2%91%A0 for null clients, and seems bad for every request like this to endure (see [FedCM fetches](https://fedidcg.github.io/FedCM/#fetch-the-config-file), one of the motivations for `unsafe-no-cors` in the first place, which tries to hack together its own CSP check elsewhere).

So if we went this route we'd probably want to assert that an explicit policy container + any other interesting state gets explicitly passed in on the request. That state would likely just be a clone/snapshot of the Document's policy container and additional state, which isn't any better than the snapshotting ESO idea above.

> I think if there is an expectation that the "client" is a snapshot of some variety, that should be clear and able to be relied upon, so I lean that direction.

Given all of this, I too lean in the direction of assuming that unless explicitly passed in, the request's client is a snapshot of the associated Document's ESO. But we should gather more feedback, perhaps @annevk has opinions?

----

Also, it would be great to more explicitly lay-out the integration that this has with https://github.com/whatwg/fetch/pull/1442 and whatever response-blocking technology already exists (I'm told CORB no longer lives in Fetch, so maybe there is none?), to get a feel for what major behavior change this would entail especially for implementers. Is it simply the fact that `unsafe-no-cors` requests have "basic" response tainting that exempts them from all of the checks that make `no-cors` an unsuitable alternative?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1533#issuecomment-1424666319
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1533/c1424666319@github.com>