Look, I wouldn't want to be responsible for maintaining anything to do with XML or XSLT either. All the technical arguments outlined for removing support make sense. But can users really call it an "update" if you could view an XML/XSLT document in Internet Explorer 6 or Chrome 1 but not the newest version?
I think this sets a concerning precedent for future deprecations, where parts of the web platform are rugpulled from developers because it's convenient for the browser vendors.
> I think this sets a concerning precedent for future deprecations, where parts of the web platform are rugpulled from developers because it's convenient for the browser vendors.
The precedent was already set when they tried to remove alert/prompt. See https://dev.to/richharris/stay-alert-d and https://css-tricks.com/choice-words-about-the-upcoming-depre...
Only a large public outcry stopped them, barely.
To quote from the first link:
--- start quote ---
Meanwhile, we don't seem to be learning from the past. If alert is fair game for removal, then so is every API we add to the platform if the web's future stewards deem it harmful.
Given Chrome's near-monopoly control of the browser market, I'm genuinely concerned about what this all means for the future of the web. An ad company shouldn't have this much influence over something that belongs to all of us. I don't know how to fix the standards process so that it's more representative of the diversity of the web's stakeholders, but I'm increasingly convinced that we need to figure it out.
--- end quote ---
The security argument isn't that great. Google has been grumbling about xslt for more than a decade. If security was really their concern they could have replaced the compiled C library with an asm.js version ten years ago, much as they did for pdf rendering. They could use wasm now. They don't need to deprecate it.
> maintaining anything to do with XML or XSLT either.
These aren't horrible formats or standards. XSLT is actually somewhat elegant.
Counterpoint: XML is a horrible format.
Why? Answer this question: how can you use XML in a way that does not create horrible security vulnerabilities?
I know the answer, but it is extremely nontrivial, and highly dependent on which programming language, library, and sometimes even which library function you use. The fact that there's no easy way to use XML without creating a security footgun is reason enough to avoid it.
I myself know only two "security vulnerabilities":
1. The entity bomb. An entity that expands to another, which expands to another, and so on so that the final result is enormous. This is an issue of the implementation: if it expands the entities eagerly then the bomb will work. But it it first examines them and checks how much space they require it can safely reject the document if it exceeds some configurable limit. As far as I know this has been fixed in all XML processors.
2. An entity can resolve to a local or remote file. First, this is a feature. Imagine a large collection of bibliographic records, each in a separate file. A publication can provide its list of references as a list of entities that refer to these files using entities. (There is an RFC that uses this as an example.) And, of course, we need both local and remote entities.
But, of course, if your XML comes from an untrusted source and you read it with this feature enabled this can lead to obvious disasters. Yet it is not a vulnerability of XML. Again, as far as I know all XML processors can disable access to local or remote entities.
You can say the same thing about HTML forms (see CORS et. al.), innerHTML, rendering user-submitted data, SQL, JSON, etc. That does not mean that you remove HTML forms or SQL databases.
If you removed support for anything that has/could have security vulnerabilities you would remove everything.
Do those points not apply verbatim to HTML?
Let alone JavaScript…
That's not any different than JSON, though. Injection, insecure deserialization , etc. can all exist in that format as well.
There's plenty of reasons to criticize XML, and plenty more to criticize XSLT. But security being the one you call out feels at least moderately disingenuous. It's a criticism of the library, not the standard or the format.
There's an extremely large difference in that a JSON deserialization vulnerability is almost always a bug in the library. JSON is not an inherently insecure format.
XML is so complex that a 100% bug-free compliant library is inherently insecure, and the vulnerability is a "user is holding it wrong" siutation, they should have disabled specific XML features etc. That means XML is an inherently much more insecure format.
There's a reason there's name for vulnerabilities like XML External Entity (XXE) injection [1] and they're named after XML, and not "bug in lib/software X". JSON and most other data formats don't have that.
[1] https://portswigger.net/web-security/xxe
XML has a relatively small specification. For some time I used to "print" web pages into PDF (or XPS) and I remember that XML 1.0 specification was three times shorter than that of YAML (it was YAML 2, I think, I don't quite remember). And XML included a) serialization itself, b) simple grammar specification in the form of DTD, c) things like internal references from one element to another, d) basic support for other notations, so that you could add, say, LaTeX math notation and formally define that this element's content is in this notation. I do not think (b), (c) or (d) were part of YAML or any other similar format.
> But can users really call it an "update" if you could view an XML/XSLT document in Internet Explorer 6 or Chrome 1 but not the newest version?
Yes. Just like we don't have Flash everywhere or ActiveX. Good riddance to them and to XSLT and, fingers crossed, XML in the future.
I'm going to say this calmly and politely to you. You think this is some kind of "fun" spicy take, but considering that some rely on these technologies I find your remark to be incredibly offensive and insulting. If we were discussing this face to face you'd have a major problem right now
It would help if you would give some details about how you rely on Flash/ActiveX/XML. Is it a matter of life and death? If so, how?