Re: [whatwg/fetch] Split 'document' destination into 'frame' and 'iframe'. (#948)

I'm a little lost about what's trying to be achieved here, so I'm sorry if this is useless:

With service worker, we're happy for a service worker to intercept a request for `<script src="https://example.com">` instead deliver a resource from `evil.com`. The script runs in the context of the page, and the service worker owns the page, so it's only lying to itself.

A service worker on `evil.com` cannot intercept the request for `<iframe href="http://example.com">`, because, as far as I know, this would allow `evil.com` to run content from a different origin within `example.com`.

This means requests which form a client (which have their own CSP, and run against a particular origin based on their final request), will go through a service worker that matches the request scope, rather than the controller of the client that initiated the request.

This all works nicely because we can tell if a response is going to be used to create a client based on the destination. An `<img>` doesn't, an `<iframe>` does, `<script>` doesn't, `new Worker` does etc etc.

We punted on `<object>`/`<embed>` because they're an exception. Here, the type of the *response* judges whether it creates a client or not. `image/jpeg` doesn't, but `text/html` does. This leads to the kind of mess you see in [step 4.9 of the object element](https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element) where it flip-flops around when `<object>` meets appcache.

If we can guarantee in advance whether a `<object>`/`<embed>` resource is going to create a client, we can feed it through service worker, otherwise it feels safest to avoid.

-- 
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/pull/948#issuecomment-544448173