Hi WebKit! I'm building out the infrastructure in Blink for Document Policy, and would like to ship at least part of it in Chrome for developers to take advantage of. I'd like to get an official position from WebKit leads on this. I'm also interested in getting thoughts from other WebKit folks about the design or implementation. Some details: Document Policy explainer: https://github.com/w3c/webappsec-permissions-policy/blob/master/document-pol... Document Policy spec: https://w3c.github.io/webappsec-permissions-policy/document-policy.html GitHub Repository (shared with Permissions Policy (previously Feature Policy)): https://github.com/w3c/webappsec-permissions-policy Blink intent-to-ship discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/Za159T1QOek/m/lewQUFl... Also previously discussed at the TAG: https://github.com/w3ctag/design-reviews/issues/408 I think that the last time I brought this to WebKit engineers would have been at TPAC last year, where it was discussed in the WebAppSec meetings as a way to provide a general configuration mechanism for documents, splitting off of ideas that had been floating around at the time for Feature Policy. While Document Policy itself doesn't prescribe any actual features, it could eventually be used to configure the behaviour of different web-platform features, such as: - Restricting the use of poorly-performing images - Disabling slow synchronous JS APIs - Configuring frame, image, or script loading styles - Restricting overall document sizes or network usage - Restricting patterns which cause page re-layout The initial intent, though, is to ship part of this in Chrome to support an opt-out for the Scroll-to-text-fragment feature. Document Policy has two different mechanisms which can work in conjunction with each other: The first is the Document-Policy (and Document-Policy-Report-Only) HTTP header, which just sets the policy on the document it ships with. The other is a negotiation mechanism between an embedder and its embedded content, which uses an Iframe attribute and an additional request header. I'm currently interested in shipping just the first of these mechanisms in Chrome. The second may warrant more discussion and review, and isn't needed for the Scroll-to-text-fragment opt-out. The details are in the Chrome Platform Status entry: https://www.chromestatus.com/feature/5756689661820928 Feel free to ask any questions; I'm happy to discuss this in whatever forum works best for folks, Thanks! Ian