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 <https://chromestatus.com/metrics/feature/timeline/popularity/4356>, 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 <https://github.com/Keyamoon/svgxuse> as a fallback mechanism <https://github.com/okp4/ui/pull/433>. 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 <https://dbratell.github.io/svg-use-icons/> 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 <jkoka...@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 <jkoka...@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 >>>> <https://appexchange.salesforce.com/#:~:text=Learn%20More-,Sponsored%20Solutions,-Show%20More> >>>> 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 >>>> <https://data-urls-in-svg-converter.glitch.me/> does? >>>> >>>> Rick >>>> >>>> On Thu, Jan 19, 2023 at 8:53 AM Daniel Bratell <bratel...@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> > <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/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 > <https://www.w3.org/TR/SVG2/struct.html#UseShadowTree:~:text=Within%20a%20use%2Delement%20shadow%20tree%2C%20%E2%80%98script%E2%80%99%20elements%20are%20inert%20(do%20not%20execute)%3B> > on the use element is enough to apply in child frames too? > > If it is for XSS, then as I mentioned, SVG link > <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/a> 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 <https://github.com/mozilla/standards-positions/issues/718>, > 2 <https://github.com/WebKit/standards-positions/issues/108>, 3 > <https://github.com/w3c/trusted-types/issues/357#issuecomment-1049761361> > , 4 <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c10>, 5 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c11>) 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 <bhee...@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 >>>>>>> <https://goto.google.com/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 <yoavwe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Would it be possible to turn >>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=30?q=ukm%20usecounter&ss=chromium> >>>>>>>>> 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 <bhee...@google.com> 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 <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 >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.mqfkui78vo5z>" >>>>>>>>>>> rule of thumb. Here's a bit of an analysis according to our other >>>>>>>>>>> compat >>>>>>>>>>> principles <http://bit.ly/blink-compat>: >>>>>>>>>>> >>>>>>>>>>> - Severity of breakage >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.u5ya6jvru7dl>: >>>>>>>>>>> lower given this is likely only about some visualis, but this >>>>>>>>>>> site <https://jobs.nzz.ch/> 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 >>>>>>>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/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 <https://wicg.github.io/deprecation-reporting/>) >>>>>>>> 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 <ad...@chromium.org>) 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 >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4k9u8ddizqrq>: >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.iklh96dxj81w>: >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>: >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4hjbxw7513sw>: >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.xcsa26ortrmi>: >>>>>>>>>>> This is allowed by spec today, so breaking it requires some more >>>>>>>>>>> diligence >>>>>>>>>>> >>>>>>>>>>> Note that the PR <https://github.com/w3c/svgwg/pull/901> 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 >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.axcg738lzcs9>: >>>>>>>>>>> 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 >>>>>>>>>>> <https://www.chromium.org/developers/enterprise-changes/>. >>>>>>>>>>> - Outreach >>>>>>>>>>> >>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.t9ade4ywppcg>: >>>>>>>>>>> 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! >>>>>> >>>>>>> >>>>>>>> >>>>>>>>>>> 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 < >>>>>>>>>>>> miketa...@chromium.org> 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 >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG> >>>>>>>>>>>>> >>>>>>>>>>>>> Motivation >>>>>>>>>>>>> >>>>>>>>>>>>> Assigning an attacker controlled string to SVGUseElement.href >>>>>>>>>>>>> causes XSS and a Trusted Types bypass >>>>>>>>>>>>> <https://github.com/w3c/trusted-types/issues/357> 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 >>>>>>>>>>>>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import>. >>>>>>>>>>>>> However, SVGUseElement is an exception to this, which also caused >>>>>>>>>>>>> a >>>>>>>>>>>>> bypass >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1306450#c10> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4356> >>>>>>>>>>>>> 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 >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/frame/deprecation/README.md> >>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://github.com/mozilla/standards-positions/issues/718> >>>>>>>>>>>>> >>>>>>>>>>>>> WebKit: Positive >>>>>>>>>>>>> <https://github.com/WebKit/standards-positions/issues/108> >>>>>>>>>>>>> >>>>>>>>>>>>> Web developers: No signals >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Debuggability >>>>>>>>>>>>> >>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>> ? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes <https://github.com/web-platform-tests/wpt/pull/37511> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>>>> -- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>> it, send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.gmail.com >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF5KQOG5R8baUM41T4fR01QbGFjvvEsf629h%2BzASCn_F0Q%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF5KQOG5R8baUM41T4fR01QbGFjvvEsf629h%2BzASCn_F0Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF65KcSCkzVupRw4n8ZG%3DKKbG5GY62HzwNSZW4Z78ZYd_w%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF65KcSCkzVupRw4n8ZG%3DKKbG5GY62HzwNSZW4Z78ZYd_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63c3823-20b6-457c-bff9-f85429421bf0n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63c3823-20b6-457c-bff9-f85429421bf0n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6%3DyB2%3DNgSMjO_uYMbnbxMi%3DPVNmsPzJjgBpsAZC14eoA%40mail.gmail.com.
