7 ms·

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more inter

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

xmcp123 11mo ago
It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”. Having flashbacks of “”
- granzymes 11mo ago
  The standards body is deprecating XSLT with support from Mozilla and Safari (Mozilla first proposed the removal). Not sure how you got from that to “Google is ignoring standards”.
  - andrewl-hn 11mo ago
    Probably if Mozilla didn't push for it initially XSLT would stay around for another decade or longer. Their board syphons the little money that is left out of their "foundation + corporation" combo, and they keep cutting people from Firefox dev team every year. Of course they don't want to maintain pieces of web standards if it means extra million for their board members.
    - echelon 11mo ago
      Mozilla's board are basically Google yes-people. I'm convinced Mozilla is purposefully engineered to be rudderless: C-suite draw down huge salaries, approve dumb, mission-orthgonal objectives, in order to keep Mozilla itself impotent in ever threatening Google. Mozilla is Google's antitrust litigation sponge. But it's also kept dumb and obedient. Google would never want Mozilla to actually be a threat. If Mozilla had ever wanted a healthy side business, it wasn't in Pocket, XR/VR, or AI. It would have been in building a DevEx platform around MDN and Rust. It would have synergized with their core web mission. Those people have since been let go.
      - glenstein 11mo ago
        Can you say more about the teams let go who worked on MDN and Rust? Wondering if I can read anything on it to stay up to speed.
        jacquesm 11mo ago
        https://news.ycombinator.com/item?id=24143819 https://news.ycombinator.com/item?id=24143819
      - akerl_ 11mo ago
        So the idea is that some group has been perpetuating a decade or so's worth of ongoing conspiracy to ensure that Mozilla continues to exist but makes decisions that "keep Mozilla itself impotent"? That seems to fail occam's razor pretty hard, given the competing hypotheses for each of their decisions include "Mozilla staff think they're doing a smart thing but they're wrong" and "Mozilla staff are doing a smart thing, it's just not what you would have done".
        cxr 11mo ago
        You're not wrong. And where philosophical razors are concerned, the most apt characterization of the source of Mozilla's decay is the one that Hanlon gave us.
      - cxr 11mo ago
        > If Mozilla had ever wanted a healthy side business, it wasn't in Pocket, XR/VR, or AI. It would have been in building a DevEx platform around MDN and Rust[…] Those people have since been let go. The first sentence isn't wrong, but the last sentence is confused in the same way that people who assume that Wikimedia employees have been largely responsible for the content on Wikipedia are confused about how stuff actually makes it into Wikipedia. In reality, WMF's biggest contribution is providing infrastructure costs and paying engineers to develop the Mediawiki platform that Wikipedia uses. Likewise, a bunch of the people who built up MDN weren't and never could be "let go", because they were never employed by Mozilla to work on MDN to begin with. (There's another problem, too, which is that addition to selling short a lot of people who are responsible for making MDN as useful as it is but never got paid for it, it presupposes that those who were being paid to work on MDN shouldn't have been let go.)
  - echelon 11mo ago
    Then standards body is Google and a bunch of companies consuming Google engine code.
    - dewey 11mo ago
      I guess you mean except Mozilla and Safari...which are the two other competing browser engines? It's not like a it's a room full of Chromium based browsers.
      - Forgeties79 11mo ago
        Safari yes Mozilla…are they actually competing? Like really and truly.
        bigyabai 11mo ago
        Mozilla has proven they can exist in a free market; really and truly, they do compete. Safari is what I'm concerned about. Without Apple's monopoly control, Safari is guaranteed to be a dead engine. WebKit isn't well-enough supported on Linux and Windows to compete against Blink and Gecko, which suggests that Safari is the most expendable engine of the three.
        meindnoch 11mo ago
        >Mozilla has proven they can exist in a free market; really and truly, they do compete. This gave me a superb belly laugh.
        oblio 11mo ago
        Mozilla used to compete well but that ended... at least 10 years ago?
        noosphr 11mo ago
        If your main competitor is giving you 90% of your revenue they aren't a competitor.
  - _heimdall 11mo ago
    There's a lot of history behind WhatWG that revolves around XML. WhatWG is focused on maintaining specs that browsers intend to implement and maintain. When Chrome, Firefox, and Safari agree to remove XSLT that effectively decides for WhatWG's removal of the spec. I wouldn't put too much weight behind who originally proposed the removal. It's a pretty small world when it comes to web specifications, the discussions likely started between vendors before one decided to propose it.
    - NewsaHackO 11mo ago
      The issue is you can’t say to put little weight who originally proposed the removal if the other poster is putting all the weight on Google, who didn’t even initially propose it
      - _heimdall 11mo ago
        I wouldn't put weight on the initial proposer either way. As best I've been able to keep up with the topic, google has been the party leading the charge arguing for the removal. I thought they were also the first to announce their decision, though maybe my timing is off there.
        akerl_ 11mo ago
        It doesn't seem like much of a charge to be led. The decision appears to have been pretty unanimous.
        _heimdall 11mo ago
        By browser vendors, you mean? Yes it seems like they were in agreement and many here seem to think that was largely driven by google though that's speculation. Users and web developers seemed much less on board though[1][2], enough that Google referenced that in their announcement. [1] https://github.com/whatwg/html/issues/11578 https://github.com/whatwg/html/issues/11578 [2] https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523
  - mtillman 11mo ago
    I think the person you’re replying to was referring to the partial support of XML instead of the xslt part.
  - lenkite 11mo ago
    > The standards body is deprecating XSLT The "CORPO CARTEL body" is deprecating XSLT. WhatWG is a not really a standards body like the W3C.
