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

Re: Using CSP

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 20 Jul 2011 00:06:53 -0700
Message-ID: <CAJE5ia-tEmk+0mm-Cki+HJ81pfm-FXAG=Jc3uK2MxKxfK88AwQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: public-web-security@w3.org
On Tue, Jul 19, 2011 at 11:14 PM, Mark Nottingham <mnot@mnot.net> wrote:
> On 20/07/2011, at 3:35 PM, Adam Barth wrote:
>>>
>>> - An example of the 'options ...' syntax in the spec would help; I had to look at the BNF before I realised I couldn't just put a bare 'inline-script' directive in the header.
>>
>> The "options" syntax got removed at some point.  I think Brandon is
>> updating the Firefox implementation to the new syntax.
>
> Hmm. If the syntax is still evolving in non-backwards-compatible ways, it might be better to use a nonsense or generated header name, and revise it on each bump, so that sites that experiment with CSP don't have problems with supporting multiple incompatible deployed protocols.

Hence the goofy "X-WebKit-CSP" name.  :)

Adam


>>> One follow-up to that; I haven't enabled reporting yet, but if I did, I'd be flooded by reports of this. Having some mechanism to squelch a particular warning would be nice.
>>
>> Any suggestions on how to accomplish that?  In some sense, it's not
>> that much extra traffic.  You'd get just as much extra traffic by
>> including one additional image on your page.  You can always filter at
>> the server.
>
> True; I'm not sure the extra complexity is worth it, unless you can slot in a modified syntax for rules that says "don't report this one." There's already seemingly a use case for only warning on a violation (the alternate header name), so having a way to put in modifiers like this could be useful in other places too.
>
> something like (using ABNF):
>
>  source = [ modifier ]  "self" / scheme ":" host  [ ":" port ]
>  modifier = "^" // do not report
>                  / "?"  // warn only
>
> etc.
>
>
>>> - I tried adding a X-WebKit-CSP header with the same policy on the front page, but Chrome behaved differently; e.g., it didn't want to load a local .js, even though that's allowed by the policy.
>>
>> If you send me a reduced test case of the issue you're running into,
>> I'd be happy to fix it.
>
> Will see what I can do.

Thanks.

Adam
Received on Wednesday, 20 July 2011 07:07:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 07:07:56 GMT