Looks like a pretty straightforward combination of these established patterns, I like it! LGTM1
On Wed, Oct 25, 2023 at 8:42 AM Ian Clelland <[email protected]> wrote: > > > On Wed, Oct 25, 2023 at 4:35 AM Yoav Weiss <[email protected]> wrote: > >> >> >> On Tue, Oct 24, 2023 at 7:24 PM Ian Clelland <[email protected]> >> wrote: >> >>> Contact [email protected] >>> >>> 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 bug >>> https://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 [email protected]. >>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXLnyOaybVS7ts9NvGa2ZDm27uHVk6unbg5hXSi1UMdzeQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXLnyOaybVS7ts9NvGa2ZDm27uHVk6unbg5hXSi1UMdzeQ%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9WJu1zPcKXwJsmtCp-%3DG16CKm-pUO54zm8RytACL0cJg%40mail.gmail.com.
