Hacker News Reader

Comment by Animats | Hacker News Reader

All this to support more ads per page.

All this is only a win mostly if you have a huge number of little assets from different sources. Ads, trackers, icon buttons, malware, etc. If it's all coming from one source, HTTP/2 is good enough. If it's mostly one big file, HTTP/1 is good enough.

View on HN

You are wrong. If you understand how browsers behave when they query a page that contains different resources from one source, and how head-of-line blocking works, you understand why so much effort was put into this protocol.

(Any introduction on QUIC will explain you these if you are interest.)

So, as a guy who is hellbent on not losing their ad blocking, are you telling me that QUIC allows the client (the browser in this case) to read from the stream up to a point, find a resource with a well-known name (or crypto hash) that is an ad/tracker, and the client is then allowed to just skip ahead in the stream, not downloading and never parsing the said ad/tracker?

If no, then QUIC has failed its purpose, for the tech-savvy browser users at least.

If yes, I'd be happy.

QUIC is just a way for a browser to make more HTTP-like connections in parallel more efficiently. It doesn't affect ad-blocking browser extensions. The browser can still implement the APIs for extensions the same way regardless of whether QUIC or a previous version of HTTP is used.

> All this to support more ads per page.

I'm also very afraid of the future of Web Assembly.

Both of these technologies i'm afraid aren't going to make things better, faster and more lightweight. They are just going to allow the bloat of the web to become worse without noticeable symptoms.

Who cares about the WebAssembly on the web? I'm looking forward to WebAssembly because it'll mean that Electron will become the new JRE: a lightweight, portable, feature-rich "full-fat GUI" application platform. ;)

This made me think of the problem of highways: the more lane you add, the more cars come to use your road and congestion is not reduced.

This is a problem with computers in general. For example IDEs and simple electron apps taking huge amounts of memory.

The problem with highways is called induced or latent demand. It’s a known problem in a lot of fields.

https://en.m.wikipedia.org/wiki/Induced_demand

It's the reverse of Moore's law:

https://en.m.wikipedia.org/wiki/Wirth%27s_law

I suspect more ads per page with less ability to block them is Google's endgame indeed.

But if browsers like Firefox find a way to skip ahead in the stream (through the ads/trackers while never downloading/parsing them in the first place) then things could be back to normal (for us the ad-blocker users).

Still though, if used for good, QUIC (or HTTP/3) seems like a pretty good piece of tech.

How does QUIC lead to "less ability to block them"?

I am not sure. But seems like the nature of the encrypted connection and the stream utilisation (akin to HTTP/2) would make it harder for something like e.g. your home PiHole to block ads at the DNS level -- or any other lower-level in your network before stuff hits the browser.

I should have worded my comment better. It wasn't a claim, it was more like a "I think Google wants this protocol to succeed for their own ulterior motives (serve ads and impede blockers), but is that what is actually going to happen?".

I mean, not directly. The ad team didn't get a team together and say "make a protocol that will get our ads to the browser quicker", it's likely a team made to "make the internet faster by solving problems with TCP", and it just happens that A. they're funded by ads and B. this speedup also happens to work in favor of ad delivery. Same for the other parts of the internet, like dynamic content [chrome, JS] and OS speed [android], they're making the entire internet faster which ends up including how fast they can push an ad.

You can't do much at the DNS level if everything comes from "google.com". Which seems to be where Google is going with this. One big multiplexed encrypted pipe between their browser and their servers, containing many streams. All pages are hosted by Google via AMP, all ads are hosted by Google, all tracking is performed through Google Tag Manager, and the power of add-ons to Google's browser is limited to prevent ad-blocking.

Reply on news.ycombinator.com