Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing XSLT for a more secure browser

developer.chrome.com

Post reply on HN
Print view View original

331–340 of 352 posts

Re: Removing XSLT for a more secure browser

#331

Post by righthand »

shadowgovt wrote: post #326
righthand wrote: post #310

Earlier quoted context omitted.

No the Mba is Freeds boss who installed him there and ensure he enforces closing of the web. Coming from sensor manufacturing to software isn’t really that impressive but it does make sense why a sensor manufacturing engineer would make arguments for removing a spec like XSLT but not a terribly complicated and security vulnerable spec like bluetooth. Which probably has 10x the complexity and 10x security plane of xsl…

> Which probably has 10x the complexity and 10x security plane ... and 10x the utility, since unlike XSLT Bluetooth requires sandboxed and mediated access to OS-level APIs that cannot be feature-compatible replicated with 3MB of JavaScript.

And sandboxing Xslt was one of the suggested ways to not break the web. But they ignored it.

Re: Removing XSLT for a more secure browser

#332

Post by shadowgovt »

righthand wrote: post #329
shadowgovt wrote: post #313

Earlier quoted context omitted.

I don't see how it can be reasonably asserted that this is "destruction of XSLT in the browser" when there are multiple XSLT conversion engines available in JavaScript.

Because when you convert xslt to javascript it’s not xslt is it? It’s javascript pretending to xslt. Furthermore if you restrict rendering xslt to javascript then you lose all the performance benefits of xslt at the engine level. Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries. All your “its fine to remove it” arguments only work if you ignore al…

You'd be replacing the native-implemented XSLT engine in the browser with a JavScript-implemented XSLT engine living in the JavaScript sandbox, not replacing XSLT with JavaScript.

There's a theorem with Turing's name on it that clarifies why that's equivalent.

> if you restrict rendering xslt to javascript then you lose all the performance benefits of xslt at the engine level.

Nowadays, I'd have to benchmark before just assuming the native implementation is faster. Especially if one of the issues is libxslt is under-maintained. JS is quite fast these days (and the polyfill investigated in the OP is wasm, not even JS). This problem can also be solved by moving the rendering server-side, in which case your ceiling for speed is much higher (and you're not spending your client's CPU on finishing the rendering of your page; added bonus in this era of mobile, battery-constrained devices).

> Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries.

Great point. Why do we have this one arbitrary meta-language for declarative transformation of one datatype that's "blessed" with a native implementation? That's an odd corner-case, isn't it. We should probably simplify by putting it on-par with other solutions for that problem.

Re: Removing XSLT for a more secure browser

#333

Post by shadowgovt »

righthand wrote: post #330
shadowgovt wrote: post #315

Earlier quoted context omitted.

These are all great ideas and I support you pursuing what you are passionate about.

No you don’t because my passions are for a open technically varied unbroken web and you’ve spent the entire time trying to paint me as crazy for wanting any of that just because not all technology is equally popular or profitable for Google.

With respect: I've never called you crazy, nor did I imply it, nor did I mean to imply it.

I think your cost / benefit analysis on maintaining a native in-browser implementation of an old, niche declarative transformation language for a hard-to-read data format that hasn't been the dominant model of sending data to browser clients for at least fifteen years is flawed, but it's not crazy. Reasonable people can certainly put their priorities in different places, and I respect our priorities don't align on this topic and you have a right to your opinion.

Re: Removing XSLT for a more secure browser

#334

Post by shadowgovt »

righthand wrote: post #331
shadowgovt wrote: post #326

Earlier quoted context omitted.

> Which probably has 10x the complexity and 10x security plane ... and 10x the utility, since unlike XSLT Bluetooth requires sandboxed and mediated access to OS-level APIs that cannot be feature-compatible replicated with 3MB of JavaScript.

And sandboxing Xslt was one of the suggested ways to not break the web. But they ignored it.

I believe you, but I think I missed that part of the conversation.

Running an XSLT engine in JavaScript is sandboxed. It's sandboxed by the JS rules. In terms of security, it's consolidating sandboxing concerns because risk of breaking XSLT becomes risk of breaking the JS engine, whereas right now there are two potential attack vectors to monitor.

(There is an unwritten assumption here: "But I can avoid the JS issues by turning off JavaScript." Which is true, but I think the ship is pretty well sailed for any w3c-compliant browser to be supporting JavaScript-off as a first-class use case these days. From a safety standpoint, we even have situations where there are security breach detections against things like iframe-busting that only work with JavaScript on).

Re: Removing XSLT for a more secure browser

#335

Post by shadowgovt »

exasperaited wrote: post #54
TingPing wrote: post #46

Earlier quoted context omitted.

I get the frustration but I don’t believe that’s really accurate. It’s not widely used and modern developers don’t see it as valuable.

XSLT in the browser was left fundamentally underdeveloped, which is why it is not really widespread. XSLT in non-browser contexts is absolutely valuable.

Agreed; as a technology, it's both clever and fun. I learned it right around the time I first touched functional programming in general and it was neat to see how you could build a chain of declarative rules to go from one document to another document.

Personally, I don't think we need a dedicated native-implemented browser engine for it. But in general I'm glad the tech exists.

Re: Removing XSLT for a more secure browser

#336

Post by dpark »

righthand wrote: post #331
shadowgovt wrote: post #326

Earlier quoted context omitted.

> Which probably has 10x the complexity and 10x security plane ... and 10x the utility, since unlike XSLT Bluetooth requires sandboxed and mediated access to OS-level APIs that cannot be feature-compatible replicated with 3MB of JavaScript.

And sandboxing Xslt was one of the suggested ways to not break the web. But they ignored it.

The question for all the browser developers is not “can we feasibly support this feature” but “is it worth it to support this feature”?

Because they must address the security problems, there is no zero-cost solution to maintain compatibility. They either abandon it or rewrite it which comes with support costs forever.

I understand you believe they made the wrong choice and I understand why you feel that way. But according to their calculus they are making the right choice based on how widely used the feature actually is.

Re: Removing XSLT for a more secure browser

#337

Post by bawolff »

JetSpiegel wrote: post #281
bawolff wrote: post #259

Earlier quoted context omitted.

> the maintainers' own admission the code was never intended to be security critical I find this hard to believe. XML is a portable data serialization format. The entire point of XML is to transfer data between separate parties who preumably dont trust each other. Most non browser xml usages are security criical and have been from the beginning. Just look at their website from 2001 https://web.archive.org/web/2001020…

What are you talking about, "free labor"? They are using the damn library, Google would benefit directly.

But they dont want to use the library.

Re: Removing XSLT for a more secure browser

#340

Post by thro1 »

lunar_mycroft wrote: post #72
phendrenad2 wrote: post #32

Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.

Chrome and other browsers could virtually completely mitigate the security issues by shipping the polyfil they're suggesting all sites depending on XSLT deploy in the browser. By doing so, their XSLT implementation would become no less secure than their javascript implementation (and fat chance they'll remove that ). The fact that they've rejected doing so is a pretty clear indication that security is just an excuse,…

by definition XSLT is more secure than JavaScript.
Post reply on HN