4 ms·

> > 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

> > 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.

troupo 1y ago
> 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... On top of that XSLT is used on more web sites than, say, WebSerial which managed to climb to a whooping 0.000596% this year https://chromestatus.com/metrics/feature/timeline/popularity/2547 https://chromestatus.com/metrics/feature/timeline/popularity... To quote Chrome's own document: --- start quote --- 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! https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... --- end quote ---
- JimDabell 1y ago
  > 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. — 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 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.
  - troupo 1y ago

troupo 1y ago

> 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... On top of that XSLT is used on more web sites than, say, WebSerial which managed to climb to a whooping 0.000596% this year https://chromestatus.com/metrics/feature/timeline/popularity/2547 https://chromestatus.com/metrics/feature/timeline/popularity... To quote Chrome's own document: --- start quote --- 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! https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=drivesdk https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... --- end quote ---

JimDabell 1y ago
> 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. — 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 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.
- troupo 1y ago