Re: [whatwg/fetch] Cross-Origin Read Blocking (CORB) (#681)

Regarding service worker and cache API:

> It seems CORB would require that Cache.match() not send the opaque body data to the renderer process until after the CORB checking is performed. The CORB checking would depend on what the service worker does with the opaque response. (If I understand correctly the CORB check requires knowing the destination of the response within the browser.)

I don't think that's right.  CORB shouldn't depend on what the destination of the request is, nor what service worker is going to do with the response.  The intention is to not expose the data of the opaque response to the service worker in the renderer process at all.  My understanding from discussions with @mattto, @anforowicz, and @nick-chromium was that service worker could still handle opaque responses without exposing that data to the renderer process, though it's worth clarifying the details on things like cache.add.

> FWIW, this does part does seem doable to me from an implementation perspective. Gecko's cache waits to open the body file descriptor until body consumption begins. So as long as we can perform the CORB check in the renderer process as part of the respondWith() call, then it seems possible to achieve this.

It might be possible for you to do the check in the renderer process, but that defeats some of the benefit of CORB.  Hopefully we can make that unnecessary.

> @csreis storing the response from a fetch() in the Cache API can be done outside service workers too, but yeah, that's roughly what we want to have in the specification around "opaque filtered responses" I think. To make it very clear these need to remain out-of-process for as long as possible.

Again, I think the intention it to keep them out of process entirely, rather than for as long as possible.  Otherwise an attacker could use the cache API to pull whatever they want into their process, correct?  Maybe we can talk with @anforowicz, @nick-chromium, and @mattto about how we're handling it in Chrome.

> I don't think the cache API is part of this. If responses are filtered/blocked as part of fetch, then only correctly filtered/blocked responses will go into the cache.

To be clear, I think we're ok with having blocked responses end up in the cache in general, as long as they're not in the renderer process.

(Sorry if I'm misunderstanding here.)

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