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

141–150 of 352 posts

Re: Removing XSLT for a more secure browser

#141

Post by cbarrick »

jerf wrote: post #84
Fileformat wrote: post #56

One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…

I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one. "XSLT is currently the only way to make feeds into something that can still be viewed." You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header: text/html,application/xhtml+xml,applica…

You've been in the RSS world since the beginning and never seen a stylized feed?

I've not been in the RSS world very much. I don't use news readers. And even I have seen a stylized RSS in the wild.

Our individual experiences are of course anecdotal, I'm just surprised at how different they are given your background.

Re: Removing XSLT for a more secure browser

#142

Post by lunar_mycroft »

kccqzy wrote: post #133
sroussey wrote: post #117

Earlier quoted context omitted.

And why doesn’t Google contribute to fixing and maintaining code they use?

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.

Re: Removing XSLT for a more secure browser

#143

Post by AlecSchueler »

Fileformat wrote: post #56

One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…

> not that many feeds are actually doing this

Isn't this kind of an argument for dropping it? Yeah it would be great if it was in use but even the people who are clicking and providing RSS feeds don't seem to care that much.

Re: Removing XSLT for a more secure browser

#144

Post by AlecSchueler »

tptacek wrote: post #116
dragonwriter wrote: post #96

Earlier quoted context omitted.

> 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. Not having it available from the browser really reduces the ability to use it in many cases, and lots of the nonbrowser XSLT ecosystem relies on the same insecure, unmaintained implementation. There is at least one major alternative (Saxon), and if browser support…

Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?

What do you find questionable about this being included as part of the broader argument?

Re: Removing XSLT for a more secure browser

#145

Post by tptacek »

AlecSchueler wrote: post #144
tptacek wrote: post #116

Earlier quoted context omitted.

Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?

What do you find questionable about this being included as part of the broader argument?

I just don't understand it. I don't understand it well enough to call out what's questionable about it.

Re: Removing XSLT for a more secure browser

#146

Post by AlecSchueler »

jerf wrote: post #84
Fileformat wrote: post #56

One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…

I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one. "XSLT is currently the only way to make feeds into something that can still be viewed." You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header: text/html,application/xhtml+xml,applica…

> I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one.

Maybe it's more for people who have no idea what RSS is and click on the intriguing icon. If they weren't greeted with a load of what seems like nonsense for nerds there could have been broader adoption of RSS.

Re: Removing XSLT for a more secure browser

#147

Post by davisr »

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…

> I’m curious. Do Google Maps, YouTube, etc even work with JS off?

I use KDE Marble (OpenStreetMap) and Invidious. They work fine.

> Original intent is borderline irrelevant. What matters is how it is actually used and what value it brings.

And that's why webshit is webshit.

> I can’t do the same with random desktop apps.

I can, and besides the point, why should anyone run random desktop apps? (Rhetorical question, they shouldn't.) I don't run code that I don't trust. And I don't trust code that I can't run for any purpose, read, study, edit, or share. I enforce this by running a totally-free (libre) operating system, booted with a totally-free BIOS, and installing and using totally-free software.

Re: Removing XSLT for a more secure browser

#148

Post by flomo »

nwellnhof wrote: post #48

The "severe security issue" in libxml2 they mention is actually a non-issue and the code in question isn't even used by Chrome. I'm all for switching to memory-safe languages but badmouthing OSS projects is poor style.

Sounded like the maintainers of libxml2 have stepped-back, so there needs to be a supported replacement, because it is widely used. (Or if you are worried the reputation of "OSS", you can volunteer!)

Re: Removing XSLT for a more secure browser

#149

Post by stronglikedan »

davisr wrote: post #87
Aurornis wrote: post #77

Earlier quoted context omitted.

> I block JS The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary. What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product…

I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.

The point of the poster you're responding to is that sites are built JS-first for 98-99% of users, and it takes extra work to make them compatible with "JavaScript should NOT be REQUIRED to view a website", and no one is going to bother doing that work for 1-2% of users.

Re: Removing XSLT for a more secure browser

#150

Post by magicalist »

MarsIronPI wrote: post #22

To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all). I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add…

> I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all)

Recent XSLT parser exploits were literally the reason this whole push to remove it was started, so this change will specifically be helping people in your shoes.

Post reply on HN