Proposal: Document-Policy available via pragma directive

[issacgerges]

Similar to Content-Security-Policy, Document-Policy should be settable via a meta tag in the head, such as

<meta http-equiv="Document-Policy" content="js-profiling">

This would make it easier for statically served sites (where customization of HTTP headers may be more painful) to opt-in. This would require changes to https://html.spec.whatwg.org/multipage/semantics.html#pragma-directives

[nornagon]

This would also make it easier to test out / use the JS self-profiling API in local development, e.g. when serving with python -mSimpleHTTPServer or npx serve, or when serving from file://.

[bathos]

I’ve found pragma directives significantly increased the fraction of loads where our CSP actually gets applied as authored, fwiw. Stripping or falsifying content-security-policy & x-frame-options headers has become a normal practice in the chrome/ff extension ecosystem even in cases where an extension’s behavior can be realized without doing this. Given extensions also tend to like running sync-xhr in the origin realm (synchronization primitive for the background page? not sure), if document-policy’s adoption increases, it could become another inconvenience and end up in the same boat.

I appreciate that dynamically narrowing policies likely implies considerable spec / implementation complexity and it’s understandable if it’s not deemed worthwhile on balance. However the web’s “opt-in” security / integrity / quality policies can feel a bit hopeless once you begin paying attention to what actually arrives in the browser.