4 ms·

Website is overly dramatic. Google doesn't hate XSLT, it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is us

Website is overly dramatic. Google doesn't hate XSLT, it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. If the author wants to raise money to pay a developer willing to maintain libxslt, Google might revise the decision.

testdelacc1 1y ago
I think they’re being dramatic for laughs.
troupo 1y ago
> it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. As for money: Remind me what was Google's profit last year? As for usage: XSLT is used on about 10x more sites [1] than Chrome-only non-standards like USB, WebTransport and others that Google has no trouble shoving into the browser [1] Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity/3472 https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity...
- bawolff 1y ago
  > Remind me what was Google's profit last year? Last i checked, google isn't a charity.
  - mschuster91 1y ago
    Their products are built on open source. Android and Chrome come to my mind, but also their core infrastructure, it's all Linux and other FOSS under the hood. Besides, xkcd #2347 [1] is talking about precisely that situation - there is a shitload of very small FOSS libraries that underpin everything and yet, funding from the big dogs for whom even ten fulltime developer salaries would be a sneeze has historically lacked hard. [1] https://xkcd.com/2347/ https://xkcd.com/2347/
    - maple3142 1y ago
      To be honest, there are two ways to solve the problem of xkcd 2347, either putting efforts into the very small library or just stop depending on it. Both solutions are fine to me and Google apparent just choose the latter one here.
      - bawolff 1y ago
        If not depending on a library is an option, then you dont really have an xkcd 2347 problem. The entire point of that comic is that some undermaintained dependencies are critical, without reasonable alternatives.
      - 1718627440 1y ago
        Except it's not Google whose "products" stop working by removing that dependency.
    - bawolff 1y ago
      The thing is, xslt isn't underpinning much of anything, that is why google is removing it instead of fixing it. Google does contribute to software that it uses. When i say google is not a charity, i mean why would they continue to use a library that is not useful to them, just so they can have an excuse to contribute to it? It makes very little sense.
      - troupo 1y ago
        > The thing is, xslt isn't underpinning much of anything Neither do huge complicated standards that Chrome pushed in recent years. > that is why google is removing it instead of fixing it. And yet Google has no issues supporting, deploying and fixing features that see 10x less usage. Also, see this comment: https://news.ycombinator.com/item?id=45874740 https://news.ycombinator.com/item?id=45874740 > i mean why would they continue to use a library that is not useful to them, just so they can have an excuse to contribute to it? It makes very little sense. They took upon themselves the role of benevolent stewards of the web. According to their own principles they should exercise extreme care when adding or removing features to the web. However, since they dominate the browser market, and have completely subsumed all web-related committees, they have turned into arrogant uncaring dictators.
  - basscomm 1y ago
    > Last i checked, google isn't a charity. Last I checked, Google isn't supposed to be able to unilaterally decide how the World Wide Web is supposed to work
- vladms 1y ago
  For me the usage argument sounds like an argument to kill the other standards rather than to keep this one. Browsers should try things. But if after many years there is no adoption they should also retire them. This would be no different if the organization is charity or not.
  - troupo 1y ago
    > For me the usage argument sounds like an argument to kill the other standards rather than to keep this one. Google themselves have a document on why killing anything in the web platform is problematic: e.g. Chrome stats severely under-report corporate usage. See "Blink principles of web compatibility" https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?pli=1&tab=t.0 https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... It has great examples for when removal didn't break things, and when it did break things etc. I don't know if anyone pays attention to this document anymore. Someone from Chrome linked to this document when they wanted to remove alert/prompt, and it completely contradicted their narrative.
verytrivial 1y ago
Full of security issues is similarly overly dramatic, Haha. Fil-c appears to already compile libxml2[1] so I wonder how far off libxslt would be? [1] https://github.com/pizlonator/fil-c/tree/deluge/projects/libxml2-2.14.4 https://github.com/pizlonator/fil-c/tree/deluge/projects/lib...
- JimDabell 1y ago
  > Full of security issues is similarly overly dramatic It doesn’t seem dramatic at all: > Finding and exploiting 20-year-old bugs in web browsers > Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs. — https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html — https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao > libxslt -- unmaintained, with multiple unfixed vulnerabilities — https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99047d0a6bcc.html https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99...
