Intent to Ship: Permissions policy violation reports

[Ian Clelland]

Contact emails

icle...@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

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)

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?

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.

[Yoav Weiss]

On Tue, Oct 24, 2023 at 7:24 PM Ian Clelland <icle...@chromium.org> wrote:

Contact emails

icle...@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

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?

 

--
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+...@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.

[Ian Clelland]

On Wed, Oct 25, 2023 at 4:35 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tue, Oct 24, 2023 at 7:24 PM Ian Clelland <icle...@chromium.org> wrote:

Contact emails

icle...@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

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 and Reporting.

[Rick Byers]

Looks like a pretty straightforward combination of these established patterns, I like it! LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXLnyOaybVS7ts9NvGa2ZDm27uHVk6unbg5hXSi1UMdzeQ%40mail.gmail.com.

[Mike Taylor]

LGTM2

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.

[Yoav Weiss]

LGTM3