Why the banner is worse on a phone
The screen. A banner that takes a quarter of a desktop window takes half a phone. The text explaining the choice falls below the fold, so you scroll to read what you are agreeing to.
The number of taps. Europe’s data protection authorities catalogued the usual tricks: no reject button on the first layer, “Settings” as the only way out, boxes already ticked behind it (EDPB report, January 2023). On a desktop that’s one extra click. On a phone it’s a second screen, a list of toggles to thumb through, and a save button at the very bottom.
Apps. A good share of phone time happens outside the browser, where there is no extension to install and no banner setting to turn on. The consent question still exists there: France’s regulator devoted a whole recommendation to mobile apps, restating that refusing must be as easy as agreeing (CNIL recommendation on mobile apps, in French).
What your Android browser can do about it
Android browsers are not equivalent here, and the gap is wider than on a desktop.
| Browser | What it offers against banners |
|---|---|
| Chrome | No extensions. Its cookie settings are about third-party cookies, not consent pop-ups. |
| Samsung Internet | Content blockers, installed as separate apps and ticked inside the browser. |
| Brave | A built-in blocker, with a list aimed at consent notices, on by default. |
| Firefox | A catalogue of extensions, content blockers included. |
Firefox is the real “extension” answer on Android. It installs the extensions published on Mozilla’s add-ons site, and Mozilla presents it as the only major Android browser to open its catalogue that way (Mozilla, December 2023). Consent-O-Matic, the extension from Aarhus University researchers that fills in consent pop-ups according to your preferences, is among them (its Firefox for Android listing).
Samsung Internet takes content blockers, but they don’t live inside the browser: they are separate apps you install and then switch on in its menu, and they hand the browser filters in Adblock Plus format (Samsung’s developer guide). Brave, for its part, applies a consent-notice list by default, and says plainly what that means: it hides the notices and undoes what comes with them, scroll locks included — it does not answer them for you (Brave). The distinction matters, and we come back to it below.
What a DNS filter will never do
“Can Pi-hole block cookie pop-ups?” is a common question. The answer is no, and it holds for all of them: Pi-hole, NextDNS, AdGuard DNS, Android’s own Private DNS setting, or AdHole set up as a domain filter only.
A DNS filter sees domain names, not buttons. It answers “nowhere” when the phone asks for the address of an ad server, and the kit that meant to connect there has nothing to show. It works, and that is the whole of it: it never goes inside a page, it never clicks, and a banner drawn by the site itself arrives under the same domain name as the article you wanted to read. Refusing that name would mean refusing the site. Banners served by an outside consent tool are the one case where a name can be blocked, and blocking still isn’t refusing: at best the pop-up doesn’t appear, at worst the page waits for an answer that never comes.
Hiding isn’t refusing
Hiding a banner and refusing a banner don’t end in the same place.
When a cosmetic rule makes the pop-up vanish, the site gets no answer at all. Under EU rules, no answer should mean no consent, since nothing that needs consent may be set without it. Should. A refusal sent to the consent tool is recorded as a refusal: it leaves no room for interpretation, and the site remembers it on your next visit instead of asking again. Both approaches have their logic, they just aim at different things: hiding gets the pop-up out of your way, refusing answers the question it asks.
What reaches every browser on the phone
To click “Reject all” in any browser, something has to act inside the page. An extension can, in a browser that accepts extensions. Outside that, Android leaves one mechanism: a local VPN. The word sounds alarming; the mechanism is plain. The app asks Android to hand it the phone’s traffic, then opens the pages itself, on the device, with nothing going out to any server. Because it opens the page, it can act inside it: hide an ad slot, neutralise a script, click “Reject all”. That is what AdGuard for Android does, and what AdHole’s Android app now does too. There are two prices, and they belong before the install, not after.
A certificate you install yourself. To open an encrypted page, the app builds a certificate authority on the phone, and you install it in Android’s settings. Since Android 11 there is no automatic install: it is a handful of screens, done by hand. AdGuard, which has worked this way for years, publishes the same walkthrough (AdGuard’s documentation).
An app that sees your pages. Whatever opens your pages sees what is in them. That only makes sense with software where you know who publishes it, what it writes on the device, what it sends, and above all which sites it leaves alone.
One reassurance that is also a limit: since Android 7, apps no longer trust user-installed certificate authorities unless their developer explicitly opted in (Android Developers Blog). So a certificate you install opens nothing inside other apps. Nobody will be refusing a banner for you in there.
Where AdHole fits, and where it stops
AdHole’s Android app is a local VPN of this kind. The tunnel leads nowhere off the device: there is no publisher server, your IP address isn’t hidden, and nothing about your browsing reaches the publisher. It filters by domain name for every app. If you turn page cleaning on (it starts off) and install the certificate, it also cleans the pages opened in browsers: ad slots hidden, ad scripts neutralised, cookie banners removed. The engine is the computer’s, the lists not quite: the phone also loads AdGuard’s list dedicated to cookie banners. That list hides many of them, including those of very common consent tools, and a hidden banner gets no answer: the distinction from the section above applies here too. The others, the app refuses for you when the site offers to reject everything.
Its limits, stated plainly:
- Browsers, and nothing else. A connection that doesn’t come from a browser is relayed as it is, byte for byte. Ads in games and news apps stay what they were; only the domain filter reaches them.
- No guarantee against an “Accept”. AdGuard’s banner list also accepts cookies on some sites, well-visited French ones among them, by clicking “Accept” or recording consent. AdHole sets part of those requests aside, not all. And as on a computer, it can pick the wrong button. If your choice matters on a site, make it yourself.
- The certificate is installed by hand, in Android’s security settings: Encryption & credentials → Install a certificate → CA certificate (labels vary by manufacturer). Its private key is built on the phone and never leaves it: the publisher has no copy. Until it is installed, no page is opened, and the browser shows no certificate error.
- Uninstalling the app does not remove the certificate from Android’s store: you remove it by hand, in Encryption & credentials → User credentials.
- Firefox asks for one more setting, hidden in its settings, because it doesn’t use the user certificate store by default. Without it, Firefox shows a security warning when it opens a site, then AdHole leaves that site as it is for ten minutes; you can also untick Firefox in the filtered browsers.
- Some sites are never opened. Banks, payment, health, government services, encrypted messaging, game stores: a starting list leaves them encrypted, browser or not. You can read it, change it, and it isn’t complete: add your own sensitive sites.
- HTTP/3 is switched off for browsers while pages are being cleaned, otherwise nothing would be filtered. A page may load a little differently.
- Android 10 at least to tell which browser owns which connection. Below that, the connection is relayed as it is and pages aren’t cleaned.
- No guaranteed blocking rate. A site may look broken; a personal rule repairs it.
What gets through and what doesn’t is set out on what AdHole blocks and what it doesn’t; the install, screen by screen, on installing AdHole on Android.
What stays out of reach
- Banners inside apps. They aren’t pages opened by a browser, and nothing on the device is going to answer them for you. The only answer is yours, in the app.
- “Accept or pay” walls. By default AdHole doesn’t remove them; a setting, off to begin with, removes the ones it recognises, not all of them. Your call. On a few sites, the banner list hides or accepts them on its own, as said above.
- Articles reserved for subscribers. That isn’t a consent question, it’s a business decision. AdHole never removes a subscriber-only wall.
Sources checked on 5 October 2026 and linked in the text.