Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

Post reply on HN
Print view View original

141–150 of 362 posts

Re: Google is killing the open web, part 2

#141

Post by glenstein »

Fileformat wrote: post #128
charcircuit wrote: post #64

>Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead. >This is a trillion-dollar ad company who has been actively destroying the open web for over a decade Google has both done more for and invested more into progressing…

I think that "market demands" is a bit of a misnomer. RSS was (and remains) too tech-y for the mainstream. If browser vendors had made it easy for mainstream users, would there have been as much "market demand"? Between killing off Google Reader and failing to support RSS/Atom, Google handed social media to Facebook et al.

Exactly, those changes which I believe were done at the time to create space for Google Plus (which I think in an alternative reality with some different choices and different execution could very well have been a relevant entrant into the social media space).

It involved driving a steak through the heart of Google reader. Perhaps the most widely used RSS reader on the planet, and ripple effects that led to the de-emphasis of RSS across the internet. Starting the historical timeline after those choices in summarizing it as an absence of market demand overlooks the fact that intentional choices were made on this front to roll it back rather than to emphasize it and make it accessible.

Re: Google is killing the open web, part 2

#142

Post by thayne »

Fileformat wrote: post #121
thayne wrote: post #52

I don't disagree that Google is killing the open web. But XSLT is a pretty weak argument for showing that. It is an extremely complicated feature that is very seldom used. I am very doubtful dropping support is some evil political decision. It is much more likely they just don't want to sink resources into maintaining something that is almost never used. For the specific use case of showing RSS and Atom feeds in the…

Of course built-in support for RSS would be better. But what are the chances of that happening?

Probably better than browser makers committing to maintaining an xslt library.

Re: Google is killing the open web, part 2

#143

Post by shadowgovt »

Okay, I was entertaining the author's position to a point, but I have to get off the train where they sing the praises of NPAPI.

Hey fam. I remember NPAPI. I wrote a very large NPAPI plugin.

The problem with NPAPI is that it lets people run arbitrary code as your browser. it was barely sandboxed. At best, it let any plugin do its level best to crash your browser session. At worst, it's a third-party binary blob you can't inspect running in the same thing you use to control your bank account.

NPAPI died for a good reason, and it has little to do with someone wanting to control your experience and everything to do with protecting you, the user, from bad actors. I think the author tips their hand a little too far here; the world they're envisioning is one where the elite hackers among us get to keep using the web and everyone else just gets owned by mechanisms they can't understand, and that's fine because it lets us be "wild" and "free" like we were in the nineties and early aughts again. Coupled with the author's downplaying of the security concerns in the XSLT lib, the author seems comfortable with the notion that security is less important than features, and I think there's a good reason that the major browser creators and maintainers disagree.

The author's dream, at the bottom, "a mesh of building blocks," is asking dozens upon dozens upon dozens of independent operators to put binary blobs in your browser outside the security sandbox. We stopped doing that for very, very good reasons.

Re: Google is killing the open web, part 2

#144

Post by dang »

Prequel:

Google is killing the open web - https://news.ycombinator.com/item?id=44949857 - Aug 2025 (181 comments)

Also related. Others?

XSLT RIP - https://news.ycombinator.com/item?id=45873434 - Nov 2025 (459 comments)

Removing XSLT for a more secure browser - https://news.ycombinator.com/item?id=45823059 - Nov 2025 (337 comments)

Intent to Deprecate and Remove XSLT - https://news.ycombinator.com/item?id=45779261 - Nov 2025 (149 comments)

XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 - Aug 2025 (146 comments)

Google did not unilaterally decide to kill XSLT - https://news.ycombinator.com/item?id=44987239 - Aug 2025 (128 comments)

"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (535 comments)

Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)

Re: Google is killing the open web, part 2

#145

Post by NewsaHackO »

_heimdall wrote: post #105
granzymes wrote: post #34

Earlier quoted context omitted.

The standards body is deprecating XSLT with support from Mozilla and Safari (Mozilla first proposed the removal). Not sure how you got from that to “Google is ignoring standards”.

There's a lot of history behind WhatWG that revolves around XML. WhatWG is focused on maintaining specs that browsers intend to implement and maintain. When Chrome, Firefox, and Safari agree to remove XSLT that effectively decides for WhatWG's removal of the spec. I wouldn't put too much weight behind who originally proposed the removal. It's a pretty small world when it comes to web specifications, the discussions l…

