Re: CSP sandboxing and workers

Something like this:

Policies are associated with and enforced or monitored for execution
contexts in the browser. If a resource load does not create a new execution
context, e.g. when a script, img or css file is transcluded, or when a
resource is fetched using an XmlHttpRequest, any policies that resource is
delivered with are discarded, and it is be subject only to the policy or
policies (if any) of the including context.
------------------------------
Resource Type and ContextWhat CSP Policy Applies?text/html, as a top-level
document loaded via navigation or creation of a new browsing contextPolicy
delivered with the resourcetext/html, loaded via XHRPolicy of the context
that performed the fetch<img>, <image>Policy of the including
contexttext/javascript,
via <script src=...>Policy of the including contexttext/javascript, as a
Worker, Shared Worker or Service WorkerPolicy delivered with the resource,
or policy of the creating context if created from a Globally Unique
Identifier URI scheme like data: or blob:SVG, inlinePolicy of the including
contextSVG, as a top-level documentPolicy delivered with the resourceSVG,
as an embedded documentPolicy delivered with the resource, or policy of the
creating context if created from a Globally Unique Identifier URI scheme
like data: or blob:SVG, as a staic or animated image document???SVG, as a
resource documentPolicy of the including contextSVG, as a font
document???<iframe>,
<object> or <embed>What may be embedded is determined by the policy of the
embedding resource, but once instantiated, the execution context is
governed by the policy delivered with the resource, or policy of the
creating context if created from a Globally Unique Identifier URI scheme
like data: or blob:


On Wed, Jun 4, 2014 at 8:06 AM, Brad Hill <hillbrad@gmail.com> wrote:

> I'll make a proposal, I think the discussion on SVG (e.g. whether the
> including context's CSP policy propagates into the SVG execution context)
> will also be relevant here.
>
>
> On Tue, Jun 3, 2014 at 1:45 AM, Mike West <mkwst@google.com> wrote:
>
>> What would you expect such a table to contain?
>>
>> Sorry, I don't think I've understood the points around which you've heard
>> developer confusion, Brad.
>>
>> -mike
>>
>> --
>> Mike West <mkwst@google.com>
>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>>
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>>
>>
>> On Tue, Jun 3, 2014 at 2:47 AM, Oda, Terri <terri.oda@intel.com> wrote:
>>
>>> On Mon, Jun 2, 2014 at 9:04 AM, Brad Hill <hillbrad@gmail.com> wrote:
>>>
>>>> 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.)
>>>> (...)
>>>>
>>>> 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.
>>>>
>>>
>>> +1 to the idea of a table.
>>>
>>> While I haven't directly gotten that question, I could definitely see it
>>> coming up, and I know I have had similar confused questions about same
>>> origin that seem to be answered most clearly with a table.
>>>
>>
>>
>