Re: some further Comments on Content Security Policy 1.0 Editor's Draft

On Tue, Jul 3, 2012 at 4:41 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
>
>> On Tue, Jul 3, 2012 at 1:52 PM, =JeffH <Jeff.Hodges@kingsmountain.com>
>> wrote:
>>> when reviewing the recent "CSP 1.1: More granular source list
>>> definitions"
>>> thread, I had these questions regarding CSP 1.0...
>>>
>>> 1. unless I've missed it, there does not appear to be any suggestion in
>>> the
>>> spec regarding whether the user agent to log and/or report CSP Policy
>>> parse
>>> errors, nor discussion whether a directive with a source-expression
>>> violating the grammar -- such as Odin's example..
>>>
>>>   script-src: http://my-site.com/js/
>>>
>>> ..which a lenient parser would likely match to the host-source production
>>> --
>>> must/should be enforced or ignored by the user agent.
>>
>> There's no requirement to log errors to the console, but a bunch of
>> implementations do.  I guess we could send violation reports, but
>> logging to the developer console seems to be effective in helping
>> folks author good policies.
>
> understood. In any case, the spec is silent about parsing errors AFAICT
> (yes?).  Mentioning them (in the framework section), and their ramifications
> would be a good idea it seems.

There isn't a notion of a parse error in the spec.  There's the set of
strings that servers ought to generate and a requirements for how user
agents must interpret every possible input.

> Plausibly, given the present spec language, might one implementation chose
> to successfully honor something like "script-src: http://my-site.com/js/" as
> "script-src: http://my-site.com", while another impl doesn't honor it at all
> due to not strictly matching the host-source production?  If so, the spec
> should probably stipulate behavior.

The requirement in the spec allow only one interpretation of every
possible input string.  The algorithm given is complete and defines
behavior for every case, leaving no room for interpretation.

> Also, proposing (very simply) how parse error occurrences might be conveyed
> ("via user agent error console") in the Implementation Considerations
> section, is perhaps worthwhile. This sort of impl suggestion is made in
> various other specs. Of course adding it formally to violation reports is
> more work, and I'm not suggesting that (was just an idea).

Sure.  Our experience is that these sorts of developer console
messages are helpful for folks writing policies.

Adam


>>> 2. Why does the directive production have a rigid requirement on one
>>> space
>>> char between directive-name and directive-value ?  given that directives
>>> have the ";" separator, why not..
>>>
>>>   directive         = *WSP [ directive-name [ 1*WSP directive-value ] ]
>>>
>>> which is more lenient for site operators to get right?
>>
>> It's just to make the parsing unambiguous.
>
> yeah, i see that in step 2.3 of "parse a CSP policy"
>
>
>> Notice that source-list
>> allows leading WSP, which means any non-zero amount of WSP is allowed
>> here anyway.
>
> doh.  nevermind.
>
>
> =JeffH
>
>
>
>
>
>
>
>
>
>

Received on Wednesday, 4 July 2012 01:38:28 UTC