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 <[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 emails
[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 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 [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
<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 [email protected].
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.
