Live data from Hacker News

Removing XSLT for a more secure browser

developer.chrome.com

191–200 of 352 posts

Re: Removing XSLT for a more secure browser

#191
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.

[deleted]

Re: Removing XSLT for a more secure browser

#192

Earlier quoted context omitted.

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…

The license would be relevant if I'd claimed that removing XSLT was illegal or opened them up to lawsuits, but I didn't. The obligation they took on is social/ethical, not legal. By your logic, chrome could choose to stop supporting literally anything (including HTML) in their "browser" and not have done anything that we can object to.

iIRC, lack of IE compatibility is fundamentally different, because the IE specific stuff they didn't implement was never part of the open web standards, but rather stuff Microsoft unilaterally chose to add.

Re: Removing XSLT for a more secure browser

#193

Earlier quoted context omitted.

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…

The license is the way it is not by choice. We should be clear about that and acknowledge KHTML, and both Safari and Chromium origins. Some parts remain LGPL to this day.

Re: Removing XSLT for a more secure browser

#194

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…

"Java is a big DSL to transform XML into stacktraces"

https://news.ycombinator.com/item?id=26663191

XSLT (or ANT) may be Turing complete, but it's firmly embedded in the Turing Tarpit.

https://en.wikipedia.org/wiki/Turing_tarpit

>"54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis

Re: Removing XSLT for a more secure browser

#195
post #147
post #138

Earlier quoted context omitted.

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

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

So no. Some major websites don’t actually work for you.

> And that's why webshit is webshit.

I don’t understand this statement. Webshit is webshit because the platform grew beyond basic html docs? At some point this just feels like hating on change. The web grew beyond static html just like Unix grew beyond terminals.

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

If this is the archetype of the person who turns off JS then I would bet the real percentage is way less than 1%.

Re: Removing XSLT for a more secure browser

#196

Earlier quoted context omitted.

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.

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

No, I'm not (and I keep saying this explicitly) saying that browsers should or should not do anything, or be responsible for anything. I’m not making a normative argument, at all.

I am stating, descriptively, that browser vendors choosing to remove XSLT functionality rather than repairing it by using an alternative implementation is very directly contrary to the claim made upthread that “XSLT isn’t going anywhere”. It is being removed from the the most popular application platform in existence, with developers being required to bring their own implementation for what was previously functionality supported by the platform. I am not saying that this is good or bad or that anyone should or should not do anything differently or making any argument about where responsibility for anything related to this lies.

Re: Removing XSLT for a more secure browser

#197
post #138

Earlier quoted context omitted.

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

People used to download way more questionable stuff and run it. Remember shareware? Remember Sourceforge? (Remember also how Sourceforge decided to basically inject malware that time?)

I used to help friends and family disinfect their PCs from all the malware they’d unintentionally installed.

Re: Removing XSLT for a more secure browser

#198

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…

Some people seem to think XSLT is used for the step from DOM -> Graphics. This is not the first time I have send a comment implying that, but it is wrong. XSLT is for the step from 'normalized data' -> DOM. And I like it, that this can be done in a declarative way.

Re: Removing XSLT for a more secure browser

#199
post #34

Makes me kind of sad. I started my carrier back in days when XHTML and co were lauded as the next thing. I worked with SOAP and WDSLs. I loved that one can express nearly everything in XML. And namespaces… Then came json and apart from being easier to read for humans I wondered why we switch from this one great exchange format to this half baked one. But maybe I’m just nostalgic. But every time I deal with json parse…

[deleted]

Re: Removing XSLT for a more secure browser

#200
post #94

Earlier quoted context omitted.

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

I don't see how this makes the "JS availability should be the baseline" assumption any more legitimate. We make it possible to function in a society for those 6% of people. Low percentage still works out to a whole lot of people who shouldn't be left out.

I disagree. The world is under no obligation to cater to a tiny minority who self-select into reduced-functionality experiences.

It’s fine for you to turn off JS. It’s also fine for developers to require JS. Software has had minimum system requirements forever. I can’t run Android apps on my Palm Pilot from 2002 either and no one is obligated to make them work for me.

Post reply on HN