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? > 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/CAFUtAY9O_VkFJk%2B0NeVtqsXQynakcPQXFELLMohfZUUSsyyyug%40mail.gmail.com.
