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

311–320 of 362 posts

Re: Google is killing the open web, part 2

#311

Post by troupo »

dpark wrote: post #289
troupo wrote: post #262

Earlier quoted context omitted.

It's literal W3C policy: https://www.w3.org/TR/html-design-principles/#priority-of-co... --- start quote --- In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight…

I could argue that W3C didn’t follow that policy when they attempted to push xhtml, which completely inverts that priority order, as xhtml is bad for users and great for purity. But instead I’ll point out that W3C no longer maintains the html spec. They ceded that to the WHATWG which was spun by the major browser developers in response to the stagnation and what amounted to abandonment of html by the W3C.

Ah, that's true. While w3c still maintains a lot of standards, the intention to remove XSLT was sent to WHATWG.

I didn't look at all documents, but Working Mode describing how specs are added or removed doesn't mention users even once. It's all about implementors: https://whatwg.org/working-mode

Re: Google is killing the open web, part 2

#312

Post by dfabulich »

kuschku wrote: post #290
dfabulich wrote: post #286

Earlier quoted context omitted.

For RSS/Atom, you put this in the XML, right inside the document element (the element or the element): You can also put CSS in there, like this: * { color: red; } Or like this:

How's the support for the first option? If that reliably works, I'm gonna stop being angry, as it solved all my needs (and would allow polyfilling xslt anyway) On second thought, that wouldn't allow me to modify the DOM before it's being parsed, I'd have to wipe the DOM and polyfill the entire page load, right?

It works great in Chrome, Safari, and Firefox.

https://github.com/dfabulich/style-xml-feeds-without-xslt

Google has recommended a polyfill for XSLT ever since they announced their plan to remove it. https://developer.chrome.com/docs/web-platform/deprecating-x...

Re: Google is killing the open web, part 2

#313

Post by dfabulich »

LtWorf wrote: post #174
dfabulich wrote: post #31

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived…

No you can't, since opening an RSS feed won't run a javascript.

https://github.com/dfabulich/style-xml-feeds-without-xslt

Re: Google is killing the open web, part 2

#314

Post by dpark »

troupo wrote: post #311
dpark wrote: post #289

Earlier quoted context omitted.

I could argue that W3C didn’t follow that policy when they attempted to push xhtml, which completely inverts that priority order, as xhtml is bad for users and great for purity. But instead I’ll point out that W3C no longer maintains the html spec. They ceded that to the WHATWG which was spun by the major browser developers in response to the stagnation and what amounted to abandonment of html by the W3C.

Ah, that's true. While w3c still maintains a lot of standards, the intention to remove XSLT was sent to WHATWG. I didn't look at all documents, but Working Mode describing how specs are added or removed doesn't mention users even once. It's all about implementors: https://whatwg.org/working-mode

The principles covers more about users. But it still does not set the same priority hierarchy as W3C.

https://whatwg.org/principles

I’m not surprised they focus on implementors in “working mode”, though. WHATWG specifically started because implementers felt like the W3C was holding back web apps. And it kind of was.

WHATWG seemed to be created with an intent to return to the earlier days of browser development, where implementors would build the stuff they felt was important and tell other implementors how to be compatible. Less talking and more shipping.

Re: Google is killing the open web, part 2

#315

Post by pjmlp »

jillesvangurp wrote: post #47
nwellnhof wrote: post #20

Removing XSLT from browsers was long overdue and I'm saying that as ex-maintainer of libxslt who probably triggered (not caused) this removal. What's more interesting is that Chromium plans to switch to a Rust-based XML parser. Currently, they seem to favor xml-rs which only implements a subset of XML. So apparently, Google is willing to remove standards-compliant XML support as well. This is a lot more concerning.

> This is a lot more concerning. I'm not so sure that's problematic. Probably browser just aren't a great platform for doing a lot of XML processing at this point. Preserving the half implemented frozen state of the early 2000s really doesn't really serve anyone except those maintaining legacy applications from that era. I can see why they are pulling out complex C++ code related to all this. It's the natural conclus…

This is C code, https://gitlab.gnome.org/GNOME/libxslt

Re: Google is killing the open web, part 2

#316

Post by ErroneousBosh »

koakuma-chan wrote: post #253
ErroneousBosh wrote: post #111

Earlier quoted context omitted.

Did you do any work besides taking screenshots and trying to figure out why FTP was broken this time? Your old job's broken workflow is not a good reason for keeping a fundamentally broken protocol that relies on allowing Remote Code Execution as a privileged user around.

I wrote a tool that took screenshots automatically and used FileZilla to upload :) And my comment is in support of removing FTP because it was lame.

Aha, fair. Why the hell did they need you to do that?

I used to work in a web dev job where when they brought in "time tracking" they wanted everyone to update a spreadsheet with what they were doing every half an hour. A spreadsheet, as literally a .xls, on a shared Windows drive. Everyone spent more time waiting for access to the spreadsheet than they did doing any work.

This situation persisted for about two weeks, and the manager that came up with the genius idea about two weeks longer than that, before we eventually told the other managers we were downing tools and leaving if he didn't either get "promoted to customer" or lay off the charlie during work hours.

Re: Google is killing the open web, part 2

#317

Post by ErroneousBosh »

kuschku wrote: post #255
ErroneousBosh wrote: post #254

Earlier quoted context omitted.

> Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares. > It's the same content, just supplied in a different format. It should be the same URL. So what do I put as the URL of an MP3 an…

> The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares. Just like protocol negotiation, HTTP has format negotiation and XML postprocessing for exactly the same reason. > So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format Whate…

> Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.

So, you need a lot of cleverness on the browser to detect which format the client needs, and return the correct thing?

Kind of not the same situation as emitting an XML file and a chunk of XSLT with it, really.

If you're going to make the server clever, why not just make the server clever enough to return either an RSS feed or an HTML page depending on what it guesses the client wants?

Re: Google is killing the open web, part 2

#318

Post by ErroneousBosh »

altmind wrote: post #266
ErroneousBosh wrote: post #107

Earlier quoted context omitted.

"Was" is the key here. FTP has been obsolete for 20 years.

People are confusing obsolete with stable and feature complete.

Right, but ftp is neither of these things.

Can you describe any real-world application where ftp is the best solution for a problem anyone has right now?

Consider the impact of an internet-exposed service that allows unauthenticated clients to remotely run code as root on your server.

Re: Google is killing the open web, part 2

#319

Post by Ygg2 »

fabrice_d wrote: post #136
Ygg2 wrote: post #73

Earlier quoted context omitted.

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 attack has well known solutions (basically, don't recurse too deep). It's not a reason to not implement DOCTYPE support.

> The billion laughs attack has well known solutions (basically, don't recurse too deep)

You can then recurse wide. In theory it's best to allow only X placeables of up to Y size.

The point is, Doctype/External entities do a similar thing to XSLT/XSD (replacing elements with other elements), but in a positively ancient way.

Re: Google is killing the open web, part 2

#320

Post by Ygg2 »

Mikhail_Edoshin wrote: post #150
Ygg2 wrote: post #73

Earlier quoted context omitted.

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…

> Other vectors probably mean a single vector: external entities,

XXE injection (which comes in several flavors), remote DTD retrieval, and quadratic blowup (a sort of twin to the billion laughs attack).

You aren't wrong though. They all live in Why process it at all? If this is as security focused as Google claims, fill the DOCTYPE with molten tungsten and throw it into the Mariana Trench. The external entities definition makes XSLT look well designed in comparison.

Post reply on HN