IIRC, there were quite a number of incompatibilities between the different browser implementations and the standard itself. Given that part of the issue here was that nobody had the resources or will to continue fixing bugs and incompatibilities, I can understand why browsers have also been reluctant to make the extension built-in - they’d essentially be doing that work for something that doesn’t work properly and that will probably never be fixed, let alone updated to support newer version of the XSLT spec.
I don’t know that I entirely agree with the decision, but I can very much understand the motivation here, and I’m very sympathetic to the argument that this is just formalising and clarifying a state of affairs that has been implicitly the case for a while now.
For a very long time there were also incompatibilities in how the HTML comments are parsed, so what? I don’t promise there aren’t now.
The state of affairs was not this. The state of affairs was the pretty-baseline number of bugs, although some of them were probably exploitable which is a drawback. Polyfill — that is already in extension stores! — is probably comparable to other implementations in bugginess, and hard to exploit. Browsers absolutely ship buggy parts without fixing things for decades, so it would be absolutely a status quo thing to switch the implementation to a safer one and keep not fixing bugs, and it would keep a nonzero amount of old sites (especially ones that are more valuable by not having updates and being the same snapshot) accessible with the normal baseline level of buggyness.
The point was not that there were incompatibilities, but that there were incompatibilities with no pathway to them being fixed - as I understand it, the underlying library for Chrome/Safari was barely even in maintenance mode, and the only independent implementation, Firefox, didn’t have the resources to address the issues.
And the problem is that that remains even with the WASM version. Yes, that fixes the core security issues by sandboxing everything, but it doesn’t solve the fact that it’s still a buggy wart with no-one interested in supporting it. And to make matters worse, all browsers would be standardising on the same implementation, so now you’ve got a spec which is basically “whatever this library does”, which isn’t great (c.f. WebSQL).
So I can really understand the argument for cutting your losses and getting rid of XSLT altogether, especially given how little of the web it would affect, and the many alternative approaches. That said, I personally think it would have been easier to just adopt the WASM library as a pseudo-standard like how all browsers render PDFs natively, and accept that this library will never really be updated. And that said, I think the whole discussion is entirely overblown, and the at times conspiratorial claims from the original article and many of the comments here are an insane reaction to this whole saga that make me very glad I’m not one of the people making these decisions.
a buggy wart with no-one interested in supporting it.
Support is overrated, stability is underrated. Nobody supporting a thing that cannot be a security issue anyway is a step up from the baseline practices when megacorps break new stuff every time.
Yes, it would be better if there were a specific pathway for external contributors to make all the work fixing any issue in comparison to the standard that they care about, then more work providing validation in some legible way, to have this looked at and merged. No, inclusion of a frozen and somewhat buggy extension that covers the core needs of a large share of current deployments is still better than dropping a thing that has been already standartised and included in the backwards compatibility promises.
so now you’ve got a spec which is basically “whatever this library does”,
Which is baseline for Web Platform now, with Chrome-trailing, except that sometimes Safari manages to just stall. So, not a justification to making worse than that.
So I can really understand the argument for cutting your losses and getting rid of XSLT altogether
Can we then cut the losses further and say that WHAT WG is the group managing the Web Platform section of MDN, and stop even pretending that «Living Standard» is not an oxymoron? Maybe that would shake some regulatory body into treating this as the quicksand it is.
And that said, I think the whole discussion is entirely overblown
I do agree with your characterisatoin of what was the best cost-benefit choice to make last week.
The problem is further disregard of the core values, even when the costly part doing a bit better has been already done. And this disregard is by an organisation who has by now earned the drawback of doubt rather than benefit of doubt.
Support is very important if you’re building a critical piece of infrastructure. It’s also worth keeping in mind that just because the browser extension uses the WASM sandbox does not make it immediately free of security issues — there are plenty of security issues that have nothing to do with the sorts of memory unsafety that WASM protects against.
Somehow critical infrastructure is very often stuck on out-of-support platforms, and the two (big though) problems they get from being stuck are availability of hardware to run all that and security.
As for ability to keep running the same code, if there are doubts about viability of WebAssembly polyfill, doesn’t that mean that Google intends to break WebAssembly? And if they do intend to break WebAssembly, well, it doesn’t make me think better of Google.
As for security: if it is a webextension that checks for a fixed element then injects the polyfill in a way that the site itself also could do it, then WebAssembly is not just «memory safety», WebAssembly serves to ensure «the site could do this injection as simply initial content». Then the question who you are protecting from whom here. The site is already exposed to the browser’s XSLT implementation being buggy, the user is already exposing the browser to the site.
IIRC, there were quite a number of incompatibilities between the different browser implementations and the standard itself. Given that part of the issue here was that nobody had the resources or will to continue fixing bugs and incompatibilities, I can understand why browsers have also been reluctant to make the extension built-in - they’d essentially be doing that work for something that doesn’t work properly and that will probably never be fixed, let alone updated to support newer version of the XSLT spec.
I don’t know that I entirely agree with the decision, but I can very much understand the motivation here, and I’m very sympathetic to the argument that this is just formalising and clarifying a state of affairs that has been implicitly the case for a while now.
score 1 · canonical
For a very long time there were also incompatibilities in how the HTML comments are parsed, so what? I don’t promise there aren’t now.
The state of affairs was not this. The state of affairs was the pretty-baseline number of bugs, although some of them were probably exploitable which is a drawback. Polyfill — that is already in extension stores! — is probably comparable to other implementations in bugginess, and hard to exploit. Browsers absolutely ship buggy parts without fixing things for decades, so it would be absolutely a status quo thing to switch the implementation to a safer one and keep not fixing bugs, and it would keep a nonzero amount of old sites (especially ones that are more valuable by not having updates and being the same snapshot) accessible with the normal baseline level of buggyness.
score 1 · canonical
The point was not that there were incompatibilities, but that there were incompatibilities with no pathway to them being fixed - as I understand it, the underlying library for Chrome/Safari was barely even in maintenance mode, and the only independent implementation, Firefox, didn’t have the resources to address the issues.
And the problem is that that remains even with the WASM version. Yes, that fixes the core security issues by sandboxing everything, but it doesn’t solve the fact that it’s still a buggy wart with no-one interested in supporting it. And to make matters worse, all browsers would be standardising on the same implementation, so now you’ve got a spec which is basically “whatever this library does”, which isn’t great (c.f. WebSQL).
So I can really understand the argument for cutting your losses and getting rid of XSLT altogether, especially given how little of the web it would affect, and the many alternative approaches. That said, I personally think it would have been easier to just adopt the WASM library as a pseudo-standard like how all browsers render PDFs natively, and accept that this library will never really be updated. And that said, I think the whole discussion is entirely overblown, and the at times conspiratorial claims from the original article and many of the comments here are an insane reaction to this whole saga that make me very glad I’m not one of the people making these decisions.
score 1 · canonical
Support is overrated, stability is underrated. Nobody supporting a thing that cannot be a security issue anyway is a step up from the baseline practices when megacorps break new stuff every time.
Yes, it would be better if there were a specific pathway for external contributors to make all the work fixing any issue in comparison to the standard that they care about, then more work providing validation in some legible way, to have this looked at and merged. No, inclusion of a frozen and somewhat buggy extension that covers the core needs of a large share of current deployments is still better than dropping a thing that has been already standartised and included in the backwards compatibility promises.
Which is baseline for Web Platform now, with Chrome-trailing, except that sometimes Safari manages to just stall. So, not a justification to making worse than that.
Can we then cut the losses further and say that WHAT WG is the group managing the Web Platform section of MDN, and stop even pretending that «Living Standard» is not an oxymoron? Maybe that would shake some regulatory body into treating this as the quicksand it is.
I do agree with your characterisatoin of what was the best cost-benefit choice to make last week.
The problem is further disregard of the core values, even when the costly part doing a bit better has been already done. And this disregard is by an organisation who has by now earned the drawback of doubt rather than benefit of doubt.
score 1 · canonical
Support is very important if you’re building a critical piece of infrastructure. It’s also worth keeping in mind that just because the browser extension uses the WASM sandbox does not make it immediately free of security issues — there are plenty of security issues that have nothing to do with the sorts of memory unsafety that WASM protects against.
score 1 · canonical
Somehow critical infrastructure is very often stuck on out-of-support platforms, and the two (big though) problems they get from being stuck are availability of hardware to run all that and security.
As for ability to keep running the same code, if there are doubts about viability of WebAssembly polyfill, doesn’t that mean that Google intends to break WebAssembly? And if they do intend to break WebAssembly, well, it doesn’t make me think better of Google.
As for security: if it is a webextension that checks for a fixed element then injects the polyfill in a way that the site itself also could do it, then WebAssembly is not just «memory safety», WebAssembly serves to ensure «the site could do this injection as simply initial content». Then the question who you are protecting from whom here. The site is already exposed to the browser’s XSLT implementation being buggy, the user is already exposing the browser to the site.
score 1 · canonical