On Mon, Jul 20, 2015 at 3:46 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > 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. > As the guy who would need to add it to Fetch, would you prefer splitting that request context, or would you prefer that MIX check that the client was an environment settings object whose global object was a Window and not a Worker? I think I'm fine either way. -mike
Received on Monday, 20 July 2015 14:11:52 UTC