diff --git a/anonymous_iframe1.png b/anonymous_iframe1.png deleted file mode 100644 index 284d0b2..0000000 Binary files a/anonymous_iframe1.png and /dev/null differ diff --git a/anonymous_iframe2.png b/anonymous_iframe2.png deleted file mode 100644 index 4d4de81..0000000 Binary files a/anonymous_iframe2.png and /dev/null differ diff --git a/anonymous_iframe3.png b/anonymous_iframe3.png deleted file mode 100644 index 7283643..0000000 Binary files a/anonymous_iframe3.png and /dev/null differ diff --git a/anonymous_iframes.md b/anonymous_iframes.md index 1d5b5a0..f3944ee 100644 --- a/anonymous_iframes.md +++ b/anonymous_iframes.md @@ -1,30 +1,73 @@ # Anonymous iframes -Author: clamy@google.com - Last Updated: 2021-05-06 +- **Author**: clamy@google.com, arthursonzogni@google.com +- **Created**: 2021-05-06 +- **Last Updated**: 2021-11-10 -## A problem - -Sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation. Among other things, cross-origin isolation will block the use of cross-origin resources and documents unless those resources opt-into inclusion via either CORS or CORP. This behavior ships today in Firefox, and Chrome aims to ship it as well in Chrome 92. - -CrossOriginIsolation is also being used to gate new features, including features that require additional opt-in in addition to crossOriginIsolation, like [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/issues/155#issuecomment-812269225). +## Table of content +- [A problem](#a-problem) +- [A proposal](#a-proposal) +- [Security and privacy considerations](#security-and-privacy-considerations) +- [Alternatives considered](#alternatives-considered) +- [Self-Review Questionnaire: Security and Privacy](#self-review-questionnaire--security-and-privacy) -The opt-in requirement is generally positive, as it ensures that developers have the opportunity to adequately evaluate the rewards of being included cross-site against the risks of potential data leakage via those environments. It poses adoption challenges, however, as it does require developers to adjust their servers to send an explicit opt-in. This is challenging in cases where there's not a single developer involved, but many. Google Ads, for example, includes third-party content, and it seems somewhat unlikely that they'll be able to ensure that all the ads creators will do the work to opt-into being loadable. +## A problem -It seems clear that adoption of any opt-in mechanism is going to be limited. From a deployment perspective (especially with an eye towards changing default behaviors), it would be ideal if we could find an approach that provided robust-enough protection against accidental cross-process leakage without requiring an explicit opt-in. We presented a first version of this mechanism in [Credentiallessness](https://github.com/mikewest/credentiallessness), which evolved into COEP credentialless. This new mode of COEP tackles subresources included in a frame. It is a good solution for deploying COEP when one includes cross-origin subresources without CORP headers, that come from a CDN for example. However, we still need to ease deployment of COEP for pages that embed cross-origin frames. +Deploying COEP is difficult for some developers, because of 3rd party iframes. +This is the typical scenario: + +1. End users needs performant websites. +2. Some developers get performant website, by using + multithreading/SharedArrayBuffer on the main document. +3. To mitigate Spectre attacks: Chrome, Firefox and Safari + gate SharedArrayBuffer usage behind the [crossOriginIsolated][coi] + capability. This requires [COOP and COEP][coop-coep]. +4. COEP requirement is recursive: 3rd party iframes are required to deploy COEP + in order to be embeddable inside a COEP parent. +5. Waiting for 3rd party to deploy COEP is painful for developers. This is out + of their control most of the time. + +Outside of performance, there are additionnal reasons website want to deploy +COEP: Getting the [cross-origin-isolated capability][coi], [high resolution +timers][highres-timer], [getViewportMedia][getViewPortMedia], etc... + +[coi]: https://html.spec.whatwg.org/#concept-settings-object-cross-origin-isolated-capability +[highres-timer]: https://www.w3.org/TR/hr-time/#:~:text=if%20crossoriginisolatedcapability%20is%20true +[getViewPortMedia]: https://github.com/w3c/mediacapture-screen-share/issues/155#issuecomment-812269225 +[coop-coep]: https://web.dev/coop-coep/ +[coep-credentialless]:https://wicg.github.io/credentiallessness/ + +Deploying COEP is challenging in cases where there's not a single developer +involved, but many. Google Ads, for example, includes third-party content, and +it seems somewhat unlikely that they'll be able to ensure that all the ads +creators will do the work to opt-into being loadable. ## A proposal -COEP, and the opt-in mechanism for [getViewportMedia](https://github.com/w3c/mediacapture-screen-share/issues/155#issuecomment-812269225) currently tackles data leak attacks by ensuring that cross-origin resources explicitly opt into being loaded in an environment with higher risks. This way, servers can protect vulnerable resources by not having them opt into being loaded in high risk environments. COEP cors-or-credentialles and the mechanism we are proposing, anonymous iframes, take a different approach. Instead of requiring opt-in to protect vulnerable resources, we aim to only make requests that result in public data being loaded in high-risk environments. Essentially, this means preventing personalized resources from being loaded. +It would be ideal if we could find an approach that provided robust-enough +protection against accidental cross-process leakage without requiring an +explicit opt-in. + +COEP, and the opt-in mechanism for [getViewportMedia][getViewportMedia] +currently tackles data leak attacks by ensuring that cross-origin resources +explicitly opt into being loaded in an environment with higher risks. This way, +servers can protect vulnerable resources by not having them opt into being +loaded in high risk environments. [COEP:credentialless][coep-credentialless] and +the mechanism we are proposing, anonymous iframes, take a different approach. +Instead of requiring opt-in to protect vulnerable resources, we aim to only make +requests that result in public data being loaded in high-risk environments. +Essentially, this means preventing personalized resources from being loaded. ### What are anonymous iframes? Documents can create anonymous iframes by adding an attribute to the iframe tag: -`