>and there's no reason to link to a raw XML RSS or Atom document directly What's the point of having an Atom feed if I can't give people a link to it? Do you j

>and there's no reason to link to a raw XML RSS or Atom document directly What's the point of having an Atom feed if I can't give people a link to it? Do you just expect me to write “this website has an atom feed” and have only the <link> element invisibly pointing at it? That is terrible UX. And then what if I want to include a link to my feed in a message to share it with someone? >Handwaving that vulnerabilities are "highly unlikely" is dangerous security theater No it isn't. There are memory safe XSLT implementations. Not so for JavaScript. This is because XSLT is a simple language and JavaScript a complicated one. You are trying to make the case that XSLT is inherently unsafe because poor implementations of it exist, yet it is actually much safer because safe implementations exist and are easy to write. It can initiate no outgoing internet connections, cannot read from memory directly, cannot do any of the things that makes JavaScript inherently dangerous. >simply transforming RSS to HTML directly with JavaScript is a MUCH smaller and harder attack surface than the massive overkill of including an entire sandboxed general purpose Turing complete XSLT processor Firstly, you can't include JavaScript tags in RSS or Atom so my website would not conform to any web standard. Secondly, by using JavaScript, I'm demanding that my users enable a highly dangerous web feature that has been the basis for many attacks. By using XSLT, I'm giving them the option to use a much smaller interface with safer implementations available. How many CVEs have their been in JavaScript runtimes compared with XSLT? And finally, browser developers should just bundle one of these JavaScript polyfills and activate it for documents with stylesheets if they are so easy to use. Demanding that users deviate from web standards to get simple features like XML styling is ridiculous and it would clearly be little effort for them to silently append a polyfill script to documents with XSLT automatically. If that's the only way they can make it secure, that's what they should do. >Your overconfidence in XSLT's security in browsers is unjustified and unsupported by its track record and reputation, its complexity is extremely high, it's written in unsafe un-sandboxed C/C++, it gets vastly less attention and hardening and use than JavaScript, and its vulnerabilities are numerous and well documented. I have no confidence at all in browsers' implementations of XSLT because they admit they use a faulty library. I have absolute confidence that it would be little effort to replace the faulty library with a correct one, and that doing so would be miles safer than expecting users to enable JavaScript. >Of course all versions of XSLT are Turing complete, as you can easily confirm on Wikipedia Do not quote Wikipedia as a source. In this case, the provided source in the Wikipedia page claims only that version 2.0 is Turing complete, and this claim is erroneous, based on a proprietary extension of certain XSLT processors but not that used in Chrome. http://tkachenko.com/blog/archives/000275.html http://tkachenko.com/blog/archives/000275.html It is quite frankly ridiculous to me that people are bending over backwards to suggest that XSLT is somehow an inherent security risk when you can include a JavaScript fragment in pages to trigger an XSLT processor. Whatever risk is posed by XSLT is a clear subset of that posed by JavaScript for this reason alone. You will never see a complete JavaScript implementation in XSLT because it isn't possible. One language is given greatly more privileged access to the resources and capabilities of the user's computer than the other. The decision of web-browser to include faulty XSLT libraries when safe ones exist is the source of risk here, and not these same people who have been putting users at risk in a billion different ways over the years come to me and suggest that I have to remove a completely innocuous feature from my website and replace it with a more dangerous one while breaking standards compliance because they can't be bothered to switch from an unsafe implementation to a safe one.