Hacker News Reader

Comment by staticassertion | Hacker News Reader

I genuinely don't see how DNS-over-http/quic is leading to unblockable advertisements. Adblocking extensions, which have got to account for at least 99% of all adblocking, don't work on DNS at all afaik - they work on already resolved hostnames?

View on HN

HOSTS files are the simplest and can already remove quite a bit of cruft, but what's effectively tunneling DNS in its own VPN will bypass that.

Ad blocking extensions are really a "last defense" and can be slowly lobotomised as they are under browser vendors' control.

You got it the wrong way around. Ad blocker extensions should be your first choice, this DNS blocking business is really for devices where that is not possible ("Smart" TV et al) and it's getting less effective by the day.

I assume DNS over Whatever will still respect the HOSTS file? I'd be really surprised to find otherwise, but would love to hear if that's the case! If you don't trust the browser you already have very little defense against ads, no? After all, the browser could always just resolve DNS itself.

HOSTS files may also be simplest (I totally disagree btw), but I can't imagine they're anywhere near the most common.

After all, the browser could always just resolve DNS itself.

That's exactly how DoH is being implemented, and it's why it has caused so much controversy.

Pretty sure Chrome has been using its own DNS resolver for ages. I don't see the issue either way.

> Pretty sure Chrome has been using its own DNS resolver for ages.

That is correct, the IPv6 probes are embedded in the Chromium source, and are removed by the Ungoogled Chromium and/or Inox patchset [1].

[1] https://github.com/Eloston/ungoogled-chromium/tree/master/pa...

How do they handle "enterprise" proxies that ban direct internet access? I probably should setup that at home.

Chrome itself always requests HTTP first, except for HSTS and their own pinned certificates list which is actually shipped within the source code.

That's also a major difference to Ungoogled Chromium, where UC will request "https://..." by default if you just enter the domain.

So in the case of Enterprise Proxies that have no locally force-installed cert to sniff on internet traffic will likely end up with HTTP-everywhere being used. But usually employers that encourage such bad practices also install their snakeoil MITM certificates locally.

Chrome respects HOSTS file modifications itself[0], but I'd still recommend a pi-hole with DOH set up[1].

0: https://i.judge.sh/chief/Spoon/notepad_fwyvP8v6li.png

1: https://docs.pi-hole.net/guides/dns-over-https/

Also, couldn't you just MITM the secure transport layer if you want to run a pihole?

Have you tried browsing through mitmproxy? I have. It works, mostly, but is quite unpleasant.

The ad data (text, layout, media) can still be hidden on the client, but AFAIK with QUIC you can push it to the browser regardless if it actually was requested.

No. QUIC is a transport protocol. Its purpose is roughly equivalent to TCP: provide a reliable byte stream transport over an unreliable datagram service (IP, though QUIC prepends a small UDP header mostly for compatibility with existing infrastructure).

You might be thinking of the HTTP server push functionality. That was introduced with HTTP/2 and has been deployed for years already over TCP transports (i.e. totally unrelated to QUIC).

Due to how advertising networks work, I'd be surprised if anyone used server push in the way you fear.

this thread is filled with some very very aggressive high level instigators, spouting wild outlandish grimdark fantasies that they in no way justify or explain.

there is such a poisonous mentality that has taken root, that is popular. no one at the ietf shares these delusional fears, & it's not because the ietf is a bought out shadow puppet. it's because in reality http3 brings what http2 brought but technically better which brought what http1 brought but technically better.

> spouting wild outlandish grimdark fantasies that they in no way justify or explain.

Did you have a good look at how the internet evolved in the last 15 years?

The IETF can invent HTTP/23 with DNS-over-whatever tomorrow, that doesn't change anything about the general state of the internet, which can best be summarized as a "burning pile of poop".

Do you really need any examples of how broken everything is? Do you really wonder that people have "grimdark fantasies" about what the "next cool web feature" will bring to us?

But this isn't supposed to be about us not liking how the internet has evolved over the last 15 years.

It's about HTTP/3.

Reply on news.ycombinator.com