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

Re: Workers inheriting CSP

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 29 Nov 2011 09:17:09 -0800
Message-ID: <CAJE5ia8D4YVPS4KLKFn+ibuzoouXPmT3uF3UOwzGgopBsf-CUg@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: public-web-security@w3.org
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.

Received on Tuesday, 29 November 2011 17:18:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:28 UTC