Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Brandon Heenan' via blink-dev]

Created crbug/1472321 to track that improvement

On Fri, Aug 11, 2023 at 1:28 AM Fergal Daly  wrote:

> On Fri, 11 Aug 2023 at 09:08, Brandon Heenan  wrote:
>
>> That makes sense—I suppose a more general wording that would apply here
>> would be "These flags prevent or revert a breaking change and will only be
>> available for a limited time." Does that sound better to you / others on
>> the thread?
>>
>
> That sounds great to me,
>
> F
>
>>
>> On Thu, Aug 10, 2023 at 4:33 AM Fergal Daly  wrote:
>>
>>> On Wed, 9 Aug 2023 at 07:23, Brandon Heenan  wrote:
>>>
 Still, previous breaking changes to the unload event that affected SAP
 were present in the /deprecated page, so the safest thing to do is to
 follow the same pattern here, no?

>>>
>>> The switch landed here , It's in M117.
>>> I've sent a CL  to make it appear on the
>>> deprecated flags page. We can CP that,
>>>
>>> F
>>>
>>> It's not marked as a deprecated feature, so it's just in the regular
>>> flags UI. We can CP a tiny change to move it. What gives me pause is that
>>> the page says
>>>
>>> "These features are disabled by default. They will not be available in
>>> future versions of Chrome."
>>>
>>> This doesn't quite match what we are doing.
>>>
>>>
>>>

 On Tue, Aug 8, 2023 at 12:18 AM Fergal Daly  wrote:

> On Tue, 8 Aug 2023 at 08:00, Brandon Heenan 
> wrote:
>
>> Flipping the permission policy default is still a breaking change
>> that requires some action from the developer to keep unload events, 
>> right?
>> If so, we still want en entry in the /deprecated page so that unmanaged
>> (vendors/BYOD/outbound) users accessing on-prem deployments have some
>> mitigation. Kenji and I discussed this case with SAP last week, and that
>> level of mitigation seemed necessary.
>>
>
> It's just about naming/presentation - I'm adding a switch no matter
> what, just whether it shows in the deprecated tab or the main tab,
>
> F
>
>
>>
>> On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly  wrote:
>>
>>>
>>>
>>> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan 
>>> wrote:
>>>
 Hello, I'm chiming in to provide some thoughts from the enterprise
 perspective.

 Our goal is to not block forward progress to the web, but to
 improve the web in an enterprise-friendly way. You shouldn't ever hear 
 me
 say "you can't do X because it's scary to the enterprise team." You 
 should
 instead hear "We expect X to be risky, but here are the things we know 
 we
 can do to make it much less risky."

 In this case, yes, this is risky for enterprises. We can say this
 with confidence because we've seen escalations before when we've made
 changes to unload events (crbug.com/933153,  crbug.com/953228).

 Kenji and Daisuke have been working with us, and my understanding
 of the plan is to:

-

Allow developers to opt-in early to the new behavior (unload
event ignored) with a permission policy
-

Communicate the change on chromestatus and the enterprise
release notes (already happening

 ).
We will provide a bug link for customers for feedback in a future 
 release.
-

Reach out to enterprises and developers we expect to be affected
-

Introduce an enterprise policy to allow an IT admin to control
unload event behavior
-

Introduce a flag in chrome://flags/deprecated to allow end
users to control unload event behavior


>>> I looked into this, I'm not sure this should be a deprecated flag.
>>> It doesn't really fit the description. Some time in the future when we
>>> start to fully disable unload, there should be a deprecated flag for 
>>> unload
>>> but right now we are just flipping the permission policy default.
>>>
>>> Are you OK with just adding a UI entry for the existing flag that
>>> controls this Permission-Policy rollout (which is named DeprecateUnload 
>>> but
>>> I'm happy to rename it)
>>>
>>> F
>>>
>>>

-

As early as M117, change the default for the policy so that
unload events will be ignored. This is the breaking change, and 
 there's
likely to be friction here. The two escalations mentioned above both
resulted in respins the first time they reached this point. 
 However, this
time around, IT admins will be able to fix their envi

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Brandon Heenan' via blink-dev]

That makes sense—I suppose a more general wording that would apply here
would be "These flags prevent or revert a breaking change and will only be
available for a limited time." Does that sound better to you / others on
the thread?

On Thu, Aug 10, 2023 at 4:33 AM Fergal Daly  wrote:

> On Wed, 9 Aug 2023 at 07:23, Brandon Heenan  wrote:
>
>> Still, previous breaking changes to the unload event that affected SAP
>> were present in the /deprecated page, so the safest thing to do is to
>> follow the same pattern here, no?
>>
>
> The switch landed here , It's in M117. I've
> sent a CL  to make it appear on the
> deprecated flags page. We can CP that,
>
> F
>
> It's not marked as a deprecated feature, so it's just in the regular flags
> UI. We can CP a tiny change to move it. What gives me pause is that the
> page says
>
> "These features are disabled by default. They will not be available in
> future versions of Chrome."
>
> This doesn't quite match what we are doing.
>
>
>
>>
>> On Tue, Aug 8, 2023 at 12:18 AM Fergal Daly  wrote:
>>
>>> On Tue, 8 Aug 2023 at 08:00, Brandon Heenan  wrote:
>>>
 Flipping the permission policy default is still a breaking change that
 requires some action from the developer to keep unload events, right? If
 so, we still want en entry in the /deprecated page so that unmanaged
 (vendors/BYOD/outbound) users accessing on-prem deployments have some
 mitigation. Kenji and I discussed this case with SAP last week, and that
 level of mitigation seemed necessary.

>>>
>>> It's just about naming/presentation - I'm adding a switch no matter
>>> what, just whether it shows in the deprecated tab or the main tab,
>>>
>>> F
>>>
>>>

 On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly  wrote:

>
>
> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan 
> wrote:
>
>> Hello, I'm chiming in to provide some thoughts from the enterprise
>> perspective.
>>
>> Our goal is to not block forward progress to the web, but to improve
>> the web in an enterprise-friendly way. You shouldn't ever hear me say 
>> "you
>> can't do X because it's scary to the enterprise team." You should instead
>> hear "We expect X to be risky, but here are the things we know we can do 
>> to
>> make it much less risky."
>>
>> In this case, yes, this is risky for enterprises. We can say this
>> with confidence because we've seen escalations before when we've made
>> changes to unload events (crbug.com/933153,  crbug.com/953228).
>>
>> Kenji and Daisuke have been working with us, and my understanding of
>> the plan is to:
>>
>>-
>>
>>Allow developers to opt-in early to the new behavior (unload
>>event ignored) with a permission policy
>>-
>>
>>Communicate the change on chromestatus and the enterprise release
>>notes (already happening
>>
>> ).
>>We will provide a bug link for customers for feedback in a future 
>> release.
>>-
>>
>>Reach out to enterprises and developers we expect to be affected
>>-
>>
>>Introduce an enterprise policy to allow an IT admin to control
>>unload event behavior
>>-
>>
>>Introduce a flag in chrome://flags/deprecated to allow end users
>>to control unload event behavior
>>
>>
> I looked into this, I'm not sure this should be a deprecated flag. It
> doesn't really fit the description. Some time in the future when we start
> to fully disable unload, there should be a deprecated flag for unload but
> right now we are just flipping the permission policy default.
>
> Are you OK with just adding a UI entry for the existing flag that
> controls this Permission-Policy rollout (which is named DeprecateUnload 
> but
> I'm happy to rename it)
>
> F
>
>
>>
>>-
>>
>>As early as M117, change the default for the policy so that
>>unload events will be ignored. This is the breaking change, and 
>> there's
>>likely to be friction here. The two escalations mentioned above both
>>resulted in respins the first time they reached this point. However, 
>> this
>>time around, IT admins will be able to fix their environment 
>> immediately
>>with the enterprise policy, end users will be able to fix themselves 
>> with
>>the deprecation flag, and developers will be able to fix their app 
>> with the
>>permission policy. With those mitigations in place, the risk of 
>> requiring a
>>respin (or Finch rollback) due to enterprise impact is dramatically
>>reduced, and this is how we eventually successfully shipped both of 
>> those
>> 

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Brandon Heenan' via blink-dev]

Still, previous breaking changes to the unload event that affected SAP were
present in the /deprecated page, so the safest thing to do is to follow the
same pattern here, no?

On Tue, Aug 8, 2023 at 12:18 AM Fergal Daly  wrote:

> On Tue, 8 Aug 2023 at 08:00, Brandon Heenan  wrote:
>
>> Flipping the permission policy default is still a breaking change that
>> requires some action from the developer to keep unload events, right? If
>> so, we still want en entry in the /deprecated page so that unmanaged
>> (vendors/BYOD/outbound) users accessing on-prem deployments have some
>> mitigation. Kenji and I discussed this case with SAP last week, and that
>> level of mitigation seemed necessary.
>>
>
> It's just about naming/presentation - I'm adding a switch no matter what,
> just whether it shows in the deprecated tab or the main tab,
>
> F
>
>
>>
>> On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly  wrote:
>>
>>>
>>>
>>> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan  wrote:
>>>
 Hello, I'm chiming in to provide some thoughts from the enterprise
 perspective.

 Our goal is to not block forward progress to the web, but to improve
 the web in an enterprise-friendly way. You shouldn't ever hear me say "you
 can't do X because it's scary to the enterprise team." You should instead
 hear "We expect X to be risky, but here are the things we know we can do to
 make it much less risky."

 In this case, yes, this is risky for enterprises. We can say this with
 confidence because we've seen escalations before when we've made changes to
 unload events (crbug.com/933153,  crbug.com/953228).

 Kenji and Daisuke have been working with us, and my understanding of
 the plan is to:

-

Allow developers to opt-in early to the new behavior (unload event
ignored) with a permission policy
-

Communicate the change on chromestatus and the enterprise release
notes (already happening

 ).
We will provide a bug link for customers for feedback in a future 
 release.
-

Reach out to enterprises and developers we expect to be affected
-

Introduce an enterprise policy to allow an IT admin to control
unload event behavior
-

Introduce a flag in chrome://flags/deprecated to allow end users to
control unload event behavior


>>> I looked into this, I'm not sure this should be a deprecated flag. It
>>> doesn't really fit the description. Some time in the future when we start
>>> to fully disable unload, there should be a deprecated flag for unload but
>>> right now we are just flipping the permission policy default.
>>>
>>> Are you OK with just adding a UI entry for the existing flag that
>>> controls this Permission-Policy rollout (which is named DeprecateUnload but
>>> I'm happy to rename it)
>>>
>>> F
>>>
>>>

-

As early as M117, change the default for the policy so that unload
events will be ignored. This is the breaking change, and there's likely 
 to
be friction here. The two escalations mentioned above both resulted in
respins the first time they reached this point. However, this time 
 around,
IT admins will be able to fix their environment immediately with the
enterprise policy, end users will be able to fix themselves with the
deprecation flag, and developers will be able to fix their app with the
permission policy. With those mitigations in place, the risk of 
 requiring a
respin (or Finch rollback) due to enterprise impact is dramatically
reduced, and this is how we eventually successfully shipped both of 
 those
above escalations.
-

We expect a long transition period after that. By default, the
unload event is ignored, but different stakeholders are able to revert 
 to
legacy behavior. Within enterprise, we expect the enterprise policy to 
 be
the most useful mitigation, and the deprecation flag is the backup for 
 BYOD
or unmanaged devices. For the above escalations, this migration period 
 was
over a year, and I'm expecting something similar this time.
-

At some point in the future, we expect to remove those mitigations
and remove support for the unload event completely. We don't have any
specific dates for that yet; we will be responsive to the needs of web
stakeholders, enterprise and otherwise.

 The two escalations I mentioned above were successfully resolved and
 the changes to not allow popups on page unload and to not allow synchronous
 XHRs on page unload were shipped. Both of those changes followed
 essentially the same plan I just laid out above, and so 

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Brandon Heenan' via blink-dev]

Flipping the permission policy default is still a breaking change that
requires some action from the developer to keep unload events, right? If
so, we still want en entry in the /deprecated page so that unmanaged
(vendors/BYOD/outbound) users accessing on-prem deployments have some
mitigation. Kenji and I discussed this case with SAP last week, and that
level of mitigation seemed necessary.

On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly  wrote:

>
>
> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan  wrote:
>
>> Hello, I'm chiming in to provide some thoughts from the enterprise
>> perspective.
>>
>> Our goal is to not block forward progress to the web, but to improve the
>> web in an enterprise-friendly way. You shouldn't ever hear me say "you
>> can't do X because it's scary to the enterprise team." You should instead
>> hear "We expect X to be risky, but here are the things we know we can do to
>> make it much less risky."
>>
>> In this case, yes, this is risky for enterprises. We can say this with
>> confidence because we've seen escalations before when we've made changes to
>> unload events (crbug.com/933153,  crbug.com/953228).
>>
>> Kenji and Daisuke have been working with us, and my understanding of the
>> plan is to:
>>
>>-
>>
>>Allow developers to opt-in early to the new behavior (unload event
>>ignored) with a permission policy
>>-
>>
>>Communicate the change on chromestatus and the enterprise release
>>notes (already happening
>>
>> ).
>>We will provide a bug link for customers for feedback in a future release.
>>-
>>
>>Reach out to enterprises and developers we expect to be affected
>>-
>>
>>Introduce an enterprise policy to allow an IT admin to control unload
>>event behavior
>>-
>>
>>Introduce a flag in chrome://flags/deprecated to allow end users to
>>control unload event behavior
>>
>>
> I looked into this, I'm not sure this should be a deprecated flag. It
> doesn't really fit the description. Some time in the future when we start
> to fully disable unload, there should be a deprecated flag for unload but
> right now we are just flipping the permission policy default.
>
> Are you OK with just adding a UI entry for the existing flag that controls
> this Permission-Policy rollout (which is named DeprecateUnload but I'm
> happy to rename it)
>
> F
>
>
>>
>>-
>>
>>As early as M117, change the default for the policy so that unload
>>events will be ignored. This is the breaking change, and there's likely to
>>be friction here. The two escalations mentioned above both resulted in
>>respins the first time they reached this point. However, this time around,
>>IT admins will be able to fix their environment immediately with the
>>enterprise policy, end users will be able to fix themselves with the
>>deprecation flag, and developers will be able to fix their app with the
>>permission policy. With those mitigations in place, the risk of requiring 
>> a
>>respin (or Finch rollback) due to enterprise impact is dramatically
>>reduced, and this is how we eventually successfully shipped both of those
>>above escalations.
>>-
>>
>>We expect a long transition period after that. By default, the unload
>>event is ignored, but different stakeholders are able to revert to legacy
>>behavior. Within enterprise, we expect the enterprise policy to be the 
>> most
>>useful mitigation, and the deprecation flag is the backup for BYOD or
>>unmanaged devices. For the above escalations, this migration period was
>>over a year, and I'm expecting something similar this time.
>>-
>>
>>At some point in the future, we expect to remove those mitigations
>>and remove support for the unload event completely. We don't have any
>>specific dates for that yet; we will be responsive to the needs of web
>>stakeholders, enterprise and otherwise.
>>
>> The two escalations I mentioned above were successfully resolved and the
>> changes to not allow popups on page unload and to not allow synchronous
>> XHRs on page unload were shipped. Both of those changes followed
>> essentially the same plan I just laid out above, and so I think it's
>> reasonable to do the same thing here.
>>
>>
>> On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers wrote:
>>
>>> On Thu, Jun 29, 2023 at 1:47 AM Kenji Baheux 
>>> wrote:
>>>

 On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly  wrote:

> On Thu, 29 Jun 2023 at 01:16, Rick Byers  wrote:
>
>> Hi Fergal,
>> Thanks for pushing through this contentious and challenging
>> deprecation. We discussed this in the API owners meeting today and were
>> worried that this plan seemed likely to be seriously problematic for
>> enterprises (policy opt-out is helpful, but far from a silver bullet
>> unfortunately). To what extent have you e

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Brandon Heenan' via blink-dev]

Hello, I'm chiming in to provide some thoughts from the enterprise 
perspective.

Our goal is to not block forward progress to the web, but to improve the 
web in an enterprise-friendly way. You shouldn't ever hear me say "you 
can't do X because it's scary to the enterprise team." You should instead 
hear "We expect X to be risky, but here are the things we know we can do to 
make it much less risky."

In this case, yes, this is risky for enterprises. We can say this with 
confidence because we've seen escalations before when we've made changes to 
unload events (crbug.com/933153,  crbug.com/953228).

Kenji and Daisuke have been working with us, and my understanding of the 
plan is to:

   - 
   
   Allow developers to opt-in early to the new behavior (unload event 
   ignored) with a permission policy
   - 
   
   Communicate the change on chromestatus and the enterprise release notes 
(already 
   happening 
   
).
 
   We will provide a bug link for customers for feedback in a future release.
   - 
   
   Reach out to enterprises and developers we expect to be affected
   - 
   
   Introduce an enterprise policy to allow an IT admin to control unload 
   event behavior
   - 
   
   Introduce a flag in chrome://flags/deprecated to allow end users to 
   control unload event behavior
   - 
   
   As early as M117, change the default for the policy so that unload 
   events will be ignored. This is the breaking change, and there's likely to 
   be friction here. The two escalations mentioned above both resulted in 
   respins the first time they reached this point. However, this time around, 
   IT admins will be able to fix their environment immediately with the 
   enterprise policy, end users will be able to fix themselves with the 
   deprecation flag, and developers will be able to fix their app with the 
   permission policy. With those mitigations in place, the risk of requiring a 
   respin (or Finch rollback) due to enterprise impact is dramatically 
   reduced, and this is how we eventually successfully shipped both of those 
   above escalations.
   - 
   
   We expect a long transition period after that. By default, the unload 
   event is ignored, but different stakeholders are able to revert to legacy 
   behavior. Within enterprise, we expect the enterprise policy to be the most 
   useful mitigation, and the deprecation flag is the backup for BYOD or 
   unmanaged devices. For the above escalations, this migration period was 
   over a year, and I'm expecting something similar this time.
   - 
   
   At some point in the future, we expect to remove those mitigations and 
   remove support for the unload event completely. We don't have any specific 
   dates for that yet; we will be responsive to the needs of web stakeholders, 
   enterprise and otherwise.
   
The two escalations I mentioned above were successfully resolved and the 
changes to not allow popups on page unload and to not allow synchronous 
XHRs on page unload were shipped. Both of those changes followed 
essentially the same plan I just laid out above, and so I think it's 
reasonable to do the same thing here.


On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers wrote:

> On Thu, Jun 29, 2023 at 1:47 AM Kenji Baheux  wrote:
>
>>
>> On Thu, Jun 29, 2023 at 1:48 PM Fergal Daly  wrote:
>>
>>> On Thu, 29 Jun 2023 at 01:16, Rick Byers  wrote:
>>>
 Hi Fergal,
 Thanks for pushing through this contentious and challenging 
 deprecation. We discussed this in the API owners meeting today and were 
 worried that this plan seemed likely to be seriously problematic for 
 enterprises (policy opt-out is helpful, but far from a silver bullet 
 unfortunately). To what extent have you engaged with them and worked to 
 follow the enterprise breaking change policy 
 ? Our hunch 
 is that at 1% or 5% we'd get escalations forcing us to abandon this plan. 
 Of course, if the enterprise team is OK with it, we could always try 
 anyway 
 and see if our hunch is right. It's possible I'm over-indexing on past 
 experiences like deprecating sync XHR in unload handlers 
 
  
 and that the enterprise world is different now, but I doubt it :-).

>>>
>>> In addition to Daisuke's response... are you concerned about enterprises 
>>> that are not using fleet management and so cannot use the opt-out? If you 
>>> think an enterprise policy will not be sufficient, a mitigation for those 
>>> enterprises would be for us to publish an extension that allows anyone to 
>>> re-enable unload (for all sites or for specific sites) by injecting the 
>>> PP:unload header. Are the escalations that can't be resolved by either a 
>>> policy or extension?
>>>
>>
>> One ext

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

['Brandon Heenan' via blink-dev]

One addition please: work with me and the enterprise team to also add a
paragraph to the enterprise release notes before the deprecation warning is
switched to on-by-default

On Fri, Apr 21, 2023 at 3:13 AM Yoav Weiss  wrote:

> LGTM2 for the above plan. Good luck!!
>
> On Thu, Apr 20, 2023 at 11:37 PM Rick Byers  wrote:
>
>> Jun and I have been talking about this offline and I think we've got a
>> reasonable plan to attempt to proceed with this breaking change:
>>
>>- Add Enterprise policy knob
>>
>>- Disable in WebView by default (or add targetSdk quirk) - in
>>discussion with WebView team
>>- Publish a blog post explaining the change and how to adapt to it,
>>linked from chromestatus entry
>>- Add deprecation warning (console + deprecation report) linking to
>>chromestatus entry
>>- Try flipping the flag on with Finch in canary and dev builds, maybe
>>beta 50%, watch for reports of bugs and engage on any to see if they're
>>similarly easy to get sites fixed
>>- Once 3 milestones have passed with the deprecation warning and
>>there's aren't major known issues, flip the flag on by default (with
>>killswitch in place)
>>- As the change makes its way to stable, keep an eye on any reports.
>>Be prepared to hit the killswitch and iterate if there is significant
>>breakage that can't be immediately addressed.
>>
>> With this plan, I'm LGTM1 to give this a shot.
>>
>> On Tue, Jan 24, 2023 at 10:22 AM Rick Byers  wrote:
>>
>>>
>>> On Mon, Jan 23, 2023 at 3:00 PM Jun Kokatsu  wrote:
>>>
 Hi All,

 I wanted to provide some updates on outreach I've done last week.

 I manually went through a list of sample sites in the use counter
 ,
 and contacted ~10 sites which will be impacted. Among those sites, 3 sites
 responded so far.

1. onsetapp.com has successfully migrated away from data: URLs in
SVGUseElement.
   - Reason for the usage:


 *"We used them to import elements from SVG sprites, basically an SVG
   file containing every icons loaded once at page load as an attempt to
   improve performance of the app."*
2. jobs.nzz.ch are testing the fix in the development pipeline, and
hope to migrate away from data: URLs in SVGUseElement soon.
- Reason for the usage is unsure as it was done a long time ago.
3. We've reached out to Salesforce contact (thanks Rick!) for
appexchange.salesforce.com. They are trying to find a responsible
team for that subdomain to understand why it was used, and if it can be
migrated away.

 Thanks Jun, that's some good anecdotal evidence that adapting to this
>>> breaking change likely isn't too hard for most folks. Despite it being only
>>> a couple anecdotes, this increases my confidence.
>>>
>>>
 I've also identified faucet.okp4.network as a false positive, because
 they use svgxuse  as a fallback
 mechanism .

>>>
>>> Fascinating.
>>>
>>> I will wait for sometime so that UKM will reach Beta or Stable, to
 further identify impacted origins with high volume of access.

>>>
>>> Yeah I think this is the most important next step. With luck we'll find
>>> that there's not too much of a long tail and we can succeed in getting a
>>> significant drop in usage through outreach.
>>>
>>> BTW, thank you Daniel for creating a page
  with easy to read
 alternatives! This was very helpful in the outreach process!

>>>
>>> Thanks Daniel! If we proceed with deprecation then perhaps this page
>>> should form the basis of a chromium.org blog post on the topic that we
>>> can link to from the chromestatus entry that will be referenced in the
>>> deprecation warning message.
>>>
>>>

 Thanks,

 Jun


 On Thu, Jan 19, 2023 at 3:23 PM Jun Kokatsu 
 wrote:

> On Thu, Jan 19, 2023 at 2:14 PM Rick Byers 
> wrote:
>
>> On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu 
>> wrote:
>>
>>> On Thu, Jan 19, 2023 at 9:29 AM Rick Byers 
>>> wrote:
>>>
 Thanks Daniel. I also looked at this page
 
  which
 inlines the same 422 kB long sprite sheet 5 separate times, only to 
 select
 a tiny 422 BYTE SVG out of it each time! In that case, simply inlining 
 the
 desired SVG would save both several MB of network and a lot of 
 parse/decode
 time. Perhaps there's an opportunity for a tool at design time which
 unrolls these inlined sprite sheets, like Jun's tool
 

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

['Brandon Heenan' via blink-dev]

Thanks for adding me. Yes, this definitely seems like the pattern where
we'd want a temporary enterprise policy to re-enable support for ~3
milestones after we remove support by default.
go/chrome-enterprise-friendly gets into the details of the why,
https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
is the step-by-step, and the enterprise team is always happy to advise as
well.

On Tue, Jan 17, 2023 at 10:51 AM Rick Byers  wrote:

> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss  wrote:
>
>> Would it be possible to turn
>> 
>> the usecounter into a UKM to get a better view of the number of impacted
>> origins, beyond just the homepage?
>>
>
> Yeah that could be useful. But we've also got some leads already so
> getting more leads may not be critical until we follow up on the ones we
> have. Can we find a developer for one of those sites who will talk to us
> about where that pattern is coming from in their toolchain and how they'd
> migrate off it? Having the UKM data will also help in selecting the sites
> that will have the most impact on our users (and hence our UseCounter
> stats). Maybe we'll get lucky and find that, despite the long tail, 90% of
> the usage is from just a few sites we can work with.
>
> I wonder if this would be a good candidate for a deprecation trial +
>> enterprise policy. That would solve this injection vector for the broader
>> web, while giving impacted folks some more time to move away from this
>> pattern.
>>
>
> Good idea. Impacting a large number of small sites is still problematic
> for a deprecation trial. Just reaching enough to make any change at all is
> the hard part. Perhaps we can make replacing the usage easier than the
> overhead of getting an applying an OT token? Still a deprecation trial
> would probably be useful. Enterprise policy, certainly. +Brandon Heenan
>  can help advise on that. I'd also advise leaving
> this enabled for WebView (at least to start), it feels like the sort of
> chromium rendering quirk we've found Android apps to rely on
> disproportionately in the past.
>
> On Fri, Jan 13, 2023 at 9:11 PM 'Jun Kokatsu' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Thank you Rick for the detailed explanation!
>>>
>>> On Fri, Jan 13, 2023 at 10:30 AM Rick Byers  wrote:
>>>
 Eliminating this makes sense to me given the security benefit. Thank
 you for pushing it! But it does seem somewhat risky from a web compat
 perspective. 0.005% is above our "small but non-trivial risk
 "
 rule of thumb. Here's a bit of an analysis according to our other compat
 principles :

- Severity of breakage

 :
lower given this is likely only about some visualis, but this site
 is a good example of non-trivial UI
breakage. This pattern of putting a base64-encoded SVG into an SVG 
element with nothing else in the  is weird, isn't it? Why would
someone do that rather than just put the SVG in directly, or put the 
 data
URL into an img tag?

 I've looked into that site. And it seems like they are reusing a single
>>> SVG image (i.e. data: URL SVG image) which contains several images, and
>>> changing which image should be rendered by combination of symbol
>>>  + id
>>> (which is only possible in use element, and not in img tag). Migration can
>>> be done by hosting the same image in the same-origin endpoint, converting
>>> it to blob: URL and assigning that to the  element, or inlining each
>>> SVG image.
>>>
>>
> Interesting. So could we write a tool which, given the source html,
> transforms it to simply inline the selected SVG? That would save some bytes
> too, right? We've found in the past that when we give developers easy tools
> to trivially adapt their code, then it makes moderate-risk deprecations go
> quite smoother. I.e. when we get to the point of having a deprecation
> warning (and report ) for
> the usage, if we can simply say "for most cases we've found you can just
> run your html through this tool to adapt it automatically", then that would
> help a LOT in having the comfort to make the breaking change. Someone from
> the devrel or tooling teams with experience in how developers approach
> images in practice (eg. +Addy Osmani ) might be able
> to advise on a pragmatic and helpful path.
>
>>
- I don't suppose there's some creative way to allow this specific
   

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['Brandon Heenan' via blink-dev]

We'll make the update in the enterprise release notes too. Thanks for
keeping us in the loop

On Mon, Jan 16, 2023 at 9:46 AM Rick Byers  wrote:

> Thanks so much Eiji!
>
> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura  wrote:
>
>> I've updated the blog post
>>  stating
>> Chrome 111 is where we ship the feature, but looks like it's rolling out
>> through 111 and 112?
>> I'll update the blog post to mention `OriginAgentClusterDefaultEnabled`
>> enterprise policy.
>>
>>
>> On Sat, Jan 14, 2023 at 1:37 AM Rick Byers  wrote:
>>
>>> Thanks for the update Daniel, good luck!
>>>
>>> In case others, like me, have missed or forgotten the long history of
>>> this difficult deprecation and what it means for web developers, this blog
>>> post is a good summary
>>> . One
>>> critical thing it doesn't mention, but probably should, is that the 
>>> OriginAgentClusterDefaultEnabled
>>> enterprise policy
>>> 
>>> can also be used to revert the default on managed devices (though it looks
>>> like the launching milestone needs to be updated there too).
>>>
>>> Rick
>>>
>>> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Hello all,

 We've now handled the bugs we've discovered, and I would like to make
 another attempt at launching. I'll follow the plan that was approved here,
 but two milestones later: Launch to 50% beta in M111 (or late M110, if I
 can still catch a bit of that release cycle), and then ramp on stable once
 M112 is out.


 On Wed, Dec 14, 2022 at 6:36 PM Daniel Vogelheim 
 wrote:

> Hello all,
>
> An update: Unfortunately we have discovered a bug with this feature,
> just as I was getting ready to enable it. The bug also affects pages that
> have not even set document.domain. Since I have now missed a substantial
> portion of the 109 beta cycle I'd like to delay the roll out once more, 
> and
> shift it by one milestone (or two; depending on when everything is fixed).
>
> On the positive side: Recently the last of the previously identified
> big document.domain users, that together accounted for about 50% of
> remaining usage, has dropped their usage. So current usage is lower than
> previously reported. See the usage dip around late November at
> deprecate.it (1st graph).
>
> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
> wrote:
>
>> LGTM3
>>
>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>
>> LGTM2
>>
>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
>>> M109, and carefully roll this out for M110, once it hits stable.
>>>
>>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
>>> vogelh...@google.com> wrote:
>>>
 On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
 wrote:

> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>
> Hello all,
>
> The approval for the Intent To Ship for Origin Isolation By
> Default / Deprecate document.domain
> 
> asks for a separate intent for the actual default change
> .
> This is that separate intent.
>
> A summary of what happened so far:
>
> - Shipping Origin Isolation by Default (and thereby deprecating
> document.domain) has security benefits, but compatibility risk.
>
> - We added warnings to the developer console and issues panel,
> published a blog post, and engaged in direct outreach. This has 
> resulted in
> substantial, measurable reduction of usage. Some sites keep using
> document.domain, but have mitigated the deprecation with other means. 
> This
> makes the risk difficult to measure.
>
> - Sampling of sites with document.domain usage and manual
> inspection yields a potential breakage estimate at ~0.015% of page 
> views.
>
> What we're asking for here is:
>
> - Enable the feature at 50% for beta (+ dev + canary) during M109,
> as a "last call" for web site authors.
>
> This sounds like a good idea. Is there any reason we couldn't go
> to 50% in M108 as well (or are you trying to avoid breakage over the 
> winter
> holidays)?
>
 No reason. I'd be happy to go to beta as soon as I receive the
 lgtms. I had conservatively budgeted that to be 109. :-)

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

['Brandon Heenan' via blink-dev]

> This probably requires an Enterprise Policy, to reduce the risk for
managed installs. +bheenan@ for opinions on that front.

I agree, this looks like a breaking change according to
go/chrome-enterprise-friendly and therefore needs a policy. Instructions
for implementing a policy are here:
https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
if you haven't done it before, and the enterprise team is happy to help if
anything seems confusing. Having this implemented as a "soft removal" with
a temporary policy escape hatch significantly reduces enterprise risk,
since even if we are surprised by a use case hiding behind many
enterprises' tendency to turn off metrics, those users can
break-fix themselves immediately while staying on the latest version.

On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  wrote:

> Hey Daniel!
>
> While searching for this intent review, I stumbled upon
> https://developer.chrome.com/blog/immutable-document-domain/
> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>
> This intent was just discussed at the API owner meeting (where Chris,
> Rego, Daniel, Philip, Alex, MikeT and myself were present).
> This change seems risky in terms of potential breakage when looking at our
> stats, and that's even before talking about enterprises, where a lot of the
> API owners feel the risk is even higher.
>
> Given that, here's a few potential next steps to try and reduce that risk:
>
>- UKM and outreach to specific large users of the API can maybe help
>drive the usage down.
>- A deprecation period of 3 milestones feels a bit short here. Is the
>expectation that turning on the opt-out header can be done under that
>period?
>- A report-only mode could have allowed sites to try and enable this,
>without risking actual breakage for their documents/properties that use
>document.domain. This is doubly true for platforms that want to warn their
>customers about this upcoming deprecation, but without taking risks on
>their behalf. At the same time, it is true that they could collect
>deprecation reports (thanks for adding those!) instead during the
>deprecation period, which can be considered an on-by-default report-only
>mode. Can y'all add specific guidance on deprecation reports to the
>documentation?
>-  It'd be helpful to reach out to enterprise folks and see what their
>responses may be for this. +Greg Whitworth.
>- This probably requires an Enterprise Policy, to reduce the risk for
>managed installs. +bheenan@ for opinions on that front.
>- Is there a plan to eventually remove the opt-out option? Or is it
>the plan to have it in place permanently?
>
> Cheers,
> Yoav
>
>
> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>
>> On 12/16/21 5:52 PM, Charlie Reis wrote:
>>
>>
>>
>> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
>>> wrote:
>>>
 On 12/14/21 11:35 AM, Daniel Bratell wrote:

 It seems more or less everyone agrees on this being a good thing, so it
 mainly comes down to web compatibility.

 How much of the web will break, and how badly. The numbers mentioned,
 0.5% of sites set document.domain, 0.05% seem to depend on document.domain,
 are quite high. One thing I didn't quite pick up is what happens if you try
 to set document.domain when it's not settable. Will it silently pretend to
 work, or will that also be a possible break point?

 I would be surprised if it didn't behave the same as setting an
 arbitrary expando on `document` - we should be safe there.

>>>
>>> Almost. The error handling is mostly the same. But while a foreign
>>> attribute on document would return the new value, document.domain (when in
>>> an origin-keyed agent cluster) does not.
>>>
>>> So:
>>>   document.foo = "bla"
>>>   document.foo  // Returns "bla".
>>>
>>>   document.domain = "bla"  // Throws SecurityException.
>>>
>>>   // On a domain www.host.com, site-keyed agent cluster (current
>>> default)
>>>   document.domain = "host.com"  // Succeeds.
>>>   document.domain;  // returns "host.com".
>>>
>>>   // On a domain www.host.com, origin-keyed agent cluster (future
>>> default)
>>>   document.domain = "host.com"  // Doesn't throw. Doesn't do anything
>>> else either.
>>>   document.domain;  // Still returns www.host.com.
>>>
>>> Risks: Interoperability and Compatibility

 * No interoperability risks. *
 Compatibility risk exists, but is fairly small as document.domain is an
 already deprecated feature. We’ve detailed UKM metrics in place and are
 planning to reach out to top users as soon as we’ve LGTMs for the plan.

 As Daniel mentioned, I think the compat risk should be considered to be
 higher, despite this being deprecated for a long time.

>>>
>>> Yes, agreed.