Re: [blink-dev] Intent to Ship: Anonymous iframes

[Mike Taylor]

LGTM3

On 11/30/22 7:19 AM, Yoav Weiss wrote:

LGTM2

On Wed, Nov 30, 2022 at 4:17 PM Rick Byers  wrote:

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


On Wed, Nov 30, 2022 at 9:12 AM Arthur Sonzogni
 wrote:

On Thu, Nov 17, 2022 at 11:50 PM Rick Byers
 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


On Thu, Nov 17, 2022 at 11:50 PM Rick Byers
 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
).
Arthur, let us know when you think decisions are captured
sufficiently for API owners to re-evaluate.

Thanks,
   Rick

On Mon, Nov 14, 2022 at 11:22 AM Zheng Wei
 wrote:

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

On Thursday, November 10, 2022 at 10:06:35 AM UTC-5
Smaug wrote:

On 11/10/22 10:33, 'Arthur Sonzogni' via blink-dev
wrote:
> Hi blink-dev,
>
> *
> *
>
> We decided to address issue #5
:
“rename anonymous iframe into iframe
credentialless”. We will
> rename to .
>
> 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.

Re: [blink-dev] Intent to Ship: Anonymous iframes

[Yoav Weiss]

LGTM2

On Wed, Nov 30, 2022 at 4:17 PM Rick Byers  wrote:

> 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
>
>
> On Wed, Nov 30, 2022 at 9:12 AM Arthur Sonzogni 
> wrote:
>
>> On Thu, Nov 17, 2022 at 11:50 PM Rick Byers  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
>>
>>
>> On Thu, Nov 17, 2022 at 11:50 PM Rick Byers  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
>>> ). Arthur,
>>> let us know when you think decisions are captured sufficiently for API
>>> owners to re-evaluate.
>>>
>>> Thanks,
>>>Rick
>>>
>>> On Mon, Nov 14, 2022 at 11:22 AM Zheng Wei  wrote:
>>>
 Google Display Ads (GPT specifically) has tried the OT and is satisfied
 with the feature's behavior. Looking forward to it!

 On Thursday, November 10, 2022 at 10:06:35 AM UTC-5 Smaug wrote:

> 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 to .
> >
> > 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 

Re: [blink-dev] Intent to Ship: Anonymous iframes

[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


On Wed, Nov 30, 2022 at 9:12 AM Arthur Sonzogni 
wrote:

> On Thu, Nov 17, 2022 at 11:50 PM Rick Byers  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
>
>
> On Thu, Nov 17, 2022 at 11:50 PM Rick Byers  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
>> ). Arthur,
>> let us know when you think decisions are captured sufficiently for API
>> owners to re-evaluate.
>>
>> Thanks,
>>Rick
>>
>> On Mon, Nov 14, 2022 at 11:22 AM Zheng Wei  wrote:
>>
>>> Google Display Ads (GPT specifically) has tried the OT and is satisfied
>>> with the feature's behavior. Looking forward to it!
>>>
>>> On Thursday, November 10, 2022 at 10:06:35 AM UTC-5 Smaug wrote:
>>>
 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 to .
 >
 > 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
 > .
 > To view this discussion on 

Re: [blink-dev] Intent to Ship: Anonymous iframes

['Arthur Sonzogni' via blink-dev]

On Thu, Nov 17, 2022 at 11:50 PM Rick Byers  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


On Thu, Nov 17, 2022 at 11:50 PM Rick Byers  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 ).
> Arthur, let us know when you think decisions are captured sufficiently for
> API owners to re-evaluate.
>
> Thanks,
>Rick
>
> On Mon, Nov 14, 2022 at 11:22 AM Zheng Wei  wrote:
>
>> Google Display Ads (GPT specifically) has tried the OT and is satisfied
>> with the feature's behavior. Looking forward to it!
>>
>> On Thursday, November 10, 2022 at 10:06:35 AM UTC-5 Smaug wrote:
>>
>>> 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 to .
>>> >
>>> > 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
>>> > .
>>> > 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_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 

Re: [blink-dev] Intent to Ship: Anonymous iframes

[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

On Mon, Nov 14, 2022 at 11:22 AM Zheng Wei  wrote:

> Google Display Ads (GPT specifically) has tried the OT and is satisfied
> with the feature's behavior. Looking forward to it!
>
> On Thursday, November 10, 2022 at 10:06:35 AM UTC-5 Smaug wrote:
>
>> 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 to .
>> >
>> > 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
>> > .
>> > 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_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/CAFUtAY8gC_JwdvBhEoNnsudDVRZ40GwHyP84c0_fb0FxymwpkQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Anonymous iframes

['Zheng Wei' via blink-dev]

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

On Thursday, November 10, 2022 at 10:06:35 AM UTC-5 Smaug wrote:

> 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 to .
> > 
> > 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 
> > .
> > 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_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/19690d52-500e-4b40-8899-b2dd5811b11bn%40chromium.org.

Re: [blink-dev] Intent to Ship: Anonymous iframes

[Olli Pettay]

On 11/10/22 10:33, 'Arthur Sonzogni' via blink-dev wrote:

Hi blink-dev,

*
*

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


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 
.


*
*

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


--
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/eaf7cf6c-b3a8-a263-3d32-47d373743540%40gmail.com.

Re: [blink-dev] Intent to Ship: Anonymous iframes

[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

On Thursday, November 10, 2022 at 10:33:43 AM UTC+2 Arthur Sonzogni wrote:

> Hi blink-dev,
>
>
> We decided to address issue #5 
> : “rename anonymous 
> iframe into iframe credentialless”. We will rename  to 
>  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.
>
>
>

-- 
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/0636fd6f-b37a-451c-a628-df5544b1de3cn%40chromium.org.

Re: [blink-dev] Intent to Ship: Anonymous iframes

['Arthur Sonzogni' via blink-dev]

Hi blink-dev,


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

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.

-- 
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/CAAzos5GDYwk7ohTD4Eq2TW43hU%3DrHfXsx2V7%2BVK%3DHdKNd02-TA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Anonymous iframes

['Arthur Sonzogni' via blink-dev]

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:
[image: image.png]

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  must not learn about its embedder, if you embed inside
an  a , 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.

-- 
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/CAAzos5HypUV7mKcgtTVAoine88LqC5qOd0qsWho9MYetYUtRnA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Anonymous iframes

[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
> 
>  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  > wrote:
> 
> 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
> 
> 
> On Fri, Oct 28, 2022 at 4:20 PM 'Arthur Sonzogni' via blink-dev
> mailto: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.
> 
> 

Re: [blink-dev] Intent to Ship: Anonymous iframes

[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?

On Tue, Nov 1, 2022 at 11:29 AM Rick Byers  wrote:

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

Re: [blink-dev] Intent to Ship: Anonymous iframes

[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


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

[blink-dev] Intent to Ship: Anonymous iframes

['Arthur Sonzogni' via blink-dev]

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



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 .


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