W3C home > Mailing lists > Public > public-web-security@w3.org > December 2011

Re: Workers inheriting CSP

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 8 Dec 2011 18:37:46 -0800
Message-ID: <CAJE5ia8sSuWG0vcx4zCjZPr1WDnHiD4MQLjwQ2oBG+ZrdiKhvw@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: public-web-security@w3.org
On Tue, Nov 29, 2011 at 9:17 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Tue, Nov 29, 2011 at 8:49 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
>> On 11/27/11 3:26 PM, Adam Barth wrote:
>>> The question is only which CSP policy controls the worker.  There's a
>>> choice about whether it's the CSP policy from the document that
>>> spawned the worker or whether it's the CSP policy from the script the
>>> worker is running.  Either is reasonable, the question is which is
>>> better.
>>
>> A worker-supplied CSP seems a bit of a conceptual stretch.
>> Developers are much more likely to think of them as a special kind
>> of <script> than to think they're more like a hidden <iframe>.
>>
>> Or to look at it another way, if Workers have their own policy a
>> page author no longer controls the policy on their own page
>> (although the exceptions would be encapsulated to the Worker). If
>> workers inherit CSP then a page author who needs to run a Worker in
>> a different policy can set up a container <iframe> with that policy
>> and talk to the worker through postMessage() to that frame. Yeah,
>> more async intermediates that way, but is it going to be a common case?
>
> Ok.  That makes sense.  The situation for SharedWorkers is less clear
> because they're less closely associated with the document that creates
> them (they're more like iframes), but that's a bridge we can cross
> when we come to it.

Done: http://dvcs.w3.org/hg/content-security-policy/rev/745be18dc482

Adam
Received on Friday, 9 December 2011 02:38:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 9 December 2011 02:38:47 GMT