W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: Clarification of CSP sandbox and workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 12 Nov 2014 09:45:40 +0100
Message-ID: <CADnb78ieKcTgQz7s06zrhSE3Z6edeuN502w6zPFoXuL5MTrf2Q@mail.gmail.com>
To: Deian Stefan <deian@cs.stanford.edu>
Cc: WebApps WG <public-webapps@w3.org>, WebAppSec WG <public-webappsec@w3.org>, Ian Hickson <ian@hixie.ch>
On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan <deian@cs.stanford.edu> wrote:
> I am implementing CSP for Workers in Firefox, but like to get a
> clarification on workers and the sandbox flag. Currently, a Worker can
> inherit or be accompanied by a CSP header. As written, the implications
> of the sandbox directive on the Worker context is not clear.
> [Following up on https://github.com/w3c/webappsec/issues/69]
> Arguably most of the sandbox flags don't make sense for Workers, but the
> empty directive (i.e., just sandbox) and sandbox allow-same-origin can
> have reasonable semantics.  So, if a Worker inherits the CSP from the
> owner document (or parent worker in later specs) or is accompanied by a
> CSP header which has the 'sandbox' directive, should the worker script's
> origin be set to a unique origin?  Or should we just ignore (and
> appropriately warn about) the sandbox flag for Workers and address the
> need for sandboxed Workers separately?

This would affect what a worker can fetch, what storage it has access
to, and which permissions it has (e.g. can it display a notification).
Might be an interesting way to run untrusted code.

But if we are going to do something like this Ian would have to define
how the sandbox directives affect a worker environment.

Received on Wednesday, 12 November 2014 08:46:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC