Usage in cross-origin iframes #177
Comments
|
There's also workers to consider. But yeah, I think we can use the top-level origin concept for this. However, that does not handle A1 -> B -> A2 scenarios. Is that something we want to take into account here? Chrome does that elsewhere for some if its partitioning. cc @clelland |
|
We could potentially do something like "If document's origin is same origin with the top-level-browsing-context's active document's origin, and the top-level-browsing-context's active document is allowed to use..."
What would this look like in practice? Is this a way to specify a feature that would only ever be allowed in the top-level? (And presumably same-origin direct descendants?) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Both Chrome and Firefox have disallowed calling
Notification.requestPermission()and (somewhat implicitly)new Notification()in cross-origin iframes. I'm not sure this is encoded explicitly anywhere in the spec.In conversation with @annevk we said that for other permissions policy-controlled features this would be done through the Permissions API's request to use algorithm, which has a step for checking "allowed to use" as per PP.
However, the Notifications spec does not define a Permissions Policy feature. This is because Notifications isn't really compatible with permission delegation, i.e. an origin that requests (push) notification permission would not expect the permission to be scoped to the embedded document.
For that reason, simply specifying a permissions policy integration with a permission name and a default allowlist, like many other specs do, seems like a bad choice, as it would allow developers to override the allowlist.
The simplest solution might be to just add checks in this spec that disallow usage in cross-origin iframes, though we could also consider supporting a "only deny, no override" option in PP.
The text was updated successfully, but these errors were encountered: