Document Policy and CSP?

[mikewest]

The Document Policy document notes that there's some potential overlap with CSP, at least insofar as the sandbox directive exists. It's not entirely clear to me what DP aims to address, and what its scope actually boils down to, but there might be more overlap. Consider the following:

• script-src offers control over specific APIs like eval() via the unsafe-eval keyword. Similar proposals exist to gate WASM via some other keyword.
• trusted-types controls TT enforcement.
• block-all-mixed-content can be seen as a restriction on Fetch, but it could also be a feature toggle insofar as it sets a flag on the document context.
• upgrade-insecure-requests is similarly situated.
• plugin-types gates <embed> and <object>
• navigate-to aims to address navigation-related issues.

https://github.com/mikewest/csp-next suggests that we should really break these kinds of mechanisms out of CSP, and into something else. That document focuses on script execution, defining a scripting-policy concept that would probably encompass the unsafe-eval bits and maybe the plugin bits? Perhaps Document Policy would be a reasonable home for the rest?

[clelland]

That sounds like a good fit -- with the possible exception of 'navigate-to', which might benefit from CSP's rich source-list syntax. The other directives all focus on what a document can do, once loaded, without necessarily forcing the same restrictions on nested content, which is the model document policy is trying to cover.