[Removing internal-only chrome-security-owp-team list] Sorry, one more question: the tests seem to be mostly failing on wpt.fyi <https://wpt.fyi/results/html/anonymous-iframe?label=master&label=experimental&aligned&view=subtest&q=html%2Fanonymous-iframe> even with --enable-experimental-web-platform-features. Do you know why that is? What's the status of the test suite?
On Tue, Nov 1, 2022 at 11:29 AM Rick Byers <rby...@chromium.org> wrote: > 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/CAFUtAY_tzxVa3J9Q-qL94O1O_x-%3DSRUqsFQ-ddv0ksagtcsUAw%40mail.gmail.com.
