- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 20 Jul 2015 06:46:25 -0700
- 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. -- https://annevankesteren.nl/
Received on Monday, 20 July 2015 13:46:51 UTC