One addition please: work with me and the enterprise team to also add a paragraph to the enterprise release notes before the deprecation warning is switched to on-by-default
On Fri, Apr 21, 2023 at 3:13 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > LGTM2 for the above plan. Good luck!! > > On Thu, Apr 20, 2023 at 11:37 PM Rick Byers <rby...@chromium.org> wrote: > >> Jun and I have been talking about this offline and I think we've got a >> reasonable plan to attempt to proceed with this breaking change: >> >> - Add Enterprise policy knob >> <https://www.chromium.org/developers/enterprise-changes/> >> - Disable in WebView by default (or add targetSdk quirk) - in >> discussion with WebView team >> - Publish a blog post explaining the change and how to adapt to it, >> linked from chromestatus entry >> - Add deprecation warning (console + deprecation report) linking to >> chromestatus entry >> - Try flipping the flag on with Finch in canary and dev builds, maybe >> beta 50%, watch for reports of bugs and engage on any to see if they're >> similarly easy to get sites fixed >> - Once 3 milestones have passed with the deprecation warning and >> there's aren't major known issues, flip the flag on by default (with >> killswitch in place) >> - As the change makes its way to stable, keep an eye on any reports. >> Be prepared to hit the killswitch and iterate if there is significant >> breakage that can't be immediately addressed. >> >> With this plan, I'm LGTM1 to give this a shot. >> >> On Tue, Jan 24, 2023 at 10:22 AM Rick Byers <rby...@chromium.org> wrote: >> >>> >>> On Mon, Jan 23, 2023 at 3:00 PM Jun Kokatsu <jkoka...@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 >>>> <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. >>>> >>>> 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 <https://github.com/Keyamoon/svgxuse> as a fallback >>>> mechanism <https://github.com/okp4/ui/pull/433>. >>>> >>> >>> 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 >>>> <https://dbratell.github.io/svg-use-icons/> 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 <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? >>>>> >>>> >>> 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> >>>>> <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 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. >>> >>>> 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/CAFKd2qX6NkSPkaWUo9__gH%2Bucjjb1n0f%2B%3DWOzvMJVcivqcLcVA%40mail.gmail.com.
