- From: Kyle Huey <me@kylehuey.com>
- Date: Thu, 26 Sep 2013 11:00:55 +0800
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Cc: Sid Stamm <sstamm@mozilla.com>, Daniel Veditz <dveditz@mozilla.com>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>
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. Because CSPs are associated with a document, and multiple documents can connect to the same SharedWorker, it is unclear which CSP should be used by a SharedWorker. Furthermore, there are plans to introduce Service Workers ( *née* Event Pages) which come into existence before any document exists for the origin at all. 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. Giving them their own CSP solves the "what CSP do I use" problem. I don't have strong feelings about whether or not we should deny a page with a more liberal CSP from connecting to a SharedWorker with a more strict CSP, but I suspect others might. 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. Thoughts? - Kyle [0] https://bugzilla.mozilla.org/show_bug.cgi?id=643325 [1] http://lists.w3.org/Archives/Public/public-webappsec/2013May/0054.html
Received on Thursday, 26 September 2013 03:01:20 UTC