Same origin S&P requirement conflicts with Permissions Policy integration #133
Labels
Comments
|
cc @anssiko @reillyeon, I've noticed this after finally taking a look at #126. |
|
I see the "top-level and same-origin children" requirement as having been a stop-gap until the Permissions Policy controls were in place and the capability could be delegated to cross-origin children only when the top-level document opted-in. I agree with your proposal. |
rakuco
added a commit
that referenced
this issue
Jan 31, 2024
…olicy one This addresses a conflict that was introduced in #121: - The presence of the Permissions Policy integration means usage of the Device Orientation API can be allowed in third-party iframes provided that the right tokens are in place. - The "Security and privacy considerations" section contains a requirement that events are fired only on child navigables that are same-origin with the top-level traversable. The latter was introduced in #25 and served as a stop-gap measure before Permissions Policy integration was added. The current implementation status is: - Blink never implemented the same-origin requirement, but added Permissions Policy integration in 2018. - WebKit has always implemented Permissions Policy integration. - Gecko implements the same-origin requirement (see Mozilla bug 1197901). This means we can safely replace the same-origin requirement with a requirement to support the Permissions Policy integration, as switching from one to the other is transparent in the sense that the exact same set of websites that worked before will continue to work with the change, as the features we define have a default allowlist of "self". Fixes #133
rakuco
added a commit
that referenced
this issue
Jan 31, 2024
…olicy one (#136) This addresses a conflict that was introduced in #121: - The presence of the Permissions Policy integration means usage of the Device Orientation API can be allowed in third-party iframes provided that the right tokens are in place. - The "Security and privacy considerations" section contains a requirement that events are fired only on child navigables that are same-origin with the top-level traversable. The latter was introduced in #25 and served as a stop-gap measure before Permissions Policy integration was added. The current implementation status is: - Blink never implemented the same-origin requirement, but added Permissions Policy integration in 2018. - WebKit has always implemented Permissions Policy integration. - Gecko implements the same-origin requirement (see Mozilla bug 1197901). This means we can safely replace the same-origin requirement with a requirement to support the Permissions Policy integration, as switching from one to the other is transparent in the sense that the exact same set of websites that worked before will continue to work with the change, as the features we define have a default allowlist of "self". Fixes #133
|
I've just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1878686 to let the Gecko developers know about these changes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the official integration of the Permissions Policy bits in #121, we now have contradicting requirements in the spec:
The same-origin requirement was added back in 2016 with #25, and it was implemented by Gecko in https://bugzilla.mozilla.org/show_bug.cgi?id=1197901 (change mirrored in mozilla/gecko-dev@bdb1f6d).
As far as I can see, this requirement was never implemented in Blink, but it did add Permissions Policy integration in early 2018 (https://bugs.chromium.org/p/chromium/issues/detail?id=796894). When WebKit implemented this API a few years later, they did add Permissions Policy integration as well, so we have 2 engines implementing the Permissions Policy integration and 1 implementing the same-origin requirement.
My proposal is to remove that item from the S&P section and add a new item referring to the Permissions API and Permissions Policy integration requirements. The current Permissions Policy requirements (with features whose default allowlist is "self") acts as a superset of the original requirement -- AFAICS, an implementation that switches from one requirement to the other will continue allowing the exact same set of sites (and this is without taking the Permissions API integration into consideration).
The text was updated successfully, but these errors were encountered: