Hacker News Reader

Comment by lunar_mycroft | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com