Reading through the discussion on the Mozilla standards position thread <https://github.com/mozilla/standards-positions/issues/628> I share the concern about the continued increase in complexity we're adding to the web platform with all these different security / isolation knobs. I will be the first to admit that I don't understand them all and have to keep looking up documentation to recover a partial understanding. But looking at the feedback from real users and seeing how folks are still relying on the SAB reverse OT <https://developer.chrome.com/blog/enabling-shared-array-buffer/#origin-trial>, I don't see any better option, and it certainly seems the team here has done their homework and is investing seriously in pragmatic measures to ease adoption of origin-level isolation (which is pretty clearly the right long-term architecture for the web). As is so often the case on the web, I think we have to take a step to the adjacent pragmatic option and trust that it'll lead to opportunities to simplify in the future as the ecosystem slowly updates. Also, since this feature is built on top of existing storage isolation primitives and is most useful for a small number of special cases like ad networks, it doesn't seem to me like it adds that much new complexity to the platform architecture.
I assume that at least one of the major customers (eg. Zoom, Google Display Ads, StackBlitz) has tried the OT and is satisfied with it's behavior and so is prepared to ramp up wide scale usage, is that right? Assuming so, then I think the benefit to shipping now outweighs the remaining interop risk and I trust the team to continue iterating in good faith in the standards community. LGTM1 to ship. Rick On Fri, Oct 28, 2022 at 4:20 PM 'Arthur Sonzogni' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > arthursonzo...@chromium.org, cl...@chromium.org > > Explainer > > https://github.com/WICG/anonymous-iframe > > Specification > > https://wicg.github.io/anonymous-iframe/#specification > > Design docs > > > https://docs.google.com/document/d/1poI75BaQ9aqcMGJn_K01-QHsQQbEOwRWvg3Af4VWTmY/edit > > Summary > > 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 > unblock developers looking to adopt cross-origin-isolation. > > This way, developers using COEP can now embed third party iframes that do > not. > > Blink component > > Blink>SecurityFeature > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature> > > > Search tags > > coep <https://chromestatus.com/features#tags:coep>, > cross-origin-embedder-policy > <https://chromestatus.com/features#tags:cross-origin-embedder-policy>, > iframe <https://chromestatus.com/features#tags:iframe>, anonymous > <https://chromestatus.com/features#tags:anonymous> > > TAG review > > https://github.com/w3ctag/design-reviews/issues/639 > > TAG review status > > Issues addressed > > Link to origin trial feedback summary > > > https://docs.google.com/document/d/1WzOrxIQnq9sTFkou9P8GshrQSeyO3MBdSvYqJjP410Q > <https://docs.google.com/document/d/1WzOrxIQnq9sTFkou9P8GshrQSeyO3MBdSvYqJjP410Q/edit> > > Risks > > 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 ( > https://github.com/mozilla/standards-positions/issues/628) > > They do like the concept of credentialless/anonymous iframes. > > However they are suggesting alternative ways of activating the feature. > Instead of the `anonymous` attribute, it could potentially be split into 3 > new sandbox flags for instance. One about allowing only partitioned > storage, one about allowing only no-opener popups, and one about disabling > autofill. It is not clear exactly how it would behave with regards to > sandbox inheritance, whether it would be understandable to developers, or > if introducing a precedent with `disallow-XXX` kind of flag as opposed to > `allow-XXX` would be problematic. > > WebKit: No signal ( > https://lists.webkit.org/pipermail/webkit-dev/2022-April/032205.html) > > Second request on Github: > https://github.com/WebKit/standards-positions/issues/45 > > Web developers: Positive (https://github.com/WICG/proposals/issues/53) > Zoom, Google Display Ads, StackBlitz are supportive. Several other > developers also expressed their need to get anonymous iframes to embed 3rd > party iframes inside crossOriginIsolated contexts. > > Other signals: N/A > > Ergonomics > > None. > > Activation > > A blog post explains how to use the feature: > > > https://groups.google.com/a/chromium.org/g/blink-dev/c/-7H19EHTenU/m/oWfFm21eAAAJ > > We don't expect developers having difficulties using it as-is. It only > requires adding the "anonymous" attribute to <iframe>. > > > Security > > See the threat model doc: > > https://wicg.github.io/anonymous-iframe/#security > > 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 > different. > > > Debuggability > > Anonymous iframes are designed to avoid breaking iframes. It does not > introduce new kinds of failures. > > In the devtool panel, when an iframe is blocked by COEP, Anonymous iframes > will be suggested as a potential solution. > > The JS API: `window.anonymouslyFramed` 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 believe this is worth it. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? > > Yes > > This is a web platform feature. Consistent behavior among all the > platforms is important. > > Weblayer is not supported, because disabling autofill hasn't been > implemented. > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > Yes > > DevTrial instructions > > https://anonymous-iframe.glitch.me > > Flag name > > --enable-blink-features=AnonymousIframe > > Requires code in //chrome? > > False > > Tracking bug > > https://bugs.chromium.org/p/chromium/issues/detail?id=1211800 > > Launch bug > > https://bugs.chromium.org/p/chromium/issues/detail?id=1342928 > > Measurement > > WebFeature::kAnonymousIframe > https://chromestatus.com/metrics/feature/timeline/popularity/4219 > > Non-OSS dependencies > > No dependencies. > > Sample links > > https://anonymous-iframe.glitch.me > > Estimated milestones > > > Chrome for desktop 109 > > OriginTrial desktop last 108 > > OriginTrial desktop first 106 > > DevTrial on desktop 105 > > > Chrome for Android 109 > > OriginTrial Android last 108 > > OriginTrial Android first 106 > > DevTrial on Android 105 > > > Android Webview 109 > > OriginTrial webView last 108 > > OriginTrial webView first 106 > > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > > N/A > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5729461725036544 > > Links to previous Intent discussions > > Intent to prototype: > https://groups.google.com/a/chromium.org/g/blink-dev/c/CjrLTguZuO4 > > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/-7H19EHTenU/m/oWfFm21eAAAJ > > Intent to Extend Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/-7H19EHTenU/m/oWfFm21eAAAJ > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > > > -- > 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAzos5HJbyTDnkf8nu89Q0fnt2E4%3DPNHSen84oxb1UbYdX882w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAzos5HJbyTDnkf8nu89Q0fnt2E4%3DPNHSen84oxb1UbYdX882w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8%2BZQv0PTiyTtAg%2BQfkFkcUtoK%2BnLorZp5FS7FF4r_mig%40mail.gmail.com.
