- From: Brad Hill <hillbrad@gmail.com>
- Date: Mon, 2 Jun 2014 09:04:46 -0700
- 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