-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Allowing top-level communication for cross-origin isolated documents #6364
Comments
I think I'm missing how |
So, hypothetically, in a browser without storage partitioning an ad iframe can synchronize state across all 3p contexts with |
@annevk I agree that Moreover, in the long-term, same-(top-level)-site cross-origin documents also have communication uses. In those cases, neither |
Apart from the tracking concern there's also an architectural concern as otherwise same-origin documents would now only have |
I'm probably missing something, but I don't think this would prevent same-origin documents from using the other APIs to communicate, as long as they're within the same storage partition; e.g. top-level same-origin documents could still share data via I'm also curious about the other kinds of impact you mentioned above, it would be helpful to understand these concerns. What I'm worried about is that without providing COI documents with a recommended API to communicate with their popups, it's likely that developers will use alternative mechanisms to achieve the same goal, e.g. use link decoration in the OAuth popup to redirect back to a document in the application's origin and then use a mechanism like |
Say A opens A' and A' has COOP and A' and A are same origin. Today that means A doesn't have a |
Yeah, no disagreement from me here: this would certainly require figuring out a way to pass data around between BCGs intentionally separated by COOP. I guess my question is whether poking a hole for I realize that both of the ideas above can be ugly (or turn out to not be feasible), but my guess is that we don't do anything the workarounds built by developers are going to be much worse in the long run. |
Personally something like WebID seems more reasonable to me long term, but I'm also interested in seeing workarounds that would work in Safari (assuming that Safari ships COOP soonish). |
This is definitely a possible approach, but practically it will mean that -- until WebID ships in most browsers -- authors of OAuth flows will have to switch to one of the workarounds like link decoration + top-level same-origin sharing of state. |
Well, we discussed OAuth flows while designing COOP and We also discussed allowing |
I don't want to belabor the point because I agree with you about the background and the difficulty here. But we do have more information today than we did a couple of years ago, which can have a bearing on our decisions. Specifically:
Having |
I think the fact that anti-tracking hasn't tackled popups (including |
I have to say this is news to me; do you have a reference you could point to for this? Also, I'd find this stance defensible if we had plans to break |
Firefox has done some investigation here and I suspect we'll get back to it: https://bugzilla.mozilla.org/show_bug.cgi?id=1657250. It has come up in the Privacy CG a bunch too. And indeed that's why there is interest in WebID (though also wariness given the scope). (Saving grace of popups is that they require user activation, but that is not hard to come by.) |
Thanks @annevk, this is helpful. Re: user activation, we could consider whether there are additional restrictions on the popup that would we could enforce to ensure anything we allow would only be usable for legitimate, i.e. non-tracking, use cases. For example, we could deliver messages only if the popup doesn't have a reference to any other window, require the popup to be same-origin with the document sending the message, etc (we'd have to be careful about this not causing an infoleak, but it should be doable). My guess is that if we're planning to keep allowing |
I really think having |
After a few conversations with @camillelamy and @arturjanc, I wonder if we could take an alternate approach to those proposed above by hardening I think this hardening would boil down to allowing user agents to consistently process-isolate the newly opened window from its opener by breaking synchronous communication channels:
This seems like a path that might be worth exploring. |
To be clear, even if the top-level window is cross-origin, that doesn't mean that all agent clusters "in that window" are. If A1 popups B and B embeds A2, A2 can reach A1 through (I guess there's a larger question here of whether we want to encourage this pattern given the issues with popups.) |
Yes, I should have been more clear about that case, and I agree with you. I do think that changing the keying for agent clusters is a reasonable way of dealing with the issue, and I'm hopeful that this use case (which does seem like it's going to bite some folks trying to adopt COI) can motivate rekindling the conversation you're pointing to.
A related question is "How can applications that exist today adopt the security primitives we'd like them to adopt?" I think we're more likely to see more adoption if we can accommodate existing practice when possible. Paving cowpaths seems easier than asking the cows to hop into the Cow Transporter 2.0™ that we haven't actually figured out how to build yet. :) |
/cc @csreis, as he's concerned about the same issue Anne noted. |
Yes, I'll mainly share that the example Anne noted happened in practice, at least in the past. In https://crbug.com/128772 from 2012, we found that Facebook was using an iframe on a cross-origin page to open a Facebook OAuth popup and expected script calls between the iframe and popup. That's a hurdle for putting OAuth popups in their own process (without OOPIFs and Site Isolation). Caveat: I don't know if there are still sites doing that or if we have alternatives to recommend for them, but it's one of the cowpaths Mike mentions, and one that caused serious bugs in Chrome in the past. |
I think that Facebook was historically responsible for most of these weird domain-lowered synchronous cross-frame/window accesses and that code should all be gone. I think cross-origin popups and iframes that break all sync relations but could use postMessage only to the opener keeps alive most important use-cases. It would even be fine to break the ability to traverse to other reachable contexts like opener.parent and the ability for the opener to navigate or do anything but close the popup reference. |
This comment has been minimized.
This comment has been minimized.
One possibility could be to apply the restrictions only when COEP is enabled - i.e. create a COOP of same-origin-allow-popups-plus-coep which enables crossOriginIsolated. Then we can treat the fact that all frames enabled COEP as an opt-in into the restrictions. After all, right now a frame with COEP can be loaded in a cross-origin isolated context where its Agent Cluster is already keyed to origin. In this context, it cannot interact synchronously with a same-origin frame in a page with a different COOP status, because there are no pages with a different COOP status in the browsing context group. So, if we only impose restrictions when you have COEP, we wouldn't be breaking functionality, and sites would still have a way to make their OAuth flows work as long as it uses PostMessage. |
@camillelamy Can you clarify what restrictions you are referring to above, i.e. are you talking specifically about the agent cluster keying changes? I think the idea is reasonable, but I'm wondering if we'd need to care about the fact that COEP only applies to the opener's frames, but not to the openee's frames. Compare:
In the first case, B1 must have opted in by setting COEP, as you say. In the other cases, COEP is only enforced on the iframes of the opening window and not the popup. I don't think this is a problem because keying of the agent clusters would prevent the top-level windows from sharing a process, I just wanted to make sure we consider this. |
Not only Oauth flows, but also if there are front-end SDKs used by third party sites(A), then the SAB usage restrictions need to be hacked like the below. SiteA-page1(COOP+COEP) <--interact via local storage/broadcastchannel-> popup to SiteA-page2(no COOP) <--interact via postmessage--> Popup to SiteB(no COOP). Is there a better way to avoid multiple popups as shown above? |
@arturjanc I am talking about both changes. Basically, the idea is that we create a new value of COOP, In pages with COOP However, to make the crossOriginIsolation status of COOP My argument is that those restrictions are ok to apply to cross-origin subframes of the
So the restrictions we are putting on COOP Basically, I think these restrictions should be ok when all cross-origin subframes have COEP, which is the point of contention for applying them to COOP pages without COEP. Since this would fix a major problem with the crossOriginIsolated rollout, I think this is a good direction for us to go in. @jyothsna The proposal I am discussing above would simplify your example. You would have SiteA(COOP same-origin-allow-popups + COEP) <--interact via postmessage--> Popup to SiteB(no COOP). |
Some update on the "COOP: restrict-properties" policy (let's call it that since nobody objected). The proposal for having it cause BCG swaps preserving a limited opener has been deemed undoable for reasons explained in issue #7713. The approach that is now being explored is the following: Have a COOP: restrict-properties policy that would cause agent clusters for that page to be isolated from others. Each BrowsingContext group would have a map of <page nonce, agent cluster map>. In general, everything would be stored in the initial empty nonce map. If we start using the COOP value, each page using it gets its own agent cluster map via a new nonce. While the behavior might seem a bit different from other COOP values at first (opener links are not restricted forever, but can be restored), it's actually not. Because we do not swap BrowsingContext groups, we're not breaking any COOP behavior, and we do not need to modify any of the fundamentals (like COOP being applied on redirects, etc). We can also reuse report-only more or less directly. The downside would be that websites using this policy to interact with cross-origin popups would also need to rework their same-origin popup interactions to only use postMessage and closed. We're especially interested in partner's opinion about the usability of that feature, or if the inability to communicate directly with same-origin popups would be too hard to overcome. |
The explainer has been updated to reflect the latest developments: |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
FWIW, I still like the policy name |
Update on this topic, we've reached out to a number of websites susceptible to be interested in this proposal but haven't received any feedback. I suspect this is due to the complexity of the topics involved. Our next step is to build a MVP and enable it via an origin trial, to gather more practical feedback from web developers. It would be nice if we could agree on a name before that so that we don't have to rename tons of places in the code base later on. You mentioned you preferred COOP: popups is that still your preference? The reasoning we had with restrict-properties was that COOP: popup would hint at something that would be used for popups, whereas the main use case is for a main frame that wants both COI and to interact with popups. WDYT? |
Hypothesis is interested in the login popup use case and would be interested in helping to test any solutions. I think our use case may be a little different than others. Our product is an iframed commenting app/widget (think something like Disqus) that publishers embed in their web pages, with a login flow that happens in a popup. The |
For an iframe to be crossOriginIsolated, it will unfortunately always require top level collaboration. The reason is pretty straight forward: without out of process iframe, they'll end up in the same process, so they need to somehow agree. And at this point out of process iframe is not something we can rely on as it is not supported widely enough. |
I think I could live with |
I slightly prefer |
My understanding was that origin isolation was there to allow a site to exist in a process that didn't contain no-cors data (or, content that had opted in to being potentially accessed via meltdown/spectre). Because of that, A developer could easily create communication between the two windows by sharing an ID in the URL, and creating a socket via the server. So it seems fine to do the same via message ports (excluding the usual things that can't travel across processes, like SAB). |
I want to give |
FWIW I've been expecting us to apply this COOP value on the main window of applications that aren't opened in popups, but need to interact with a cross-origin popup (and which want COI so they can't use COOP: SOAP). It seems fairly awkward to use |
Just a heads up, since we haven't been able to convince each other and that I've got all the docs/explainers/WPT as restrict-properties and that I'll start putting together patches soon, we'll stick to that. This can always be changed in the future but will require significant effort. |
Just a note for thoughts, something that came up while working on a prototype is what we want to do with names when going to/from a COOP: RP page. Is it acceptable that a window name set by COOP: RP page is then leaked into the next non COOP: RP window? Do we want to force a name cleanup? And if we do is it going to break the regular -> COOP -> regular flow we were worried about in the first place? |
Thought: make (I still struggle to make much sense of |
what's the latest status on this? |
Secure popup interactions with |
I have made my page cross using isolated using coop: restrict-properties & coep : credentialless. I am using msal & okta for authentication. There are certain use cases where I have to focus and close the popup window, but we can't use these methods directly instead we have to post message to these child windows via window.postMessage. But how can I add listeners to these messages on the popup/child window as I don't have control over it. Has anyone solved this issue? |
Could somebody provide some context on why this was done? Is this an implementation detail and the behavior should be the same as with the additional agent cluster keying? |
@simon-friedberger The behavior is exactly the same as additional agent cluster keying. This is an implementation detail, but we also think that it is easier to reason about than extra keying. @anvipul We'd like to better understand the impact on not having access to focus and close. My understanding is that you should still be able to login, though an authentication popup might be left behind. Is that correct? |
@camillelamy Sometimes user may shift the focus to some other tab (with popup still open) & popup will be hidden behind the browser. Now when user comes back and click again on sign in button, either we can focus the already opened popup or close the previously opened popup and open the new one (in the latter case, we can have popup left behind even though the user has logged in). |
@camillelamy, do you have any idea on how we can add event listener on the popup window which is not in our control? |
@anvipul My understanding is that while the flow might still be less ideal (ie you might end up with an extra OAuth popup), the user should still be able to login. We would really like to avoid exposing |
@anvipul It's not possible to add an event listener on a third party window. The whole point of COOP is to limit the ability of other websites to influence you. However, you can reach out to the owner of the window and ask them about the possibility of adding the event listener. They can then review your request and see if it makes sense for their website. |
@camillelamy Reaching out to the owner is not practical. Our scenario is OIDC, and through OIDC or SAML redirects, the origin could switch to any authentication service. You are correct in stating that the basic successful scenario should work. Our concern is that if a user navigates away during authentication, then we leave abandoned popups in the background. We know that they are there, but there is nothing that we can do about it. Our users will not know about COOP restrictions. They will just think that our application is poorly written. Do you have any thoughts on an eventual solution to this issue? |
The current model of cross-origin isolation is incompatible with federated sign-in flows based on popups. Any popup opened by a document with a COOP of
same-origin
will not be able to communicate with its opener, preventing passing information to the application to which the user wants to sign in (or, commonly, to the identity provider's iframe embedded by that application).Some background for this decision is in #3740 (comment) and the subsequent discussion.
Based on discussions with developers, it looks like this can become a barrier to adoption of cross-origin isolation and to efforts to enforce better isolation by default. We should give developers a recommended solution for this use case which will not require them to re-architect their applications to remove cross-origin isolation from parts of their application where the user is able to sign in.
The main difficulty is that due to browsers' efforts to disable the sharing of state across storage partitions, APIs which could have potentially been used as a fallback to allow the popup to communicate with its opener (
BroadcastChannel
,localStorage
) are unlikely to be tractable approaches in the long term.A few possible alternatives:
postMessage
to be used in situations where COOP caused a browsing context group switch.localStorage
orBroadcastChannel
.I do think that something like WebID could be a good long-term solution, but I'm worried that without a short/medium-term alternative we'll make life difficult for developers; an approach like (1) or (2) above could possibly be a reasonable alternative. Given the increasing interest in cross-origin isolation it seems somewhat important for us to figure this out soon.
/cc @annevk @mikewest @camillelamy Any thoughts or other ideas here?
The text was updated successfully, but these errors were encountered: