I don't use XSLT and don't object to this, but seeing "security" cited made me realize how reflexively distrustful I've become of them using that justification for a given decision. Is this one actually about security? Who knows!

▲

masfuerte 19 hours ago | parent | next [-]

There are security issues in the C implementation they currently use. They could remove this without breaking anything by incorporating the JS XSLT polyfill into the browser. But they won't because money.

▲

bawolff 20 hours ago | parent | prev | next [-]

Didn't this come pretty directly after someone found some security vulns? I think the logic was, this is a huge chunk of code that is really complex which almost nobody uses outside of toy examples (and rss feeds). Sure, we fixed the issue just reported, but who knows what else is lurking here, it doesn't seem worth it.

As a general rule, simplifying and removing code is one of the best things you can do for security. Sure you have to balance that with doing useful things. The most secure computer is an unplugged computer but it wouldn't be a very useful one; security is about tradeoffs. There is a reason though that security is almost always cited - to some degree or another, deleting code is always good for security.

▲

jeroenhd 10 hours ago | parent | next [-]

The vulnerabilities themselves often didn't really affect Chrome, but by the maintainers' own admission the code was never intended to be security critical. They got burned out after a series of vulnerability reports with publication deadlines made them decide to just take security bugs like normal bugs so the community could help fix things. That doesn't really fit with the "protect users by keeping security issues ecret for three months" approach corporations prefer. Eventually the maintainers stepped down.

Neither Google nor Apple were willing to sponsor a fork of the project but clearly they can't risk unmaintained dependencies in their billion dollar product, so they're rushing to pull the plug.

"Who knows what's lurking there" is a good argument to minimize attack surface, but Google has only been adding more attack surface over the past couple of years. I find it hard to defend that processing a structured document should be outside of a browser's feature set, but Javascript USB drivers and serial ports are necessary to drive the web. The same way libxml2 was never intended to be security critical, many GPU drivers were never written to protect from malicious programs, yet WebGPU and similar technology i being pushed hard and fast.

If we're deleting code to improvve against theoretical security risks, I know plenty of niche APIs that should probably be axed.

▲

bawolff 8 hours ago | parent [-]

> the maintainers' own admission the code was never intended to be security critical

I find this hard to believe. XML is a portable data serialization format. The entire point of XML is to transfer data between separate parties who preumably dont trust each other. Most non browser xml usages are security criical and have been from the beginning.

Just look at their website from 2001 https://web.archive.org/web/20010202061700/http://xmlsoft.or... they specificly advertise processing remote documents from http & ftp as a usecase.

Second, i don't know what libxml has to do with anything. I know the libraries are related but browsers are not removing libxml they are removing libxslt.

> Neither Google nor Apple were willing to sponsor a fork of the project but clearly they can't risk unmaintained dependencies in their billion dollar product, so they're rushing to pull the plug.

Why would they sponser a fork? I wouldn't in their position. A fork solves the maitenance issue but not the other problems. The lack of maintainers exasperbate the problem, but it is not the problem.

There is this weird entitlement people have with google where people expect google to randomly provide open source projects with free labour even if its not inline with google's interests.

If google was demanding someone else step up to maintain, then saying they should do it would be reasonable. But they aren't doing that. After all a new maintainer did step up, but the deprecation is still happening as it wasnt solely about that.

> but Javascript USB drivers and serial ports are necessary to drive the web

I also think these are stupid features, but their risk profile is probably quite a bit lower than xslt. Not all code has the same risk factors. What sort of api is exposed, how its exposed, code quality, etc all matter.

Ultimately though its google's web browser. People have this weird entitlement with google where they expect google to make specific product decisions. Its open source software. The solution to google making bad product decisions is the right to fork. If the decisions are that bad, the fork will win. Having google design their software by a comittee, where a comittee is the entire internet,is not reasonable nor would it make a good product.

	▲	JetSpiegel 2 hours ago \| parent [-]
		What are you talking about, "free labor"? They are using the damn library, Google would benefit directly.

▲

wswope 19 hours ago | parent | prev [-]

> As a general rule, simplifying and removing code is one of the best things you can do for security.

Sure, but that’s not what they’re doing in the big picture. XSLT is a tiny drop in the bucket compared to all the surface area of the niche, non-standard APIs tacked onto Chromium. It’s classic EEE.

https://developer.chrome.com/docs/web-platform/

	▲	bawolff 18 hours ago \| parent [-]
		My understanding is that contrary to popular opinion it is firefox not chrome that originally pushed for the removal, so i dont know how relavent that is. It seems like all browser vendors are in agreement on xslt. that said, xslt is a bit of a weird api in how it interacts with everything. Not all apis are equally risky and i suspect xslt is pretty high up there on the risk vs reward ratio.

▲

JimDabell 20 hours ago | parent | prev | next [-]

> Finding and exploiting 20-year-old bugs in web browsers

> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.

— https://www.offensivecon.org/speakers/2025/ivan-fratric.html

— https://www.youtube.com/watch?v=U1kc7fcF5Ao

> libxslt -- unmaintained, with multiple unfixed vulnerabilities

— https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99...

▲

willseth 15 hours ago | parent | prev | next [-]

It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.

▲

throw_m239339 14 hours ago | parent | prev | next [-]

Especially when Google largely has the money to maintain the alleged unsecure library... of course it's an excuse to break the web once again.

XSLT is fantastic. You just feed it an XML file and it can change it into HTML, without any need for javascript.

▲

chrismorgan 18 hours ago | parent | prev | next [-]

> example.com needs to review the security of your connection before proceeding.

This text from Cloudflare challenge pages is just a flat-out lie.

▲

Devasta 21 hours ago | parent | prev [-]

Its "Security" when they want to do a thing, its "WebCompat" when they don't.