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/CAL5BFfXmS%3DjgO90EJu_pKOUdcfbUsK0kizVOqYkhW8WzThJriA%40mail.gmail.com.
