Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing XSLT for a more secure browser

developer.chrome.com

Post reply on HN
Print view View original

251–260 of 352 posts

Re: Removing XSLT for a more secure browser

#251

Post by cxr »

QuadrupleA wrote: post #249
cxr wrote: post #235

Earlier quoted context omitted.

Point to the part of your comment that has any-fucking-thing to do with the topic at hand (i.e. engages with the actual substance of the comment that it's posted as a reply to). Your comment starts with "Yes but", as if it to present it as a rebuttal or rejoinder to something that was said, but then proceeds into total non-sequitur. It's an unrestrained attempt at a change of subject and makes for a not-very-hard-to-…

Alright, you're extremely rude and combative so I'll probably tap out here. But consider if the "yellow tchotchkes" draw some power from my house, produce some stinky blue smoke that occasionally wafts over, requires a government-paid maintenance person to occasionally stop by and work on, that I partly pay for with my taxes. That's my point.

> Alright, you're extremely rude

In contrast to poisoning the discussion with subtle conversational antimatter while wearing a veneer of amiability. My comments in this thread are not insidiously off-topic non-replies presented as somehow relevant in apposition to the ones that precede them.

> consider if the "yellow tchotchkes" draw some power from my house, produce some stinky blue smoke that occasionally wafts over, requires a government-paid maintenance person to occasionally stop by and work on, that I partly pay for with my taxes

Anyone making the "overwork the analogy" move automatically loses, always. Even ignoring that, nothing in this sentence even makes any sense wrt XSLT in the browser or the role of browser makers as stewards of stable Web standards. It's devoid of any cogent point and communicates no insight on the topic at hand.

Re: Removing XSLT for a more secure browser

#252

Post by cxr »

shadowgovt wrote: post #247
cxr wrote: post #219

Earlier quoted context omitted.

> As with most things on the web, the answer is "They will if it breaks a website that a critical mass of users care about." This is a (poor) attempt at gaslighting/retconning. The phrase "Don't break the Web" is not original to this thread. (I can't say I look forward to your follow-up reply employing sleights of hand like claims about how stuff like Flash that was never standardized, or the withdrawal of experiment…

Mozilla's own site expounds on "Don't Break the Web" as "Web browser vendors should be able to implement new web technologies without causing a difference in rendering or functionality that would cause their users to think a website is broken and try another browser as a result." There is no meaningful risk of that here. The percentage of web users who are trying to understand content via XSLT'd RSS is nearly zero, a…

> Mozilla's own site expounds on "Don't Break the Web" as

I'm a former Mozillian. I don't give a shit how it has been retconned by whomever happened to be writing copy that day, if indeed they have—it isn't even worth bothering to check.

"Don't break the Web" means exactly what it sounds like it means. Anything else is a lie.

> If the machine is so complex that nobody wants to maintain it, it will go unmaintained

There isn't a shortage of people willing to work on Web browsers. What there is is a finite amount of resources (in the form of compensation to engineers), and a set of people holding engineering positions at browser companies who, by those engineers' own admission, do not satisfy the conditions of being both personally qualified and equipped to do the necessary work here. But instead of stepping down from their role and freeing up resources to be better allocated to those who are equipped and willing, they're keeping their feet planted for the simple selfish reason that doing otherwise might entail a salary reduction and/or diminished power and influence. So they sacrifice the Web.

Fuck them.

Re: Removing XSLT for a more secure browser

#253

Post by jeroenhd »

bawolff wrote: post #75
gdulli wrote: post #38

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!

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…

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.

Re: Removing XSLT for a more secure browser

#254

Post by array_key_first »

neilk wrote: post #174
MarsIronPI wrote: post #22

To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all). I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add…

XSLT is being exploited right now for security vulnerabilities, and there is no solution on the horizon. The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tom…

> The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators.

Yes, they also have much more vulnerabilities, because browsers are JIT compiling JS to w+x memory pages. And JS continues to get more complex with time. This is just fundamentally not the case with XSLT.

We're comparing a few XSLT vulnerabilities to hundreds of JIT compiler exploits.

Re: Removing XSLT for a more secure browser

#255

Post by will4274 »

lunar_mycroft wrote: post #192
will4274 wrote: post #182

Earlier quoted context omitted.

According to whom? Chromium is open source and free (both as in beer and speech). The license says they've made no future commitments and made no warrants. Google signed up to give something away for free to people who want to use it. From the very first version, it wasn't perfectly compatible with other web browsers (which mostly did IE quirks things). If you don't want to use it, because it doesn't maintain enough…

The license would be relevant if I'd claimed that removing XSLT was illegal or opened them up to lawsuits, but I didn't. The obligation they took on is social/ethical, not legal. By your logic, chrome could choose to stop supporting literally anything (including HTML) in their "browser" and not have done anything that we can object to. iIRC, lack of IE compatibility is fundamentally different, because the IE specific…

> By your logic, chrome could choose to stop supporting literally anything (including HTML) in their "browser" and not have done anything that we can object to.

Literally this. Microsoft used to ship a free web browser. Then they stopped. That's not something anybody can object to.

> because the IE specific stuff they didn't implement was never part of the open web standards, but rather stuff Microsoft unilaterally chose to add.

Standards aren't holy books. It's actually more important to support real customer use cases than to follow standards.

But you know this. If standards are more important that real use cases, then the fact that XSLT has been removed from the html5 standard is enough justification to remove it from Chrome.

Re: Removing XSLT for a more secure browser

#256

Post by beej71 »

I'd never written any XSL before last week when I got the crazy idea of putting my resume in XML format and using stylesheets to produce both resume and CV forms, redacted and not, with references or not. And when I had it working in HTML, I started on the Typst stylesheet. xsltproc, being so old, basically renders the results instantly. And Typst, being so new, does as well.

Re: Removing XSLT for a more secure browser

#257

Post by shadowgovt »

cxr wrote: post #252
shadowgovt wrote: post #247

Earlier quoted context omitted.

Mozilla's own site expounds on "Don't Break the Web" as "Web browser vendors should be able to implement new web technologies without causing a difference in rendering or functionality that would cause their users to think a website is broken and try another browser as a result." There is no meaningful risk of that here. The percentage of web users who are trying to understand content via XSLT'd RSS is nearly zero, a…

> Mozilla's own site expounds on "Don't Break the Web" as I'm a former Mozillian. I don't give a shit how it has been retconned by whomever happened to be writing copy that day, if indeed they have—it isn't even worth bothering to check. "Don't break the Web" means exactly what it sounds like it means. Anything else is a lie. > If the machine is so complex that nobody wants to maintain it, it will go unmaintained The…

Sounds like you're volunteering to maintain the XSLT support in Firefox. That's great! That means when Chrome tries to decommission it, users who rely upon it will flock to Firefox instead because it's the only browser that works right with the websites they use.

Firefox ascendancy is overdue. Best of luck!

Re: Removing XSLT for a more secure browser

#258

Post by throwaway290 »

shadowgovt wrote: post #224
jeffbee wrote: post #91

Earlier quoted context omitted.

Man, reaching way back in history here, but this reminds me of why I stopped contributing to Mozilla decades ago. My contribution was the link toolbar, that was supposed to give a UI representation of the canonical link elements like next and prev and whatnot. At the last minute before a major release some jerkhole of a product manager at AOL cut my feature from the release. It's incredible the way such pretty bureau…

Good user-facing software tends to have a coherent vision, and that involves getting features cut that people put a lot of time and effort into; even though those features have value, it's possible they don't have value in the product under development. I don't really have enough context to say whether that was the case here. Mostly I'm raising the comment to note that this is an issue in commercial software too, but…

It's a browser. its job is render HTML

if a fix renders HTML better and more complete it should be done. it is always possible to make it configurable or change it later.

instead mozilla is pushing anti-web llm integrations.

Re: Removing XSLT for a more secure browser

#259

Post by bawolff »

jeroenhd wrote: post #253
bawolff wrote: post #75

Earlier quoted context omitted.

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…

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…

> 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.

Re: Removing XSLT for a more secure browser

#260

Post by JimDabell »

righthand wrote: post #211
JimDabell wrote: post #68

Earlier quoted context omitted.

> They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons. Mozilla: > Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support. — https://github.com/moz…

So you’re choosing to help them spin the lie by cherry picking comments. The Mozilla comment itself ends with: > If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance. > If it turns out not to be possible to remove the feature, we’d like to replace our current implementation. The mai…

If somebody says “our position is A but if that’s not possible we should do B”, it means they prefer A. It doesn’t mean they prefer B, and telling people that they prefer B when you know otherwise is dishonest.
Post reply on HN