An ad blocker that lives inside the browser is trying to referee a fight from inside the ring. Bromure moves the referee to the network itself, where no page can reach, no script can touch, and no "anti-adblock" banner can argue with it.

Ad blocking is the single most popular browser feature that is not shipped in the browser. Hundreds of millions of people install a third-party extension on day one because the modern web is genuinely unusable without one. That, in itself, is a design smell. But the way almost every ad blocker works is worth paying attention to, because the architecture turns out to matter a lot — both for how well it works, and for what happens when the page actively tries to fight it.

This post walks through how an ad blocker usually works, why that shape has real limits, and how Bromure takes a different approach that borrows its core idea from a tool you may have heard of on a Raspberry Pi in someone's basement.

Ads are not just annoying. They are a loading problem, a privacy

problem, and an attack vector.

It is easy to forget, after a few years of ad blocking, what the raw web actually looks like. A popular news article, loaded without any filtering, will typically fetch resources from 30 to 80 third-party domains. Most of those are analytics, tracking pixels, and real-time bidding endpoints. They add weight, they add latency, they drop cookies on behalf of companies you have never heard of, and — as discussed in the ransomware post from earlier this month — they are one of the quiet delivery vehicles for malware, because ad networks occasionally get tricked into serving malicious creatives on legitimate sites.

What a single page visit actually pulls in, in 2026, without any filtering. The article you are reading is usually the smallest request on the page. Everything else is the machinery the article was wrapped in.

Blocking those requests is therefore not a cosmetic problem. It is a performance win, a privacy win, and — because ad networks are a regular malware distribution channel — an actual security win. The only question is how you block them.

How a typical browser extension blocks ads.

Almost every mainstream ad blocker, including the popular ones you have probably installed, is a browser extension. Which means that, architecturally, it lives inside the browser — it runs JavaScript inside the browser process, registers callbacks against the browser's networking APIs (webRequest, declarativeNetRequest), and inspects each request the browser is about to make.

How an extension-based ad blocker typically operates. The extension lives inside the browser. Every outgoing request is handed to it for approval; it blocks the ones whose URLs match its rules. The page and the extension share the same process and, in most cases, the same permissions.

That shape works — it is, after all, what most people rely on every day — but it has real structural limits:

The page can tell

Since the extension lives in the same process as the page, the page's own JavaScript can probe for it: "did my request actually go out? did this variable end up defined?" Entire sites (and most paywalled news outlets) detect missing requests and refuse to load without them, demanding the user "disable their ad blocker."

The page is in the same trust zone

The extension and the hostile page it is trying to filter share a browser process, a renderer, sometimes a set of permissions. A sufficiently bad browser exploit in the page disables the extension along with everything else. Extensions are code; they are also attack surface.

The request has already been born

By the time the extension sees a request, the browser has already decided to make it, parsed the URL, and (depending on API) performed the DNS lookup. Blocking at that stage is filtering, not prevention.

The filtering API keeps getting weaker

Chrome's Manifest v3 rewrite constrained what filtering extensions can do, chiefly by capping rule counts and replacing dynamic webRequest with declarativeNetRequest. The architecture of the extension API is set by the browser vendor, not by you.

How Bromure does it: the wall is not the extension.

Bromure's ad blocker is not an extension. The browser itself has no ad-blocking code at all. Instead, the network stack of the disposable Linux VM that the browser runs inside is the ad blocker — and from the browser's point of view, the ad domains simply do not resolve.

Inside a Bromure profile's VM, every outbound connection from the browser is routed through a local HTTP proxy. That proxy resolves every domain through a local DNS server whose 'no' list is a blocklist. If the domain is on the list, the browser gets an unreachable address and never makes the connection — the page's own scripts included.

Mechanically, two small, boring pieces of software do the work:

A local HTTP proxy (Squid)

Every outbound request from the browser is transparently routed through a Squid proxy running on localhost:3128 inside the VM. Squid is the plumbing: it does not decide what is an ad, it just does DNS resolution and forwarding for the browser.

A local DNS resolver (dnsmasq)

Squid is told to resolve every domain through a local dnsmasq instance on 127.0.0.1. dnsmasq's config includes a blocklist of around 100,000 domains — ad networks, trackers, analytics, known-malicious hosts. Anything on the list resolves to 0.0.0.0, which goes nowhere.

The result is a network that, from the browser's perspective, is internet-shaped except that ad and tracking domains have no DNS records at all. The browser asks for doubleclick.net, gets back "no route," and moves on. No connection is opened. No TLS handshake is attempted. No cookie goes anywhere, because there is no anywhere to send it to.

The same idea that has been running in basements for years.

If you have ever set up pi-hole, the small-box DNS sinkhole that a lot of people run on a Raspberry Pi to filter ads out of their entire home network, the Bromure architecture will feel deeply familiar. The underlying blocklist is Steven Black's unified hosts file, the same one those home installs have been running for years. The conceptual move is identical: do not try to remove ads from the page, just refuse to tell the browser how to find the ad's server in the first place.

The important difference is where the sinkhole lives. A household-wide sinkhole protects every device on the home network; a Bromure sinkhole protects exactly one browser profile. Turn it on for the profile you use to read news; leave it off for the profile where your bank would rather you not route through any unusual middleware.

What this actually buys you.

0.0.0.0.No network connection is opened.No TLS, no SNI, no HTTP request.Page cannot tell the difference from DNS failure.AD SERVER LEARNSnothing.There is no connection to observe.

Same page visit, different architectures. The extension lets the request begin and filters it at the last possible moment. Bromure refuses the question before it is ever asked. The ad server knows nothing about the Bromure user — not even that they tried.

The practical wins stack up:

Cannot be disabled by a compromised page

The blocklist is not code loaded by the browser; it is the browser's network. A renderer exploit, a hostile script, a misbehaving third-party library — none of them can reach the dnsmasq config, because none of them can reach out of the browser process to the VM's network stack.

Pages cannot see around it

The page's JavaScript can check navigator properties all day; it cannot see the DNS configuration of the network it is on, because that is not a thing JavaScript is allowed to know. To the page, a blocked ad looks exactly like an ad domain that went down for a minute.

No extension attack surface

Ad-blocker extensions have, on more than one occasion, been compromised — either through the extension store, through an acquisition, or through a malicious update. There is no such extension in Bromure to compromise, because there is no extension.

Per-profile, toggled like any other capability

Ad blocking is a per-profile setting ("Block Ads" in Privacy & Safety), off by default, on in whichever profiles you choose. Your banking profile stays unfiltered; your daily-reading profile is clean.

The honest limits.

Nothing in this space is free. A few things the network-layer approach deliberately does not do, and that you should know up front:

No cosmetic filtering

A classic extension can hide the empty box where a banner used to be. Bromure does not rewrite the page, so if the publisher reserved a 728×90 block, the block stays there, blank. It is a small cosmetic nuisance on a handful of sites, and the trade-off is that there is nothing in the page for a script to notice.

First-party ads survive

If a site serves its own ads from its own domain (the way some large tech platforms now do), domain-level blocking cannot distinguish "article" from "ad" — both live at the same hostname. This is a real gap; the answer, where it matters, is a content-script layer on top, which is work we are looking at.

Anti-adblock walls still detect absence

Some sites do not need to find the ad blocker. They just check whether a specific script loaded, and refuse to show the article if it did not. For those sites, any blocker — extension or network — will be caught. That is a policy argument with the publisher, not a technical one with the blocker.

The blocklist ships with Bromure

The gravity.list is baked in at image build time and updates when you update Bromure. It does not pull the newest rules every hour the way a dedicated always-on home sinkhole can. For a list based on hostnames, this is usually fine — ad domains do not turn over as fast as, say, malware domains — but it is worth knowing.

The shape of the thing.

The broader point is not that Bromure's ad blocker is magically better at matching rules than uBlock Origin. uBlock's rule engine is, in fact, more sophisticated. The point is about where the block happens. An extension is a polite referee asking the browser to please not load this thing. Bromure is the road the request would have traveled on, quietly closed off at the mouth of the freeway, before the driver ever got in the car.

Ad blocking in a sealed VM is not a new feature of Bromure; it is a consequence of the architecture that was there from day one. The network layer of every profile is its own small world. That world can have WARP in it. It can have a paid VPN. It can have a Tor transport. And it can have, for free, the same DNS sinkhole that has been quietly filtering ads in people's basements for years — installed, configured, and scoped to exactly the browser session you want it in.

If you want the long version, the blocklist is a plain text file shipped inside the VM image — you can inspect it directly at the next release and read every one of the hundred thousand domains that will quietly stop existing for your browser. If you just want the short one, open Privacy & Safety on any Bromure profile and flip "Block Ads" on. The road is already closed. You just have to drive.