Intent to Deprecate and Remove: data: URL in SVGUseElement

[Jun Kokatsu]

Contact emails

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

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.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5128825141198848

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

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

Contact emails

jkok...@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+...@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.gmail.com.

[Jun Kokatsu]

On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor <mike...@chromium.org> wrote:

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

Contact emails

jkok...@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 🙂

[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 <use> element with nothing else in the <svg> 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

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

[Jun Kokatsu]

Thank you Rick for the detailed explanation!

On Fri, Jan 13, 2023 at 10:30 AM Rick Byers <rby...@chromium.org> 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 <use> element with nothing else in the <svg> 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 <use> 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 <use> 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: This is allowed by spec today, so breaking it requires some more diligence

Note that the PR to SVG spec got merged.

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

Yes, it sounds good to me! I will check what has to be done and do those step by step 🙂

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

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

[Rick Byers]

On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss <yoav...@chromium.org> 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 <blin...@chromium.org> wrote:

Thank you Rick for the detailed explanation!

On Fri, Jan 13, 2023 at 10:30 AM Rick Byers <rby...@chromium.org> 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 <use> element with nothing else in the <svg> 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 <use> 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 <use> 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: This is allowed by spec today, so breaking it requires some more diligence

Note that the PR to SVG spec got merged.

Right, yes, sorry. What I meant was we took the initiative to make a breaking change to long established behavior - IMHO that makes the bar higher than if Chrome had just had a bug in allowing something that was never spec'd or allowed by other browsers. Still I think we can use this positively in our outreach - say something like "the spec has changed to not allow this, all the major browser engines agree that for security reasons it should be disallowed. It already doesn't work in Safari and other WebKit browsers, we want to help you fix your site to work in all browsers". 

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

Yes, it sounds good to me! I will check what has to be done and do those step by step 🙂

Ok, good luck! Sorry this isn't as straightforward as a clear recipe.  But if we can get a couple developers telling us they were easily able to fix their issue by using a tool or straightforward instructions we can point other to, and we see the UseCounter drop significantly (say by half or so) without major new red flags, then I'd personally be OK approving a removal attempt. Of course it's common to learn during beta (or, worst case, upon stable release) that the compat issue is worse than we thought and so the change needs to be reverted (or flagged off with finch) in a hurry. But I think we've learned a lot over the years about how to predict and avoid that failure mode. Let me know if I can do anything else to help, happy to meet to brainstorm further for example. Good luck!

[Brandon Heenan]

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.

[Jun Kokatsu]

On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan <bhe...@google.com> 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 <rby...@chromium.org> wrote:

On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss <yoav...@chromium.org> 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 <blin...@chromium.org> wrote:

Thank you Rick for the detailed explanation!

On Fri, Jan 13, 2023 at 10:30 AM Rick Byers <rby...@chromium.org> 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 <use> element with nothing else in the <svg> 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 <use> 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've created a site to convert data: URLs in SVGUseElement to inline SVG.

https://data-urls-in-svg-converter.glitch.me/ 

• 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 <use> 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: This is allowed by spec today, so breaking it requires some more diligence

Note that the PR to SVG spec got merged.

Right, yes, sorry. What I meant was we took the initiative to make a breaking change to long established behavior - IMHO that makes the bar higher than if Chrome had just had a bug in allowing something that was never spec'd or allowed by other browsers. Still I think we can use this positively in our outreach - say something like "the spec has changed to not allow this, all the major browser engines agree that for security reasons it should be disallowed. It already doesn't work in Safari and other WebKit browsers, we want to help you fix your site to work in all browsers". 

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

Yes, it sounds good to me! I will check what has to be done and do those step by step 🙂

Ok, good luck! Sorry this isn't as straightforward as a clear recipe.  But if we can get a couple developers telling us they were easily able to fix their issue by using a tool or straightforward instructions we can point other to, and we see the UseCounter drop significantly (say by half or so) without major new red flags, then I'd personally be OK approving a removal attempt. Of course it's common to learn during beta (or, worst case, upon stable release) that the compat issue is worse than we thought and so the change needs to be reverted (or flagged off with finch) in a hurry. But I think we've learned a lot over the years about how to predict and avoid that failure mode. Let me know if I can do anything else to help, happy to meet to brainstorm further for example. Good luck!

Thanks! I'll start outreach for a couple of sites we already know are affected, and go from there! 

[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

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[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

<svg style="display:none"><defs><symbol id="icon1">...</symbol><symbol id="icon2">...</symbol></defs></svg>

And then refer to the icons in it with <svg><use xlink:href="#icon1"></svg> or <svg><use xlink:href="#icon2"></svg>

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63c3823-20b6-457c-bff9-f85429421bf0n%40chromium.org.

[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

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Jun Kokatsu]

On Thu, Jan 19, 2023 at 9:29 AM Rick Byers <rby...@chromium.org> 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 <brat...@gmail.com> 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

<svg style="display:none"><defs><symbol id="icon1">...</symbol><symbol id="icon2">...</symbol></defs></svg>

And then refer to the icons in it with <svg><use xlink:href="#icon1"></svg> or <svg><use xlink:href="#icon2"></svg>

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.

[Rick Byers]

On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu <jkok...@google.com> wrote:

On Thu, Jan 19, 2023 at 9:29 AM Rick Byers <rby...@chromium.org> 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 <brat...@gmail.com> 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

<svg style="display:none"><defs><symbol id="icon1">...</symbol><symbol id="icon2">...</symbol></defs></svg>

And then refer to the icons in it with <svg><use xlink:href="#icon1"></svg> or <svg><use xlink:href="#icon2"></svg>

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? 

[Jun Kokatsu]

On Thu, Jan 19, 2023 at 2:14 PM Rick Byers <rby...@chromium.org> wrote:

On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu <jkok...@google.com> wrote:

On Thu, Jan 19, 2023 at 9:29 AM Rick Byers <rby...@chromium.org> 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 <brat...@gmail.com> 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

<svg style="display:none"><defs><symbol id="icon1">...</symbol><symbol id="icon2">...</symbol></defs></svg>

And then refer to the icons in it with <svg><use xlink:href="#icon1"></svg> or <svg><use xlink:href="#icon2"></svg>

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

[Jun Kokatsu]

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

[Rick Byers]

On Mon, Jan 23, 2023 at 3:00 PM Jun Kokatsu <jkok...@google.com> 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 <jkok...@google.com> wrote:

On Thu, Jan 19, 2023 at 2:14 PM Rick Byers <rby...@chromium.org> wrote:

On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu <jkok...@google.com> wrote:

On Thu, Jan 19, 2023 at 9:29 AM Rick Byers <rby...@chromium.org> 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 <brat...@gmail.com> 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

<svg style="display:none"><defs><symbol id="icon1">...</symbol><symbol id="icon2">...</symbol></defs></svg>

And then refer to the icons in it with <svg><use xlink:href="#icon1"></svg> or <svg><use xlink:href="#icon2"></svg>

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?

 

I was thinking for 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. 

Oh yeah I certainly wouldn't suggest we do anything chromium-specific here. Just that if we decide the web compat challenge of deprecating all data urls is too high, then we could probably get other vendors on board with something more modest and get that fully spec'd and tested.

For example, if the <foreignObject> 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 for those links, I hadn't appreciated how much discussion had gone into the tradeoffs already. I agree that if we can convince ourselves it's not too breaking that this is the best solution. But I see from the discussion that the consensus was based on the assumption that we had already decided the web compat risk was sufficiently low. I'd certainly prefer not to re-open the standards discussion as this solution seems the safest, simplest and most coherent for the platform, but it's good to know what our fallback options are so that we can keep the cost/benefit tradeoffs in mind as we learn more.

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

[Yoav Weiss]

LGTM2 for the above plan. Good luck!!

[Brandon Heenan]

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

[Jun Kokatsu]

Hi Brandon!

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

Thanks,

Jun

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF4pXiQd2OvaSfB0ZLFZ-0Ej9ghW%2BDbhrCVMUzy9Zhk4Zw%40mail.gmail.com.

[Rick Byers]

I just wanted to take a minute to reflect back on this tricky breaking change, since I was unsure whether it would be successful or not. In the end we got exactly zero bug reports or complaints (as far as Jun and I know), and it looks like the use counter has dropped to about 1/3rd of where it was at before this went to stable. We are aware of at least one site that is still broken (sickdeals.net), but it's a minor icon at the bottom of the page so not a major functionality problem. 

My takeaway is that this non-trivial breaking change was successful because:

• Severity of breakage: The vast majority of breakage was relatively cosmetic - minor icons 
• Outreach: Jun published a great blog post, and used UKM data to reach out to several sites who made a fix. At least one of these (salesforce) was a high enough severity of breakage that it would have likely been an emergency if not for the pro-active outreach
• Ease of adaptation: The blog post had a clear description of how to fix the issue, with a link to samples that were easy to understand and replicate. When Jun did outreach, developers were easily able to fix their site
• Interoperability: We heard from at least one developer that they hadn't realized their page was broken in Safari and they were happy to be shown how to easily fix it to work across all browsers. This likely increased the goodwill in our outreach and decreased the chance of developers considering it a Chrome bug once they understood it.

It's unclear whether the enterprise policy was useful or not (not sure if we have metrics, and even if we did there's a good chance they wouldn't get sent from an enterprise environment). But otherwise I think the work (UKM, outreach, blog) was highly valuable to the success. We can never know the counterfactual, but with so much accidental pain in our past, it's good to reflect on these tricky cases that end up going well.

Thank you Jun for all the diligence and patience! I'm so glad you chose this path rather than leaving an ugly wart in the platform forever!

   Rick

[Jun Kokatsu]

Thanks Rick!

It's also worth mentioning that Firefox followed this deprecation in Firefox 122, and now this feature is deprecated in all modern browsers!

Jun

[Thomas Steiner]

Hey all,

Congratulations on this deprecation. Just as an FYI, I have created a talk based on this deprecation, and whenever I give it, people really are surprised by and appreciate the amount of work that goes into deprecating features. Glad this story ended well! 

Cheers,

Tom

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

--

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.3 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

[Rick Byers]

Great slide deck Thomas, thank you!

I'm glad to hear that's the feedback you get. In addition to actually minimizing harm, it's also an important goal of our process to earn and retain the trust of web  businesses for Chromium being a responsible and reliable steward of the platform on which their business depends.

Rick