Please sort out who's responsible for a srcdoc document's CSP

[bzbarsky]

https://w3c.github.io/webappsec-csp/#initialize-global-object-csp has notes about how this algorithm causes a srcdoc document to alias something. But HTML provides a srcdoc response with a CSP list of its own, which is then not aliased by https://w3c.github.io/webappsec-csp/#initialize-document-csp

Of course https://w3c.github.io/webappsec-csp/#initialize-global-object-csp is never invoked by HTML for the Document case anyway, only for workers, and this algorithm seems to be assuming (but not asserting!) that anyway, so I'm not sure what this note is really trying to say.

// cc @mikewest

[annevk]

Instead of "alias" we should really use "shared" (or even better, a pointer to an object which is described as being capable of being used by multiple other objects) or "copy".

[annevk]

(The pointer approach is what we use for origins these days, which used to use the rather confusing "alias" concept.)

[mikewest]

Yeah. It looks like this shifted around a bit and I did a bad job cleaning up afterwards.

The goal is for documents whose URLs have "local schemes" (e.g. data:..., blob:..., about:blank, about:srcdoc, etc) to be restricted by the policy of the page into which they're embedded, or the page which opened them in a new window. We don't do this clearly today, I agree. Skimming the various algorithms:

1. I think we need to keep the CSP list transition to the response generated for an overridden reload in https://html.spec.whatwg.org/#an-overridden-reload.

2. I think we can drop the CSP list alias in the response generated by the srcdoc case in https://html.spec.whatwg.org/#process-the-iframe-attributes, and allow the "Initialize a Document's CSP list" algorithm in CSP to handle it.

3. "Initialize a global object's CSP list" can be narrowed to "Initialize a worker's CSP list" (we used to call it from "Initialize a Document's CSP list", which explains some of the crufty comments).

Sound reasonable?

[bzbarsky]

The goal is for documents whose URLs have "local schemes" (e.g. data:..., blob:..., about:blank, about:srcdoc, etc) to be restricted by the policy of the page into which they're embedded, or the page which opened them in a new window.

I thought about this some more this morning, and I think this goal is misguided. I filed #211 with an explanation of why it's misguided.

For purposes of this bug, your step 3 makes sense. Your step 2 does NOT make sense to me per #211 and in fact we should be moving the opposite direction, imo: propagating CSPs along with request/response stuff. Your step 1 probably makes sense insofar as any of "overridden reload" makes sense (e.g. its use of "active document", if correct, makes the CSP list bits correct; if that part is wrong then the whole algorithm is wrong).