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
On Thursday, January 23, 2025 at 3:28:11 PM UTC-8 Jun Kokatsu wrote:
> 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) <
> yoav...@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 emailsjkok...@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 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/0bcf6470-8142-42c4-b4fa-762fc4319cden%40chromium.org.
