Intent to Experiment: Anonymous iframes

Skip to first unread message

Arthur Sonzogni

Jul 27, 2022, 9:34:56 AM7/27/22

Contact emails



Design docs


Anonymous iframes give developers a way to load documents in third party iframes using new and ephemeral contexts. Anonymous iframes are a generalization of COEP credentialless to support 3rd party iframes that may not deploy COEP. Like with COEP credentialless, we replace the opt-in of cross-origin subresources by avoiding to load non-public resources. This will remove the constraint that 3rd party iframes must support COEP in order to be embedded in a COEP page and will unblock developers looking to adopt cross-origin-isolation. This way, developers using COEP can now embed third party iframes that do not.

Blink component


Search tags


TAG review

TAG review status

Issues addressed


Interoperability and Compatibility

The main risk is that anonymous iframes fail to become an interoperable part of the web platform if other browsers do not implement the API.

Gecko: No signal (

WebKit: No signal (

Web developers: Positive ( Zoom, Google Display Ads, StackBlitz are supportive. Several other developer also expressed their need to get anonymous iframe to embed 3rd party iframes inside crossOriginIsolated contexts.

Other signals:




We are going to publish a blog post: We don't expect developers having difficulties using is as-is. It only requires adding the "anonymous" attribute to <iframe>.


See the threat model doc: http://go/anonymous-iframe-threat-model

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No risks identified. This is platform independent. WebView is not an exception.

Goals for experimentation

- Double check the feature makes sense given large developers like Google Ads and Zoom. - Confirm this resolves the difficulties deploying COEP and understand any limitations. - Get feedback about the shape of the API. - Understand if developers need additional APIs to use it. For instance: or others.

Reason this experiment is being extended

Ongoing technical constraints



Anonymous iframes were designed to avoid breaking iframes. They do not introduce new kinds of failures. In the devtool issue explaining an iframe was blocked by COEP, Anonymous iframes will be suggested as a potential solution. The JS API: `window.isAnonymouslyFramed` already reflects whether a document is embedded inside an anonymous iframe or not. This is not reflected in devtool yet, but it could be in the future, if we think this is worth it.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


This is a web platform feature. Consistent behavior among all the platforms is important.

Is this feature fully tested by web-platform-tests?


DevTrial instructions

Flag name


Requires code in //chrome?


Tracking bug

Launch bug

Estimated milestones

OriginTrial desktop last108
OriginTrial desktop first106
DevTrial on desktop105
OriginTrial Android last108
OriginTrial Android first106
DevTrial on Android105
OriginTrial webView last108
OriginTrial webView first106

Link to entry on the Chrome Platform Status

Links to previous Intent discussions

Intent to prototype:

This intent message was generated by Chrome Platform Status.

Mike Taylor

Jul 27, 2022, 12:19:59 PM7/27/22
to Arthur Sonzogni, blink-dev
LGTM to experiment from M106 to M108 (I think that's the range you're requesting, please let me know if I'm reading it wrong).
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Reply all
Reply to author
0 new messages