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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 20 Jul 2015 06:46:25 -0700
Message-ID: <CADnb78jTAbJB0WzQ2ope6JJ=sz4xoQrQ_JQ05smZxNTHhE6qgA@mail.gmail.com>
To: Mike West <mkwst@google.com>
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 Mon, Jul 20, 2015 at 6:39 AM, Mike West <mkwst@google.com> wrote:
> I've added a brief section on this to the security considerations
> (https://w3c.github.io/webappsec/specs/mixedcontent/#service-workers), and
> updated the algorithm at
> https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch.
> Brian, note that this means we really do need the response checking bits
> that you were concerned about earlier.
> If the two of you are happy, then I suppose we can do the back-through-CR
> dance just like we're doing with CSP2. Hooray for process! :)

I just realized "request's client equals request's window" doesn't
work when the Request object is from a different window-global than
where it's used. That is, if the Request object originates from an
<iframe> and you use it in the parent.

I guess we could give fetch() a special context inside service
workers. E.g. "serviceworkerfetch". It might get observable if we ever
do https://wiki.whatwg.org/wiki/Foreign_Fetch but that doesn't seem
too bad? If you want that, please file an issue against Fetch.

Received on Monday, 20 July 2015 13:46:51 UTC

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