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

Per-frame or per-frames-that-can-access-each-other #14

Closed
annevk opened this issue Mar 12, 2020 · 7 comments · Fixed by #29
Closed

Per-frame or per-frames-that-can-access-each-other #14

annevk opened this issue Mar 12, 2020 · 7 comments · Fixed by #29
Assignees

Comments

@annevk
Copy link
Collaborator

annevk commented Mar 12, 2020

I'd like #3 to be clarified a bit. One thing I think is that if A embeds B1 that embeds B2, that B1 and B2 get their state flipped together as they can call each others functions. (In HTML terms the scope would be the window agent.)

Same if A embeds B1 and B2 (siblings).

@johnwilander
Copy link
Collaborator

Thanks for filing! Let's go with some example domain names since "party" is at play here.

Are you envisioning something like:
A: news.example
B1: embedderService.example
B2: social.example

Or something like:
A: news.example
B1: sub.social.example
B2: othersub.social.example

?

@annevk
Copy link
Collaborator Author

annevk commented Mar 14, 2020

A is example.com, B1 is test.invalid/1, B2 is test.invalid/2. (I.e., A and B are cross-site, Bs are same-origin.)

@johnwilander
Copy link
Collaborator

Sorry for the delay. This is an interesting corner case.

Looking back on earlier discussions, we've said that sibling iframes should not get storage access since they 1) don't know that a sibling of theirs is requesting access and 2) may have open connections or transactions with storage such as partitioned storage. I believe nested iframes are in the same situation.

However, I did discuss with @englehardt and @ehsan about another idea, namely a way for iframes to opt in to shared storage access. That way they can be prepared for the sudden change and maybe also be required to not access partitioned storage (so as to not create situations where the browser would have to sever those connections).

I'll open up a new issue where we can discuss that since it could potentially solve this for both sibling iframes and nested iframes.

@annevk
Copy link
Collaborator Author

annevk commented Mar 26, 2020

You're asserting that they don't know, but I'm not sure what you are basing that assertion on as they have direct access to each others state (and functions, etc.). And their storage is shared so any transaction would affect both frames.

@johnwilander
Copy link
Collaborator

The call to requestStorageAccess() happens on tap/click in one iframe and asynchronously decides whether or not to grant storage access. I don’t know all the ways frames can communicate without consuming the gesture. Is that what you’re suggesting they do? Kind of “I just got a tap and will request storage access. Your access to cookies (and possibly other means of storage) may change at any moment from now.” That communication would have to be synchronous or else be racy, right? Similarly, the requesting iframe would have to tell all of its siblings and children that it was denied storage access so they can stop waiting.

Maybe I’m missing some alternate way of handling this.

@annevk
Copy link
Collaborator Author

annevk commented Mar 26, 2020

They can directly access each other via script. In particular, when they are siblings, the first one can get to the second one by using self.parent[1]. They can call common functions, they can manage state that way. There's no reason to expect they're not fully aware of each other.

@hober
Copy link
Member

hober commented Apr 27, 2020

I'm hoping the work to address #28 will clarify this.

@hober hober self-assigned this Apr 28, 2020
@hober hober linked a pull request Apr 29, 2020 that will close this issue
@hober hober closed this as completed in #29 May 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants