I think I'm missing how postMessage() doesn't have the same tracking potential.

postMessage() lets you communicate only with a window to which you have a reference (or, possibly in this case, would have had a reference if it wasn't for COOP). The other mechanisms let you share data between all same-origin windows, even if they are in unrelated browsing context groups (possibly restricted by storage partitioning; but at the very least with same-origin windows in other BCGs with the same storage key).

So, hypothetically, in a browser without storage partitioning an ad iframe can synchronize state across all 3p contexts with BroadcastChannel or localStorage, but not with postMessage(). (FWIW this doesn't necessarily make a qualitative difference here; but I could imagine that from a cross-site tracking perspective postMessage() may be less concerning.)

@annevk I agree that postMessage has tracking potential for cross-site cases, but I don't think they're quite the same. In the long-term, I think WebID or something similar is the answer. However, in the short term, I think leaving federated auth at postMessage is preferable to moving it to BroadcastChannel. Tracking with BroadcastChannel requires the two top-level sites be open concurrently at all. postMessage at least requires the documents reach each other. To track, you'd need to either wait for that to happen (which we can hopefully reduce over time) or you'd need to, e.g., visibly open a popup. That's still not great, hence WebID, but I think it's meaningfully better than the BroadcastChannel version.

Moreover, in the long-term, same-(top-level)-site cross-origin documents also have communication uses. In those cases, neither postMessage nor BroadcastChannel have a tracking concerns. For non-broadcast versions of those flows, I think there are good developer ergonomics and performance (wake up fewer documents) reasons to prefer postMessage.

Apart from the tracking concern there's also an architectural concern as otherwise same-origin documents would now only have postMessage() as communication channel, supposedly. Not to speak of the impact on browsing context groups, less bfcache opportunities, etc.

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 localStorage, etc. The goal here is to additionally allow certain kinds of same-origin communication across storage partitions, which isn't disallowed by cross-site tracking protections (you still have direct DOM access to cross-partition same-origin documents), but which is disallowed by cross-origin isolation (because you can no longer postMessage() to your popup).

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 localStorage to exchange data. This is going to be more clunky and will possibly conflict with other cross-site tracking measures in the future.

Say A opens A' and A' has COOP and A' and A are same origin. Today that means A doesn't have a WindowProxy for A', with this, I guess it would. But somehow only postMessage() would be available? Today, A and A' do not share a browsing context group and therefore have independent agent clusters. With this, unclear? Today, WindowProxy references are never shared outside a browsing context group. With this, unclear?

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 postMessage and allowing it to work across BCGs would be reasonable, or whether -- for example -- it's more appealing to make exemptions for BroadcastChannel to let it work across storage partitions in some cases (or implement WebID, or ...)

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 same-origin-allow-popups and unsafe-none were always meant for those use cases.

We also discussed allowing postMessage() and there were several implementation realities that made this infeasible (though I think for Firefox we're mostly past that now, including on mobile), but I also don't think we really tried to figure out what it would mean. And at this point I'd rather not add more tools to the popup workflow as they cause issues for anti-tracking and bfcache.

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:

1. Cross-origin isolation is gaining developer interest beyond what we (or at least I personally) expected, including ideas to enable it as the web default. We can't expect COI to be a niche thing for which developers are willing to jump through significant hoops.
2. Anti-tracking improvements (storage partitioning) are removing mechanisms that were possible alternatives for this use case at the time we decided we can punt on postMessage support in COOP. Even if developers can still use workarounds (say, link decoration), it's likely that they aren't the right long-term approach and we shouldn't push developers in their direction.

Having postMessage work for the popup workflow actually seems like the most compelling option from an anti-tracking point of view. Anti-tracking efforts don't restrict postMessage with your popups; the fact that you can't use it from a COI context is an artifact of how we specced COOP, rather than being dictated by privacy considerations. It seems worthwhile to think about what workarounds developers will develop here (which I'm worried may be objectively worse from both a privacy and complexity point of view).

I think the fact that anti-tracking hasn't tackled popups (including postMessage()) yet is precisely because of OAuth making it hard, but everyone is well aware that they present loopholes that ought to be closed.

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 postMessage to popups from non-COI contexts, which doesn't seem like it's on the horizon? Otherwise we're just punishing developers who do the right thing and enable COOP+COEP.

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 postMessage() in non-COI contexts in the medium term, something like this could possibly be a workable interim solution until WebID or a better alternative ships. It wouldn't provide sites with anything more than non-COI documents can do already (and we could hopefully limit the scope, as mentioned above), and it could prevent the proliferation of workarounds that are more likely to conflict with upcoming anti-tracking work.

I really think having postMessage broken with COOP is going to make it hard to implement for a lot of modern web applications, which have been pushed toward the greater security guarantees it provides vs historical approaches. I appreciate the nod to WebID, but there are plenty of cases where secure cross-origin communication is required that are not auth related.

After a few conversations with @camillelamy and @arturjanc, I wonder if we could take an alternate approach to those proposed above by hardening COOP: same-origin-allow-popups until we considered it solid enough to enable cross-origin isolation (in combination with an appropriate COEP, just as today). If we could do that, we wouldn't need to break the window handle, and postMessage could continue to work, without asking developers to do additional work.

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:

• For cross-origin windows, the web platform doesn't provide any synchronous communication channels. Process isolation is therefore possible on all platforms today in Chrome, and should be possible across platforms in Firefox once Project Fission ships (or perhaps this part is already shipping?). This is the interesting core of the payments and sign-in use cases, so it's nice that it works.

• For cross-origin-but-same-site windows, this could be possible if we tie a window's agent cluster to its origin if any COOP other than unsafe-none is asserted. This would break synchronous access patterns (via document.domain and WebAssembly.Module), bringing us to the same platform-level picture as cross-origin windows. This is similar to what's proposed in COOP same-origin and same-origin-allow-popups should key agent clusters to origin even without COEP #6177.

• For same-origin windows, we'd need to break synchronous communication between COI and non-COI contexts. That could be accomplished by taking the COI status of the new window into account when assigning the new window to an agent cluster (making the window appear closed if it asserts unsafe-none), or by doing something more dramatic, perhaps binding the COI status to the origin, much as we do with the origin's domain today? This direction is proposed in Restrict communication between same-origin documents in different pages with different COOP status #6178.

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 parent.opener. So I think it all comes down to how you would solve for that. (And it sounds like the proposal is to change the keying for agent clusters, presumably coupled with changing IsPlatformObjectSameOrigin, which seems sound, but also breaks new ground as @domenic notes.)

(I guess there's a larger question here of whether we want to encourage this pattern given the issues with popups.)

To be clear, even if the top-level window is cross-origin, that doesn't mean that all agent clusters "in that window" are.

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.

(I guess there's a larger question here of whether we want to encourage this pattern given the issues with popups.)

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.

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:

1. A [COOP: same-origin-allow-popups-plus-coep] iframes B1, opens B2 [COOP: unsafe-none] as a popup.
2. A1 [COOP: same-origin-allow-popups-plus-coep] opens B [COOP: unsafe-none] as a popup; B iframes A2.
3. A slight variant of the above: A1 [COOP: same-origin-allow-popups-plus-coep] embeds B1, opens A2 [COOP: unsafe-none] which embeds B2.

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.
Page 2's purpose is solely to enable the cross-origin interaction via postmessage because siteA-page1 enabled COOP+COEP to use SAB.
Site B is say some page related to the front-end SDK's company(say like a AWS SDK or Facebook SDK etc)

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, same-origin-allow-popups-plus-coep. This is set when a top level document sends a Cross-Origin-Opener-Policy: same-origin-allow-popups header and a Cross-Origin-Embedder-Policy: require-corp header. When a page has a COOP value of same-origin-allow-popups-plus-coep, its browsing context can be crossOriginIsolated if the user agent supports crossOriginIsolation.

In pages with COOP same-origin-allow-popups-plus-coep, agent clusters are keyed to origin. This is exactly like with COOP same-origin-plus-coep pages.

However, to make the crossOriginIsolation status of COOP same-origin-allow-popups-plus-coep work, we need to add one extra restriction. That is, documents whose top-level browsing contexts have different crossOriginIsolated status cannot have synchronous access to each other, and should only have access to the cross-origin WindowProxy methods. Maybe we can achieve that through keying agent clusters on crossOriginIsolated status as well, or maybe we need to add the crossOriginIsolated status as a parameter to determine if documents are same-origin or not (I am not really sure of the right way to spec this behavior).

My argument is that those restrictions are ok to apply to cross-origin subframes of the same-origin-allow-popups-plus-coep, because those subframes have set COEP require-corp. Which means that they have already opted into being loaded in a same-origin-plus-coep page, which has the following restrictions:

1. Agent clusters are keyed to origin.
2. Communication with documents in pages with different crossOriginIsolated status is impossible due to browsing context group switches.

So the restrictions we are putting on COOP same-origin-allow-popups-plus-coep pages are a subset of the restrictions in same-origin-plus-coep pages, which should be fine. Similarly, while documents in a popup opened by the same-origin-allow-popups-plus-coep page would not be able to interact synchronously with documents in the same-origin-allow-popups-plus-coep page, this is still better than no interaction at all in the same-origin-plus-coep page.

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:
https://github.com/hemeryar/explainers/blob/main/coop_restrict_properties.md

FWIW, I still like the policy name popup, but we can discuss that more once we've gotten some web developer feedback.

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 restrict-properties proposal looked like it would be adequate. One concern I do have is that we don't have control over the headers that the top-level site sends, and so it would be highly preferable if the solution didn't require changing those. We do have control over the code which loads the login popup and the headers that are sent for the iframe's HTML.

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 popup (singular as policy names usually are singular I think?) is still a reasonable name as the policy is both for popup endpoints and those making use of popup endpoints.

I could live with restrict-properties personally, but to me it's a bit vaguer and harder to spell. Maybe @domenic, @smaug----, or @jakearchibald have thoughts that could sway this one way or another?

I slightly prefer restrict-properties as when I'm thinking "what does this COOP policy do?" it's pretty easy to remember that restrict-properties is the one that gives me a restricted set of properties. Whereas I think of most/all COOP values as being related to popups, so popup doesn't really help me.

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, WindowProxy is problematic, since it includes synchronous access to the DOM same-origin, and I guess sync-ish access to location cross-origin. I didn't think it had anything to do with tracking prevention.

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 popup one more push. The way I'm thinking about it is that as a web developer, you want to answer the question "what policy do I want?". And popup is the clearest hint we can give web developers that either want to open popups or develop popup endpoints. And then when they read up on it they can find out it'll restrict properties and prevent sharing of shared memory, even when both sides are the same origin.

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 popup in this context so something like restrict-properties matches my mental model better.

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 windows.name readonly in RP mode? (I wouldn't mind hiding it entirely, e.g., returning the empty string, but that might be a bit much.)

(I still struggle to make much sense of restrict-properties by the way. In that yes, properties are restricted, but to me it doesn't really communicate the overall idea at all.)

what's the latest status on this?

Secure popup interactions with restrict-properties - Chrome Developers
https://developer.chrome.com/blog/coop-restrict-properties/

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?

The explainer says:

The basic COOP: restrict-properties idea would be to use a single BrowsingContext group, but to increase the keying of Agent Cluster. We would have multiple same-origin documents not be able to synchronously script each other, despite being able to reach each other's Window object.
Instead of increasing Agent Cluster keying, we introduce a new superset of BrowsingContext group, [...]

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 focus and close, as these functions are often used in popunder scenarios. We'd like to make this kind of attacks harder when targeting pages with COOP restrict-properties.

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

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