- But these sham community engagement exercises piss me off - That’s Google for you: they’ve been doing self-serving open-source for decades. - For instance: they open-sourced Android. That helped Android become the dominant platform and Google capture the cellphone market. Since then, Google has been slowly moving their stuff away from the open-source AOSP and into their proprietary stack, introduced proprietary features that are almost compulsory for a practical, working Android system like Play Protect, and are actively killing deGoogled ROMs. - There’s only one thing to keep in mind with Google: if they do something, it’s not in your interest, and they know how to play long games. Anything they do will be used against you some day. - if they do something, it’s not in your interest - lets make billboards out of this and place it everywhere - if they do something, it’s not in your interest - this is often true, but sometimes (like in this case) they are actually doing things that are in (almost) everyone’s interest: making browsers more secure 🙄 - (see my other comment in this thread for details) 
 
- if they do something, it’s not in your interest - this is often true, but sometimes (like in this case) they are actually doing things that are in (almost) everyone’s interest: making browsers more secure 🙄 - (see my other comment in this thread for details) 
 
- fuck google generally, but in this case that mastodon post’s characterization that “Respondents overwhelmingly reject the suggestion” is not accurate - lots of people in that thread are in favor of removing it and those who aren’t aren’t making a strong case to keep it. - imo client-side XSLT never needed to be implemented; afaict its primary use is styling RSS feeds and I doubt many people ever actually read RSS feeds styled that way even if millions of feeds are/were. - some important context here- https://gitlab.gnome.org/GNOME/libxslt/-/issues/127 CVE-2024-55549 (“Being an unpaid volunteer, I also don’t really care about external deadlines. I’ll just make the issue and the fix public and people can patch libxslt themselves. I also realized that I simply do not have enough free time and energy to continue maintaining libxslt and will step down as maintainer.”)
- https://gitlab.gnome.org/GNOME/libxslt/-/issues/128 CVE-2025-24855
- https://gitlab.gnome.org/GNOME/libxslt/-/issues/139 CVE-2025-7424
- https://gitlab.gnome.org/GNOME/libxslt/-/issues/140 CVE-2025-7425
- https://gitlab.gnome.org/GNOME/libxslt/-/issues/144 use-after-free, no CVE assigned yet
- https://gitlab.gnome.org/GNOME/libxslt/-/issues/150 “libxslt is unmaintained” (some good news there, at least: two weeks ago, the guy who reported those five bugs over the last eight months stepped up to be the new maintainer… i assume he probably isn’t a Jia Tan 😅 since he is endorsed by a co-founder of GNOME itself. but, even if he does improve the library drastically, that still won’t justify having browsers include it in their general attack surface imo)
 - tldr: This obscure “feature” is a significant source of vulnerabilities which attackers are able to compromise endpoints with right now. The GNOME project’s libxslt is used by all modern browsers and has been largely unmaintained for a long time, and it is a pretty sure bet that it has lots more remotely-exploitable bugs (in addition to those which have already been discovered and not yet fixed, or for which fixes are not yet widely distributed). - it sounds like there is also a mostly-working JS replacement for this C++ code; if it is actually possible to ship that and avoid breaking any sites it would be preferable, but, otherwise, i for one would certainly be in favor of dropping browsers’ XSLT support (which was only ever for XSLT 1.0 anyway!) completely ASAP. - That’s interesting context, I agree that if it’s a security issue then it makes sense to drop native implementation. 
 
- See also Microsoft and also Oracle Open Source Engagement. 