- Aurornis 11mo ago
  I don’t get the comparison. The XSLT deprecation has support beyond Google.
  - amarant 11mo ago
    It's just ill-informed ideological thinking. People see Google doing anything and automatically assume it's a bad thing and that it's only happening because Google are evil. HN has historically been relatively free of such dogma, but it seems times are changing, even here
    - pmontra 11mo ago
      Maybe free of the "evil Google" dogma but not free from dogma. The few who dared to express one tenth of the disapproval what we usually express about Apple nowadays were downvoted to transparent ink in a matter of minutes. Microsoft had its honeymoon period with HN after their pro open source campaign, WSL, VSCode etc. People who prudently remembered the Microsoft of the 90s and the 2000s did get their fair share of downvotes. Then Windows 11 happened. Surprise. Actually I thought that there has been a consensus about Google being evil for at least ten years but I might me wrong.
      - amarant 11mo ago
        "relatively" is meant to be doing a lot of work in my previous comment. Allow me to clarify: Obviously some amount was always there, but it used to be so much less than it is now, and, more importantly, the difference between HN and other social media, such as Reddit, used to be bigger, in terms of amount of dogma. HN still has less dogma than Reddit, but it's closer than it used to be in my estimation. Reddit is still getting more dogma each day, but HN is slowly catching up. I don't know where to turn to for online discourse that is at least mostly free from dogma these days. This used to be it.
      - deleted 11mo ago
        [deleted]
    - hn_throwaway_99 11mo ago
- otabdeveloper4 11mo ago
  So-called "standards" on the Google (c) Internet (c) network are but a formality.
- waitwot 11mo ago
  Interesting to watch technologists complain rather than engineer alternatives, ignore political activism.
svieira 11mo ago
> Removing XSLT from browsers was long overdue > Google is willing to remove standards-compliant XML support as well. > They're the same picture. To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well, it's dashed inconvenient to maintain a WASM layer for a dependency that is not safe to vendor any more as a C dependency" is not the kind of servant-oriented mentality that made the web great, not just as a platform to build on, but as a platform to emulate.
- akerl_ 11mo ago
  Can you cite where this "servant-oriented" mentality is from? I don't recall a part of the web where browser developers were viewed as not having agency about what code they ship in their software.
  - etchalon 11mo ago
    I cannot imagine a time when browsers were "servant-oriented". Every browser I can think of was/is subservient to some big-big-company's big-big-strategy.
    - akerl_ 11mo ago
      There have been plenty of browsers that were not part of a big company, either for part or all of their history. They don't tend to have massive market share, in part because browsers are amazingly complex and when they break, users get pissed because their browsing is affected. Even the browsers created by individuals or small groups don't have, as far as I've ever seen, a "servant-oriented mindset": like all software projects, they are ultimately developed and supported at the discretion of their developer(s). This is how you get interesting quirks like Opera including torrent support natively, or Brave bundling its own advertising/cryptocurrency thing.
      - etchalon 11mo ago
jillesvangurp 11mo ago
> This is a lot more concerning. I'm not so sure that's problematic. Probably browser just aren't a great platform for doing a lot of XML processing at this point. Preserving the half implemented frozen state of the early 2000s really doesn't really serve anyone except those maintaining legacy applications from that era. I can see why they are pulling out complex C++ code related to all this. It's the natural conclusion of XHTML being sidelined in favor of HTML 5 about 15-20 years ago. The whole web service bubble, bloated namespace processing, and all the other complexity that came with that just has a lot of gnarly libraries associated with it. The world kind of has moved on since then. From a security point of view it's probably a good idea to reduce the attack surface a bit by moving to a Rust based implementation. What use cases remain for XML parsing in a browser if XSLT support is removed? I guess some parsing from javascript. In which case you could argue that the usual solution in the JS world of using polyfills and e.g. wasm libraries might provide a valid/good enough alternative or migration path.
- pjmlp 11mo ago
  This is C code, https://gitlab.gnome.org/GNOME/libxslt https://gitlab.gnome.org/GNOME/libxslt
- microtherion 11mo ago
  SVG is XML based.
- fithisux 11mo ago
  They don't reduce complexity. They translate C++ (static complexity) to JS (dynamic complexity). Also it is not complexity if XSLT lives in a third-party library with a well defined interface. Thei problem is control. They gain control in 2 ways. They will get more involved in xml code base and the bad actors run in the JS sandbox. That is why we have standards though. To relinquish control through interoperability.
zetafunction 11mo ago
https://issues.chromium.org/issues/451401343 https://issues.chromium.org/issues/451401343 tracks work needed in the upstream xml-rs repository, so it seems like the team is working on addressing issues that would affect standards compliance. Disclaimer: I work on Chrome and have occasionally dabbled in libxml2/libxslt in the past, but I'm not directly involved in any of the current work.
- Ygg2 11mo ago
  Wait. They are going along with a XML parser that supports DOCTYPES? I get XSLT is ancient and full of exploits, but so is DOCTYPE. Literally poster boy for billion laughs attack (among other vectors).
  - mananaysiempre 11mo ago
    You don't need DOCTYPE for that, you can put an ENTITY declaration straight in your source file ("internal subset") and the XML spec it needs to be processed. (I seem to recall someone saying that Adobe tools are fond of putting those in their exported SVG files.)
  - fabrice_d 11mo ago
    The billion laughs attack has well known solutions (basically, don't recurse too deep). It's not a reason to not implement DOCTYPE support.
    - Ygg2 11mo ago
      > The billion laughs attack has well known solutions (basically, don't recurse too deep) You can then recurse wide. In theory it's best to allow only X placeables of up to Y size. The point is, Doctype/External entities do a similar thing to XSLT/XSD (replacing elements with other elements), but in a positively ancient way.
  - Mikhail_Edoshin 11mo ago
    The billion laughs bug was fixed in libxml2 in 2008. (As far as I understand in .Net this bug was fixed in 2014 with .Net 4.5.2. In 2019 a bug similar to "billion laughs" was found in Go YAML parser although it was explicitly mentioned and forbidden by YAML specs. Among other products it affected Kubernetes.) Other vectors probably mean a single vector: external entities, where a) you process untrusted XML on server and b) allow the processor to read external entities. This is not a bug, but early versions of XML processors may lack an option to disallow access to external entities. This also has been fixed. XSLT has no exploits at all, that is no features that can be misused.
