> Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.
You’re equivocating here.
You were complaining that browser maintainers had no qualms about adding functionality with large attack surfaces. This was untrue and I pointed out that these things have received a lot of attention from browser maintainers.
You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
Adding a feature with a large attack surface area is a security risk that needs to be evaluated.
Removing a feature with a large attack surface area is not a security risk – it’s the opposite!
The reason people want to have a lengthy discussion when adding features is to avoid introducing security issues.
The reason you want to have a lengthy discussion when removing XSLT is because you want the XSLT functionality.
These two situations are not the same thing at all but you are presenting them as equivalent.
Furthermore, the security risks of XSLT have already been clearly shown:
> 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.
If you were honestly worried about “the huge attack surface areas” of these features, then you should be glad that they had lengthy discussions beforehand, and you should be worried about XSLT being present in browsers. But instead you are using the discussion of those new features as a way to defend XSLT being present.
> Yo, if a feature is deliberately ignored, let's remove it. That's exactly what hairless to SVG for example. Oh wait...
This makes no sense, SVG is in widespread use.
> On top of that XSLT is used on more web sites than, say, WebSerial
I already explained why it makes no sense to make this comparison.
> You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
It is.
Large complex spec with a potentially large attack service, but which is still in use (even though small use, but not enough to justify removal according to very same browser vendors who are not Google, and according to Google's own document)?
> then you should be glad that they had lengthy discussions beforehand
I'm not glad, because Google shipped them regardless of any concerns from any of the other browser vendors.
You’re equivocating here.
You were complaining that browser maintainers had no qualms about adding functionality with large attack surfaces. This was untrue and I pointed out that these things have received a lot of attention from browser maintainers.
You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.
Adding a feature with a large attack surface area is a security risk that needs to be evaluated.
Removing a feature with a large attack surface area is not a security risk – it’s the opposite!
The reason people want to have a lengthy discussion when adding features is to avoid introducing security issues.
The reason you want to have a lengthy discussion when removing XSLT is because you want the XSLT functionality.
These two situations are not the same thing at all but you are presenting them as equivalent.
Furthermore, the security risks of XSLT have already been clearly shown:
> 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.youtube.com/watch?v=U1kc7fcF5Ao
If you were honestly worried about “the huge attack surface areas” of these features, then you should be glad that they had lengthy discussions beforehand, and you should be worried about XSLT being present in browsers. But instead you are using the discussion of those new features as a way to defend XSLT being present.
> Yo, if a feature is deliberately ignored, let's remove it. That's exactly what hairless to SVG for example. Oh wait...
This makes no sense, SVG is in widespread use.
> On top of that XSLT is used on more web sites than, say, WebSerial
I already explained why it makes no sense to make this comparison.