Re: [webkit-dev] Request for position on Reporting API (now with structured headers!)
Hi WebKit -- I sent this request out some time ago, but we're getting closer to shipping, and I'm wondering if there's a position I can refer to on the updated Reporting API? Thanks! On Mon, Dec 14, 2020 at 10:09 AM Ian Clelland wrote: > Hi WebKit! > > In Chrome-land, we've been working on updating our implementation of the > Reporting API to align with the spec changes made over the last year or so, > which resolve a number of privacy issues, separating reports generated > within the context of a single document from those which relate to overall > network conditions, and isolating reports from unrelated documents. This > also includes a new header, Reporting-Endpoints, whose value is not > persisted between document loads. > > We're hoping to ship these updates sometime early in the new year, and > would love to get the thoughts / opinions / feedback from WebKit developers. > > Thanks! > Ian > > Some relevant links: > * Explainer: https://github.com/w3c/reporting > * Spec: https://w3c.github.io/reporting > * Recently-opened TAG review: > https://github.com/w3ctag/design-reviews/issues/585 > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on Reporting API (now with structured headers!)
Hi WebKit! In Chrome-land, we've been working on updating our implementation of the Reporting API to align with the spec changes made over the last year or so, which resolve a number of privacy issues, separating reports generated within the context of a single document from those which relate to overall network conditions, and isolating reports from unrelated documents. This also includes a new header, Reporting-Endpoints, whose value is not persisted between document loads. We're hoping to ship these updates sometime early in the new year, and would love to get the thoughts / opinions / feedback from WebKit developers. Thanks! Ian Some relevant links: * Explainer: https://github.com/w3c/reporting * Spec: https://w3c.github.io/reporting * Recently-opened TAG review: https://github.com/w3ctag/design-reviews/issues/585 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on Permissions-Policy header
(Sending this from the right email address this time, hopefully) Hi WebKit! I'd like to ask WebKit leads for their stance on the Permissions-Policy header (https://www.chromestatus.com/feature/5745992911552512) Permissions Policy is the new (since https://github.com/w3c/webappsec-permissions-policy/issues/359) name for Feature Policy, and the Permissions-Policy header is part of that spec. WebKit has supported Feature Policy through the attribute for some time, and the header has been designed to augment that functionality, by allowing sites to control which origins should never be granted use of powerful features. (Previously, the Feature-Policy header could be used to implicitly *grant* that delegation, rather than blocking it; that has been changed in response to developer feedback) I'm happy to discuss this in any forum, if folks have questions. Thanks! Ian Other references: Spec: https://w3c.github.io/webappsec-permissions-policy/ Tag review: https://github.com/w3ctag/design-reviews/issues/341 Original intent to prototype in Blink: https://groups.google.com/a/chromium.org/d/msg/blink-dev/As1ABvc2QdA/yZSpPXY4CAAJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Requesting a position on Document Policy
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 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 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
[webkit-dev] Requesting a position on Document Policy
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
