Re: CSP3 as a polylithic set of modules?

While I like the maintainability of this proposal, it seems like it might
complicated the versioning that Dev has proposed in the past (that I really
like). Namely, for each sub-spec, you'd have to tie it into a specific CSP
version you'd like it to be in, and tracking all of that information down
across specs might be difficult. But if we want versioning, maybe it's
still worth figuring out how to do it well across distributed chunks like
this.
--Joel

On Mon, Sep 28, 2015 at 2:17 PM Brian Smith <brian@briansmith.org> wrote:

> Mike West <mkwst@google.com> wrote:
>
>> We've had some success splitting out features like Upgrade recently.
>> Perhaps we can go even further to break up our monolith into a set of
>> miniliths that lean on each other in various ways?
>>
>> I have a half-baked idea to split CSP3 into a number of documents along
>> the following lines:
>>
>> * "CSP: Core": defines the headers, their syntax, the general processing
>> model, the binding of policies to Documents and Workers, and provide hooks
>> for the general concept of "violation" and reporting that other documents
>> could poke at (reporting might be worth breaking out into a separate
>> document, actually).
>>
>
> Reporting should be specified, normatively, in Javascript code that uses
> the CSP2 DOM events and XHR to do what browser's reporting modules do. I
> don't think reporting is really "core" to CSP, even though it is a very
> useful feature. In particular, the reporting mechanism only makes sense for
> browser implementations of CSP, but it doesn't really make sense for
> server-side or client-side templating engines that take a CSP to guide them
> in rejecting bad inputs (input-side validation instead of output-side
> validation of CSP). So, I think reporting should be moved out of core.
>
>
>> As a test balloon for this last bit of the proposal, I've sketched out
>> mnot's `cookie-scope` idea as a separate document at
>> https://w3c.github.io/webappsec/specs/csp-cookies/. WDYT? On the one
>> hand, it's pretty small. On the other, perhaps browser vendors could be
>> encouraged to tick a number of tiny checkboxes faster than they might tick
>> a big checkbox, even if the functionality is the same?
>>
>
> The main advantage I see in splitting out features into multiple documents
> is that things that trigger the W3C process causing a document reverting
> back to CR from PR (etc.) would negatively affect smaller pieces.
>
> Since the goal seems to be to prioritize features that browsers should
> implement right away, I think it is worth categorizing features this way:
>
> 1. Features that everybody implements (approximately CSP 1).
>
> 2. Aspects that affect compatibility with CSP-1-only implementations. For
> example, if there are aspects of the CSP 2 syntax that cause CSP-1-only
> implementations to fail to parse the policy, because the policy conforms to
> CSP 2 syntax but not CSP 1 syntax, then these issues should be addressed in
> some way.
>
> 3. Apsects of CSP that are really important for a browser to implement,
> because they cannot be enforced by input-side validation of CSP policy
> conformance (on the server or in JS code implementing a templating engine).
> For example, "frame-ancestor" is very important for browsers to implement
> because it can't be enforced input-side, but new source-list stuff is less
> important because the templating engine can and should have already have
> prevented all that badness in the first place before the browser sees it.
>
> 4. The defense-in-depth features that are redundant with good input-side
> validation practices but which are critical if you have a bunch of terrible
> code sitting on your servers with bugs that you want to use CSP to
> wallpaper over.
>
> Ultimately, I think it is unreasonable to expect web browsers to invest
> time to implement features that just wallpaper over server-side bugs, and I
> think a lot of CSP would actually be classified that way. I think CSP is
> brilliant but I think our emphasis on browser enforcement of CSP policies
> is counterproductive in the long run. Most of CSP should actually be
> enforced by the templating engines. I think the idea of sending a CSP
> header with a bunch of source-list directives for the browser to enforce
> will be considered an obsolete practice in a few years as input-side
> enforcement of CSP gets implemented and deployed.
>
>
>> P.P.S. I'm also starting to think that Brian was right about CSP being
>> better if we lock it down it to purely restrictive directives, and move
>> things like `referrer` out to their own whatever.
>>
>
> Brilliant!
>
>
>> Don't tell him I said so, though.
>>
>
> Will do. He'd never let you forget it. :)
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>