James_K 11mo ago
What's long overdue is them updating to a modern version of XSLT.
_heimdall 11mo ago
Given that you have experience working on libxslt, why do you think they should have removed the spec entirely rather than improving the current implementation or moving towards modern XSLT 3?
dietr1ch 11mo ago
> Currently, they seem to favor xml-rs which only implements a subset of XML. Which seems to be a sane decision given the XML language allows for data blow-ups[^0]. I'm not sure what specific subset of XML `xml-rs` implements, but to me it seems insane to fully implement XML because of this. [^0]: https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack
zzo38computer 11mo ago
I think it might make more sense to use WebAssembly and make them as extensions which are included by default (many other things possibly should also be made as extensions rather than built-in functions). The same can be done for picture formats, etc. This would improve security while also improving the versatility (since you can replace parts of things), if the extension mechanism would have these capabilities. (However, I also think that generally you should not require too many features, if it can be avoided, whether those features are JavaScripts, TLS, WebAssembly, CSS, and XSLT. However, they can be useful in many circumstances despite that.)
- jjkaczor 11mo ago
  Yeah, when I first heard about this a month or so ago, my thoughts were exactly this - a WebAssembly polyfil.
gnatolf 11mo ago
I was somewhat confused and irritated by the lack of a clear frontrunner crate for XML support in rust. I get that xml isn't sexy, but still.
cptskippy 11mo ago
> Currently, they seem to favor xml-rs which only implements a subset of XML. What in particular do you find objectionable about this implementation? It's only claiming to be an XML parser, it isn't claiming to validate against a DTD or Schema. The XML standard is very complex and broad, I would be surprised if anyone has implemented it in it's entirety beyond a company like Microsoft or Oracle. Even then I would question it. At the end of the day, much of XML is hard if not impossible to use or maintain. A lot of it was defined without much thought given to practicality and for most developers they will never had to deal with a lot of it's eccentricities.
fithisux 11mo ago
Why keep XSLT if the huge majority of devs use the HTML5+CSS+Javascript combo? Why pump money on a standard which will not be used? Are XML technologies better or safer? Probably. However practice sets the standards. Is it a good thing? It remains to be seen. Personally I am not satisfied with the "Web" experience. I find it unsafe, privacy disrespecting, slow and non-standards compliant.

xmcp123 11mo ago

It’s interesting to see the casual slide of Google towards almost internet explorer 5.1 style behavior, where standards can just be ignored “because market share”. Having flashbacks of “”

granzymes 11mo ago
The standards body is deprecating XSLT with support from Mozilla and Safari (Mozilla first proposed the removal). Not sure how you got from that to “Google is ignoring standards”.
- andrewl-hn 11mo ago
  Probably if Mozilla didn't push for it initially XSLT would stay around for another decade or longer. Their board syphons the little money that is left out of their "foundation + corporation" combo, and they keep cutting people from Firefox dev team every year. Of course they don't want to maintain pieces of web standards if it means extra million for their board members.
  - echelon 11mo ago
    Mozilla's board are basically Google yes-people. I'm convinced Mozilla is purposefully engineered to be rudderless: C-suite draw down huge salaries, approve dumb, mission-orthgonal objectives, in order to keep Mozilla itself impotent in ever threatening Google. Mozilla is Google's antitrust litigation sponge. But it's also kept dumb and obedient. Google would never want Mozilla to actually be a threat. If Mozilla had ever wanted a healthy side business, it wasn't in Pocket, XR/VR, or AI. It would have been in building a DevEx platform around MDN and Rust. It would have synergized with their core web mission. Those people have since been let go.
    - glenstein 11mo ago
      Can you say more about the teams let go who worked on MDN and Rust? Wondering if I can read anything on it to stay up to speed.
      - jacquesm 11mo ago
        https://news.ycombinator.com/item?id=24143819 https://news.ycombinator.com/item?id=24143819
    - akerl_ 11mo ago
      So the idea is that some group has been perpetuating a decade or so's worth of ongoing conspiracy to ensure that Mozilla continues to exist but makes decisions that "keep Mozilla itself impotent"? That seems to fail occam's razor pretty hard, given the competing hypotheses for each of their decisions include "Mozilla staff think they're doing a smart thing but they're wrong" and "Mozilla staff are doing a smart thing, it's just not what you would have done".
      - cxr 11mo ago
        You're not wrong. And where philosophical razors are concerned, the most apt characterization of the source of Mozilla's decay is the one that Hanlon gave us.
    - cxr 11mo ago
      > If Mozilla had ever wanted a healthy side business, it wasn't in Pocket, XR/VR, or AI. It would have been in building a DevEx platform around MDN and Rust[…] Those people have since been let go. The first sentence isn't wrong, but the last sentence is confused in the same way that people who assume that Wikimedia employees have been largely responsible for the content on Wikipedia are confused about how stuff actually makes it into Wikipedia. In reality, WMF's biggest contribution is providing infrastructure costs and paying engineers to develop the Mediawiki platform that Wikipedia uses. Likewise, a bunch of the people who built up MDN weren't and never could be "let go", because they were never employed by Mozilla to work on MDN to begin with. (There's another problem, too, which is that addition to selling short a lot of people who are responsible for making MDN as useful as it is but never got paid for it, it presupposes that those who were being paid to work on MDN shouldn't have been let go.)
