Hi @hemeryar first our apologies for taking so long to get you feedback on this review. After reviewing it this week and going back to review our work on #649 it's not clear from the material you've provided how you've addressed the issues & questions we raised in that review. Can you provide a little primer here on the changes? Thanks - we will endeavour to get you a response more quickly.

hi @hemeryar just a gentle ping on the above request. Can you let us know changes since our #649 review or any current status? Thanks.

Hi @torgo ! We are still iterating on the specific design as we speak, so I haven't taken the time to answer, sorry about that!

On your three points:

• We are concerned about anything that adds complexity to the web, confusing developers and making it harder for developers and site owners to produce websites. This proposal is substantially complex, though it does offer big benefits especially to users.

I agree that the proposal is complex, unfortunately, I don't see any simpler approach that does not rely on out-of-process-iframes. Since not all browsers have that capability, we have to twist the spec to make the process model possible.

• We are still interested to hear how use cases develop. In our meeting, we asked if there was an assumption that, for example, a bank will never want to surface a PDF of a customers' bank statement on another origin. It sounded like you might discover that that use case does — or doesn't — actually occur in the wild. It will be interesting to hear how the various groups impacted by this response.

This is something that is planned, we want to run an Origin Trial on Chrome in early 2023 to hear developer feedback of what they struggle with in the current proposal. One thing that is of particular interest to us is how named targeting would work. This is especially important if we want to make this a default in the distant future.

• We started a discussion with you all about how to shift the defaults on existing content to benefit from this proposal. On the one hand, that could be a very substantial shift for the web, which is always challenging. On the other hand, we are still behind our Evergreen Web finding and recognise that everything needs to upgrade. So we are interested to hear, in due course, how you want to explore this.

This is what we've worked on quite a bit in the design recently, and have decided that we would preserve same-origin same-header openers, as doing otherwise would very likely reduce to 0 the possibility that this proposal becomes a default. We're also looking at things like window.name restore, and targeting across pages and what would make acceptable default behaviors.

I think the Origin Trial should give us a better understanding of how this will be used what will be the blockers, and I can come back to this discussion with a bit more information to provide to the TAG :)

Cheers, Arthur

Hi @hemeryar thanks for this - much appreciated. It sounds like things are in flight and it might be better to wait for the results of the origin trial. The issue of developer complexity is an important one and one that keeps surfacing in the context of security-related specifications. So we would encourage you to please consider this thoroughly. If we build a more secure web platform but developers are unable to use it then we're not accomplishing the wider goal of securing the web. We'll check back by mid December to see where you are in the process.

Hi @hemeryar we're just checking up on this - have there been any updates or findings you can share?

Hi @torgo !

I've written a new explainer here with the latest developments: https://github.com/hemeryar/coi-with-popups. It's not complete but should give you a good idea of how the development process is going.

We've tried to adjust the design to make the feature as usable as possible to avoid having to add yet another policy in the future. This should work for all common cases. The current characteristics (same-origin same coop can DOM script, third party iframe can open functional popups, window.name gets restored after going back to a COOP: restrict-properties page, etc.) are designed for this purpose.

We're also planning on adding a new spec concept, the COOP group, which encompasses multiple browsing context groups that have limited access to each other. This allows us to modify the standard for non COOP: restrict-properties documents as little as possible. No new agent cluster keying, no new capabilities for browsing context groups, etc. If you're not interacting with the feature you shouldn't have to care about it. This hopefully helps a bit with the complexity.

We're also discussing a modification of how COOP origins are inherited and used, to support COOP: restrict-properties, but also to have a unified and (hopefully) more comprehensive behavior. See https://github.com/whatwg/html/issues/8481 and https://github.com/hemeryar/coi-with-popups/blob/main/docs/cross_origin_iframe_popup.MD.

We're hoping to start the OT early this year on Chrome side.

Thanks! Arthur

Hi @hemeryar we're happy to help. However (and I apologize if I sound like a broken record here) but I'm still missing discussion of user need in this explainer. What I guess I am looking for is a paragraph before https://github.com/hemeryar/coi-with-popups#why-does-crossoriginisolated-require-coop-same-origin (before the paragraph that starts "because of Spectre") that says something along the lines of "a common web usage pattern is this: users try to accomplish xxx goals; web sites use yyy technologies to create a user experience to service these goals. ZZZ information is exchanged in the following ways.... Because of Spectre this is put at risk in the following ways..."

I appreciate that this work is solving an important set of security problems for the web - however part of the TAG review is necessarily to understand how it fits into the overall set of user needs of the web platform.

Hi @torgo ! Thanks for the pointers, I think that will help us convince other vendors it is worth pursuing as well. I've added an intro section with actual requests we've had from websites. Just for a quick reference I'm adding them here as well:

• gmail.com wants to do memory measurement to diagnose performance. Some emails contain meet.com iframes which open a meeting when interacted with.
• zoom.com wants to use sharedArrayBuffers to reduce the copying of media data. It needs to support being opened from third-party apps, via an SDK.
• perfetto.dev, a trace visualization app, would like to use a more accurate performance.now() to improve performance. They use third-party popups to display traces without having them sent to their server.
• construct.com, an online game engine needs javascript threading for performance, but uses another domain for rendered game-preview popups.

