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

On Tue, Feb 17, 2015 at 7:22 PM, Brian Smith <brian@briansmith.org> wrote:

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


That's a correct understanding of the draft that's up for review, and is
the way Fetch is currently implemented in Chrome.


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

There's a proposal floating around to allow a "no-cors" fetch to be treated
as optionally-blockable content. We'd likely need to split the contexts, in
the same way we've done for `<img>` and `<picture>`.

As a "no-cors" fetch returns an opaque blob to the page, it wouldn't be
useful for much of anything other than media (and would therefore be just
as dangerous as an image). Since media is one of the major blockers to
getting some folks onto HTTPS, it seems like that might be a compromise
worth making in MIX2.

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

I don't think I disagree with you, but I'd like to know what information
leakage you're most concerned with (and to whom). Referrer information?
Cookies? Intentional exfiltration via GET/POST params?

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