- echelon 11mo ago
  Then standards body is Google and a bunch of companies consuming Google engine code.
  - dewey 11mo ago
    I guess you mean except Mozilla and Safari...which are the two other competing browser engines? It's not like a it's a room full of Chromium based browsers.
    - Forgeties79 11mo ago
      Safari yes Mozilla…are they actually competing? Like really and truly.
      - bigyabai 11mo ago
        Mozilla has proven they can exist in a free market; really and truly, they do compete. Safari is what I'm concerned about. Without Apple's monopoly control, Safari is guaranteed to be a dead engine. WebKit isn't well-enough supported on Linux and Windows to compete against Blink and Gecko, which suggests that Safari is the most expendable engine of the three.
        meindnoch 11mo ago
        >Mozilla has proven they can exist in a free market; really and truly, they do compete. This gave me a superb belly laugh.
        oblio 11mo ago
        Mozilla used to compete well but that ended... at least 10 years ago?
        noosphr 11mo ago
        If your main competitor is giving you 90% of your revenue they aren't a competitor.
- _heimdall 11mo ago
  There's a lot of history behind WhatWG that revolves around XML. WhatWG is focused on maintaining specs that browsers intend to implement and maintain. When Chrome, Firefox, and Safari agree to remove XSLT that effectively decides for WhatWG's removal of the spec. I wouldn't put too much weight behind who originally proposed the removal. It's a pretty small world when it comes to web specifications, the discussions likely started between vendors before one decided to propose it.
  - NewsaHackO 11mo ago
    The issue is you can’t say to put little weight who originally proposed the removal if the other poster is putting all the weight on Google, who didn’t even initially propose it
    - _heimdall 11mo ago
      I wouldn't put weight on the initial proposer either way. As best I've been able to keep up with the topic, google has been the party leading the charge arguing for the removal. I thought they were also the first to announce their decision, though maybe my timing is off there.
      - akerl_ 11mo ago
        It doesn't seem like much of a charge to be led. The decision appears to have been pretty unanimous.
        _heimdall 11mo ago
        By browser vendors, you mean? Yes it seems like they were in agreement and many here seem to think that was largely driven by google though that's speculation. Users and web developers seemed much less on board though[1][2], enough that Google referenced that in their announcement. [1] https://github.com/whatwg/html/issues/11578 https://github.com/whatwg/html/issues/11578 [2] https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11523
- mtillman 11mo ago
  I think the person you’re replying to was referring to the partial support of XML instead of the xslt part.
- lenkite 11mo ago
  > The standards body is deprecating XSLT The "CORPO CARTEL body" is deprecating XSLT. WhatWG is a not really a standards body like the W3C.
