Contact emailsiclell...@chromium.org Explainer https://github.com/w3c/webappsec-permissions-policy/blob/main/reporting.md
Specificationhttps://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) *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.
