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

[Rick Byers]

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
>>  does?
>>
>> Rick
>>
>> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
>> wrote:
>>
>>> Without saying whether it is appropriate to block data urls, I would
>>> like to say that doing what the site is doing with icons in data urls is
>>> far from the best way to do it. Since there are better ways to 
>>> accomplish
>>> the same output, it's not in itself a use pattern that must be 
>>> preserved.
>>> It is better to either have the icons in a separate file, or if that is
>>> unsuitable, have them

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

[Yoav Weiss]

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
>>>  does?
>>>
>>> Rick
>>>
>>> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
>>> wrote:
>>>
 Without saying whether it is appropriate to block data urls, I
 would like to say that doing what the site is doing with icons in data 
 urls
 is far from the best way to do it. Since there

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

['Jun Kokatsu' via blink-dev]

Hi Brandon!

I'll make sure to do that! I'll ping you next week when I start to work
on it!

Thanks,

Jun


On Fri, Apr 21, 2023 at 7:55 AM Brandon Heenan  wrote:

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

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

[Mike West]

LGTM3.

-mike


On Fri, Apr 21, 2023 at 7:42 PM 'Jun Kokatsu' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi Brandon!
>
> I'll make sure to do that! I'll ping you next week when I start to work
> on it!
>
> Thanks,
>
> Jun
>
>
> On Fri, Apr 21, 2023 at 7:55 AM Brandon Heenan  wrote:
>
>> 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 pag

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

[Mike Taylor]

On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote:



Contact emails

jkoka...@google.com


Specification

https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute 



https://github.com/w3c/svgwg/pull/901/files


Summary

Assigning a data: URL in SVGUseElement can cause XSS. And this also 
led to a Trusted Types bypass.



Therefore, we plan to deprecate and remove support for it.



Blink component

Blink>SVG 




Motivation

Assigning an attacker controlled string to SVGUseElement.href causes 
XSS and a Trusted Types bypass 
because of data: 
URLs. If we fix this bug by requiring TrustedScriptURL assignment to 
SVGUseElement.href under Trusted Types enforcement, many sites would 
need to refactor code (even for same-origin URL or Blob URL assignment).



Since Webkit does not support data: URLs in SVGUseElement and both 
Mozilla and Webkit are supportive for the removal, we think that 
removing support for data: URLs in SVGUseElement is the right way to 
solve this problem.



Additionally, data: URLs can only trigger script execution in script 
loaders such as HTMLScriptElement.src or dynamic import 
. 
However, SVGUseElement is an exception to this, which also caused a 
bypass 
in 
the Sanitizer API. We believe that this also led to several other bugs 
in sanitizers and linters missing a check for this special case.



The usage 
of 
data: URLs in SVGUseElement is about 0.005%.



Digging into the HTTP Archive shows usages in ~50 sites. There are 2 
major sites (slickdeals.net and 
hunter.104.com.tw ) which use data: URLs in 
SVGUseElement.


