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

311–320 of 352 posts

Re: Removing XSLT for a more secure browser

#311

Post by righthand »

dpark wrote: post #307
righthand wrote: post #301

Earlier quoted context omitted.

Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. Not: popular browsers needle through technologies and tell everyone they know best Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using. What is open web to you? “Overpaid Mba at Google says…

> Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. The “wide range of technologies” is not what makes the web “open”. The openness comes from the fact that anyone can write web sites and anyone can write a browser that can render the same websites that chrome can render. “More features” does not imply “more open”. Dropping support for xslt would ma…

I don’t care to continue this discussion primarily because you are making nearly the same points as two other commenters and it has become a three way exhausting conversation. You hate XSLT or something and love Google, congrats, you win this discussion. XSLT will be removed, Javascript will reign king. You will be happy. Every one will say Mason Freed is right and smart and that XML sucks because no one who matters uses it. I was never going to convince you to like or consider other technologies, anyways. And since that is true, this conversation doesn't do anything to try and help save XSLT and not worth continuing for me at least.

I wish it weren't the case but good luck and I'm sure we'll speak again with nearly the same conversation at the next thread for a standard deprecation that ad companies don't like.

Re: Removing XSLT for a more secure browser

#312

Post by righthand »

exasperaited wrote: post #108
dfox wrote: post #27

Earlier quoted context omitted.

> Security? MUCH worse. Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense. Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)

Are the security concerns not about libxslt, rather than XSLT?

They are about libxslt but Mason Freed doesn’t want you to know that. They could contribute a rust project which has already implemented XSLT 1.0 thus matching the browsers. But that would good software engineering and logical.

Re: Removing XSLT for a more secure browser

#313

Post by shadowgovt »

righthand wrote: post #308
dpark wrote: post #306

Earlier quoted context omitted.

> There is no negative trade off by maintaining XSLT other than not being lazy developers. Only because it’s not your money or time being traded. Yes, if we pretend that engineering effort is free then there’s no reason Google couldn’t just rewrite this entire library in Rust or whatever. But if that were true you would just rewrite the library yourself and send the pull request to Chromium. In the real world where e…

Surprise, there’s already an effort to write xml related libraries in Rust: xrust library for one. It doesn’t have to be this pearl gripping bitching and moaning about budgets and practicality. That’s just what Google wants you to believe. No all of the major browsers weren’t planning to drop this. It literally only started happening because of Google. And Google is essentially forcing the hand. Again this is bad fai…

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.

Re: Removing XSLT for a more secure browser

#314

Post by shadowgovt »

righthand wrote: post #311
dpark wrote: post #307

Earlier quoted context omitted.

> Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. The “wide range of technologies” is not what makes the web “open”. The openness comes from the fact that anyone can write web sites and anyone can write a browser that can render the same websites that chrome can render. “More features” does not imply “more open”. Dropping support for xslt would ma…

I don’t care to continue this discussion primarily because you are making nearly the same points as two other commenters and it has become a three way exhausting conversation. You hate XSLT or something and love Google, congrats, you win this discussion. XSLT will be removed, Javascript will reign king. You will be happy. Every one will say Mason Freed is right and smart and that XML sucks because no one who matters…

Bold of you to assume other commenters in this thread have no experience with XML or XSLT.

I was there when it was the new hottest thing and I was there when it became last year's thing. These things come and go, and this one's time has come.

Re: Removing XSLT for a more secure browser

#315

Post by shadowgovt »

righthand wrote: post #309
shadowgovt wrote: post #304

Earlier quoted context omitted.

There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt. I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side). > not…

Sure. But since this announcement I’ve been planning ways to support xslt. Here are the projects I’m considering: - iced-ui browser with xslt + servo - contribute to xslt xrust project - investigate sandboxing xslt in firefox and implementing xrust - same as the previous but for Chrome - have an llm generate 1000s of static websites built in xslt and deploy them across the internet - promote and contribute to the rec…

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

Re: Removing XSLT for a more secure browser

#317

Post by dpark »

righthand wrote: post #308
dpark wrote: post #306

Earlier quoted context omitted.

> There is no negative trade off by maintaining XSLT other than not being lazy developers. Only because it’s not your money or time being traded. Yes, if we pretend that engineering effort is free then there’s no reason Google couldn’t just rewrite this entire library in Rust or whatever. But if that were true you would just rewrite the library yourself and send the pull request to Chromium. In the real world where e…

Surprise, there’s already an effort to write xml related libraries in Rust: xrust library for one. It doesn’t have to be this pearl gripping bitching and moaning about budgets and practicality. That’s just what Google wants you to believe. No all of the major browsers weren’t planning to drop this. It literally only started happening because of Google. And Google is essentially forcing the hand. Again this is bad fai…

Google isn’t forcing anyone’s hand here. They are removing functionality. Everyone else could just not do that and maintain compatibility if they believed it was valuable to do so.

I don’t know why you have a chip on your shoulder for Google but sure. Yes, Google is clearly doing this purely because they are evil and removing this little-used tech is the key to cementing their stranglehold on the internet. Yes, Google is strong-arming poor Apple and Mozilla into this. Yes, everyone who disagrees with you is both a complete moron and a “daddy Google” fanboy.

Better now?

Re: Removing XSLT for a more secure browser

#318

Post by dpark »

shadowgovt wrote: post #293
dpark wrote: post #288

Earlier quoted context omitted.

Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?

Gopher support in browser was never, IIUC, a w3c standard. Piecing the puzzle pieces together from multiple threads: There's an argument to be made that the HTML standard, which post-dates the browser wars and was more-or-less the detente that was agreed upon by the major vendors of the day, includes a rule that no compliant browser should drop a feature (no matter how old or unused that feature is) because "Don't br…

> that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says.

This is coming out of WHATWG so in actuality the spec itself is being updated to remove the functionality. So yes, the end state is very much that devs cannot rely on this functionality.

Re: Removing XSLT for a more secure browser

#319

Post by bmacho »

eddd-ddde wrote: post #114
RogBogTog wrote: post #93

I think that's sad. XSLT is in my point a view a very misunderstood technology. It gets hated on a lot. I wonder if this hate is by people who actually used and understood it, though. In any case, more often than not this is by people who in the same sentence endorse JavaScript (which, by any objective way of measuring is just a language far more poorly designed).

What does XSLT provide that you cannot achieve with plain JS?

It can style RSS without enabling javascript and all that spy and malware.

Re: Removing XSLT for a more secure browser

#320

Post by array_key_first »

lifthrasiir wrote: post #279
array_key_first wrote: post #254

Earlier quoted context omitted.

> The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. Yes, they also have much more vulnerabilities, because browsers are JIT compiling JS to w+x memory pages. And JS continues to get more complex with time. This is just fundamentally not the case with XSLT. We're comparing a fe…

While JIT exploits represent a large share of vulnerabilities in JS engines, there are enough other classes of vulnerabilities that simply turning JIT off is not sufficient. (The same goes for simply turning JS off, the Web browser internal is complex enough even without JS.)

Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works.

Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!

Post reply on HN