W3C home > Mailing lists > Public > www-tag@w3.org > May 2013

Re: Trimming the SecurityPolicy DOM interface

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 1 May 2013 08:42:37 -0700
Message-ID: <CAPfop_0XBMfmVAfzHcAZ+uqbirEaNhji4bQhuc3tpymE_RJ3UA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>, public-webappsec@w3.org, Alex Russell <slightlyoff@google.com>, Ian Melven <imelven@mozilla.com>, "Eduardo' Vela" <evn@google.com>, Adam Barth <w3c@adambarth.com>
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.
>>>
>>
>>
>
Received on Wednesday, 1 May 2013 15:43:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:00 UTC