Re: Service Workers and MIX (was Re: MIX: Exiting last call?)

On Mon, Dec 15, 2014 at 12:25 PM, Mike West <mkwst@google.com> wrote:
> I sympathize with the desire to make the fetch API behave similarly to XHR
> with regard to mixed content.

I don't think we can compare fetch() to XMLHttpRequest since it allows
a thing XMLHttpRequest does not, making cross-origin fetches with mode
"no-cors".

And I think only for that mode are we considering the ugly https ->
http allowance.

(In particular I would expect <img crossorigin> to never allow Mixed Content.)


> The conversation on
> https://github.com/slightlyoff/ServiceWorker/issues/493 seems to have
> stalled, and it's not clear to me what the current state of implementation
> is in Chrome or Firefox.
>
> Past conversations to the side, I don't see value in allowing `fetch()` to
> grab insecure resources, for the same reasons that we don't allow XHR to
> grab insecure resources. I don't think there's any disagreement on this
> point with regard to `fetch()` in the context of a Document.

I'm not sure that's the case. Along with fetch() we also have a Cache
API that follows similar semantics. It would be weird for that cache
API to act differently depending on the environment you invoke it
from. I think the same goes for fetch() to some extent. The basic flow
of obtaining a response and feeding that to some element that needs it
will not always require a service worker as middle man.


> The debate comes up in the context of a Service Worker, where `fetch()`
> might be used to grab a new response to a request which ought to be cached
> and returned to a Document for rendering/execution. Grabbing insecure
> resources in response to requests that we know are going to be treated as
> optionally-blockable seems like a reasonable thing to want to do. Caching
> those responses likewise. I'm less enthusiastic about just grabbing insecure
> resources via Fetch outside the context of a request with a specific
> context.

The cache API allows that kind of thing already, no? And we don't do
anything with the context at the moment other than give it to CSP for
checks. It's not something we couple with the response.


> That said, if we an assume that Fetch sets the TLS-state of the response
> correctly, the page would continue to be protected from "bad stuff" by the
> logic in
> https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-response;
> insecure images would be displayed, insecure scripts would be blocked.
>
> Does that sound workable?

That makes sense to me, even though I'm not a fan, but I can see how
service workers is already hard with TLS, requiring no Mixed Content
in addition might be a bridge too far.


-- 
https://annevankesteren.nl/

Received on Tuesday, 16 December 2014 10:55:50 UTC