Intent to Ship: Anonymous iframes

[Arthur Sonzogni]

Contact emails

arthurs...@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

 

Search tags

coep, cross-origin-embedder-policy, iframe, 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

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?

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.

[Rick Byers]

Reading through the discussion on the Mozilla standards position thread 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, 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

--
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+...@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.

[Rick Byers]

[Removing internal-only chrome-security-owp-team list]

Sorry, one more question: the tests seem to be mostly failing on wpt.fyi even with --enable-experimental-web-platform-features. Do you know why that is? What's the status of the test suite?

[Manuel Rego Casasnovas]

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

> <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
>
> Contact emails
>
> arthurs...@chromium.org
> <mailto:arthurs...@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

> <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/>

> 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+...@chromium.org

> <mailto:blink-dev+...@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+...@chromium.org

> <mailto:blink-dev+...@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>.

[Arthur Sonzogni]

Sorry for the delay, I was Travelling, OOO, then Covid.

Sorry, one more question: the tests seem to be mostly failing on wpt.fyi even with --enable-experimental-web-platform-features. Do you know why that is? What's the status of the test suite?

Thanks for noticing. That was about how the feature is declared. Let's fix it.

A few questions, is there any plan to move the spec code into HTML or
other relevant specs? Do we have PRs for that?

Yes & Yes.
The anonymous iframe spec is a set of small patches against the HTML, Fetch, Storage, and Cookie specification.

A link to described patch is given before each section:

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.

There are 2 WPT and a doc. I agree adding a section direction in the explainer would be useful. I will do it.

TLDR: FencedFrame and anonymous iframe are totally different/unrelated. Since <fencedframe> must not learn about its embedder, if you embed inside an <iframe anonymous> a <fencedframe>, it has no effect and the FencedFrame is still subject to COEP. The other way around works the way 

 

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.

I agree. The first explainer was added inside camillelamy/explainer repo. That's not great, because it contains several unrelated explainers. I had to create a new one so that it can be transferred under the WICG: WICG/anonymous-iframe. Having said that, we can't go back into the past.

 

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.

They are all in the same doc today. Are you suggesting splitting it into a separate markdown file?

I am not sure what the benefits would be. For those used to github, there are links to each section.

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

That would be lovely. I guess a PR against this file in Mozilla repository is the proper way to make this happen. I will try.

[Arthur Sonzogni]

Hi blink-dev,

We decided to address issue #5: “rename anonymous iframe into iframe credentialless”. We will rename <iframe anonymous> to <iframe credentialless>.

For this adjustment to take place, the new plan is to ship in M110 instead of M109. We do not think the origin trial will need to be extended, since partners have been or will be able to test up to M108. Therefore, there will be a gap between the original trial and launch version.

However, renaming from anonymous to credentialless will not answer Mozilla's core argument. They believe that the feature would be best controlled via multiple new sandbox flags. We think it is much less ergonomic and makes the feature harder to explain to developers. The integration with sandbox flags has challenging open questions around edge cases, as listed in this document. 

Considering this, we think the current solution is a better one. We have feedback from partners that it solves their needs. Considering that we have no clear feedback Mozilla would be interested in implementing anonymous iframes even if they were spelled as sandbox flags, we believe we should ship with what we have implemented.

[Smaug]

> They believe that the feature would be best controlled via multiple new sandbox flags.

I don't think anyone from Mozilla has said that. What I have said is that the current way to control how iframes work is getting very complicated and the new attribute adds yet another mechanism. And if most of the users will use both sandbox and credentialless, understanding how those work together can be rather confusing. Also, credentialless isn't exposing the primitives itself, but some unique set of features. I'd rather see primitives to be

exposed and other features built on top of them.


-Olli

[Olli Pettay]

On 11/10/22 10:33, 'Arthur Sonzogni' via blink-dev wrote:
> Hi blink-dev,
>
> *
> *
>
> We decided to address issue #5 <https://github.com/WICG/anonymous-iframe/issues/5>: “rename anonymous iframe into iframe credentialless”. We will

> rename <iframe anonymous>to <iframe credentialless>.
>
> For this adjustment to take place, the new plan is to ship in M110 instead of M109. We do not think the origin trial will need to be extended, since
> partners have been or will be able to test up to M108. Therefore, there will be a gap between the original trial and launch version.
>
> However, renaming from anonymous to credentialless will not answer Mozilla's core argument. They believe that the feature would be best controlled via
> multiple new sandbox flags.

I don't think anyone from Mozilla has said that. What I have said is that the current way to control how iframes work is getting very complicated and
the new attribute adds yet another mechanism. And if most of the users will use both sandbox and credentialless, understanding how those work together
can be rather confusing. Also, credentialless isn't exposing the primitives itself, but some unique set of features. I'd rather see primitives to be
exposed and other features built on top of them.


-Olli

We think it is much less ergonomic and makes the feature harder to explain to developers. The integration with sandbox
> flags has challenging open questions around edge cases, as listed in this document

> <https://github.com/WICG/anonymous-iframe/blob/main/mozilla-sandbox-proposal.md>.
>
> *
> *

>
> Considering this, we think the current solution is a better one. We have feedback from partners that it solves their needs. Considering that we have
> no clear feedback Mozilla would be interested in implementing anonymous iframes even if they were spelled as sandbox flags, we believe we should ship
> with what we have implemented.
>
>

> --
> 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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAzos5GDYwk7ohTD4Eq2TW43hU%3DrHfXsx2V7%2BVK%3DHdKNd02-TA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAzos5GDYwk7ohTD4Eq2TW43hU%3DrHfXsx2V7%2BVK%3DHdKNd02-TA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Zheng Wei]

Google Display Ads (GPT specifically) has tried the OT and is satisfied with the feature's behavior. Looking forward to it!

[Rick Byers]

Discussed in the API owners meeting yesterday. It sounds like work is ongoing to fully resolve issue #5 including a good discussion at WebAppSec WG yesterday (summary in the Mozilla standards position issue). Arthur, let us know when you think decisions are captured sufficiently for API owners to re-evaluate.

Thanks,

   Rick

[Arthur Sonzogni]

On Thu, Nov 17, 2022 at 11:50 PM Rick Byers <rby...@chromium.org> wrote:

Discussed in the API owners meeting yesterday. It sounds like work is ongoing to fully resolve issue #5 including a good discussion at WebAppSec WG yesterday (summary in the Mozilla standards position issue).

 

 issue #5 has been implemented. Anonymous iframe is now renamed: iframe credentialless. The implementation is ready to ship for M110.

After the webappsec meeting with Dan Veditz. I asked on this Mozilla standard position thread how we might reach agreement or what action to take instead. I don't believe we came to anything close to that. So far, I haven't had any luck getting additional responses.

Arthur, let us know when you think decisions are captured sufficiently for API owners to re-evaluate.

I'm not sure how to progress beyond that. So I think the API owner can now re-evaluate. 

Arthur @arthursonzogni

[Rick Byers]

Thanks for driving the naming issue to resolution Arthur. Given the lack of engagement on the mozilla standards position issue, I don't see anything else concrete that should block shipping. I also think we could make an investment in negative sandbox flags independently if there were consensus that it was the right thing to do, but that's also a very long running debate (eg. we went over it with the introduction of feature policies and the 'allow' attribute years ago). 

LGTM1

[Yoav Weiss]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_q53fj%2BKGD0sVBkPR8waqq9CwZzp9w9FLLwq-UryGY7w%40mail.gmail.com.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUh3N5jRib7hVKFicubRozdMCHOcb8rOZzM0q%3DHG3ZLeg%40mail.gmail.com.