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
deleted by creator
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.