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

181–190 of 352 posts

Re: Removing XSLT for a more secure browser

#181

Post by mhitza »

robocat wrote: post #177
Kwpolska wrote: post #103

Earlier quoted context omitted.

Or perhaps the multi-billion-dollar corporations could stop piggy-backing on volunteers and invest in maintaining the Web platform?

Which popular browsers are significantly leaning on individual contributors or volunteers?

Almost all of them? as I recall there was a single volunteer developer maintaining the xml/xslt libraries they were using.

Wasn't it similar with openssl 13+ years ago? Few volunteer maintainers, and only after a couple of major vulnerabilities money got thrown at that project?

I'm sure there's more and that's why the famous xkcd comic is always of relevance.

Re: Removing XSLT for a more secure browser

#182

Post by will4274 »

lunar_mycroft wrote: post #142
kccqzy wrote: post #133

Earlier quoted context omitted.

Because they don't want to use the code. They begrudgingly use it to support XSLT and now they don't use it.

Maintaining web standards without breaking backwards compatibility is literally what they signed up for when they decided to make a browser. If they didn't want to do that job, they shouldn't have made one.

According to whom?

Chromium is open source and free (both as in beer and speech). The license says they've made no future commitments and made no warrants.

Google signed up to give something away for free to people who want to use it. From the very first version, it wasn't perfectly compatible with other web browsers (which mostly did IE quirks things). If you don't want to use it, because it doesn't maintain enough backwards compatibility... Then don't.

Re: Removing XSLT for a more secure browser

#183

Post by MrJohz »

Fileformat wrote: post #169
chuckadams wrote: post #89

Earlier quoted context omitted.

> Cancelling XSLT is going in the wrong direction (IMHO). XSLT isn't going anywhere: hardwiring into the browser an implementation that's known to be insecure and is basically unmaintained is what's going away. The people doing the wailing/rending/gnashing about the removal of libxslt needed to step up to fix and maintain it. It seems like something an extension ought to be capable of, and if not, fix the extension A…

So... you want newbies to install an extension/plugin before they get a human-readable view of a feed??? That's about as new-user-hostile as I can imagine.

There are plenty of ways around this.

As others have pointed out, there are other options for styling XML that work well enough in practice. You can also do content negotiation on the server, so that a browser requesting an html document will get the human-readable version, while any feed reader will be sent the XML version. (If you render the html page with XSLT, you can even take advantage of better XSLT implementations where you don't need to work around bugs and cross-platform jank.) Or you can rely on `link` tags, letting users submit your homepage to their feed reader, and having the feed reader figure out where everything is.

There might even be a mime code for RSS feeds, such that if you open an RSS feed in your browser, it automatically figures out the correct application (i.e. your preferred RSS reader) to open that feed in. But I've not seen that actually implemented anywhere, which is a shame, because that seems like by far the best option for user experience.

Re: Removing XSLT for a more secure browser

#184

Post by nagaiaida »

dpark wrote: post #138
davisr wrote: post #130

Earlier quoted context omitted.

Did I say abandon? No. I said it should not be required. JavaScript should be supplementary to a page, but not necessary to view it. This was its original intent. > JS is what has allowed websites to replace desktop apps in many cases. Horribly at that, with poorer accessibility features, worse latency, abused visual style that doesn't match the host operating system, unusable during times of net outages, etc, etc.

> JavaScript should be supplementary to a page, but not necessary to view it. I’m curious. Do Google Maps, YouTube, etc even work with JS off? > This was its original intent. Original intent is borderline irrelevant. What matters is how it is actually used and what value it brings. > Horribly at that I disagree. You say you turn JS off for security but JS has made billions of people more secure by creating a sandbox…

> You say you turn JS off for security but JS has made billions of people more secure by creating a sandbox for these random apps to run in.

is "every website now expects to run arbitrary code on the client's computer" really a more secure state of affairs? after high profile hardware vulnerabilities exploitable even from within sandboxed js?

from how many unique distributors did the average person run random untrusted apps that required sandboxing before and after this became the normal way to deliver a purely informational website and also basically everything started happening online?

Re: Removing XSLT for a more secure browser

#185

Post by Kwpolska »

robocat wrote: post #177
Kwpolska wrote: post #103

Earlier quoted context omitted.

Or perhaps the multi-billion-dollar corporations could stop piggy-backing on volunteers and invest in maintaining the Web platform?

Which popular browsers are significantly leaning on individual contributors or volunteers?

Google decided to drop XSLT, because the volunteer-maintained libxslt had no maintainers for some time. So, instead of helping the project, they just decided to remove a feature.

Re: Removing XSLT for a more secure browser

#186

Post by deepspace »

DonHopkins wrote: post #123
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).

