LGTM3 On Wed, Oct 25, 2023 at 9:36 PM Mike Taylor <miketa...@chromium.org> wrote:
> LGTM2 > On 10/25/23 3:00 PM, 'Rick Byers' via blink-dev wrote: > > 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 <iclell...@chromium.org> > wrote: > >> >> >> 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 emails iclell...@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 component Blink>FeaturePolicy >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFeaturePolicy> >>>> >>>> TAG review None, 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 status Pending ( >>>> 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://flags None >>>> >>>> Finch feature name PermissionsPolicyReporting >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1493159 >>>> >>>> Launch bug https://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 >> <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 blink-dev+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9WJu1zPcKXwJsmtCp-%3DG16CKm-pUO54zm8RytACL0cJg%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/CAL5BFfVtjReqD%2B-1Guq2JFfsheGR98Um99QA0nhE1n_YPotD4Q%40mail.gmail.com.