Aurornis 11mo ago
I don’t get the comparison. The XSLT deprecation has support beyond Google.
- amarant 11mo ago
  It's just ill-informed ideological thinking. People see Google doing anything and automatically assume it's a bad thing and that it's only happening because Google are evil. HN has historically been relatively free of such dogma, but it seems times are changing, even here
  - pmontra 11mo ago
    Maybe free of the "evil Google" dogma but not free from dogma. The few who dared to express one tenth of the disapproval what we usually express about Apple nowadays were downvoted to transparent ink in a matter of minutes. Microsoft had its honeymoon period with HN after their pro open source campaign, WSL, VSCode etc. People who prudently remembered the Microsoft of the 90s and the 2000s did get their fair share of downvotes. Then Windows 11 happened. Surprise. Actually I thought that there has been a consensus about Google being evil for at least ten years but I might me wrong.
    - amarant 11mo ago
      "relatively" is meant to be doing a lot of work in my previous comment. Allow me to clarify: Obviously some amount was always there, but it used to be so much less than it is now, and, more importantly, the difference between HN and other social media, such as Reddit, used to be bigger, in terms of amount of dogma. HN still has less dogma than Reddit, but it's closer than it used to be in my estimation. Reddit is still getting more dogma each day, but HN is slowly catching up. I don't know where to turn to for online discourse that is at least mostly free from dogma these days. This used to be it.
    - deleted 11mo ago
      [deleted]
  - hn_throwaway_99 11mo ago
otabdeveloper4 11mo ago
So-called "standards" on the Google (c) Internet (c) network are but a formality.
waitwot 11mo ago
Interesting to watch technologists complain rather than engineer alternatives, ignore political activism.

svieira 11mo ago

> Removing XSLT from browsers was long overdue > Google is willing to remove standards-compliant XML support as well. > They're the same picture. To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well, it's dashed inconvenient to maintain a WASM layer for a dependency that is not safe to vendor any more as a C dependency" is not the kind of servant-oriented mentality that made the web great, not just as a platform to build on, but as a platform to emulate.

akerl_ 11mo ago
Can you cite where this "servant-oriented" mentality is from? I don't recall a part of the web where browser developers were viewed as not having agency about what code they ship in their software.
- etchalon 11mo ago
  I cannot imagine a time when browsers were "servant-oriented". Every browser I can think of was/is subservient to some big-big-company's big-big-strategy.
  - akerl_ 11mo ago
    There have been plenty of browsers that were not part of a big company, either for part or all of their history. They don't tend to have massive market share, in part because browsers are amazingly complex and when they break, users get pissed because their browsing is affected. Even the browsers created by individuals or small groups don't have, as far as I've ever seen, a "servant-oriented mindset": like all software projects, they are ultimately developed and supported at the discretion of their developer(s). This is how you get interesting quirks like Opera including torrent support natively, or Brave bundling its own advertising/cryptocurrency thing.
    - etchalon 11mo ago

jillesvangurp 11mo ago

> This is a lot more concerning. I'm not so sure that's problematic. Probably browser just aren't a great platform for doing a lot of XML processing at this point. Preserving the half implemented frozen state of the early 2000s really doesn't really serve anyone except those maintaining legacy applications from that era. I can see why they are pulling out complex C++ code related to all this. It's the natural conclusion of XHTML being sidelined in favor of HTML 5 about 15-20 years ago. The whole web service bubble, bloated namespace processing, and all the other complexity that came with that just has a lot of gnarly libraries associated with it. The world kind of has moved on since then. From a security point of view it's probably a good idea to reduce the attack surface a bit by moving to a Rust based implementation. What use cases remain for XML parsing in a browser if XSLT support is removed? I guess some parsing from javascript. In which case you could argue that the usual solution in the JS world of using polyfills and e.g. wasm libraries might provide a valid/good enough alternative or migration path.

pjmlp 11mo ago
This is C code, https://gitlab.gnome.org/GNOME/libxslt https://gitlab.gnome.org/GNOME/libxslt
microtherion 11mo ago
SVG is XML based.
fithisux 11mo ago
They don't reduce complexity. They translate C++ (static complexity) to JS (dynamic complexity). Also it is not complexity if XSLT lives in a third-party library with a well defined interface. Thei problem is control. They gain control in 2 ways. They will get more involved in xml code base and the bad actors run in the JS sandbox. That is why we have standards though. To relinquish control through interoperability.

zetafunction 11mo ago

