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

+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.)