Hi @torgo ! Thanks for the pointers, I think that will help us convince other vendors it is worth pursuing as well. I've added an intro section with actual requests we've had from websites. Just for a quick reference I'm adding them here as well:

• gmail.com wants to do memory measurement to diagnose performance. Some emails contain meet.com iframes which open a meeting when interacted with.
• zoom.com wants to use sharedArrayBuffers to reduce the copying of media data. It needs to support being opened from third-party apps, via an SDK.
• perfetto.dev, a trace visualization app, would like to use a more accurate performance.now() to improve performance. They use third-party popups to display traces without having them sent to their server.
• construct.com, an online game engine needs javascript threading for performance, but uses another domain for rendered game-preview popups.

These are all great examples of developer needs, but what @torgo was asking for are user needs.

Hi @hober! In all the above cases the user need is fast websites that have low memory usage. Without this change, websites that interact with popups (for varied reasons, as examples listed in my previous post hopefully showcase), will be slower than websites not using popups. Developers will have to make a choice between functionality and performance. The impact will be most visible on computation heavy websites, that can have huge improvements using things like WASM multi threading, unblocked by crossOriginIsolated.

Hi @hemeryar - this is getting dangerously close to documented user needs. :) I think it's just a matter of re-phrasing the above in terms of what user benefit they are providing. If it's just "faster web sites" that's fine. What I'm reading into the above is "Users will be able to experience more responsive web sites, especially on memory-constrained devices..." "More responsive game performance..." etc...? I know it may seem pedantic, but the intent here is to pin down who really benefits from the addition of this API to the platform, in line with the documented design principle of putting user needs first.

Hi @torgo ! Tentative rephrase:

• Users will be able to experience more responsive web sites, especially on memory-constrained devices.
• Users will be able to access more high computation services on the internet (game engines, photo editing, video conferencing, etc.) that would not be otherwise available or very slow.
• Users will be protected from Specter attacks while browsing the web.

Hope that's more in line with what you were expecting. Thanks!

I've written a new explainer here with the latest developments: https://github.com/hemeryar/coi-with-popups. It's not complete but should give you a good idea of how the development process is going.

The explainer says "Firefox: No Signals; Safari: No Signals." Have you asked anybody from Gecko or WebKit to take a look at this?

Hi @hemeryar thanks for that - it looks good - and sorry it took so long to get you that answer. A little more detail / context would be helpful. Do you have any feedback on the multi-stakeholder issue that @hober raised? Is there any other status you can let us know about? Have you had developer feedback on this design from the origin trial?

Hi @torgo, the origin trial will start in Chrome 116 (stable release Tue, Aug 15, 2023), and is expected to run for around 3 milestones, so we should get the first pieces of feedback outside Google in September. An important piece of context, is that Chrome still has unrestricted SharedArrayBuffer (not bound by COOP and COEP) behind a "reverse" Origin Trial, and that we are trying to remove it as quickly as possible without breaking existing uses. This prompts us to find solutions to the popup use cases more aggressively, without waiting for the wider adoption of other APIs that could replace popup uses in the long run (WebAuthn for example).

Firefox was involved in the original discussions, see (https://github.com/whatwg/html/issues/6364, mostly @annevk at the time). The proposal involves novel possibilities for the HTML spec (same-origin documents being able to reach each other but be considered cross-origin for example). The final consensus was that we would need to first demonstrate that it would solve developers issues and be a generally worthwhile addition to the web platform before being reviewed. That's what we aim for with the Origin Trial.

Hope that helps!

This came up today in a breakout during our TAG vF2F. We're looking forward to any insights you gain from the origin trial that you're about to run. We'll push off further review until after some data's come back and you have an update for us. Thanks!

I don't know if this is the place to comment about this, but the restricted-properties is useful, to allow our customers to have a more secure frontend implementation, while still letting us make use of the window.closed property, something we couldn't make work with the other values of the header. Our use-case is guiding a user to log in and provide access in an external site, and wait until the created window is closed, to check against our backend to see if we now have access or not.

@hemeryar we are picking this up again in our f2f - can you let us know any status / outputs of the trial? It looks to us like this has been overtaken/superseded by the coi-with-popups proposal? If so, what is the status of this proposal? Can we ask that you file a design review for that one? Noting also that this is appearing in someone's private repo - is it intended to go somewhere more official?

Hi @torgo,

I have picked the worked up from @hemeryar. We've since moved the proposal to the WICG. Here is a link to the WICG explainer. That said, following the Origin Trial that Chrome ran, we are rethinking our approach with regards to making crossOriginIsolation more deployable. In particular, there are still issues with deployability not solved by COOP: restrict-properties (3rd party frames and COEP). We're looking at whether we can solve those and the issue of COI with popups at the same time. This means that we are likely to modify our proposal of COOP: restrict-properties from what is currently written in the explainer.

@camillelamy thanks for that note. Has there been any progress or anything you'd like TAG feedback on?

Hi @camillelamy has there been any update on this? It looks like the explainer may have moved? Can you update? Thanks!

Hi @torgo, we have submitted a new API for TAG review that is meant to replace this proposal (new proposal: Document-Isolation-Policy). Do you still want me to update the explainer?

Since you're no longer pursuing this issue's proposal, could you update https://github.com/WICG/coop-restrict-properties to say that and archive its repository? I'll close this issue.