- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 30 Sep 2013 21:15:18 +0000 (UTC)
- To: Kyle Huey <me@kylehuey.com>
- cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Sid Stamm <sstamm@mozilla.com>, Daniel Veditz <dveditz@mozilla.com>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>, Adam Barth <abarth@eecs.berkeley.edu>
On Thu, 26 Sep 2013, Kyle Huey wrote: > > It's unclear how SharedWorkers should interact with Content Security > Policies. This came up during code review of the SharedWorker > implementation in Gecko[0]. There was a public-webappsec thread[1] on > this back in May that didn't really reach a conclusion and I'd like to > drive towards one here. What is the goal of applying CSP to workers? Like, what are the security concerns we'd be blocking? Many of the things CSP does to Documents don't seem to apply to Workers. (I'm just trying to understand the problem space here, not saying CSP is not applicable at all or anything.) > It seems like the best solution to this problem is to associate a CSP > directly with the worker from the headers served when the JS file for the > worker is shipped down. Seems reasonable. > If we choose to do this we should also think about whether we should do > the same for regular workers. The same JS file and the same headers > being run under different policies if you do Worker(foo.js) and > SharedWorker(foo.js) seems unexpected. We could make regular workers > default to the document CSP if nothing is specified for backwards > compatibility. Fine by me. I'll let Adam and the CSP guys make the final call on this; let me know if I need to update the HTML spec at all. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 30 September 2013 21:15:41 UTC