W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: CSP sandboxing and workers

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 2 Jun 2014 09:04:46 -0700
Message-ID: <CAEeYn8i1+nROm81-VTZksZObev17U-ocy2j5He0K+3_kBEGdWg@mail.gmail.com>
To: Mike West <mike@mikewest.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>, Ian Hickson <ian@hixie.ch>
A wider point of possible confusion here - we need to make sure
developers understand they can't use CSP to enforce restrictions like
sandboxing on a script file.  (I've had very smart people ask me about
this in the past - the model of what is a "resource" from the
browser's internals is not immediately obvious to everyone.)

We're discussing the different kinds of "environments" defined by HTML
over on the mixed-content thread, perhaps that's a useful reference
point here, too?

Among "JavaScript global environment", "document environment",
"dedicated worker environment", "shared worker
environment", and "worker environment", where does CSP state live and
what loads get to influence it?  Maybe a table would be helpful.

On Sun, Jun 1, 2014 at 2:46 AM, Mike West <mike@mikewest.org> wrote:
> I could certainly see value in sandboxing a worker, at least for the
> 'allow-same-origin' bits. I'm not sure how applicable the other flags are.
>
> -mike
>
>
> On Sun, Jun 1, 2014 at 10:04 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>
>> We should note in the specification that sandboxing only has effect
>> when CSP applies to a global environment associated with a browsing
>> context. It wouldn't apply to workers or e.g. a document fetched
>> through XMLHttpRequest.
>>
>> However, we might want to have it apply to workers, maybe we should
>> introduce that?
>>
>>
>> --
>> http://annevankesteren.nl/
>>
>
Received on Monday, 2 June 2014 16:05:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC