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

91–100 of 352 posts

Re: Removing XSLT for a more secure browser

#91

Post by jeffbee »

Fileformat wrote: post #66
yegle wrote: post #58

Earlier quoted context omitted.

FWIW the original post explicitly mentioned this use case and offered two ways to workaround.

Gotta love the reference to the header element. There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.

Man, reaching way back in history here, but this reminds me of why I stopped contributing to Mozilla decades ago. My contribution was the link toolbar, that was supposed to give a UI representation of the canonical link elements like next and prev and whatnot. At the last minute before a major release some jerkhole of a product manager at AOL cut my feature from the release. It's incredible the way such pretty bureaucrats have shaped web browsers over the years.

Re: Removing XSLT for a more secure browser

#92

Post by stickfigure »

mschuster91 wrote: post #26
stickfigure wrote: post #16

Earlier quoted context omitted.

This is only repeated by people who have never used it. XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).

I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty. Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!

It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...

I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language".

That doesn't mean that XML isn't useful. Just not as a programming language.

Re: Removing XSLT for a more secure browser

#93

Post by RogBogTog »

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).

Re: Removing XSLT for a more secure browser

#94

Post by dpark »

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.

> And so does about 1-2% of all Web users.

To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all.

The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.

Re: Removing XSLT for a more secure browser

#95

Post by masfuerte »

gdulli wrote: post #38

I don't use XSLT and don't object to this, but seeing "security" cited made me realize how reflexively distrustful I've become of them using that justification for a given decision. Is this one actually about security? Who knows!

There are security issues in the C implementation they currently use. They could remove this without breaking anything by incorporating the JS XSLT polyfill into the browser. But they won't because money.

Re: Removing XSLT for a more secure browser

#96

Post by dragonwriter »

chuckadams wrote: post #89
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…

> 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…

> 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 was switching backing implementation rather than just ending support, “XSLT isn’t going anywhere” would be a more natural conclusion, but that’s not, for whatever reason, the case.

Re: Removing XSLT for a more secure browser

#97

Post by chuckadams »

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.

The issue in question is just one of the several long-unfixed vulnerabilities we know about, from a library that doesn't have that many hands or eyes on it to begin with.

Re: Removing XSLT for a more secure browser

#98

Post by dpark »

shadowgovt wrote: post #78
righthand wrote: post #50

Earlier quoted context omitted.

I’m a modern developer and I see it as valuable. Why side with the browser teams and ignoring user feedback? If “modern developers” actually spent time with it, they’d find it valuable. Modern developers are idiots if their constant cry is “just write it in JS”. No idea what’s inaccurate about this. A billion dollar company that has no problem pivoting otherwise, can’t fund open technology “because budgets” is simply…

The dominant user feedback is the hard statistics on how rarely it's used. You can't trim the space of "users" to just "people who already adopted the technology" in the context of the cost of browser support.

“Everyone who uses the blink tag agrees it’s critical functionality.”

Re: Removing XSLT for a more secure browser

#99

Post by mschuster91 »

stickfigure wrote: post #92
mschuster91 wrote: post #26

Earlier quoted context omitted.

I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty. Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!

It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams... I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every pop…

> It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...

npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;)

Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab.

> look at pretty much every popular CI system for "YAML is not a programming language".

Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.

Re: Removing XSLT for a more secure browser

#100

Post by update »

arandr0x wrote: post #55

It's encouraging to see browsers actually deprecate APIs, when I think a lot of problems with the Web and Web security in particular is people start using new technologies too fast but don't stop using old ones fast enough. That said, it's also pretty sad. I remember back in the 2000s writing purely XML websites with stylesheets for display, and XML+XSLT is more powerful, more rigorous, and arguably more performant n…

> I remember back in the 2000s writing purely XML websites with stylesheets for display

Awesome! I made a blog using XML+XSLT, back in high school. It was worth it just to see the flabbergasted look on my friends faces when I told them to view the source code of the page, and it was just XML with no visible HTML or CSS[0].

[0] https://www.w3schools.com/xml/simplexsl.xml - example XML+XSLT page from w3schools

Post reply on HN