The use in slickdeals.net is invisible (i.e. 
used in the footer but doesn't appear), and hunter.104.com.tw 
is using it for a single icon in the footer 
(which is already broken when rendered in Webkit). Rest of the usages 
seems to be in individual small sites.



I poked around the 10 sample sites at the bottom of the use counter:

https://www.aspareanord.it/, https://www.umbria.camcom.it, 
https://www.bisenzio.it/, https://www.comune.vernio.po.it/, 
https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/, 
https://www.us.schott.com/, https://shop.wavin.com/, 
https://jobs.nzz.ch/, https://www.learnapp.com/


For the 6 Italian sites (I guess the same agency made them?), the right 
arrow icon next to "Vedi" would disappear. For a site like 
https://jobs.nzz.ch - there's a number of visually significant design 
icons that would be gone towards the bottom (and yes, it looks sort of 
broken today in Safari).


It's not the end of the world, looking at these 10 sites, but I wonder 
how a developer would know how to fix this. Have you considered a 
DevTools issue?




Initial public proposal



TAG review



TAG review status

Not applicable.

Because this intent removes part of a feature, and it is already 
shipped in Webkit (i.e. never supported).



Risks



Interoperability and Compatibility



Gecko: Positive 




WebKit: Positive 




Web developers: No signals



Debuggability



Is this feature fully tested by web-platform-tests

?

Yes 


Flag name

RemoveDataUrlInSvgUse



Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1300195 




Estimated milestones

Deprecate for 2 milestones, then remove depending on breakages.

Can you say more about what the deprecation looks like (i.e., blog post, 
deprecation reports, devtools issue, etc)?



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5128825141198848 




This intent message was generated by Chrome Platform Status 
.

--
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/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_Uz

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

['Jun Kokatsu' via blink-dev]

On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor  wrote:

> On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote:
>
> Contact emails
>
> jkoka...@google.com
>
> Specification
>
> https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute
>
> https://github.com/w3c/svgwg/pull/901/files
>
> Summary
>
> Assigning a data: URL in SVGUseElement can cause XSS. And this also led to
> a Trusted Types bypass.
>
> Therefore, we plan to deprecate and remove support for it.
>
>
> Blink component
>
> Blink>SVG
> 
>
> Motivation
>
> Assigning an attacker controlled string to SVGUseElement.href causes XSS
> and a Trusted Types bypass
>  because of data: URLs.
> If we fix this bug by requiring TrustedScriptURL assignment to
> SVGUseElement.href under Trusted Types enforcement, many sites would need
> to refactor code (even for same-origin URL or Blob URL assignment).
>
> Since Webkit does not support data: URLs in SVGUseElement and both Mozilla
> and Webkit are supportive for the removal, we think that removing support
> for data: URLs in SVGUseElement is the right way to solve this problem.
>
> Additionally, data: URLs can only trigger script execution in script
> loaders such as HTMLScriptElement.src or dynamic import
> .
> However, SVGUseElement is an exception to this, which also caused a bypass
>  in
> the Sanitizer API. We believe that this also led to several other bugs in
> sanitizers and linters missing a check for this special case.
>
> The usage
>  of
> data: URLs in SVGUseElement is about 0.005%.
>
> Digging into the HTTP Archive shows usages in ~50 sites. There are 2 major
> sites (slickdeals.net and hunter.104.com.tw) which use data: URLs in
> SVGUseElement.
>
> The use in slickdeals.net is invisible (i.e. used in the footer but
> doesn't appear), and hunter.104.com.tw is using it for a single icon in
> the footer (which is already broken when rendered in Webkit). Rest of the
> usages seems to be in individual small sites.
>
> I poked around the 10 sample sites at the bottom of the use counter:
>
> https://www.aspareanord.it/, https://www.umbria.camcom.it,
> https://www.bisenzio.it/, https://www.comune.vernio.po.it/,
> https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/,
> https://www.us.schott.com/, https://shop.wavin.com/, https://jobs.nzz.ch/,
> https://www.learnapp.com/
>
> For the 6 Italian sites (I guess the same agency made them?), the right
> arrow icon next to "Vedi" would disappear. For a site like
> https://jobs.nzz.ch - there's a number of visually significant design
> icons that would be gone towards the bottom (and yes, it looks sort of
> broken today in Safari).
>
> It's not the end of the world, looking at these 10 sites, but I wonder how
> a developer would know how to fix this. Have you considered a DevTools
> issue?
>

Thank you for the suggestion! Yes, I do plan to follow Deprecation steps

and
add a Devtools issue 🙂

> Initial public proposal
>
> TAG review
>
> TAG review status
>
> Not applicable.
>
> Because this intent removes part of a feature, and it is already shipped
> in Webkit (i.e. never supported).
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Positive
> 
>
> WebKit: Positive
> 
>
> Web developers: No signals
>
>
> Debuggability
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes 
>
> Flag name
>
> RemoveDataUrlInSvgUse
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1300195
>
> Estimated milestones
>
> Deprecate for 2 milestones, then remove depending on breakages.
>
> Can you say more about what the deprecation looks like (i.e., blog post,
> deprecation reports, devtools issue, etc)?
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5128825141198848
>
> This intent message was generated by Chrome Platform Status
> .
> --
> 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/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.

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

[Rick Byers]

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 don't suppose there's some creative way to allow this specific odd
   pattern while still getting the security benefit, is there?
   - Unique sites impacted
   
:
   Finding a variety of small sites is actually a lot worse than if we had
   found only a few bigger sites. It means there's probably some common tool
   or pattern leading different designers/developers to do this and so likely
   a relatively large number of individuals who would need to be involved in
   fixing the breakage. Of course our HTTP Archive list of sites is just a
   subset of who's fully impacted, so if the problem is a long-tail one as it
   seems, HTTP archive data shows us only the tip of that long tail.
   - Security
   
:
   it's definitely worth taking some comapt risk to reduce XSS surface area. I
   don't fully understand the threat model though. Is this mainly a risk for
   sites who are programmatically putting (potentially attacker-controlled)
   strings into SVGUseElement hrefs? Or are you more worried about cases where
   the attacker controls the HTML and can take advantage of this oddity in the
   platform on any normal site? I'm just trying to gauge the magnitude of the
   security benefit here to weigh it against the comapt risk, any help is
   appreciated.
   - Ease of adaptation
   
:
   seems like it should be easy to use an alternative, at least for these
   image cases, but I guess it's hard to say without knowing why people are
   doing this. Is there perhaps some website design tool which is generating
   this and will need to change?
   - Interop
   
:
   The fact that this doesn't work in Safari is a vote in favor of breaking it
   in chromium to achieve interop. It does work in Firefox though.
   - Standards conformance
   
:
   This is allowed by spec today, so breaking it requires some more diligence
   - Enterprise
   
:
   Being broken in Safari is an indication the risk will be higher in
   enterprise software which is often chromium-only. We may need to go through
   the enterprise breaking change process
   .
   - Outreach
   
:
   Given the relatively high usage, if we want to proceed with this plan I
   think this is the main opportunity for mitigations. Can we try contacting
   some of these sites we've identified to understand why they're using this
   pattern? Is there a tool generating this pattern which we can get updated
   before we make the change? I think we'd need a blog post capturing what
   we've learned from talking with a few customers who have done this and how
   they fixed it for their UI design flow.

Sorry it's not looking to be an easy decision, but I hope this gives you
some ideas for how we might be able to reduce the risk to a point that we
could proceed. WDYT?

Rick

On Thu, Jan 12, 2023 at 3:11 PM 'Jun Kokatsu' via blink-dev <
blink-dev@chromium.org> wrote:

> On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor 
> wrote:
>
>> On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote:
>>
>> Contact emails
>>
>> jkoka...@google.com
>>
>> Specification
>>
>> https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute
>>
>> https://github.com/w3c/svgwg/pull/901/files
>>
>> Summary
>>
>> Assigning a data: URL in SVGUseElement can cause XSS. And this also 

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

['Jun Kokatsu' via blink-dev]

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.

>
>- I don't suppose there's some creative way to allow this specific odd
>pattern while still getting the security benefit, is there?
>
> Unfortunately, no. While we could read the href value of  elements
and convert the data: URL to blob: URL, we won't know if the data: URL was
set by the site owner, or a malicious attacker (through HTML injection). So
while we could provide such a library, it does not provide the security
benefit that we are seeking.

>
>- Unique sites impacted
>
> :
>Finding a variety of small sites is actually a lot worse than if we had
>found only a few bigger sites. It means there's probably some common tool
>or pattern leading different designers/developers to do this and so likely
>a relatively large number of individuals who would need to be involved in
>fixing the breakage. Of course our HTTP Archive list of sites is just a
>subset of who's fully impacted, so if the problem is a long-tail one as it
>seems, HTTP archive data shows us only the tip of that long tail.
>- Security
>
> :
>it's definitely worth taking some comapt risk to reduce XSS surface area. I
>don't fully understand the threat model though. Is this mainly a risk for
>sites who are programmatically putting (potentially attacker-controlled)
>strings into SVGUseElement hrefs? Or are you more worried about cases where
>the attacker controls the HTML and can take advantage of this oddity in the
>platform on any normal site? I'm just trying to gauge the magnitude of the
>security benefit here to weigh it against the comapt risk, any help is
>appreciated.
>
> We are worried about both (i.e. Server-side injection and DOM XSS). The
fact that this has led to several browser security feature bypasses (e.g.
Sanitizer API and Trusted Types) suggests that it's not a commonly known
XSS sink, and therefore we believe that it's common for security mechanisms
(e.g. sanitizers, linters) to miss this odd feature.

>
>- Ease of adaptation
>
> :
>seems like it should be easy to use an alternative, at least for these
>image cases, but I guess it's hard to say without knowing why people are
>doing this. Is there perhaps some website design tool which is generating
>this and will need to change?
>
> I think it is easy to migrate by hosting the same image to the same-origin
endpoint. However, I do understand that it's just less work to use data:
URL than using same-origin image or blob: URL.

>
>- Interop
>
> :
>The fact that this doesn't work in Safari is a vote in favor of breaking it
>in chromium to achieve interop. It does work in Firefox though.
>
>  For the interop, it's best to use a same-origin URL or blob: URL. And
since both Mozilla and Webkit are supportive, I believe it's positive.

>
>- Standards conformance
>
> 

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

[Yoav Weiss]

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?

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.

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.
>
>>
>>- I don't suppose there's some creative way to allow this specific
>>odd pattern while still getting the security benefit, is there?
>>
>> Unfortunately, no. While we could read the href value of  elements
> and convert the data: URL to blob: URL, we won't know if the data: URL was
> set by the site owner, or a malicious attacker (through HTML injection). So
> while we could provide such a library, it does not provide the security
> benefit that we are seeking.
>
>>
>>- Unique sites impacted
>>
>> :
>>Finding a variety of small sites is actually a lot worse than if we had
>>found only a few bigger sites. It means there's probably some common tool
>>or pattern leading different designers/developers to do this and so likely
>>a relatively large number of individuals who would need to be involved in
>>fixing the breakage. Of course our HTTP Archive list of sites is just a
>>subset of who's fully impacted, so if the problem is a long-tail one as it
>>seems, HTTP archive data shows us only the tip of that long tail.
>>- Security
>>
>> :
>>it's definitely worth taking some comapt risk to reduce XSS surface area. 
>> I
>>don't fully understand the threat model though. Is this mainly a risk for
>>sites who are programmatically putting (potentially attacker-controlled)
>>strings into SVGUseElement hrefs? Or are you more worried about cases 
>> where
>>the attacker controls the HTML and can take advantage of this oddity in 
>> the
>>platform on any normal site? I'm just trying to gauge the magnitude of the
>>security benefit here to weigh it against the comapt risk, any help is
>>appreciated.
>>
>> We are worried about both (i.e. Server-side injection and DOM XSS). The
> fact that this has led to several browser security feature bypasses (e.g.
> Sanitizer API and Trusted Types) suggests that it's not a commonly known
> XSS sink, and therefore we believe that it's common for security mechanisms
> (e.g. sanitizers, linters) to miss this odd feature.
>
>>
>>- Ease of adaptation
>>
>> :
>>seems like it should be easy to use an alternative, at least for these
>>image cases, but I guess it's hard to say without knowing why people are
>>doing this. Is there perhaps some website design tool which is generating
>>this and will need to change?
>>
>> I think it is easy to migrate by hosti

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

[Rick Byers]

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
>>>odd pattern while still getting the security benefit, is there?
>>>
>>> Unfortunately, no. While we could read the href value of  elements
>> and convert the data: URL to blob: URL, we won't know if the data: URL was
>> set by the site owner, or a malicious attacker (through HTML injection). So
>> while we could provide such a library, it does not provide the security
>> benefit that we are seeking.
>>
>>>
>>>- Unique sites impacted
>>>
>>> :
>>>Finding a variety of

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 Deprecate and Remove: data: URL in SVGUseElement

['Jun Kokatsu' via blink-dev]

On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan  wrote:

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

Thank you for the details on enterprise policy! I'll make sure to follow
those steps when I plan to remove the feature by default!

> 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.
>>
>
Added UKM at https://crrev.com/c/4171733.

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

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

[Alex Russell]

Per today's API OWNERs meeting, a dumb question: is the XSS risk here 
largely down to script execution triggered by this pattern? Or non-script 
content in the inline'd SVG?

Thanks

On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:

> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan  
> wrote:
>
>> 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.
>>
>  
> Thank you for the details on enterprise policy! I'll make sure to follow 
> those steps when I plan to remove the feature by default! 
>
>> 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.
>>>
>>  
> Added UKM at https://crrev.com/c/4171733.
>
>>
>>> 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 

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

[Daniel Bratell]

Without saying whether it is appropriate to block data urls, I would 
like to say that doing what the site is doing with icons in data urls is 
far from the best way to do it. Since there are better ways to 
accomplish the same output, it's not in itself a use pattern that must 
be preserved. It is better to either have the icons in a separate file, 
or if that is unsuitable, have them inline in an invisible svg. I put a 
quick demo at https://dbratell.github.io/svg-use-icons/ but in short you 
could have


...id="icon2">...


And then refer to the icons in it with xlink:href="#icon1"> or 


That would have cut tens of KB from the cz site source. I checked with 
fs and thanks to optimizations Blink would not have created a separate 
svg document for each icon but that was also a risk.


(Also curious to the answer to Alex' question)

/Daniel

On 2023-01-18 17:50, Alex Russell wrote:
Per today's API OWNERs meeting, a dumb question: is the XSS risk here 
largely down to script execution triggered by this pattern? Or 
non-script content in the inline'd SVG?


Thanks

On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:

On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan
 wrote:

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.

Thank you for the details on enterprise policy! I'll make sure to
follow those steps when I plan to remove the feature by default!

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.

Added UKM at https://crrev.com/c/4171733.


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

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

[Rick Byers]

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

Rick

On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell  wrote:

> Without saying whether it is appropriate to block data urls, I would like
> to say that doing what the site is doing with icons in data urls is far
> from the best way to do it. Since there are better ways to accomplish the
> same output, it's not in itself a use pattern that must be preserved. It is
> better to either have the icons in a separate file, or if that is
> unsuitable, have them inline in an invisible svg. I put a quick demo at
> https://dbratell.github.io/svg-use-icons/ but in short you could have
>
> ... id="icon2">...
>
> And then refer to the icons in it with  xlink:href="#icon1"> or 
> That would have cut tens of KB from the cz site source. I checked with fs
> and thanks to optimizations Blink would not have created a separate svg
> document for each icon but that was also a risk.
>
> (Also curious to the answer to Alex' question)
>
> /Daniel
>
> On 2023-01-18 17:50, Alex Russell wrote:
>
> Per today's API OWNERs meeting, a dumb question: is the XSS risk here
> largely down to script execution triggered by this pattern? Or non-script
> content in the inline'd SVG?
>
> Thanks
>
> On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:
>
>> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan 
>> wrote:
>>
>>> 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.
>>>
>>
>> Thank you for the details on enterprise policy! I'll make sure to follow
>> those steps when I plan to remove the feature by default!
>>
>>> 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.

>>>
>> Added UKM at https://crrev.com/c/4171733.
>>
>>>
 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

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

['Jun Kokatsu' via blink-dev]

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
>  does?
>
> Rick
>
> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
> wrote:
>
>> Without saying whether it is appropriate to block data urls, I would like
>> to say that doing what the site is doing with icons in data urls is far
>> from the best way to do it. Since there are better ways to accomplish the
>> same output, it's not in itself a use pattern that must be preserved. It is
>> better to either have the icons in a separate file, or if that is
>> unsuitable, have them inline in an invisible svg. I put a quick demo at
>> https://dbratell.github.io/svg-use-icons/ but in short you could have
>>
>> ...> id="icon2">...
>>
>> And then refer to the icons in it with > xlink:href="#icon1"> or 
>> That would have cut tens of KB from the cz site source. I checked with fs
>> and thanks to optimizations Blink would not have created a separate svg
>> document for each icon but that was also a risk.
>>
>> (Also curious to the answer to Alex' question)
>>
>> /Daniel
>>
>> On 2023-01-18 17:50, Alex Russell wrote:
>>
>> Per today's API OWNERs meeting, a dumb question: is the XSS risk here
>> largely down to script execution triggered by this pattern? Or non-script
>> content in the inline'd SVG?
>>
>> Sorry, I just noticed that I only replied to Alex yesterday 🙂
The XSS risk here is mostly about script execution triggered by this
pattern. This includes (but not limited to) inline event handlers and links
with Javascript URLs.

> Thanks
>>
>> On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:
>>
>>> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan 
>>> wrote:
>>>
 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.

>>>
>>> Thank you for the details on enterprise policy! I'll make sure to follow
>>> those steps when I plan to remove the feature by default!
>>>
 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.
>

>>> Added UKM at https://crrev.com/c/4171733.
>>>

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

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

[Rick Byers]

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
>>  does?
>>
>> Rick
>>
>> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
>> wrote:
>>
>>> Without saying whether it is appropriate to block data urls, I would
>>> like to say that doing what the site is doing with icons in data urls is
>>> far from the best way to do it. Since there are better ways to accomplish
>>> the same output, it's not in itself a use pattern that must be preserved.
>>> It is better to either have the icons in a separate file, or if that is
>>> unsuitable, have them inline in an invisible svg. I put a quick demo at
>>> https://dbratell.github.io/svg-use-icons/ but in short you could have
>>>
>>> ...>> id="icon2">...
>>>
>>> And then refer to the icons in it with >> xlink:href="#icon1"> or 
>>> That would have cut tens of KB from the cz site source. I checked with
>>> fs and thanks to optimizations Blink would not have created a separate svg
>>> document for each icon but that was also a risk.
>>>
>>> (Also curious to the answer to Alex' question)
>>>
>>> /Daniel
>>>
>>> On 2023-01-18 17:50, Alex Russell wrote:
>>>
>>> Per today's API OWNERs meeting, a dumb question: is the XSS risk here
>>> largely down to script execution triggered by this pattern? Or non-script
>>> content in the inline'd SVG?
>>>
>>> Sorry, I just noticed that I only replied to Alex yesterday 🙂
> The XSS risk here is mostly about script execution triggered by this
> pattern. This includes (but not limited to) inline event handlers and links
> with Javascript URLs.
>

So if we find it's too breaking to disallow this pattern completely, could
we instead just disable script execution from within the context of
documents resulting from data: URLs in SVGUseAttributes?

> Thanks
>>>
>>> On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:
>>>
 On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan 
 wrote:

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

 Thank you for the details on enterprise policy! I'll make sure to
 follow those steps when I plan to remove the feature by default!

> 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.
>>
>
 Added UKM at https://crrev.com/c/4171733.

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

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

['Jun Kokatsu' via blink-dev]

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
>>>  does?
>>>
>>> Rick
>>>
>>> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
>>> wrote:
>>>
 Without saying whether it is appropriate to block data urls, I would
 like to say that doing what the site is doing with icons in data urls is
 far from the best way to do it. Since there are better ways to accomplish
 the same output, it's not in itself a use pattern that must be preserved.
 It is better to either have the icons in a separate file, or if that is
 unsuitable, have them inline in an invisible svg. I put a quick demo at
 https://dbratell.github.io/svg-use-icons/ but in short you could have

 ...>>> id="icon2">...

 And then refer to the icons in it with >>> xlink:href="#icon1"> or 
 That would have cut tens of KB from the cz site source. I checked with
 fs and thanks to optimizations Blink would not have created a separate svg
 document for each icon but that was also a risk.

 (Also curious to the answer to Alex' question)

 /Daniel

 On 2023-01-18 17:50, Alex Russell wrote:

 Per today's API OWNERs meeting, a dumb question: is the XSS risk here
 largely down to script execution triggered by this pattern? Or non-script
 content in the inline'd SVG?

 Sorry, I just noticed that I only replied to Alex yesterday 🙂
>> The XSS risk here is mostly about script execution triggered by this
>> pattern. This includes (but not limited to) inline event handlers and links
>> with Javascript URLs.
>>
>
> So if we find it's too breaking to disallow this pattern completely, could
> we instead just disable script execution from within the context of
> documents resulting from data: URLs in SVGUseAttributes?
>

Is that solution for Trusted Types or XSS through SVGUseElement in general?

If it is for Trusted Types, it does solve the issue in Chromium for short
term, but we want other rendering engines to implement Trusted Types as
well. Does that mean we spec this in Trusted Types that inline event
handlers from SVGUseElement will be disallowed when enforcing Trusted
Types?
One thing I'm not sure about this approach is that each rendering engine
has differences in supported features inside SVGUseElement.
For example, if the 
 is
supported, then iframes inside foreignObject can have srcdoc, and it can
contain script tags which are considered "stored" XSS (because the payload
never goes through DOM APIs), and therefore Trusted Types could be bypassed
(i.e. script tags are not inline event handlers). But maybe the current
script element restriction

on the use element is enough to apply in child frames too?

If it is for XSS, then as I mentioned, SVG link
 with
Javascript: URL can still trigger XSS (because the script execution is a
result of navigation, which can happen in the top frame or iframes by
target attribute).

Long story short, we did consider disabling scripts, but people's consensus
(1 , 2
, 3
, 4
, 5
) has
been that it's just better to deprecate data: URLs in SVGUseElement.

> Thanks

 On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:

> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan 
> wrote:
>
>> 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/enterp

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

['Jun Kokatsu' via blink-dev]

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.

I've also identified faucet.okp4.network as a false positive, because they
use svgxuse  as a fallback mechanism
.

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

BTW, thank you Daniel for creating a page
 with easy to read alternatives!
This was very helpful in the outreach process!

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

 Rick

 On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
 wrote:

> Without saying whether it is appropriate to block data urls, I would
> like to say that doing what the site is doing with icons in data urls is
> far from the best way to do it. Since there are better ways to accomplish
> the same output, it's not in itself a use pattern that must be preserved.
> It is better to either have the icons in a separate file, or if that is
> unsuitable, have them inline in an invisible svg. I put a quick demo at
> https://dbratell.github.io/svg-use-icons/ but in short you could have
>
> ... id="icon2">...
>
> And then refer to the icons in it with  xlink:href="#icon1"> or 
> That would have cut tens of KB from the cz site source. I checked with
> fs and thanks to optimizations Blink would not have created a separate svg
> document for each icon but that was also a risk.
>
> (Also curious to the answer to Alex' question)
>
> /Daniel
>
> On 2023-01-18 17:50, Alex Russell wrote:
>
> Per today's API OWNERs meeting, a dumb question: is the XSS risk here
> largely down to script execution triggered by this pattern? Or non-script
> content in the inline'd SVG?
>
> Sorry, I just noticed that I only replied to Alex yesterday 🙂
>>> The XSS risk here is mostly about script execution triggered by this
>>> pattern. This includes (but not limited to) inline event handlers and links
>>> with Javascript URLs.
>>>
>>
>> So if we find it's too breaking to disallow this pattern completely,
>> could we instead just disable script execution from within the context of
>> documents resulting from data: URLs in SVGUseAttributes?
>>
>
> Is that solution for Trusted Types or XSS through SVGUseElement in general?
>
> If it is for Trusted Types, it does solve the issue in Chromium for short
> term, but we want other rendering engines to implement Trusted Types as
> well. Does that mean we spec this in Trusted Types that inline event
> handlers from SVGUseElement will be disallowed when enforcing Trusted
> Types?
> One thing I'm not sure about this approach is that each rendering engine
> has differences in supported features inside SVGUseElement.
> For example, if the 
> 
> is supported, then iframes inside foreignObject can have srcdoc, and it can
> contain script tags which are considered "stored" XSS (because the payload
> never goes through DOM APIs), and therefore Trusted Types could be bypassed
> (i.e. script tags are no

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

[Rick Byers]

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
>  does?
>
> Rick
>
> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell 
> wrote:
>
>> Without saying whether it is appropriate to block data urls, I would
>> like to say that doing what the site is doing with icons in data urls is
>> far from the best way to do it. Since there are better ways to accomplish
>> the same output, it's not in itself a use pattern that must be preserved.
>> It is better to either have the icons in a separate file, or if that is
>> unsuitable, have them inline in an invisible svg. I put a quick demo at
>> https://dbratell.github.io/svg-use-icons/ but in short you could have
>>
>> > id="icon1">..
>>
>> And then refer to the icons in it with > xlink:href="#icon1"> or 
>> That would have cut tens of KB from the cz site source. I checked
>> with fs and thanks to optimizations Blink would not have created a 
>> separate
>> svg document for each icon but that was also a risk.
>>
>> (Also curious to the answer to Alex' question)
>>
>> /Daniel
>>
>> On 2023-01-18 17:50, Alex Russell wrote:
>>
>> Per today's API OWNERs meeting, a dumb question: is the XSS risk here
>> largely down to script execution triggered by this pattern? Or non-script
>> content in the inline'd SVG?
>>
>> Sorry, I just noticed that I only replied to Alex yesterday 🙂
 The XSS risk here is mostly about script execution triggered by this
 pattern. This includes (but not limited to) inline event handlers and links
 with Javascript URLs.

>>>
>>> So if we find it's too breaking to disallow this pattern completely,
>>> could we instead just disable script execution from within the context of
>>> documents resulting from data: URLs in SVGUseAttributes?
>>>
>>
>> Is that solution for Trust