Initializing a document's CSP list requires synchronous cross-process access

[bzbarsky]

https://w3c.github.io/webappsec-csp/#initialize-document-csp step 1.1 examines "request’s client’s global object’s CSP list". The request's client's global object can be in a different process in a variety of cases: noopener/noreferrer loads, sandboxed documents with process-per-origin, data: documents with process-per-origin, etc.

I thought this had been discussed before and what Chrome actually does is store a snapshot of the client's CSP on the load and then initialize from that, but I can't find an existing issue tracking this. If that's what Chrome does (and this is what I think I'd like Firefox to do), then it's observably different from the spec as written right now if the CSP of the client global is mutated (via <meta>) between the load start and the initialization of the resulting document, and we should be able to write tests for this...

@annevk @mikewest @andypaicu @ckerschb @dveditz

[annevk]

So I found #273 which clarified the copy behavior.

But there's also these unresolved issues around this elsehwere:

• Move CSP monkey patches into HTML. whatwg/html#271
• Co-locate text on inheriting origins, HTTPS state, CSP and possibly document,s URL whatwg/html#856
• Creator browsing context state whatwg/html#2508
• How should javascript: navigations interact with CSP? whatwg/html#2589
• Should about:blank inherit CSP in addition to origin? whatwg/html#2592
• Should blob: inherit CSP in addition to origin?  whatwg/html#2593

https://w3c.github.io/webappsec-csp/#initialize-document-csp step 1.1 examines "request’s client’s global object’s CSP list".

Now, that section seems to have been replaced by https://w3c.github.io/webappsec-csp/#run-document-csp-initialization.
That doesn't examine "request’s client’s global object’s CSP list" any longer. The "request’s client’s global object’s CSP list" is still accessed by https://w3c.github.io/webappsec-csp/#should-block-navigation-request; so this might still be an issue.

The request's client's global object can be in a different process in a variety of cases: noopener/noreferrer loads, sandboxed documents with process-per-origin, data: documents with process-per-origin, etc.

I thought this had been discussed before and what Chrome actually does is store a snapshot of the client's CSP on the load and then initialize from that, but I can't find an existing issue tracking this. If that's what Chrome does (and this is what I think I'd like Firefox to do), then it's observably different from the spec as written right now if the CSP of the client global is mutated (via <meta>) between the load start and the initialization of the resulting document, and we should be able to write tests for this...

@annevk @mikewest @andypaicu @ckerschb @dveditz

[antosart]

It's not clear to me what the issue is, can you help clarify? I believe Chrome currently correctly implements the spec wrt the navigational check. The initiator's CSP (i.e. request's client's global object's CSP list) is snapshotted when the navigation is initiated).

[bzbarsky]

@antosart The issue is that the spec, when it talks about "request’s client’s global object’s CSP list", is currently talking about at the list at the point in time when it talks about it, not when navigation started.

Since the lists are mutable, snapshotting the list at start of navigation is not in fact a correct implementation of the spec as it was when this issue was filed.

[antosart]

I believe this has been fixed by #692.