If you check it though what they're using XSLTProcessor for, it seems to be a fallback for an MSXML polyfill, e.g. when you search for "XSLTProcessor" here you can see it: view-source:http://discuz.turzx.com/assets/forum.js?v=3c534b8a
So in the case of Flarum their DOMParser using alternative would chime in, as that's an additional fallback to the MSXML / ActiveX using polyfill.
The critical part is “cares to expend resources”. Google really wants these communication protocols for whatever reason and is happy to support them, but clearly does not care about Xslt.
> > Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that
> And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth
This is not true. Both Mozilla and Apple rejected WebUSB, WebSerial, and WebBluetooth, and Apple rejected WebMIDI as well. Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand. So yes, browser maintainers definitely do have qualms about shoving those huge attack surfaces in there, and those qualms are a matter of public record you can read at your leisure.
> most of which have as much usage as XSLT
It doesn’t make sense to compare the usage of proposed features to a feature that has been implemented by all browsers for 25 years. Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
> Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand.
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.
> Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.
Yes, if a feature is deliberately ignored, let's remove it. That's exactly what happened to SVG for example. Oh wait...
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
> 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.
And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth, WebKitchenSink, most of which have as much usage as XSLT: https://chromestatus.com/metrics/feature/timeline/popularity... or https://chromestatus.com/metrics/feature/timeline/popularity...