Re: new CSP draft.

On Sun, Jan 10, 2016 at 3:32 AM, Jonathan Kingston <jonathan@jooped.co.uk>
wrote:

> Hey all and Mike,
>
> I found a few nits after picking it apart on the plane, I'll raise one bug
> for them as all minor.
>
> Parts that I can remember from picking through that stuck out:
>
> - Policy list and CSP list seem to be used interchangeably is that
> correct, they can be unified? (Granted one is a serialised list but source
> list and policies follow that trend)
>

I think "policy list" only occurs in the term "serialized policy list".
That's one concept.

"CSP list" is something associated with a request or execution concept.
That's a different concept. Since it's defined in Fetch and HTML, we
decided to be a little more specific than "policy" with the name. I suppose
we could call "serialized policy list" "serialized CSP list" instead.
*shrug* Would that be helpful?


> - It's also not clear to me when '2.1.2. Parse a serialized policy list'
> would ever be used.
>

It's called to parse the `Content-Security-Policy` header (in
https://w3c.github.io/webappsec-csp/#set-response-csp-list). Basically, a
CSP header contains a number of policies, separated by a comma. This
algorithm breaks that list into individual policies, and parses each using
https://w3c.github.io/webappsec-csp/#parse-serialized-policy. I'm willing
to believe that there's no need to distinguish those steps as distinct
algorithms, but I wonder if there are cases where we really want to refer
to the "parse _a_ policy" algorithm vs the "parse this header" algorithm. I
think there might be.


> - '2.1.1. Parse a serialized policy' mentions the following:
> "If policy’s directive set contains a directive whose name is directive
> name, skip the remaining substeps and continue to the next item."
> This isn't clear to me on the intent of why it was skipped. Is it that the
> value was unparsable or the name wasn't matched?
>

This happens in the case where a directive is specified more than once in a
particular policy. The existing error-handling behavior is to accept the
first directive and reject the repetition. That is, `script-src 'none';
script-src whatever.com` will be treated as `script-src 'none'`.


> - 'Issue 1: Is this kind of thing specified anywhere? I didn’t see
> anything that looked useful in [ES2015].'
> Nope this is actually non standard, I have always wanted standardised
> error codes etc that are unique and not impacted by user language. I'm
> happy to start a draft strawman proposal if you would like that?
>

Feel more than free. :)


> - 'The defined directives fall into one of several categories:' - this
> probably needs a issue by it to define those categories.
>

https://github.com/w3c/webappsec-csp/commit/b313a0de87bec1a59f84d192082e32a1a2badb9d

Thanks for taking the time to review the document!

-mike