Why an ad blocker is not enough
What a browser extension can and cannot protect, why that protection is shrinking, and what changes when the blocking moves into the network itself.
An ad-blocking extension is a genuinely good thing. It strips ads and trackers out of pages, it visibly speeds the web up, and it is one of the few privacy tools normal people actually install. Even the US cybersecurity agency CISA has recommended ad blocking as a defence, because malicious ads are a real infection route, not just an annoyance.
But it is worth being precise about what an extension is. It is a program running inside one browser, on one device, with exactly the powers that browser chooses to grant it. Its protection ends at the edge of that window — and lately, the powers have been shrinking too.
The ground moving under extensions
The most capable blocker ever built, uBlock Origin, no longer runs in the world’s most popular browser. Google’s Manifest V3 extension rules removed the deep request-blocking that made it work: Chrome began disabling it in late 2024, switched off the old extension platform for everyone in July 2025, and by mid-2026 had stripped out the last of the workarounds. The sanctioned replacement, uBlock Origin Lite, is honest about being less — capped filter lists and none of the dynamic filtering that caught the trackers that adapt.
Google’s stated reasons are security and performance, and they are not nothing. But it is also a company that makes the large majority of its money from advertising, deciding how much power ad blockers get. You do not need a conspiracy theory to find that arrangement uncomfortable — a conflict of interest is enough. (The full extension lives on in Firefox, which is one good reason Firefox still matters.)
The lesson is not “extensions are useless”. It is that protection which exists inside someone else’s product exists at their pleasure. If you want a layer nobody can switch off in an update, it has to live somewhere you control.
The question every device asks first
Before any device can talk to a tracker, it has to ask a question: where does tracker.example live? That lookup is DNS, and it is the closest thing the internet has to a phone book. Every connection from every app on every device starts with it.
Normally your ISP answers, or Google does — which is itself a complete diary of every service your household contacts. Run your own filtering resolver — AdGuard Home and Pi-hole are the well-known open-source options — and the question comes to you instead. For ordinary domains it answers normally. For the tens of thousands of known tracking and advertising domains on its blocklists, it answers: that lives nowhere.
- 01 a device asks a question "where does tracker.example live?" — every connection starts this way
- 02 the resolver is yours the question lands on the network's own filter, not your ISP's
- 03 known trackers get no answer the domain resolves to nowhere, so the request cannot even begin
- 04 everything else flows normally pages load as usual; the beacons simply never arrive
This happens below the browser, so it covers every device on the network — phones, TVs, consoles, the lot — with nothing installed on any of them.
The request does not get blocked so much as never born. And because this happens below the browser, it covers the devices no extension can reach: the TV that phones home about what you watch, the phone apps with their bundled analytics, the “smart” appliances, the guest’s laptop. Nothing is installed on any of them. They just get their answers from a phone book with the surveillance pages removed.
On this network that is exactly what runs: every device on the VPN gets its DNS answered by a self-hosted AdGuard Home instance, so the filtering travels with the device — the architecture is documented on /mesh. And if you are curious what your connection currently reveals — your address, your network, who is answering your DNS — ip.itzgee.com will show you, from the same vantage point any website has.
Being honest about the limits
Network filtering is not magic, and anyone selling it as total is selling.
It works on names, so it cannot touch ads served from the same domain as the content — YouTube’s ads come from YouTube, and no DNS answer can separate the two. It cannot tidy a page cosmetically the way an extension can. And a hostile device can try to sidestep it by carrying its own hard-wired DNS or tunnelling lookups inside encrypted web traffic — some TVs and gadgets genuinely do — which is solvable at the router, but only if you know to solve it.
So the honest answer is layers, not either/or. Network-level filtering as the floor, covering everything that connects. A real content blocker in the browser — on a browser that still permits a real one — for the page-level work DNS cannot do. Neither replaces the other; each covers the other’s blind side.
The difference is not technical so much as constitutional. An extension is permission, granted inside someone else’s software and revocable in an update. Your own resolver is infrastructure — and the last two years of browser history are a good argument for owning the floor.