-
Notifications
You must be signed in to change notification settings - Fork 27
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
Permissions Policy Integration (formalize nested iframe support) #78
Conversation
storage-access.bs
Outdated
@@ -202,7 +200,7 @@ When invoked on {{Document}} |doc|, the <dfn export method for=Document><code>re | |||
1. Let |p| be [=a new promise=]. | |||
1. If this algorithm was invoked when |doc|'s {{Window}} object did not have [=transient activation=], [=reject=] and return |p|. | |||
1. If |doc|'s [=Document/browsing context=] is a [=top-level browsing context=], [=/resolve=] and return |p|. | |||
1. If |doc|'s [=Document/browsing context=]'s [=parent browsing context=] is not a [=top-level browsing context=], [=reject=] and return |p|. | |||
1. If |doc|'s [=relevant settings object=] is not [=allowed to use=] the `"request-storage-access"` permission, [=reject=] and return |p|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"allowed to use" operates on a document I believe so you need to grab a document from the environment settings object here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reluctantly approving.
@clelland do we keep a registry of these values someplace? Any thoughts from you on this?
@hober @johnwilander I'll merge this, let me know if you still have any concerns and we can figure those out in follow-ups |
This is a first stab at integrating permissions policy and support nested iframes in the spec, see #10 and #12 . A few notes:
"request-storage-access"
). It's important to note that this policy only controls requesting storage access, it does not tell user agents with persistent/passive storage (see Active or passive storage access after explicit user opt-in #2) how to behave if anallow=none
attribute was added after an iframe received storage access."*"
default allowlist which @annevk intended to deprecate. We went back and fort on this but ultimately"*"
captures the reality of current implementations best, especially considering that WebKit does not have PP support (and thus implictly default to"*"
) for the time being. If we had started from scratch on this then maybe"self"
would have been the best option, but personally I don't see that happening without WebKit support. Let me know if anyone disagrees.