The issue is you can’t say to put little weight who originally proposed the removal if the other poster is putting all the weight on Google, who didn’t even initially propose it

Re: Google is killing the open web, part 2

#147

Post by rwmj »

zekica wrote: post #35
Aurornis wrote: post #16

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

I used it. It's an (ugly) functional programming language that can transform one XML into another - think of it as Lisp for XML processing but even less readable. It can work great when you have XML you want to present nicely in a browser by transforming it into XHTML while still serving the browser the original XML. One use I had was to show the contents of RSS/Atom feeds as a nice page in a browser.

I would just do this on the server side. You can even do it statically when generating the XML. In fact until all the stuff about XSLT in browsers appeared recently, I didn't even know that browsers could do it.

Re: Google is killing the open web, part 2

#148

Post by dpark »

croes wrote: post #140
Aurornis wrote: post #109

Earlier quoted context omitted.

> The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This is an attempt to rewrite history. Early browser like NCSA Mosaic were never even released as Open Source Software. Netscape Navigator made headlines by offering a free version for academic or non-profit use, but they wanted to charge as much a…

The web wasn’t the browser it was the protocols.

That’s not an accurate statement. The web was not just the protocols. It was the protocols and the servers that served them and the browsers that supported them and the web sites that were built with them. There is no web without browsers just like there is no web without websites.

Re: Google is killing the open web, part 2

#149

Post by lunar_mycroft »

gspencley wrote: post #66
lunar_mycroft wrote: post #38

Earlier quoted context omitted.

The fact that people didn't realize that a site used XSLT before the recent drama is meaningless. Even as a developer, I don't know how most of the sites I visit work under the hood. Unless I have a reason to go poking around, I would probably never know whether a site used react, solid, svelte, or jquery. But it ultimately doesn't matter either way. A major selling point/part of the "contract" the web platform has w…

> But it ultimately doesn't matter either way. A major selling point/part of the "contract" the web platform has with web developers is backwards compatibility. The fact that you put "contract" in quotes suggests that you know there really is no such thing. Backwards compatibility is a feature. One that needs to be actively valued, developed and maintained. It requires resources. There really is no "the web platform.…

> The fact that you put "contract" in quotes suggests that you know there really is no such thing.

It's in quotes because people seem keen to remind everyone that there's no legal obligation on the part of the browser makers not to break backwards compatibility. The reasoning seems to be that if we can't sue google for a given action, that action must be fine and the people objecting to it must be wrong. I take a rather dim view of this line of reasoning.

> The reason we have as much backwards compatibility as we do is largely historical and always driven by business goals and requirements, as dictated by customers.

As you yourself pointed out, the web is a giant pile of cobbled together technologies that all seemed like a good idea at the time. If breaking changes were an option, there is a _long_ list of potential depreciation to pick from which would greatly simplify development of both browsers and websites/apps. Further, new features/standards would be able to be added with much less care, since if problems were found in those standards they could be removed/reworked. Despite those huge benefits, no such changes are/should be made, because the costs breaking backwards compatibility are just that high. Maintaining the implied promise that software written for the web will continue to work is a business requirement, because it's crucial for the long term health of the ecosystem.

Re: Google is killing the open web, part 2

#150

Post by Mikhail_Edoshin »

Ygg2 wrote: post #73
zetafunction wrote: post #67

Earlier quoted context omitted.

https://issues.chromium.org/issues/451401343 tracks work needed in the upstream xml-rs repository, so it seems like the team is working on addressing issues that would affect standards compliance. Disclaimer: I work on Chrome and have occasionally dabbled in libxml2/libxslt in the past, but I'm not directly involved in any of the current work.

Wait. They are going along with a XML parser that supports DOCTYPES? I get XSLT is ancient and full of exploits, but so is DOCTYPE. Literally poster boy for billion laughs attack (among other vectors).

The billion laughs bug was fixed in libxml2 in 2008. (As far as I understand in .Net this bug was fixed in 2014 with .Net 4.5.2. In 2019 a bug similar to "billion laughs" was found in Go YAML parser although it was explicitly mentioned and forbidden by YAML specs. Among other products it affected Kubernetes.)

Other vectors probably mean a single vector: external entities, where a) you process untrusted XML on server and b) allow the processor to read external entities. This is not a bug, but early versions of XML processors may lack an option to disallow access to external entities. This also has been fixed.

XSLT has no exploits at all, that is no features that can be misused.

Post reply on HN