themafia 1y ago
> no one wants to maintain libxslt For $0? Probably not. For $40m/year, I bet you could create an entire company that just maintains and supports all these "abandoned" projects.
- ExoticPearTree 1y ago
  > or $0? Probably not. For $40m/year, I bet you could create an entire company No sane commercial entity will dump even a cent into supporting an unused technology. You have better luck pitching this idea to your senator to set up an agency for dead stuff - it will create tens or hundreds of jobs. And what's $40mm in the big picture?
  - themafia 1y ago
    > your senator Funny you should mention that. US Title Code uses XSLT. https://simonwillison.net/2025/Aug/19/xslt/ https://simonwillison.net/2025/Aug/19/xslt/
    - ExoticPearTree 1y ago
      I know it is there. I am more curious as to why no one updated all that to modern browser technology.
      - phantasmish 1y ago
        Until these recent rumblings out of Google, it was modern browser technology.
        ExoticPearTree 1y ago
        > Until these recent rumblings out of Google, it was modern browser technology. It is supported technology. That's all it is. And it will be no more. No one is stopping you from rendering your XML to HTML server side using XSLT.
      - 1y ago
cubefox 1y ago
Why not switch the browser to use a JavaScript implementation internally instead of the old C++ implementation?
basscomm 1y ago
> Google doesn't hate XSLT, it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. If the author wants to raise money to pay a developer willing to maintain libxslt, Google might revise the decision. Counterpoint: google hates XML and XSLT. I've been working on a hobby site using XML and XSLT for the last five years. Google refused to crawl and index anything on it. I have a working sitemap, a permissive robots.txt, a googlebot html file proving that I'm the owner of the site, and I've jumped through every hoop I can find, and they still refused to crawl or index anything except a snippet of the main index.xml page and they won't crawl any links on that. I switched everything over to a static site generator a few weeks ago, and Google immediately crawled the whole thing and started showing snippets of the entire site in less than a day. My guess is that their usage stats are skewed because they've designed their entire search apparatus to ignore it.
yxhuvud 1y ago
Honestly, let it die. Perhaps the standard will die or perhaps someone will make an open source solution that actually support XSLT 2 and 3.

testdelacc1 1y ago

I think they’re being dramatic for laughs.

troupo 1y ago

> it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. As for money: Remind me what was Google's profit last year? As for usage: XSLT is used on about 10x more sites [1] than Chrome-only non-standards like USB, WebTransport and others that Google has no trouble shoving into the browser [1] Compare XSLT https://chromestatus.com/metrics/feature/timeline/popularity/79 https://chromestatus.com/metrics/feature/timeline/popularity... with USB https://chromestatus.com/metrics/feature/timeline/popularity/1521 https://chromestatus.com/metrics/feature/timeline/popularity... or WebTransport: https://chromestatus.com/metrics/feature/timeline/popularity/3472 https://chromestatus.com/metrics/feature/timeline/popularity... or even MIDI (also supported by Firerox) https://chromestatus.com/metrics/feature/timeline/popularity/2029 https://chromestatus.com/metrics/feature/timeline/popularity...

bawolff 1y ago
> Remind me what was Google's profit last year? Last i checked, google isn't a charity.
- mschuster91 1y ago
  Their products are built on open source. Android and Chrome come to my mind, but also their core infrastructure, it's all Linux and other FOSS under the hood. Besides, xkcd #2347 [1] is talking about precisely that situation - there is a shitload of very small FOSS libraries that underpin everything and yet, funding from the big dogs for whom even ten fulltime developer salaries would be a sneeze has historically lacked hard. [1] https://xkcd.com/2347/ https://xkcd.com/2347/
  - maple3142 1y ago
    To be honest, there are two ways to solve the problem of xkcd 2347, either putting efforts into the very small library or just stop depending on it. Both solutions are fine to me and Google apparent just choose the latter one here.
    - bawolff 1y ago
      If not depending on a library is an option, then you dont really have an xkcd 2347 problem. The entire point of that comic is that some undermaintained dependencies are critical, without reasonable alternatives.
    - 1718627440 1y ago
      Except it's not Google whose "products" stop working by removing that dependency.
  - bawolff 1y ago
    The thing is, xslt isn't underpinning much of anything, that is why google is removing it instead of fixing it. Google does contribute to software that it uses. When i say google is not a charity, i mean why would they continue to use a library that is not useful to them, just so they can have an excuse to contribute to it? It makes very little sense.
    - troupo 1y ago
      > The thing is, xslt isn't underpinning much of anything Neither do huge complicated standards that Chrome pushed in recent years. > that is why google is removing it instead of fixing it. And yet Google has no issues supporting, deploying and fixing features that see 10x less usage. Also, see this comment: https://news.ycombinator.com/item?id=45874740 https://news.ycombinator.com/item?id=45874740 > i mean why would they continue to use a library that is not useful to them, just so they can have an excuse to contribute to it? It makes very little sense. They took upon themselves the role of benevolent stewards of the web. According to their own principles they should exercise extreme care when adding or removing features to the web. However, since they dominate the browser market, and have completely subsumed all web-related committees, they have turned into arrogant uncaring dictators.
