Re: new CSP draft.

Hey again,

On Mon, Jan 11, 2016 at 9:43 AM Mike West <mkwst@google.com> wrote:

>
> 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?
>

I think it helps unless there is a reason "serialized CSP list" is
different other than than it being serialized like 'serialized directive'
and 'serialized policy.'


>
>> - 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.
>

Happy to leave separate as you say it's a better extension point. I was
less aware of the multiple policies except in the case when multiple
headers are sent.

To clarify multiple comma separated policies in the serialized policy would
behave the same as '8.1. The effect of multiple policies'? If so I think
additional headers could be described as adding to the 'CSP list'.

That also clears up another error I thought there was :D


>
>
>> - '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'`.
>

Ah makes sense now reading the algo again thanks.


>
>
>> - '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. :)
>

I'll try I noticed that there has been a very old outstanding stack algo
strawman.


>
>
>> - '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 also!