W3C home > Mailing lists > Public > public-web-security@w3.org > July 2011

Re: Using CSP

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 20 Jul 2011 15:56:53 +1000
Cc: Adam Barth <w3c@adambarth.com>, public-web-security@w3.org
Message-Id: <226E5551-810E-40CE-B033-687182F4BB2C@mnot.net>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
On 20/07/2011, at 3:48 PM, Devdatta Akhawe wrote:

> On 19 July 2011 22:35, Adam Barth <w3c@adambarth.com> wrote:
>> On Tue, Jul 19, 2011 at 9:27 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> I just spent a small amount of time putting CSP onto my private site, <http://www.mnot.net/>.
>>> A few quick impressions, FWIW (yes, I realise it's still very much a work-in-progress):
>>> - Based on how the spec is written, I expected to be able to use multiple HTTP headers to refine policy; e.g., have a 'base' policy of "allow 'self'", and then in subdirectories add options, etc. as appropriate. However, in practice, this didn't seem to work; weird errors kept on coming up in the console (FF5 and Aurora), so I had to put the entire policy in one header, leading to lots of repetition.
>> WebKit doesn't implement policy refinement either.  It uses the simple
>> "first policy wins" approach.
> Even if it did implement refinement, I don't see how Mark's use case
> would have worked. CSP mandates intersection based refinement. Or in
> the words of the spec
> "no action can be taken by the user-agent when rendering the protected
> document unless every policy directive of every policy header received
> permits such an action."
> Thus, Mark can't really keep refining his policy in subdirectories. If
> the first policy didn't allow something, then no additions can make
> the policy more open.

That makes sense when I think about it. Policy intersection is always rough; perhaps some more examples would help. 


Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 20 July 2011 05:57:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC