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 07:29:12 UTC