On Wed, Oct 25, 2023 at 4:35 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Tue, Oct 24, 2023 at 7:24 PM Ian Clelland <iclell...@chromium.org> > wrote: > >> Contact emailsiclell...@chromium.org >> >> Explainer >> https://github.com/w3c/webappsec-permissions-policy/blob/main/reporting.md >> >> Specification >> https://w3c.github.io/webappsec-permissions-policy/#reporting >> >> Design docs >> https://github.com/w3c/webappsec-permissions-policy/blob/main/reporting.md >> >> Summary >> >> This integrates the Permissions policy API with the Reporting API, >> allowing web developers to configure endpoints to which permissions policy >> violation reports will be sent, allowing site owners to see when disallowed >> features are being requested on their pages in the field. It also includes >> the Permissions-Policy-Report-Only header, which enables reports to be sent >> based on a proposed policy (analogous to >> Content-Security-Policy-Report-Only) so that policy changes can be >> evaluated for potential breakage before implementing them in the regular, >> enforcing mode. >> >> >> Blink componentBlink>FeaturePolicy >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFeaturePolicy> >> >> TAG reviewNone, although both Permissions Policy ( >> https://github.com/w3ctag/design-reviews/issues/159; >> https://github.com/w3ctag/design-reviews/issues/341) and Reporting ( >> https://github.com/w3ctag/design-reviews/issues/585) have been >> previously reviewed by the TAG. >> >> TAG review statusPending ( >> https://github.com/w3ctag/design-reviews/issues/909) >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal ( >> https://github.com/mozilla/standards-positions/issues/909) >> >> *WebKit*: No signal ( >> https://github.com/WebKit/standards-positions/issues/269) >> > > Do you know if any of them implements both reporting and permissions > policy? > WebKit and Gecko both implement permissions policy to some extent; I do not believe that either of them implement the Permissions-Policy header yet, which would be required for reporting. Safari has shipped support for reporting, while Gecko has an implementation which is currently behind a flag in Firefox. (Firefox *does* support CSP level 2 reporting, but not the generic Reporting API mechanism). That said, Mozilla has a positive position on both Permissions Policy <https://mozilla.github.io/standards-positions/#feature-policy> and Reporting <https://mozilla.github.io/standards-positions/#reporting>. >> *Web developers*: Positive I've heard from developers at both Google and >> Meta that this would be extremely important for them to roll out >> permissions policies on their properties, in order to be able to safely >> lock down permissions. Additionally, I've heard that this is critical for >> adoption of some features such as Cross-origin isolation, which have the >> potential to break sites if not configured correctly. >> >> *Other signals*: >> >> Ergonomics >> >> This is a change to permissions policy, which already touches a large >> number of APIs, and now includes the Reporting API. The major ergonomic >> risk here is in the method of configuration, of assigning features to >> reporting endpoints. A previous origin trial simply sent all violations to >> the "default" endpoint, without allowing any other flexibility in >> configuration. This imposes a burden on the developer to filter those out >> which are not desired. That endpoint today also receives several other >> non-configurable reports, and we have received feedback that that kind of >> design is not ergonomic. The current design instead requires developers to >> configure each feature for which they would like to receive reports. This >> may be sub-optimal, and we may in the future want to define a syntax for a >> catch-all endpoint, but I believe that can be a syntax extension which >> would be backwards-compatible with this feature. >> >> >> Activation >> >> This is no more challenging than existing reporting mechanisms. >> >> >> Security >> >> The permissions policy on a page can impose conditions on embedded >> content, but it is still important that user actions in that content not >> leak information to the containing page. For that reason, the reporting is >> designed such that a page can only receive reports for violations which >> occurred in that page. Any embedded content will need to have reporting >> enabled independently. >> >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> Permissions policy and reporting each have independent support in >> DevTools for debugging. I don't believe that the specific combination of >> the two requires special consideration. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)?Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> >> https://wpt.fyi/results/permissions-policy/reporting?label=experimental&label=master&aligned >> >> >> Flag name on chrome://flagsNone >> >> Finch feature namePermissionsPolicyReporting >> >> Requires code in //chrome?False >> >> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1493159 >> >> Launch bughttps://launch.corp.google.com/launch/4285768 >> >> Estimated milestones >> Shipping on desktop 120 >> Shipping on Android 120 >> Shipping on WebView 120 >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> None; the spec changes have landed. >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5105435227455488 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJ%3DKP76-BjdbOv%2B1u7Ej6W91oTHf8JJ9GOxknTJM4kYAg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJ%3DKP76-BjdbOv%2B1u7Ej6W91oTHf8JJ9GOxknTJM4kYAg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXLnyOaybVS7ts9NvGa2ZDm27uHVk6unbg5hXSi1UMdzeQ%40mail.gmail.com.
