Thanks, Anne. 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! :) -mike -- 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.) On Mon, Jul 20, 2015 at 3:08 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Jul 20, 2015 at 6:02 AM, Mike West <mkwst@google.com> wrote: > > The case I'm interested in is a secure document which executes > > `fetch([insecure URL goes here])`. Does the current language block it? I > > believe it does, as the request's `window` will be either `client` or > > `no-window`? Is that how you intended the `window` property to work? > > I see, I didn't mean to block that. But if you want to block that, you > could: "If request's client is request's window, return *blocked*." > > > -- > https://annevankesteren.nl/ >
Received on Monday, 20 July 2015 13:40:10 UTC