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.