Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim

The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.



Chrome and other browsers could virtually completely mitigate the security issues by shipping the polyfil they're suggesting all sites depending on XSLT deploy in the browser. By doing so, their XSLT implementation would become no less secure than their javascript implementation (and fat chance they'll remove that). The fact that they've rejected doing so is a pretty clear indication that security is just an excuse, IMO.


I wish more people would see this. They know exactly how to sandbox it, they’re telling you how to, they’re even providing and recommending a browser extension to securely restore the functionality they’re removing!

The security argument can be valid motivation for doing something, but is utterly illegitimate as a reason for removing. They want to remove it because they abandoned it many years ago, and it’s a maintenance burden. Not a security burden, they’ve shown exactly how to fix that as part of preparing to remove it!


And it's a very small maintenance burden at that. Shipping the polyfil would technically still be a dependency, but about as decoupled a dependency as you can get. It's only interaction with the rest of the code would be through public APIs that browsers have to keep stable anyway.


by definition XSLT is more secure than JavaScript.


Yes and no. It's true that if you had to pick one to support and were only considering security, it would virtually certainly be better to go with XSLT. However, browser makers basically _have_ to support javascript, so as long as XSLT has a non-zero attack surface (which it does, at least as long as it's a native implementation), including it would be less secure. That said, as I pointed out, there are obvious ways to mitigate this issue and reduce the extra attack surface to effectively zero.


"[Y]ou're welcome to fork Chromium or Firefox" is the software developer equivalent of saying "you're welcome to go fuck yourself."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: