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: https://github.com/w3c/webappsec-permissions-policy/pull/546 Thanks, Jun On Wed, Jan 22, 2025 at 6:55 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > An explainer (even an inline one) and pointers to the relevant spec > sections would be very helpful when reviewing this intent. Thanks! :) > > On Thursday, January 16, 2025 at 11:42:03 PM UTC+1 Jun Kokatsu wrote: > >> Contact emailsjkoka...@google.com >> >> Specificationhttps://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 componentBlink>PermissionsPolicy >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPermissionsPolicy%22> >> >> TAG reviewNone >> >> TAG review statusNot applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal >> <https://github.com/mozilla/standards-positions/issues/1164> >> >> *WebKit*: No signal >> <https://github.com/WebKit/standards-positions/issues/448> >> >> *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://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?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 milestones >> Shipping on desktop 134 >> >> 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 >> <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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF4tNSgyOcjwy4toKwFK0bzgpg0G9aCph0O4FYgRddCKzA%40mail.gmail.com.
