[w3c/ServiceWorker] `CacheStorage` & `COEP:credentialless` (#1592)

The current behavior of CacheStorage with COEP is uniformly implemented across Firefox, Edge and Chrome:
https://wpt.fyi/results/html/cross-origin-embedder-policy?label=master&label=experimental&aligned

If the fetch client has `COEP:unsafe-none` and the response is fetched again via CacheStorage from a client with `COEP:require-corp`, we run again the CORP check on the cross-origin `no-cors` response and potentially block it. This avoids a cross-origin `no-cors` response from entering a `crossOriginIsolated` process without an explicit opt-in from the server.

The current spec is:
```
1. [=list/For each=] |response| of |responses|:
  1. If |response|'s [=response/type=] is "`opaque`" and [=cross-origin resource policy check=] with |promise|'s [=relevant settings object=]'s [=environment settings object/origin=], |promise|'s [=relevant settings object=], and |response|'s [=internal/internal response=] returns <b>blocked</b>, then reject |promise| with a `TypeError` and abort these steps.
```
See:
- https://github.com/w3c/ServiceWorker/issues/1490
- https://github.com/w3c/ServiceWorker/pull/1516/files
----

We have the same question for `COEP:credentialless` (see https://github.com/whatwg/html/issues/6637). How to prevent credentialled opaque responses from entering the `crossOriginIsolated` context?

This is a bit different, because `COEP:credentialless` is about the request and `COEP:require-corp` about the response.

Possibilities could be:
1. Do not provide CacheStorage to `COEP:credentialless` context.
2. Same implementation of `COEP:require-corp`, run the `cross-origin resource policy check` and require corp. 
3. Store the embedder policy of the original client in the stored response. Block opaque responses requested from `COEP:unsafe-none` into `COEP:credentialless`. We can also potentially allow the one passing `cross-origin resource policy check` with require-corp.

@mikewest @annevk @yutakahirano @asutherland @camillelamy

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1592