- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Mon, 01 Dec 2014 14:04:49 -0800
- To: Brad Hill <hillbrad@fb.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
- Message-ID: <877fyb2fi6.fsf@stmarks.lan>
Brad Hill <hillbrad@fb.com> writes: > We talked on list in the past about using CSP + sandbox to disable > ServiceWorkers. > > I'd like to propose adding the following normative note to the sandbox > directive > In CSP. I believe this is already implied by: > > https://w3c.github.io/webappsec/specs/content-security-policy/#which-policy > -applies > > but it would be good to make it specific as all the sandboxing algorithms > we > reference only apply to Documents, not "headless" script execution > contexts. > > > Proposal: > ====================== > > Note: When delivered via an HTTP header, a Content Security Policy may > indicate > sandboxing be applied to a JavaScript execution environment that > is not an HTML Document. One such scenario of particular interest is > script > content intended to be used for the creation of a Web Worker, Shared > Worker or > Service Worker. While many of the sandboxing flags do not apply to > such > environments, if the sandbox directive delivered with the resource > used > to create a worker implies the <code>sandboxed scripts browsing > context flag</code>, or, if the sandbox directive delivered with > such a resource implies the <code>sandboxed origin browsing context > flag</code> and the creation of the new execution context requires > it be same-origin with its creating context, abort the processing > model > for the creation of the new script environment with a network error. I support something along these lines. I do have a question: for Workers wouldn't this always imply that you can't create a Worker with a fresh origin? (I am happy to discuss sandboxed workers as a separate feature.) Deian
Received on Monday, 1 December 2014 22:05:18 UTC