- basscomm 1y ago
  > Last i checked, google isn't a charity. Last I checked, Google isn't supposed to be able to unilaterally decide how the World Wide Web is supposed to work
vladms 1y ago
For me the usage argument sounds like an argument to kill the other standards rather than to keep this one. Browsers should try things. But if after many years there is no adoption they should also retire them. This would be no different if the organization is charity or not.
- troupo 1y ago
  > For me the usage argument sounds like an argument to kill the other standards rather than to keep this one. Google themselves have a document on why killing anything in the web platform is problematic: e.g. Chrome stats severely under-report corporate usage. See "Blink principles of web compatibility" https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?pli=1&tab=t.0 https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... It has great examples for when removal didn't break things, and when it did break things etc. I don't know if anyone pays attention to this document anymore. Someone from Chrome linked to this document when they wanted to remove alert/prompt, and it completely contradicted their narrative.

verytrivial 1y ago

Full of security issues is similarly overly dramatic, Haha. Fil-c appears to already compile libxml2[1] so I wonder how far off libxslt would be? [1] https://github.com/pizlonator/fil-c/tree/deluge/projects/libxml2-2.14.4 https://github.com/pizlonator/fil-c/tree/deluge/projects/lib...

JimDabell 1y ago
> Full of security issues is similarly overly dramatic It doesn’t seem dramatic at all: > Finding and exploiting 20-year-old bugs in web browsers > Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs. — https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html — https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao > libxslt -- unmaintained, with multiple unfixed vulnerabilities — https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99047d0a6bcc.html https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99...

themafia 1y ago

> no one wants to maintain libxslt For $0? Probably not. For $40m/year, I bet you could create an entire company that just maintains and supports all these "abandoned" projects.

ExoticPearTree 1y ago
> or $0? Probably not. For $40m/year, I bet you could create an entire company No sane commercial entity will dump even a cent into supporting an unused technology. You have better luck pitching this idea to your senator to set up an agency for dead stuff - it will create tens or hundreds of jobs. And what's $40mm in the big picture?
- themafia 1y ago
  > your senator Funny you should mention that. US Title Code uses XSLT. https://simonwillison.net/2025/Aug/19/xslt/ https://simonwillison.net/2025/Aug/19/xslt/
  - ExoticPearTree 1y ago
    I know it is there. I am more curious as to why no one updated all that to modern browser technology.
    - phantasmish 1y ago
      Until these recent rumblings out of Google, it was modern browser technology.
      - ExoticPearTree 1y ago
        > Until these recent rumblings out of Google, it was modern browser technology. It is supported technology. That's all it is. And it will be no more. No one is stopping you from rendering your XML to HTML server side using XSLT.
    - 1y ago

cubefox 1y ago

Why not switch the browser to use a JavaScript implementation internally instead of the old C++ implementation?

basscomm 1y ago

> Google doesn't hate XSLT, it is simply no one wants to maintain libxslt and it is full of security issues. Given how rarely it is used, it is just not worth the time + money. If the author wants to raise money to pay a developer willing to maintain libxslt, Google might revise the decision. Counterpoint: google hates XML and XSLT. I've been working on a hobby site using XML and XSLT for the last five years. Google refused to crawl and index anything on it. I have a working sitemap, a permissive robots.txt, a googlebot html file proving that I'm the owner of the site, and I've jumped through every hoop I can find, and they still refused to crawl or index anything except a snippet of the main index.xml page and they won't crawl any links on that. I switched everything over to a static site generator a few weeks ago, and Google immediately crawled the whole thing and started showing snippets of the entire site in less than a day. My guess is that their usage stats are skewed because they've designed their entire search apparatus to ignore it.

yxhuvud 1y ago

Honestly, let it die. Perhaps the standard will die or perhaps someone will make an open source solution that actually support XSLT 2 and 3.