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

Re: CfC: Mixed Content to PR; deadline July 6th.

From: Mike West <mkwst@google.com>
Date: Thu, 30 Jul 2015 10:43:26 +0200
Message-ID: <CAKXHy=don7VCtR-eWQ6CfF7D6fVqiuCZUpv=RU5xW5mMJj=hGQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Brian Smith <brian@briansmith.org>, Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Kristijan Burnik <burnik@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Alex Russell <slightlyoff@google.com>, Ryan Sleevi <sleevi@google.com>
On Thu, Jul 30, 2015 at 10:24 AM, Anne van Kesteren <annevk@annevk.nl>

> On Thu, Jul 30, 2015 at 9:59 AM, Mike West <mkwst@google.com> wrote:
> > Anne: I'm not sure what you meant by "I suppose it won't always disallow
> > that". When would we want to allow insecure responses to secure
> requests? I
> > don't think that's something we've discussed, nor is it something I
> think is
> > terribly appealing.
> If you have
>   <img src=https://example.com/x>
> and the service worker replies with
>   e.respondWith(fetch("http://unsafe.example/x", {mode:"no-cors"}))
> there's nothing really that prevents that.

Doesn't the set of `window` checks and associated copy behavior that we
discussed prevent this? That is, `fetch(e.request)` works because it copies
the window object rather than setting `no-window`. This code would set
`no-window`, and would therefore fail.

Have I misunderstood the algorithm in Fetch?


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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 30 July 2015 08:44:15 UTC

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