w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
399 stars 155 forks source link

Example 3 is misleading/Delegating Trust to Nested Contexts #550

Open JannisBush opened 5 months ago

JannisBush commented 5 months ago

Example 3 in the spec states:

SecureCorp Inc. wants to completely disable use of the Geolocation API within all descendant navigables except for its own origin and those whose origin is "https://example.com", even in the presence of an attacker who can embed their own iframes on SecureCorp’s pages. It can do this by delivering the following HTTP response header to define a restricted permissions policy for Geolocation: Permissions-Policy: geolocation=(self "https://example.com")

For me this description reads as if only the two origins self and https://example.com could ever use the Geolocation API. However, if I understood the specification correctly (and this is also what my tests in Chromium show), allowing an origin also allows all descendants of that origin/delegates the decision of what to do with the next level of inclusions to that origin. In this example: if https://example.com includes iframes and grants them access via the allow tag (and not disabling it via the PP header) theses iframes are also allowed to use the Geolocation API.

Example: A (PP: geolocation=(A B), iframe allow=geolocation src=B) -> B (no PP, iframe allow=geolocation src=C) -> C (no PP): C can request access to geolocation even though A only specified A and B.

I would suggest rewording the example and also outside of the example more explicitly state this delegation as it might be confusing at the moment..