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.
None
Potential Permissions Policy violation reports should not include any new information about cross-origin iframes
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
Shipping on desktop | 134 |
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).
NonePotential 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>
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.
Contact emailsjkok...@google.com
Specificationhttps://github.com/w3c/webappsec-permissions-policy/pull/546
SummaryIntroduces 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.
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").
Motivation
Blink componentBlink>PermissionsPolicy
TAG reviewNone
TAG review statusNot applicable
Other signals:
SecurityPotential Permissions Policy violation reports should not include any new information about cross-origin iframes
WebView application risksDoes this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
DebuggabilityNone
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://flagsNone
Finch feature namePotentialPermissionsPolicyReporting
Requires code in //chrome?False
Tracking bughttps://issues.chromium.org/issues/40941424
Estimated milestonesShipping on desktop134
Anticipated spec changesOpen 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 Statushttps://chromestatus.com/feature/5154241037205504?gate=5069369228656640
On Friday, January 17, 2025 at 7:42:03 AM UTC+9 Jun Kokatsu wrote:Contact emailsjkok...@google.com
Specificationhttps://github.com/w3c/webappsec-permissions-policy/pull/546
SummaryIntroduces 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.
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").
Motivation
Blink componentBlink>PermissionsPolicy
TAG reviewNone
TAG review statusNot applicableCan 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.
Other signals:
SecurityPotential Permissions Policy violation reports should not include any new information about cross-origin iframes
WebView application risksDoes this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
DebuggabilityNone
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?NoWhich platform will it not be supported on?
LGTM1
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:
Contact emailsjkok...@google.com
Specificationhttps://github.com/w3c/webappsec-permissions-policy/pull/546
SummaryIntroduces 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.
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").
Motivation
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.
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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.
--
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.