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