Comment by gucci-on-fleek | Hacker News Reader

Comment by gucci-on-fleek | Hacker News Reader

Parent Full thread

> Last time this came up the consensus was that libxstl was barely maintained and never intended to be used in a secure context and full of bugs.

Sure, I agree with you there, but removing XSLT support entirely doesn't seem like a very good solution. The Chrome developer who proposed removing XSLT developed a browser extension that embeds libxslt [0], so my preferred solution would be to bundle that by default with the browser. This would:

1. Fix any libxslt security issues immediately, instead of leaving it enabled for 18 months until it's fully deprecated.

2. Solve any backwards compatibility concerns, since it's using the exact same library as before. This would avoid needing to get "consensus" from other browser makers, since they wouldn't be removing any features.

3. Be easy and straightforward to implement and maintain, since the extension is already written and browsers already bundle some extensions by default. Writing a replacement in Rust/another memory-safe language is certainly a good idea, but this solution requires far less effort.

This option was proposed to the Chrome developers, but was rejected for vague and uncompelling reasons [1].

> I think if the XSLT people really wanted to save it the best thing to do would have been to write a replacement in Rust.

That's already been done [2], but maintaining that and integrating it into the browsers is still lots of work, and the browser makers clearly don't have enough time/interest to bother with it.

[0]: https://github.com/mfreed7/xslt_extension

[1]: https://github.com/whatwg/html/issues/11523#issuecomment-315...

[2]: https://gitlab.gnome.org/World/Rust/markup-rs/xrust

From your [1] “rejected for vague and uncompelling reasons”:

>>> To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser.

>> Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I'm thinking about how Firefox renders PDFs without native code using PDF.js.)

> This is definitely something we have been thinking about. However, our current feeling is that since the web has mostly moved on from XSLT, and there are external libraries that have kept current with XSLT 3.0, it would be better to remove 1.0 from browsers, rather than keep an old version around with even more wrappers around them.

The bit that bothers me is that Google continue to primarily say they’re removing it for security reasons, although they have literally made a browser extension which is a drop-in replacement and removes 100% of the security concerns. The people that are writing about the reasons know this (one of them is the guy that wrote it), which makes the claim a blatant lie.

I want people to call Google specifically out on this (and Apple and Mozilla if they ever express it that way, which they may have done but I don’t know): that their “security” argument is deceit, trickery, dishonest, grossly misleading, a bald-faced lie. If they said they want to remove it because barely anyone uses it and it will shrink their distribution by one megabyte, I would still disagree because I value the ability to apply XSLT on feeds and other XML documents (my Atom and RSS feed stylesheets are the most comprehensive I know of), but I would at least listen to such honest arguments. But falsely hiding behind “security”? I impugn their honour.

(If their extension is not, as their descriptions have implied, a complete, drop-in replacement with no caveats, I invite correction and may amend my expressed opinion.)

You still need to maintain that sandbox. Ultimately no one wants to spend energy maintaining software that isn't used very heavily. That's why feature depreciation happens. If someone cares enough, they should step in an offer to take over long term maintenance and fix the problems. Ideally a group of people, and perhaps more ideally, a group with some financial backing (eg a company), otherwise it may be difficult to actually trust that they will live up to the commitment.

Even projects like Linux deprecate old underused features all the time. At least the Internet has real metrics about API usage which allows for making informed decisions. Folks describing how they are part of that small fraction of users doesn't really change the data. What's also interesting is that a very similar group of people seem to lament about how it's impossible to write a new browser these days because there are too many features to support.

"The sandbox" in this case is their ability to execute WASM securely. It's a necessary part of the "modern" web. If they were planning on also nuking WASM from orbit because it couldn't be made secure, this would be another topic entirely. There's nothing they're maintaining just-for-xslt-1.0-support beyond a simple build of libxslt to WASM, a copy block in their build code, and a line in a JSON list to load WASM provided built-ins (which they would want anyway for other code).

The word is "deprecation", and your understanding of what it means isn't how it has tended to work at all. The Web is not the Tizen SDK. This is a significant change to how browser vendors treat Web standards.

I think their logic makes sense. They're removing support because of security concerns, and they're not adding support back using an extension because approximately nobody uses this feature.

Adding the support back via an extension isn't cost free.

I suppose that’s a legitimate framing. But I will still insist that, at the very least, their framing is deliberately misleading, and that saying “you can’t have XSLT because security” is dishonest.

But when it “isn’t cost-free”… they’ve already done 99.9% of the work required (they already have the extension, and I believe they already have infrastructure to ship built-in functionality in the form of Web Extensions—definitely Firefox does that), and I seem to recall hearing of them shifting one or two things from C/C++ to WASM before already, so really it’s only a question of whether it will increase installer/installed size, which I don’t know about.

According to the extension's README there are still issues with it, so they definitely would have to do more work.

And yeah Chrome is really strict about binary size these days. Every kB has to be justified. It doesn't support brotli compression because it would have added like 16kB to the binary size.

an insecure mess contained in a sandbox is still an insecure mess

it just has slightly less chance of affecting something else

"effecting something else" (i.e. escaping the sandbox) is the core issue. JavaScript (and WASM) engines have to be designed to defend against the user running outright malicious scripts without those scripts being able to gain access to the rest of the browser or the host system. By comparison, potentially exploitable but non-malicious, messy code is basically a non-issue. Any attacker that found a bug in a sandboxed XSLT polyfil that allowed them to escape the sandbox or do anything else malicious would be able to just ship the same code to the browser themselves to achieve the same effect.

Reply on news.ycombinator.com