Skip to content
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

Open
johannhof opened this issue Jan 17, 2022 · 2 comments
Open

Usage in cross-origin iframes #177

johannhof opened this issue Jan 17, 2022 · 2 comments

Comments

@johannhof
Copy link
Member

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.

@annevk
Copy link
Member

annevk commented Feb 10, 2022

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

@clelland
Copy link

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..."

though we could also consider supporting a "only deny, no override" option in PP.

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?)

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Sep 21, 2024
…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
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Sep 23, 2024
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Sep 26, 2024
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Sep 26, 2024
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Sep 26, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants