[webkit-dev] Requesting a position on Document Policy

[Ian Clelland]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200728/1c67b97d/attachment.htm>