Hi, A few questions, is there any plan to move the spec code into HTML or other relevant specs? Do we have PRs for that?
There's another feature called "Fenced frames" (https://chromestatus.com/feature/5699388062040064) that is currently being worked on. Wouldn't be nice to explain how anonymous iframes vs fencedrames are? And if they interact in some way or not? Would fencedrames need an anonymous attribute at some point? Maybe we could add some of this information into the explainer. About the explainer, the one used in the TAG review is: https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md But now it seems to be integrated into the spec https://wicg.github.io/anonymous-iframe/ which is not very common. Also the explainer usually includes the problem, alternatives discussed and the like, and now they're like separated sections in the spec. Maybe some reformatting could be useful. I guess it'd be also nice to ensure we have proper documentation about this, "anonymous" attribute is not mentioned at MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe Cheers, Rego On 01/11/2022 16:54, Rick Byers wrote: > [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 > <mailto: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 <mailto:blink-dev@chromium.org>> wrote: > > > Contact emails > > arthursonzo...@chromium.org > <mailto:arthursonzo...@chromium.org>, cl...@chromium.org > <mailto:cl...@chromium.org> > > > Explainer > > https://github.com/WICG/anonymous-iframe > <https://github.com/WICG/anonymous-iframe> > > > Specification > > https://wicg.github.io/anonymous-iframe/#specification > <https://wicg.github.io/anonymous-iframe/#specification> > > > Design docs > > > https://docs.google.com/document/d/1poI75BaQ9aqcMGJn_K01-QHsQQbEOwRWvg3Af4VWTmY/edit > > <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 > <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 > <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 > <https://lists.webkit.org/pipermail/webkit-dev/2022-April/032205.html>) > > Second request on Github: > https://github.com/WebKit/standards-positions/issues/45 > <https://github.com/WebKit/standards-positions/issues/45> > > > Web developers: Positive > (https://github.com/WICG/proposals/issues/53 > <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 > > <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 > <https://wicg.github.io/anonymous-iframe/#security> > > http://go/anonymous-iframe-threat-model > <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 > <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 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1211800> > > > Launch bug > > https://bugs.chromium.org/p/chromium/issues/detail?id=1342928 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1342928> > > > Measurement > > WebFeature::kAnonymousIframe > https://chromestatus.com/metrics/feature/timeline/popularity/4219 > <https://chromestatus.com/metrics/feature/timeline/popularity/4219> > > > Non-OSS dependencies > > No dependencies. > > > Sample links > > > https://anonymous-iframe.glitch.me > <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 > <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 > <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 > > <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 > > <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 > <mailto: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 > <mailto: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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_tzxVa3J9Q-qL94O1O_x-%3DSRUqsFQ-ddv0ksagtcsUAw%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/72b0f399-3731-2c09-efc2-aba5b5a200de%40igalia.com.
