Re: Trimming the SecurityPolicy DOM interface

WebKit/Blink treats <meta> exactly the same as new HTTP header. You're
correct to say that that's contrary to the spec text.

I think the TODOs in that section make it clear that it's less solid than
other sections; there are some clear use-cases for the behavior Blink
supports that the current spec doesn't provide for, and a lack of consensus
about how to approach them (or whether to support them at all).

Dan (Hi Dan!) is tasked with proposing some new text for that section (
https://www.w3.org/2011/webappsec/track/actions/109 and another I can't
find). Once there's a strawman out there for discussion, I'm hopeful that
we can come to consensus on what exactly <meta> should support, and how it
should work.

-mike

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Wed, May 1, 2013 at 5:42 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> Hi Mike
>
> The current draft says that the policy in the header takes precedence over
> meta tag and the first meta tag takes precedence over others. The meta tag
> is ignored if a policy exists as already
>
>
> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#html-meta-element--experimental
>
> It seems the enforcing multiple policies note is only for multiple CSP
> headers.
>
> Thanks
> dev
> On May 1, 2013 12:29 AM, "Mike West" <mkwst@google.com> wrote:
>
>> WebKit/Blink respects every CSP policy it receives; that is, you can
>> tighten the page's effective policy by adding a new <meta> tag. You cannot
>> loosen an existing policy. See
>> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#enforcing-multiple-policiesfor the rationale.
>>
>> I'm not sure I see the value in allowing script to loosen the resource's
>> existing policy. I understand the use-case, but allowing script on the page
>> to loosen the page's policy seems counter to the main thrust of CSP's
>> protections.
>>
>> On the main point, I do see use cases for some of what Alex has been
>> talking about in previous threads. I'm hoping that those (constructing and
>> querying individual policy objects) are orthogonal to the API that's
>> currently specified in the spec (querying the page's effective policy).
>>
>> -mike
>>
>> --
>> Mike West <mkwst@google.com>, Developer Advocate
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>>
>>
>> On Tue, Apr 30, 2013 at 12:12 AM, Eduardo' Vela <evn@google.com> wrote:
>>
>>> Yes, that's what I'm doing ATM, but WebKit only respects the first CSP
>>> policy it receives, so this only works if the page has no CSP yet.
>>>
>>>
>>> On Mon, Apr 29, 2013 at 12:56 PM, Ian Melven <imelven@mozilla.com>wrote:
>>>
>>>>
>>>> fwiw, CSP in a <meta> tag has also been brought up as an approach to
>>>> that use case (tightening
>>>> the CSP policy after an initial bootstrap phase has loaded a bunch of
>>>> stuff).
>>>>
>>>> thanks,
>>>> ian
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Eduardo' Vela" <evn@google.com>
>>>> To: "Adam Barth" <w3c@adambarth.com>
>>>> Cc: "Alex Russell" <slightlyoff@google.com>, public-webappsec@w3.org,
>>>> "Mike West" <mkwst@google.com>, "www-tag@w3.org List" <www-tag@w3.org>
>>>> Sent: Saturday, April 27, 2013 3:25:48 PM
>>>> Subject: Re: Trimming the SecurityPolicy DOM interface
>>>>
>>>>
>>>>
>>>> And script-subset could allow the policy be subset.. May be useful if
>>>> you want say, load inline scripts at load time, and then lock it down to no
>>>> inline scripts.
>>>>
>>>
>>>
>>