COOP: restrict-properties early review

[hemeryar]

Wotcher TAG!

I'm requesting a TAG review of a new value for Cross-Origin-Opener-Policy: "restrict-properties".

This is the second iteration of trying to have crossOriginIsolated while interacting with cross-origin popups. The goal is still the same: be able to benefit from powerful APIs like SharedArrayBuffer without breaking interaction with cross-origin popups like Auth flows or payments.

• Explainer¹ (minimally containing user needs and example code): [url]
• Security and Privacy self-review²: [url]
• Primary contacts (and their relationship to the specification):
  • [Arthur Hemery] ([github username]), [Google]
  • [Camille Lamy] ([github username]), [Google]
• Organization/project driving the design: [Google]
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5072630953017344

Further details:

• [ X] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WHATWG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: Allowing top-level communication for cross-origin isolated documents  whatwg/html#6364
• Major unresolved issues with or opposition to this design: We'll be running an origin trial on Chrome to verify that there are no deployment blockers for web developers. The spec agreement should follow once we've demonstrated (or not) that this solution works.
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as :
💬 leave review feedback as a comment in this issue and @-notify [hemeryar]

[torgo]

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.

[torgo]

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.

[hemeryar]

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

[torgo]

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.

[hemeryar]

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 (whatwg/html#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!

[hober]

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!

[spersico]

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.

[torgo]

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

[camillelamy]

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.

[torgo]

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

[torgo]

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

[camillelamy]

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?

[jyasskin]

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.