Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Ship: Permissions Policy reports for iframes

197 views
Skip to first unread message

Jun Kokatsu

unread,
Jan 16, 2025, 5:42:03 PMJan 16
to blink-dev

Contact emails

jkok...@google.com


Specification

https://github.com/w3c/webappsec-permissions-policy/pull/546

Summary

Introduces a new violation type called "Potential Permissions Policy violation", which will only look at Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions propagated to iframes.


Motivation

Permissions Policy violation reports for cross-origin iframes are only sent to the iframe's reporting endpoint and not to the embedder's reporting endpoint, because of the concern that it might leak sensitive information about a cross-origin iframe. However, this makes it difficult for sites to enforce Permissions Policy because it can't learn about breakages in cross-origin iframes. This feature introduces a new violation type called "Potential Permissions Policy violation", which will only look at existing Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions being propagated to iframes. Since both Permissions Policy and allow attributes are set by the embedder, this feature does not leak any new information to the embedder. However, potential Permissions Policy violations will be sent when an iframe is loaded, and not when the iframe uses the prohibited feature, which is different from the normal Permissions Policy violations which fires upon a feature usage (hence the name "potential").

Blink component

Blink>PermissionsPolicy

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Security

Potential Permissions Policy violation reports should not include any new information about cross-origin iframes



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

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

https://github.com/web-platform-tests/wpt/pull/49978

Flag name on about://flags

None

Finch feature name

PotentialPermissionsPolicyReporting

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40941424

Estimated milestones

Shipping on desktop134


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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5154241037205504?gate=5069369228656640

This intent message was generated by Chrome Platform Status.

Yoav Weiss (@Shopify)

unread,
Jan 22, 2025, 9:54:59 AMJan 22
to blink-dev, Jun Kokatsu
An explainer (even an inline one) and pointers to the relevant spec sections would be very helpful when reviewing this intent. Thanks! :)

Jun Kokatsu

unread,
Jan 23, 2025, 6:28:11 PMJan 23
to Yoav Weiss (@Shopify), blink-dev

Explainer

Potential Permissions Policy violation report triggers when Permissions Policy (or report-only) is enforced on a document, where iframe has an allow attribute which conflicts with the Permissions Policy specified by the header.


Unlike Permissions Policy violations, Potential Permissions Policy violations fires when the iframe is loaded, not when the feature is being used, so that it will not leak the feature usage inside cross-origin iframes.


Example:


Permissions-Policy: camera=();

<!--

This sends a Potential Permissions Policy violation because the "camera" permission is not allowed for any origin, but this site tries to delegate the camera permission to example.com.

-->
<iframe src="https://example.com" allow="camera"></iframe>


PoC: https://test.shhnjk.com/permissions_policy.php?pp=camera=()&allow=camera&url=https://example.com&xss=%3Cs%3Eadd%20any%20html%20here%3C/s%3E%3Cbr%3E

Security Considerations

This change compares Permissions Policy defined in the document against iframe’s `src` and `allow` attributes to find a conflict. Since Permissions Policy, `src` attribute, and `allow` attribute are all set by the same document, this change should not leak any new information to the document.


You can see the relevant spec in the following PR:

Thanks,

Jun

Jun Kokatsu

unread,
Jan 24, 2025, 2:46:32 AMJan 24
to blink-dev, Jun Kokatsu, blink-dev, Yoav Weiss (@Shopify)
Sorry, forgot to include how a violation report looks like:

```
{
  "age": 0,
  "body": {
    "allowAttribute": "camera",
    "disposition": "enforce",
    "message": "Potential permissions policy violation: camera is not allowed in this document.",
    "policyId": "camera"
  },
  "type": "potential-permissions-policy-violation",
  "url": "https://test.shhnjk.com/permissions_policy.php",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36"
}
```

