CSP3 as a polylithic set of modules?

I've been thinking a little bit about CSP2, and that fact that the bits I
considered most important (nonces and hashes) are taking a little while to
gain implementations across modern browsers.

I think at least part of the cause boils down to the monolithic nature of
the spec that Mark Nottingham and Travis Leithead (and, I suppose, the TAG
by proxy) identified in
https://github.com/w3ctag/spec-reviews/issues/42#issuecomment-143102301.
Implementing nonces isn't "Implementing CSP2", and that might make it more
difficult to a) tease out the interesting bits, and b) fit into the
schedule. Also, the document is huge.

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

* "CSP: Script Interface": This would define the DOM events from CSP2, and
the magical new explains-everything API that will be part of CSP3.

* "CSP: Resource Loading": defines the "Source List" syntax, processing,
and matching, as well as the `*-src` directives. I guess we'd stuff and
`plugin-types` in here as well.

* "CSP: Document State": defines directives like `sandbox`, `base-uri`,
`form-action`, `frame-ancestors`, and whatever we come up with to lock down
`document.domain`.

* "CSP: Upgrade": defines `upgrade-insecure-requests"

* "CSP: {1,n}" defines whatever else we come up with.

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?

-mike

P.S. Brian, of course, did all of this before in
https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0083.html,
and I mostly ignored it. Sorry, Brian!

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. Don't tell him I said so,
though.

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)