W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

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

From: Mike West <mkwst@google.com>
Date: Mon, 15 Dec 2014 12:25:48 +0100
Message-ID: <CAKXHy=fiaxiSspkwU5dR7ctpXzGTB=rKHS6+M8nYurJ+t3LG7w@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
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>
+Anne, Jake, Alex for the SW discussion.

On Mon, Dec 15, 2014 at 3:46 AM, Brian Smith <brian@briansmith.org> wrote:
>
> 4. In [5] and [6], I suggested changing the rules for ServiceWorkers.
> As I said before, I agree that my initial proposal was unnecessarily
> heavy-handed. However, I made a follow-up suggestion that allows a
> ServiceWorker to avoid breaking a page that has mixed content, without
> allowing window.fetch to become a new vector for mixed content
> vulnerabilities. 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. This is a fundamental problem with the
> current draft that hasn't been sufficiently addressed.
>
> [4] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0249.html
> [5] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0282.html
> [6] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0283.html


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.

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.

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?

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 15 December 2014 11:26:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC