W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

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

From: Brian Smith <brian@briansmith.org>
Date: Tue, 17 Feb 2015 10:22:28 -0800
Message-ID: <CAFewVt4HzerkSbvfzcNrBmM8s8YQwDk1L0qnoB077vmc1z5-YQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Jake Archibald <jakearchibald@google.com>, Alex Russell <slightlyoff@google.com>
Mike West <mkwst@google.com> wrote:
> On Mon, Dec 15, 2014 at 3:46 AM, Brian Smith <brian@briansmith.org> wrote:


>> Since window.fetch is almost the same as XHR, it
>> doesn't make sense for window.fetch to have a significantly different
>> mixed content policy than XHR.


> I sympathize with the desire to make the fetch API behave similarly to XHR
> with regard to 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.


> 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?

My understanding from reading the Fetch document is calling fetch()
will initiate a fetch with a context of "fetch", so the rules in cited
will treat all calls to fetch() as blockable mixed content. That is
exactly what I think should happen. However, I'm concerned that we
have arrived at different conclusions having read the same documents.
Why do you think that the fetch context would be anything other than
"fetch" for a call to fetch()?

In any case, it is important that the blocking be done in the "should
block request" stage and not only the "should block response" stage.
One of the main security benefits of blocking mixed content for
XHR/Websockets/fetch() is to limit information leakage from the secure
origin, and we shouldn't lose that by allowing requests from fetch()
to go through.

Received on Tuesday, 17 February 2015 18:22:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC