- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 20 Jul 2011 15:56:53 +1000
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Adam Barth <w3c@adambarth.com>, public-web-security@w3.org
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. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 20 July 2011 05:57:24 UTC