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
> <https://github.com/WICG/anonymous-iframe/issues/5> including a good
> discussion at WebAppSec WG yesterday (summary in the Mozilla standards
> position issue <https://github.com/mozilla/standards-positions/issues/628>).
>
>

 issue #5 <https://github.com/WICG/anonymous-iframe/issues/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
<https://github.com/mozilla/standards-positions/issues/628#issuecomment-1318940625>
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
> <https://github.com/WICG/anonymous-iframe/issues/5> including a good
> discussion at WebAppSec WG yesterday (summary in the Mozilla standards
> position issue <https://github.com/mozilla/standards-positions/issues/628>).
> 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 gro

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.

[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

https:

Re: [blink-dev] Intent to Ship: Cross-Origin-Embedder-Policy: credentialless

['Arthur Sonzogni' via blink-dev]

> That makes sense, but maybe there's a way for us to combine this and the
recent PNA intent
<https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ>
and
be more bold there only in the case of a COEP: credentialless embedder?

That's an interesting idea! I think it's worth considering when PNA will
have an implementation of preflight checks. For now, it doesn't and I would
like to avoid tying two features together during a launch.
Moreover, this would still not bring better than the status-co for now,
because the SAB OT remains.

However, this is a nice subset to experiment/launch PNA earlier. Maybe we
can be more aggressive here. The subset might be COEP:credentialless,
COEP:X, COI.
This would require adding some metrics to understand exactly how many pages
would be affected by PNA in every subset. I think we will add some metrics
for M96 as well and make a decision based on that.

Arthur @arthursonzogni


Le ven. 10 sept. 2021 à 14:22, Yoav Weiss  a écrit :

> Thanks for working on this! This seems like a great addition to the
> CrossOriginIsolation story, and will help developers make their users safer
> in the face of non-cooperative third parties.
>
> On Fri, Sep 10, 2021 at 1:17 PM 'Arthur Sonzogni' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsarthursonzo...@chromium.org, cl...@chromium.org,
>> mk...@chromium.org
>>
>> Explainerhttps://github.com/WICG/credentiallessness
>>
>> Specificationhttps://wicg.github.io/credentiallessness/
>>
>> Design docs
>> https://github.com/WICG/credentiallessness
>>
>> https://docs.google.com/document/d/1U1pDzS_WJpfkq6QqOeqgmXmba_I4tIbUR-5C1AHzI9o/edit#
>>
>> Summary
>>
>> Introduce Cross-Origin-Embedder-Policy: credentialless. This causes
>> cross-origin no-cors requests to omit credentials (cookies, client
>> certificates, etc). Similarly to COEP:require-corp, it can enable
>> cross-origin isolation.
>>
>>
>> Blink componentBlink>SecurityFeature
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature>
>>
>> Search tagscoep <https://chromestatus.com/features#tags:coep>,
>> credentialless <https://chromestatus.com/features#tags:credentialless>,
>> coop <https://chromestatus.com/features#tags:coop>, crossoriginisolation
>> <https://chromestatus.com/features#tags:crossoriginisolation>,
>> crossOriginisolated
>> <https://chromestatus.com/features#tags:crossOriginisolated>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/582
>>
>> TAG review statusPending
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/document/d/1Rcho9z8obW0A7aeM3Zz1QR3fN7KcmTHgjdF_mKEXiRQ
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Compatibility risk: This is an opt-in new feature, so there are no
>> compatibility risks. Interoperability risk: New feature. Risk is failing to
>> become an interoperable part of the web platform.
>>
>>
>> Gecko: Worth prototyping (
>> https://github.com/mozilla/standards-positions/issues/539#issuecomment-867473836
>> )
>> Worth prototyping, but concerns are about the timing in between shipping:
>> COEP:credentialless, Private Network Access (PNA), ORB. See
>> https://github.com/mozilla/standards-positions/issues/539#issuecomment-914418485
>>
>
> Anne's argument is that shipping this before shipping PNA
> protections would put private resources at extra risk, because the
> documents including them would be considered COI, and therefore would have
> access to high precision timers.
>
> Our argument is that the reverse OT for SAB access without COI already
> enables that in Chrome.
>
> That makes sense, but maybe there's a way for us to combine this and the
> recent PNA intent
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ>
>  and
> be more bold there only in the case of a COEP: credentialless embedder?
> For example, avoid waiting 2 milestones/letting folks opt-out for 4 more
> milestones if the embedder opted-in to credentialless?
>
> I'm not sure if it makes sense to block on this (or at all), but it could
> be a middle ground that'd timebox those concerns.
>
>
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html)
>> No official replies yet. Safari is currently implementing COOP/COEP, but
>> have no plan yet about COEP:credentialless variant:
>> https://twitter.com/mikewest/status/1434878018191826948<
>>

[blink-dev] Intent to Ship: Cross-Origin-Embedder-Policy: credentialless

['Arthur Sonzogni' via blink-dev]

Contact emailsarthursonzo...@chromium.org, cl...@chromium.org,
mk...@chromium.org

Explainerhttps://github.com/WICG/credentiallessness

Specificationhttps://wicg.github.io/credentiallessness/

Design docs
https://github.com/WICG/credentiallessness
https://docs.google.com/document/d/1U1pDzS_WJpfkq6QqOeqgmXmba_I4tIbUR-5C1AHzI9o/edit#

Summary

Introduce Cross-Origin-Embedder-Policy: credentialless. This causes
cross-origin no-cors requests to omit credentials (cookies, client
certificates, etc). Similarly to COEP:require-corp, it can enable
cross-origin isolation.


Blink componentBlink>SecurityFeature


Search tagscoep ,
credentialless , coop
, crossoriginisolation
,
crossOriginisolated


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/582

TAG review statusPending

Link to origin trial feedback summary
https://docs.google.com/document/d/1Rcho9z8obW0A7aeM3Zz1QR3fN7KcmTHgjdF_mKEXiRQ

Risks


Interoperability and Compatibility

Compatibility risk: This is an opt-in new feature, so there are no
compatibility risks. Interoperability risk: New feature. Risk is failing to
become an interoperable part of the web platform.


Gecko: Worth prototyping (
https://github.com/mozilla/standards-positions/issues/539#issuecomment-867473836
)
Worth prototyping, but concerns are about the timing in between shipping:
COEP:credentialless, Private Network Access (PNA), ORB. See
https://github.com/mozilla/standards-positions/issues/539#issuecomment-914418485

WebKit: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2021-June/031898.html)
No official replies yet. Safari is currently implementing COOP/COEP, but
have no plan yet about COEP:credentialless variant:
https://twitter.com/mikewest/status/1434878018191826948<

Web developers: Positive (
https://github.com/WICG/proposals/issues/31#issuecomment-858822619)
Google Earth, Twitter, Zoom, etc... are positive.

Ergonomics

Similarly to the existing COEP:require-corp, it will also be often used in
tandem with Cross-Origin-Opener-Policy: same-origin (COOP)


Activation

This is an HTTP header. Developers need to be able to configure their
server. This is hard for them when hosting their page on servers they don't
really own, like https://github.io pages.


Debuggability

The same devtool features as for COEP:require-corp: 1. Display COEP policy:
Devtool > Application > Frames > top > Security & Isolation > Cross-Origin
Embedder Policy. 2. Devtool issues:
https://source.chromium.org/search?q=file:devtools-frontend%2Fsrc%2Ffront_end%2Fmodels%2Fissues_manager%2Fdescriptions%2FCoep*&ss=chromium



Is this feature fully tested by web-platform-tests

?Yes

Flag namechrome://flags/#cross-origin-embedder-policy-credentialless

Requires code in //chrome?False

Tracking bughttps://crbug.com/1175099

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218896

Measurementhttps://chromestatus.com/metrics/feature/timeline/popularity/3881

Sample links
http://coep-credentialless.glitch.me/

Estimated milestones
OriginTrial desktop last 95
OriginTrial desktop first 93
DevTrial on desktop 93
OriginTrial android last 95
OriginTrial android first 93
DevTrial on android 93
DevTrial on Webview 93

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4918234241302528

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/DOtU6R4TuAY/m/kPbID-LAAQAJ
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Sdc0G1bvKr0/m/YHR8RuWyAAAJ


This intent message was generated by Chrome Platform Status
.
Arthur @arthursonzogni

-- 
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/CAAzos5GX5UpU_8V5faX0KzvWG9y5FT8BvCDJ5LUQ929LWM3%3DPA%40mail.gmail.com.

Re: [blink-dev] Intent to Continue Experimenting: Shared Element Transitions

['Arthur Sonzogni' via blink-dev]

Hi Vladimir,
Could you confirm this is a continuation of the OriginTrial supporting only
Single-Page transitions? We weren't sure by reading this intent.
Arthur @arthursonzogni


Le mer. 1 sept. 2021 à 16:33, Yoav Weiss  a écrit :

> *LGTM* to extend the experiment till M96 (inclusive)
>
> On Mon, Aug 30, 2021 at 7:09 PM Vladimir Levin 
> wrote:
>
>> Contact emailsvmp...@chromium.org, chris...@chromium.org,
>> voll...@chromium.org, khushalsa...@chromium.org
>>
>> Explainer
>> https://github.com/vmpstr/shared-element-transitions/blob/main/README.md
>>
>> Summary
>>
>> Shared Element Transitions is a proposal for a new script API that allows
>> a simple set of transitions in both Single-Page Applications (SPAs) and
>> Multi-Page Applications (MPAs). This feature enhances the visual polish of
>> pages without requiring a large development effort from developers to make
>> transitions look nice. By selecting from a set of user-agent implemented
>> transition effects, the developers can achieve a polished transition look
>> with minimal effort.
>>
>>
>> Blink componentBlink>Animation
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low. As a new feature, the risk here is that other browsers do not
>> implement it, but since this is a progressive enhancement, sites should be
>> able to drop usage of the feature easily in browsers where it is not
>> supported.
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: Positive Interest in the feature:
>> https://twitter.com/jaffathecake/status/1386673316354797570 Main
>> feedback is requests to provide more customizability and power:
>> https://github.com/WICG/shared-element-transitions/issues/28
>> https://github.com/WICG/shared-element-transitions/issues/9
>>
>> Ergonomics
>>
>> None.
>>
>>
>> Activation
>>
>> Low. As with interop/compat risks, the difficulty stems from this being a
>> new feature without support in other browsers. A polyfill for the SPA case
>> would be beneficial, but it will not be possible to polyfill MPA behavior.
>> That said, dropping the customized transition should not impact the
>> usability of a site, fundamentally, so this can easily be dropped on
>> browsers that do not support the feature.
>>
>>
>> Security
>>
>> The current implementation handles transitions in Viz in anticipation of
>> MPA scenarios. More details on this are outlined in the design doc. See
>> also the security and privacy self-review questionnaire that was completed
>> as part of the TAG review process:
>> https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md
>>
>>
>> Goals for experimentation
>>
>> The API shape is currently limited, providing only a stock set of
>> transition types. We've already seen engagement on the WICG and a desire
>> for more customization (see web developer response). We hope to learn more
>> about the utility of the default transition types and experiences partners
>> would like to create, but are unable to achieve with the limited API (we
>> have two external partners who have indicated interest). Based on that
>> feedback, we may make changes to the API to add more customization. We also
>> want to know how easy it is to adopt this API on an existing site.
>>
>>
>> Reason this experiment is being extended
>>
>> We have gathered feedback from partners, but some amendments to the
>> feature are needed in order for them to utilize the feature. Specifically,
>> easing function, duration, and delay controls for shared elements is needed
>> to better animation control. We are working on adding the controls and
>> would like to extend the experiment. Original experiment start date: M92
>> Original experiment end date: M94 Proposed new end date: M96
>>
>>
>> Ongoing technical constraints
>>
>> None.
>>
>>
>> Debuggability
>>
>> It is possible to set breakpoints inside post-preparation and
>> post-transition handlers, but beyond this there is no way, presently, to
>> debug an unexpected transition. Specifically, there currently is no way to
>> scrub through a transition, or to inspect the shared/transitioned elements.
>> These are potential areas for improvement if we get developer feedback that
>> these would be helpful.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No
>>
>> Currently no support for Android WebView. WebView presents challenges due
>> to its rendering architecture.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag nameDocumentTransition
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1150461
>>
>> Estimated miles