Modified initialized document's CSP to match changes in CSP spec #4190
Conversation
| data-x="concept-response">response</span> used to generate the document. <ref spec="CSP"></p> | ||
| algorithm on the <code>Document</code> object, the <span data-x="concept-response"> | ||
| response</span> used to generate the document, and the <span data-x="concept-request"> | ||
| request</span> used to generate the document. <ref spec="CSP"></p> |
There was a problem hiding this comment.
Can we simply pass response and request here? It's not clear to me why the original text uses concept-response. Also, does CSP anticipate request sometimes being null?
There was a problem hiding this comment.
I've modified it.
CSP does not anticipate the request being null. I've tried but failed to follow in which situations the request is null. From what I can tell, step 13 here could call process a navigation response with a null request but it's not clear to me in which situation this would occur. When is navigation called with a response-type resource?
There was a problem hiding this comment.
srcdoc uses this. There was also a document.open() situation, but that got removed. I thought javascript: used it too, but that seems to pass along the request as well.
There was a problem hiding this comment.
That is concerning because srcdoc is one of the scenarios where we want to inherit from the navigation initiator. What serves as the source browsing context for srcdoc navigations?
There was a problem hiding this comment.
That's a distinct argument to the navigation algorithm not carried by request. Though note #1130. It should probably be "source document" or some such.
There was a problem hiding this comment.
Yeah, I meant that https://html.spec.whatwg.org/#process-the-iframe-attributes does not make it clear what the source browsing context (or the navigation initiator, as it makes more sense in my head) for a srcdoc navigation is. And https://html.spec.whatwg.org/#navigate does not explain anything other than that it involves a source browsing context.
Looking at it again it seems like the node document's CSP list is cloned onto the response's CSP list which seems to imply that the navigation initiator is always the embedding document. I'm not entirely sure this is correct. What if a different context sets the srcdoc attribute on a frame? It's possible that this was relying on the old parent/opener inheritance model that I'm trying to change.
There was a problem hiding this comment.
I'm not sure, you'd have to test I'm afraid.
There was a problem hiding this comment.
I will update the CSP spec to be able to handle a null request. For now the existing srcdoc behavior is fine.
|
Also, should this really be something like "run XXX with AAA, BBB, and CCC"? We're not executing it upon the passed arguments, are we? |
I'm happy to use whatever terminology seems most appropriate. The CSP spec says: What should it be then, something like |
|
Yeah, but we use "run" rather than "call" normally. |
|
I've changed it to |
|
Yeah I'm in the process of adding general inheritance tests as part of https://chromium-review.googlesource.com/c/chromium/src/+/1314633 Specific tests for the srcdoc case discussed above are also in progress: https://chromium-review.googlesource.com/c/chromium/src/+/1350889 The tracking issue is w3c/webappsec-csp#364 where I've added a comment about what needs to be updated in CSP. |
Slight changes in the initialize a document's CSP call parameters have been made in the CSP spec
w3c/webappsec-csp#358
and later
w3c/webappsec-csp#365
This PR mirrors those modifications.
Tracking issue w3c/webappsec-csp#364