Main differences with Permissions Policy violation reports are:
  1. It includes allowAttributes in the body (which comes from the violating iframe's allow attribute).
  2. Name of the violation type is called "potential-permissions-policy-violation".

Thanks,

Jun

Domenic Denicola

unread,
Jan 26, 2025, 9:45:39 PMJan 26
to blink-dev, Jun Kokatsu


On Friday, January 17, 2025 at 7:42:03 AM UTC+9 Jun Kokatsu wrote:


Summary

Introduces a new violation type called "Potential Permissions Policy violation", which will only look at Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions propagated to iframes.


Motivation
Permissions Policy violation reports for cross-origin iframes are only sent to the iframe's reporting endpoint and not to the embedder's reporting endpoint, because of the concern that it might leak sensitive information about a cross-origin iframe. However, this makes it difficult for sites to enforce Permissions Policy because it can't learn about breakages in cross-origin iframes. This feature introduces a new violation type called "Potential Permissions Policy violation", which will only look at existing Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions being propagated to iframes. Since both Permissions Policy and allow attributes are set by the embedder, this feature does not leak any new information to the embedder. However, potential Permissions Policy violations will be sent when an iframe is loaded, and not when the iframe uses the prohibited feature, which is different from the normal Permissions Policy violations which fires upon a feature usage (hence the name "potential").

Blink componentBlink>PermissionsPolicy

TAG reviewNone

TAG review statusNot applicable

Can you say more why you believe TAG review is not applicable for this feature? I cannot figure out which exception, if any, it falls under from this list.
 


Risks


Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal

Web developers: No signals

Why are we proposing to ship this, if it is not interesting to any web developers, and has support from no other browsers?
 

Other signals:

Security

Potential Permissions Policy violation reports should not include any new information about cross-origin iframes



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

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No

Which platform will it not be supported on?
 


Flag name on about://flagsNone

Finch feature namePotentialPermissionsPolicyReporting

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/40941424

Estimated milestonesShipping on desktop134

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

Jun Kokatsu

unread,
Jan 27, 2025, 6:27:21 PMJan 27
to blink-dev, Domenic Denicola, Jun Kokatsu
On Sunday, January 26, 2025 at 6:45:39 PM UTC-8 Domenic Denicola wrote:


On Friday, January 17, 2025 at 7:42:03 AM UTC+9 Jun Kokatsu wrote:


Summary

Introduces a new violation type called "Potential Permissions Policy violation", which will only look at Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions propagated to iframes.


Motivation
Permissions Policy violation reports for cross-origin iframes are only sent to the iframe's reporting endpoint and not to the embedder's reporting endpoint, because of the concern that it might leak sensitive information about a cross-origin iframe. However, this makes it difficult for sites to enforce Permissions Policy because it can't learn about breakages in cross-origin iframes. This feature introduces a new violation type called "Potential Permissions Policy violation", which will only look at existing Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions being propagated to iframes. Since both Permissions Policy and allow attributes are set by the embedder, this feature does not leak any new information to the embedder. However, potential Permissions Policy violations will be sent when an iframe is loaded, and not when the iframe uses the prohibited feature, which is different from the normal Permissions Policy violations which fires upon a feature usage (hence the name "potential").

Blink componentBlink>PermissionsPolicy

TAG reviewNone

TAG review statusNot applicable

Can you say more why you believe TAG review is not applicable for this feature? I cannot figure out which exception, if any, it falls under from this list.

Sorry, I think I missed this step. I will submit for a TAG review, and come back to this thread once the TAG review is approved.
 


Risks


Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal

Web developers: No signals

Why are we proposing to ship this, if it is not interesting to any web developers, and has support from no other browsers?

We'd like to mitigate Permission Delegation of powerful permissions to unintentional sites (e.g. HTML injection in Bing resulted in camera access in Edge) in Google applications.
So we do have internal developer support. But I'm not sure if there is external developer support.
 

Other signals:

Security

Potential Permissions Policy violation reports should not include any new information about cross-origin iframes



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

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No

Which platform will it not be supported on?

This had to be Yes. I've fixed it in Chrome status. 

Mike Taylor

unread,
Jan 28, 2025, 10:15:57 AMJan 28
to Jun Kokatsu, blink-dev, Domenic Denicola

LGTM1

On 1/27/25 6:27 PM, 'Jun Kokatsu' via blink-dev wrote:
On Sunday, January 26, 2025 at 6:45:39 PM UTC-8 Domenic Denicola wrote:


On Friday, January 17, 2025 at 7:42:03 AM UTC+9 Jun Kokatsu wrote:


Summary

Introduces a new violation type called "Potential Permissions Policy violation", which will only look at Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions propagated to iframes.


Motivation
Permissions Policy violation reports for cross-origin iframes are only sent to the iframe's reporting endpoint and not to the embedder's reporting endpoint, because of the concern that it might leak sensitive information about a cross-origin iframe. However, this makes it difficult for sites to enforce Permissions Policy because it can't learn about breakages in cross-origin iframes. This feature introduces a new violation type called "Potential Permissions Policy violation", which will only look at existing Permissions Policy (including report-only policy) and the allow attribute set in iframes to detect the conflict between Permissions Policy enforced vs permissions being propagated to iframes. Since both Permissions Policy and allow attributes are set by the embedder, this feature does not leak any new information to the embedder. However, potential Permissions Policy violations will be sent when an iframe is loaded, and not when the iframe uses the prohibited feature, which is different from the normal Permissions Policy violations which fires upon a feature usage (hence the name "potential").

Blink componentBlink>PermissionsPolicy

TAG reviewNone

TAG review statusNot applicable

Can you say more why you believe TAG review is not applicable for this feature? I cannot figure out which exception, if any, it falls under from this list.

Sorry, I think I missed this step. I will submit for a TAG review, and come back to this thread once the TAG review is approved.
FWIW, I don't think we should block on TAG review resolution - but it's useful to file an issue, in case someone is keeping track of APIs that do reporting, or have report-only modes.
--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/453d70c8-b1b4-4607-8a76-ff564f00b231n%40chromium.org.

Vladimir Levin

unread,
Jan 29, 2025, 10:53:43 AMJan 29
to blink-dev, Mike Taylor, Domenic Denicola, Jun Kokatsu
LGTM2. I think this is a useful improvement over permission policy violation reporting

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Chris Harrelson

unread,
Jan 29, 2025, 11:08:15 AMJan 29
to Vladimir Levin, blink-dev, Mike Taylor, Domenic Denicola, Jun Kokatsu
LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f98e6ec-8ea6-4982-ad4c-44d88c48ec3dn%40chromium.org.
Reply all
Reply to author
Forward
0 new messages