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
            
<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/23391cea-31c4-4ab1-82d0-3515cf913235%40chromium.org.

Reply via email to