Comment by lunar_mycroft
7 hours ago
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.