https://issues.chromium.org/issues/451401343 https://issues.chromium.org/issues/451401343 tracks work needed in the upstream xml-rs repository, so it seems like the team is working on addressing issues that would affect standards compliance. Disclaimer: I work on Chrome and have occasionally dabbled in libxml2/libxslt in the past, but I'm not directly involved in any of the current work.

Ygg2 11mo ago
Wait. They are going along with a XML parser that supports DOCTYPES? I get XSLT is ancient and full of exploits, but so is DOCTYPE. Literally poster boy for billion laughs attack (among other vectors).
- mananaysiempre 11mo ago
  You don't need DOCTYPE for that, you can put an ENTITY declaration straight in your source file ("internal subset") and the XML spec it needs to be processed. (I seem to recall someone saying that Adobe tools are fond of putting those in their exported SVG files.)
- fabrice_d 11mo ago
  The billion laughs attack has well known solutions (basically, don't recurse too deep). It's not a reason to not implement DOCTYPE support.
  - Ygg2 11mo ago
    > The billion laughs attack has well known solutions (basically, don't recurse too deep) You can then recurse wide. In theory it's best to allow only X placeables of up to Y size. The point is, Doctype/External entities do a similar thing to XSLT/XSD (replacing elements with other elements), but in a positively ancient way.
- Mikhail_Edoshin 11mo ago
  The billion laughs bug was fixed in libxml2 in 2008. (As far as I understand in .Net this bug was fixed in 2014 with .Net 4.5.2. In 2019 a bug similar to "billion laughs" was found in Go YAML parser although it was explicitly mentioned and forbidden by YAML specs. Among other products it affected Kubernetes.) Other vectors probably mean a single vector: external entities, where a) you process untrusted XML on server and b) allow the processor to read external entities. This is not a bug, but early versions of XML processors may lack an option to disallow access to external entities. This also has been fixed. XSLT has no exploits at all, that is no features that can be misused.

James_K 11mo ago

What's long overdue is them updating to a modern version of XSLT.

_heimdall 11mo ago

Given that you have experience working on libxslt, why do you think they should have removed the spec entirely rather than improving the current implementation or moving towards modern XSLT 3?

dietr1ch 11mo ago

> Currently, they seem to favor xml-rs which only implements a subset of XML. Which seems to be a sane decision given the XML language allows for data blow-ups[^0]. I'm not sure what specific subset of XML `xml-rs` implements, but to me it seems insane to fully implement XML because of this. [^0]: https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack

zzo38computer 11mo ago

I think it might make more sense to use WebAssembly and make them as extensions which are included by default (many other things possibly should also be made as extensions rather than built-in functions). The same can be done for picture formats, etc. This would improve security while also improving the versatility (since you can replace parts of things), if the extension mechanism would have these capabilities. (However, I also think that generally you should not require too many features, if it can be avoided, whether those features are JavaScripts, TLS, WebAssembly, CSS, and XSLT. However, they can be useful in many circumstances despite that.)

jjkaczor 11mo ago
Yeah, when I first heard about this a month or so ago, my thoughts were exactly this - a WebAssembly polyfil.

gnatolf 11mo ago

I was somewhat confused and irritated by the lack of a clear frontrunner crate for XML support in rust. I get that xml isn't sexy, but still.

cptskippy 11mo ago

> Currently, they seem to favor xml-rs which only implements a subset of XML. What in particular do you find objectionable about this implementation? It's only claiming to be an XML parser, it isn't claiming to validate against a DTD or Schema. The XML standard is very complex and broad, I would be surprised if anyone has implemented it in it's entirety beyond a company like Microsoft or Oracle. Even then I would question it. At the end of the day, much of XML is hard if not impossible to use or maintain. A lot of it was defined without much thought given to practicality and for most developers they will never had to deal with a lot of it's eccentricities.

fithisux 11mo ago

Why keep XSLT if the huge majority of devs use the HTML5+CSS+Javascript combo? Why pump money on a standard which will not be used? Are XML technologies better or safer? Probably. However practice sets the standards. Is it a good thing? It remains to be seen. Personally I am not satisfied with the "Web" experience. I find it unsafe, privacy disrespecting, slow and non-standards compliant.