New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please sort out who's responsible for a srcdoc document's CSP #209
Comments
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". |
(The pointer approach is what we use for origins these days, which used to use the rather confusing "alias" concept.) |
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.
Sound reasonable? |
As discussed in #209, we haven't done a good job keeping these algorithms up to date. This patch cleans them up, and a subsequent patch will adjust HTML accordingly.
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). |
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
The text was updated successfully, but these errors were encountered: