-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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?) |
…l partition key r=asuth,bvandersloot This patch keeps the current status where Firefox and Chrome both allows notification permission in ABA context although the spec does not cover it. (whatwg/notifications#177, also listed in https://privacycg.github.io/storage-partitioning/#remaining-user-agent-state) The child patch in bug 1914203 will add a telemetry to see whether the usage is low enough so that we can block ABA access, to make it more consistent with storage partitioning. Differential Revision: https://phabricator.services.mozilla.com/D219908
…l partition key r=asuth,bvandersloot This patch keeps the current status where Firefox and Chrome both allows notification permission in ABA context although the spec does not cover it. (whatwg/notifications#177, also listed in https://privacycg.github.io/storage-partitioning/#remaining-user-agent-state) The child patch in bug 1914203 will add a telemetry to see whether the usage is low enough so that we can block ABA access, to make it more consistent with storage partitioning. Differential Revision: https://phabricator.services.mozilla.com/D219908
…l partition key r=asuth,bvandersloot This patch keeps the current status where Firefox and Chrome both allows notification permission in ABA context although the spec does not cover it. (whatwg/notifications#177, also listed in https://privacycg.github.io/storage-partitioning/#remaining-user-agent-state) The child patch in bug 1914203 will add a telemetry to see whether the usage is low enough so that we can block ABA access, to make it more consistent with storage partitioning. Differential Revision: https://phabricator.services.mozilla.com/D219908 UltraBlame original commit: bd858e1f75435642347157a152c8e28d612e1895
…l partition key r=asuth,bvandersloot This patch keeps the current status where Firefox and Chrome both allows notification permission in ABA context although the spec does not cover it. (whatwg/notifications#177, also listed in https://privacycg.github.io/storage-partitioning/#remaining-user-agent-state) The child patch in bug 1914203 will add a telemetry to see whether the usage is low enough so that we can block ABA access, to make it more consistent with storage partitioning. Differential Revision: https://phabricator.services.mozilla.com/D219908 UltraBlame original commit: bd858e1f75435642347157a152c8e28d612e1895
…l partition key r=asuth,bvandersloot This patch keeps the current status where Firefox and Chrome both allows notification permission in ABA context although the spec does not cover it. (whatwg/notifications#177, also listed in https://privacycg.github.io/storage-partitioning/#remaining-user-agent-state) The child patch in bug 1914203 will add a telemetry to see whether the usage is low enough so that we can block ABA access, to make it more consistent with storage partitioning. Differential Revision: https://phabricator.services.mozilla.com/D219908 UltraBlame original commit: bd858e1f75435642347157a152c8e28d612e1895
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: