Ad blockers and what they cannot block

Ad blockers are one of the few privacy tools that people install without being talked into it. The page loads faster, the layout stops jumping around, and the sidebar full of flashing garbage disappears. That’s a real, immediate benefit. But “blocks ads” and “stops tracking” are not the same claim, and a lot of people quietly assume the second one comes free with the first. It doesn’t. Understanding where the gap is matters more than picking a specific extension.

How ad blockers actually work

Most browser-based ad blockers, uBlock Origin being the most common example, work off filter lists like EasyList and EasyPrivacy. These lists are just large collections of rules: block requests to this domain, hide this CSS element, strip this script tag. When your browser tries to load a page, the extension checks each outgoing request against the list and blocks the ones that match known ad servers or tracker domains.

DNS-level blockers like Pi-hole or NextDNS work a step earlier, at the point where your device asks “what’s the IP address for adserver.example.com” and gets no answer, so the connection never opens at all. This catches ads and trackers across every app on the network, not just the browser, which is a real advantage over an extension.

Both approaches share the same core weakness: they only work against things that show up on a list of known bad domains and patterns. If the request doesn’t look like what the list expects, nothing gets blocked, no matter how much tracking that request is doing.

First-party tracking and domain cloaking

A lot of modern tracking is deliberately built to not look like tracking. The clearest example is what’s usually called CNAME cloaking. Instead of a tracker running on trackerco.com, a site sets up a subdomain like stats.thesitename.com that uses a CNAME DNS record pointing back to the tracking company’s infrastructure. To a blocklist, that request looks like first-party traffic to the site you’re already on, because technically it is going to a subdomain of that site. The actual data still ends up with the third party running the backend, but the domain-matching approach that filter lists depend on can’t tell the difference without risking breaking the site itself.

Publishers also just run analytics scripts as first-party code bundled with core site functionality. Blocking the request means the page breaks, so blockers either whitelist it or leave it alone. This isn’t a bug in any particular blocker; it’s a structural limit of deciding what to block based on where a request goes rather than what it does.

Fingerprinting doesn’t need a request to block

Filter lists are built around blocking connections. Browser fingerprinting mostly doesn’t need a new connection at all. Canvas fingerprinting draws an invisible image and reads back subtle rendering differences caused by your GPU, drivers, and font set. Audio context fingerprinting does something similar with how your device processes a silent tone. Font enumeration checks which fonts are installed. None of this requires talking to a blocked domain, it’s all happening inside the page you already loaded, using APIs the browser exposes by design for legitimate reasons like rendering text and graphics.

Some ad blockers, uBlock Origin included, have added specific rules to interfere with known fingerprinting scripts, but this coverage is necessarily partial and reactive. A script has to be identified and added to a list before it can be blocked, and fingerprinting techniques don’t need a recognizable domain the way ad requests do. This is a different threat model than ad-blocking was designed to solve, and no filter list closes it completely.

Native apps are a separate environment

Everything above assumes you’re in a browser. A browser extension has no reach into a native mobile app. If you’re using a banking app, a social media app, or a game, any tracking SDK built into that app, common ones include mobile ad SDKs from major ad networks, communicates directly over its own encrypted connection that a browser extension never sees, because it isn’t in the browser at all.

System-wide DNS blockers do reach into apps, since they operate at the network level rather than inside a specific browser. But even then, they’re only blocking connections to domains already known to be tracking infrastructure. An app that bundles its analytics call into the same connection as core functionality, or that talks to a first-party server which then quietly relays data onward, isn’t stopped by a DNS list either.

Being logged in tells the platform who you are

Ad blockers block requests, not accounts. If you’re logged into Google, Facebook, or Amazon in another tab, or even just persistently logged in on your phone, those companies don’t need a tracking cookie to connect your activity to you: your account itself is the identifier. Visiting a page with an embedded YouTube video, a “share on Facebook” button, a Google Font, or a reCAPTCHA widget can all involve a request to that company’s servers, and being logged in changes what that connection means, even where the underlying script isn’t doing anything a blocklist would flag as malicious.

This is worth being specific about because it’s not a flaw in any ad blocker. It’s a different mechanism entirely, tied to authentication rather than tracking scripts, and no filter list is designed to intercept it.

Server-side ad insertion has nothing to intercept

Some video platforms and ad-supported streaming services now stitch ads directly into the video stream on the server before it ever reaches your device, rather than loading the ad as a separate request your browser makes afterward. From the client’s perspective, there’s just one continuous stream of video. There’s no separate “ad request” for a blocker to see and drop, because the ad and the content arrived as the same file. This is a growing practice specifically because it sidesteps client-side blocking, and it’s a structural response to how ad blockers work rather than a workaround for a specific product.

Data that already exists doesn’t need a new connection

Even a perfectly maintained blocklist only affects what happens on your device going forward. Ad networks and data brokers that already hold profile data on you, built from your browsing history before you installed a blocker, from other devices you own, from loyalty programs, or from purchased data, can still use that data for targeting through channels a browser extension never touches, like matching a hashed email address you gave one company against an ad account elsewhere. Blocking new tracking requests doesn’t retroactively remove data that was already collected and sold.

What ad blockers are actually good at

None of this means ad blockers are pointless, and it’s worth saying plainly what they do well: they cut a huge volume of known ad-serving and tracking domains, they reduce exposure to malvertising, where malicious code is delivered through legitimate-looking ad networks, and they make browsing measurably faster and less cluttered on most sites. That’s a real, useful outcome on its own.

The mistake is treating an ad blocker as a general privacy solution rather than what it actually is: a filter against a specific, list-matched category of requests. A realistic privacy setup usually layers a few things aimed at different problems: an ad blocker for ad and tracker domains, encrypted DNS or a trustworthy DNS resolver for query privacy from your ISP, careful account hygiene for the login-based tracking a blocklist can’t touch, and an honest sense of which of these problems actually apply to your situation. No single tool in that stack, ad blocker included, closes every gap on its own, and being clear about which gap each one actually covers is what makes the rest of the setup worth the effort.

If you want more breakdowns like this, of what a given privacy tool actually does under the hood and where its edges are, you can find the rest of our explainers on The Privacy Wire.