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

221–230 of 352 posts

Re: Removing XSLT for a more secure browser

#221

Post by cxr »

shadowgovt wrote: post #81
cxr wrote: post #36

Earlier quoted context omitted.

> They all agreed to remove it. All those people suck, too. Were you counting on a different response? > XSLT is extremely unpopular and worse than JS in every way This isn't a quorum of folks torpedoing a proposed standard. This is a decades-old stable spec and an established part of the Web platform, and welching on their end of the deal will break things, contra "Don't break the Web".

You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.

Do you still beat your wife? https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife?>

Re: Removing XSLT for a more secure browser

#222

Post by willseth »

zzo38computer wrote: post #176

XSLT seem like it could be something implemented with WebAssembly (and/or JavaScript), in an extension (if the extension mechanism is made suitable; I think some changes might be helpful to support this and other things), possibly one that is included by default (and can be overridden by the user, like any other extension should be); if it is implemented in that way then it might avoid some of the security issues. (P…

The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.

Re: Removing XSLT for a more secure browser

#223

Post by pjmlp »

wryoak wrote: post #204
Fileformat wrote: post #164

Earlier quoted context omitted.

You are probably right, but it is depressing how techies don't see the big picture & don't want to provide an on-ramp to the RSS/Atom world for newcomers.

Google is widely faulted with effectively killing RSS by pulling the plug on Reader (I, for example, haven’t used RSS since), so I don’t think they’re missing the big picture, I think they just prefer a different picture

I never got the backslash with Reader, having always used native apps to handle RSS.

Re: Removing XSLT for a more secure browser

#224

Post by shadowgovt »

jeffbee wrote: post #91
Fileformat wrote: post #66

Earlier quoted context omitted.

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

Good user-facing software tends to have a coherent vision, and that involves getting features cut that people put a lot of time and effort into; even though those features have value, it's possible they don't have value in the product under development.

I don't really have enough context to say whether that was the case here. Mostly I'm raising the comment to note that this is an issue in commercial software too, but the sting is immediately moderated by "At least you got paid." It's a lot easier to see one's work fail to be reflected in the finished product when you can dry your tears with the bills in your money-pile (and I don't know how open source competes in things as cut-throat and taste-opinionated as UI when that continues to be true without solving the problem by injecting money into the process, which carries its own risks).

Re: Removing XSLT for a more secure browser

#225

Post by willseth »

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!

It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.

Re: Removing XSLT for a more secure browser

#226

Post by shadowgovt »

wryoak wrote: post #204
Fileformat wrote: post #164

Earlier quoted context omitted.

You are probably right, but it is depressing how techies don't see the big picture & don't want to provide an on-ramp to the RSS/Atom world for newcomers.

Google is widely faulted with effectively killing RSS by pulling the plug on Reader (I, for example, haven’t used RSS since), so I don’t think they’re missing the big picture, I think they just prefer a different picture

It's probably worth considering that if the technology could be killed by one company pulling its chips off the board, perhaps the technology wasn't standing on its own.

We still use RSS and Atom feeds for podcasts. It's a pretty widely-adopted use case. Perhaps there is a lot more to the contraction of RSS as a way for discovering publishing of "blog"-style media than "Reader got killed" (it seems like Reader offered more features than just RSS consolidation that someone could, hypothetically, build... But nobody has yet?).

Re: Removing XSLT for a more secure browser

#227

Post by willseth »

phendrenad2 wrote: post #32

Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.

"[Y]ou're welcome to fork Chromium or Firefox" is the software developer equivalent of saying "you're welcome to go fuck yourself."

Re: Removing XSLT for a more secure browser

#228

Post by wryoak »

pjmlp wrote: post #223
wryoak wrote: post #204

Earlier quoted context omitted.

Google is widely faulted with effectively killing RSS by pulling the plug on Reader (I, for example, haven’t used RSS since), so I don’t think they’re missing the big picture, I think they just prefer a different picture

I never got the backslash with Reader, having always used native apps to handle RSS.

Native apps are always better, but having a web page syncing your feeds made it easier to access them, eg from the library or work computer. Not to mention nothing to install (or update) reduces friction. I didn’t have to stop using RSS, but the newly exposed hurdles were enough discouragement that I did stop

Re: Removing XSLT for a more secure browser

#229

Post by shadowgovt »

cxr wrote: post #221
shadowgovt wrote: post #81

Earlier quoted context omitted.

You can continue to use XSLT server-side to emit HTML if you are deeply, deeply concerned about the technology.

Do you still beat your wife? https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife? >

I don't think that applies here (especially since I didn't even ask a question).

"I'm sad it's going away in the client!"

"So move it to the server, and the end-user will get essentially the same experience."

Am I missing something here?

Re: Removing XSLT for a more secure browser

#230

Post by jiggawatts »

geocar wrote: post #179
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…

> One extremely important... Not to downplay what you think is important, but I think it's pretty important that governments and public bodies use XSLT. https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BIL... https://www.weather.gov/xml/current_obs/KABE.xml https://www.europarl.europa.eu/politicalparties/index_en.xml https://apps.tga.gov.au/downl…

> “They don't put ads on their sites, so I'm not surprised…”

Similarly, Chrome regularly breaks or outright drops support for web features used only in private enterprise networks. Think NTLM or Kerberos authentication, private CA revocation list checking, that kind of thing.

Again, nobody uses Google Ads on internal apps!

Post reply on HN