Anonymous iframe.

[ArthurSonzogni]

Introduction

Deploying COEP is difficult for some developers, because of third party iframes. Here is the typical scenario:

1. End users need performant websites.
2. Some developers get performant websites by using multithreading/SharedArrayBuffer in their top-level document.
3. To mitigate Spectre attacks, browsers vendors like Chrome, Firefox and Safari gate SharedArrayBuffer usage behind the crossOriginIsolated capability. This requires deploying both COEP and COOP
4. COEP requirement is recursive: To use COEP, all the <iframe> must also use COEP.
5. Waiting for third party to deploy COEP is painful for developers. This is almost always out of their control.

Beyond performance, there are additionnal features gated behind the crossOriginIsolated capability: high resolution timers, getViewportMedia, etc...

Deploying COEP is challenging in cases where there's not a single developer involved, but many.

Anonymous iframe gives developers a way to load documents in a third party iframe from a new and ephemeral context, scoped to the current page. In return, the Cross-Origin-Embedder-Policy (COEP) embedding rules can be lifted.

This way, developers using COEP can now embed third party iframes that do not set COEP.

See repository

Links

• The problem
• Explainer
• Alternatives considered
• Tests
• Demo
• Specification
• Security considerations
• Privacy considerations
• Self-Review Questionnaire: Security and Privacy

Feedback

Zoom, StackBlitz, and Google Display Ads are supportive.
For instance, the latter loads ads content in iframes. The content can be served from 3rd parties, which is out of their direct control. It takes an industry-wide change and opt-in every resource for ads to work properly. It seems somewhat unlikely that they'll be able to ensure that all the ads creators will do the work. Implementing Anonymous-iframe would allow all publishers to get out of the SAB reverse origin trial.

Twitter:
Twitter is very close to ship COEP:credentialless, modulo patching React and completing a few de-iframing tasks. So they will probably not need anonymous iframe to enable crossOriginIsolation. I will get more detailed feedback soon. For now:

Generally though, along the lines of the same-origin-allow-popups, if it can be done securely, this seems like a reasonable thing to support. My only hesitation would be that adding it means it's likely people will use this and never actually lean on the iframed site to upgrade.

---

+CC @mikewest @camillelamy @annevk @whatwg/cross-origin-isolation

[mikewest]

@yoavweiss Is the developer feedback provided here enough support to move Arthur's repo to WICG?

[ArthurSonzogni]

@yoavweiss just asked me if I could get the persons above to speak directly here. I will ask them.

[deng4437]

Since SharedArrayBuffer strategy was activated last year, Zoom team has started deploying COEP.
By now it has still been difficult for Zoom team to make sure COEP is properly deployed for all 3rd party iframes.
We are looking forward to new workarounds like Anonymous iframe to make the jobs easier.

[yoavweiss]

Thanks for chiming in @deng4437!
@ArthurSonzogni - feel free to transfer the repo to me and I'll take it from there.

[yoavweiss]

The repo is now live at https://github.com/WICG/anonymous-iframe

Happy incubating!!

[zhengweiwithoutthei]

Ads doesn't work on COEP sites right now. This is because ads loads and embed cross-origin contents. It takes an slow and expensive industry-wide change to opt in CORP for every resource for ads to continue work. We are looking forward to this workaround to support ads on COEP sites.

[SamVerschueren]

Hi everyone 👋 !

I'm a software engineer working on the WebContainers technology at StackBlitz. For WebContainers, we heavily rely on SharedArrayBuffer and thus have to use cross-origin isolation with COOP/COEP. I recently blogged about cross-browser support with cross-origin isolation which explains all the hurdles we ran into while implementing this.

StackBlitz uses an iframe to preview the users website next to the code on the same page. Because the top-level website is cross-origin isolated, the iframe itself has to be served with COEP: require-corp as well (in Chrome we can use COEP: credentialless). This means that all external images, loaded from an asset server for instance, have to be served with the appropriate CORP: cross-origin header. If that's not the case, it does not work.

We even received an issue because of this a couple of days ago. And you can easily try it out for yourself by opening hydrogen.new in Firefox. Scrolling down a bit shows that the images of the products can not be loaded because they are loaded from cdn.shopify.com without the appropriate CORP header.

If we could use anonymous iframes here, we could lift the restriction of serving the embedded iframe with COEP: require-corp and our users wouldn't run into these issues. So for StackBlitz, being able to use anonymous iframes, would actually help a lot. We can control what our website loads (to some level), but we cannot control what users try to load in their browsers.

[yoavweiss]

Thanks for chiming in! That seems like enough support to move the repo over.
@ArthurSonzogni - feel free to ping me offline RE the transfer.

[ArthurSonzogni]

Thanks everyone!

Thanks for chiming in! That seems like enough support to move the repo over.
@ArthurSonzogni - feel free to ping me offline RE the transfer.

Thanks, but I believe you already did the transfer, don't you?

[yoavweiss]

I am confused... You indeed did. apologies for the noise