Pinging this thread again, since the TAG has asked about multi-vendor interest <https://github.com/w3ctag/design-reviews/issues/408>as well recently.
Since I sent the original email, there has also been some discussion within the WebAppSec W3C working group about using Document Policy to deprecate security-negative features on the web platform; +John Wilander <wilan...@apple.com> who may have additional thoughts on the utility of this API from that angle. On Tue, Jul 28, 2020 at 10:02 AM Ian Clelland <iclell...@chromium.org> wrote: > 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-policy-explainer.md > 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/lewQUFlBCQAJ > 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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