Au contraire: the more you understand and use XSLT, the more you hate it. People who don't understand it and haven't used it don't have enough information and perspective to truly hate it properly. I and many other people don't hate XSLT out of misunderstanding at all: just the opposite. XSLT is like programming with both hands tied behind your back, or pedaling a bicycle with only one leg. For any non-trivial task,…

Well said. I wrote an XSLT based application back in the early 2000s, and I always imagined the creators of XSLT as a bunch of slavering demented sadists. I hate XSLT with a passion and would take brainfuck over it any day.

Hearing the words Xalan, Xerces, FOP makes me break out in a cold sweat, 20 years later.

Re: Removing XSLT for a more secure browser

#187

Post by spookie »

lunar_mycroft wrote: post #142
kccqzy wrote: post #133

Earlier quoted context omitted.

Because they don't want to use the code. They begrudgingly use it to support XSLT and now they don't use it.

Maintaining web standards without breaking backwards compatibility is literally what they signed up for when they decided to make a browser. If they didn't want to do that job, they shouldn't have made one.

They "own the web". They steer its standards, and other browsers' development paths (if they want to remain relevant).

It is remarkable the anti-trust case went as it did.

Re: Removing XSLT for a more secure browser

#188

Post by dragonwriter »

tptacek wrote: post #165
dragonwriter wrote: post #155

Earlier quoted context omitted.

I don’t see anything that looks remotely like a normative argument about what browsers should or should not do anywhere in my post that you are responding to, did you perhaps mean to respond to some other post? My point was that the decision to remove XSLT support from browsers rather than replacing the insecure, unmaintained implementation with a secure, maintained implementation is an indicator opposed to the claim…

Is the idea that if they did so, the insecure non-browser XSLT-users could adopt their implementation?

The idea is that if they did so, the people using software running in the browser could continue to use XSLT with just the browser platform because the functionality would still be there with a different backend implementation, but instead that in-browser XSLT functionality is going somewhere, specifically, away.

Re: Removing XSLT for a more secure browser

#189

Post by sedatk »

I like XSLT, and I’ve been using the browser-based APIs in my projects, but I must say that XSLT ecosystem has been in a sad state:

- Browsers have only supported XSLT 1.0, for decades, which is the stone age of templating. XSLT 3.0 is much nicer, but there’s no browser support for it.

- There are only two cross-platform libraries built for it: libxslt and Saxon. Saxon seriously lacks ergonomics to say the least.

One option for Google as a trillion dollar company would be to drive an initiative for “better XSLT” and write a Rust-based replacement for libxslt with maybe XSLT 3.0 support, but killing it is more on-brand I guess.

I also dislike the message “just use this [huge framework everyone uses]”. Browser-based template rendering without loading a framework into the page has been an invaluable boon. It will be missed.

Re: Removing XSLT for a more secure browser

#190

Post by tptacek »

dragonwriter wrote: post #188
tptacek wrote: post #165

Earlier quoted context omitted.

Is the idea that if they did so, the insecure non-browser XSLT-users could adopt their implementation?

The idea is that if they did so, the people using software running in the browser could continue to use XSLT with just the browser platform because the functionality would still be there with a different backend implementation, but instead that in-browser XSLT functionality is going somewhere, specifically, away .

Right but either way, the vulnerability exists today, and you're saying that whether or not the browser platform supports the functionality that harbors the vulnerabilities, the browser platform should be responsible for resolving those vulnerabilities. That's how I read it.
Post reply on HN