- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 29 Jul 2014 09:19:48 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Joshua Peek <josh@joshpeek.com>, Mike West <mkwst@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Ilya Grigorik <igrigorik@google.com>, Jeffrey Yasskin <jyasskin@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jake Archibald <jakearchibald@google.com>, Alex Russell <slightlyoff@google.com>
Well, a non-same-origin service worker doesn't make sense anyway, and
neither do any of the current sandbox directives, so I'm not sure
there is a good case for using sandbox on service workers except in
this manner to disable them.
On Tue, Jul 29, 2014 at 9:12 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Jul 25, 2014 at 12:05 AM, Joshua Peek <josh@joshpeek.com> wrote:
>> Couldn't CSP sandbox apply to service workers?
>>
>> GET https://raw.githubusercontent.com/worker.html
>> navigator.serviceWorker.register('worker.js').
>>
>> GET https://raw.githubusercontent.com/worker.js
>> Content-Security-Policy: sandbox
>>
>> I'd expect the registration to fail since `worker.js` should be
>> considered a separate origin.
>
> But that does seem a bit weird as sandboxing would then only work for
> workers if you use allow-same-origin, which seems rather confusing.
> How would you envision sandboxing for workers to work in general?
>
>
> --
> http://annevankesteren.nl/
>
Received on Tuesday, 29 July 2014 16:20:16 UTC