Mostly Harmless (Unless You Block Ads)

There is a particular flavour of dread that arrives when a security researcher says "I found a domain on my home network I couldn't explain, so I pulled the thread." It usually ends in a CVE, a botnet, or a ransomware group with an unnecessarily jaunty name. Occasionally, though, it ends somewhere far more mundane and far more annoying: a perfectly legal advertising company that has been quietly deciding what to store on your computer for over a year, while its client's privacy policy insists, in writing, that it stores nothing at all.

That is the shape of the story a friend of mine, a researcher called Jamie Moles, wrote up this week, in two posts that I would encourage anyone who has ever clicked "I agree" without reading it to go and read in full (part one and part two). I am going to translate it out of packet-capture into plain English, because the details matter, and because the details are also both hilarious and horrifying at the same time. Somewhere Marvin the Paranoid Android is nodding slowly.

 

A domain called bigwetbrush.com

Jamie noticed his home network sensor logging a DNS request, every 301 seconds, day and night, to a domain called bigwetbrush.com. Not a typo, not a phishing domain dressed up to look official, just a slightly whimsical name that used to belong to an American watercolour painter. The domain had been recycled, dressed with a bit of filler text about carpet cleaning so it would look like a going concern to anyone scanning it, and pointed at a Google Cloud load balancer with a DNS time-to-live of twenty seconds. That last detail is the only reason any of this got noticed at all: a sensible cache lifetime would have let it hide in the resolver forever.

Chasing the process, the tab, and eventually the JavaScript itself, Jamie found a script that identifies itself internally, without much shame, as belonging to a company called Admiral. Admiral is a real, US-based advertising technology vendor (trading as Leven Labs, Inc. out of Gainesville, Florida) whose actual, legitimate business is selling "adblock recovery" software to publishers: detect that a reader is blocking ads, then nag, throttle, or paywall them until they either turn the blocker off or pay up. There is nothing inherently sinister about that idea. Plenty of publishers have a defensible case for it. The problem, as it turns out, is what the script actually does once it is running, and what the site it runs on tells its readers it does.

The publisher in this case is the Telegraph, one of the UK's larger subscription newspapers, and Jamie is a paying subscriber. That detail matters, because it means the people quietly getting profiled here are, in no small number of cases, the people already paying for the privilege of reading the news.

 

What the script actually does

The detection battery, once decoded, is impressively thorough. It plants around eighty invisible "bait" elements on the page carrying CSS selectors lifted straight out of the filter lists used by uBlock Origin, AdGuard, Adblock Plus and friends, then checks which ones got hidden. It fingerprints eleven separate ad-tech and analytics libraries to see whether a blocker has quietly stubbed them out with an empty function pretending to be the real thing. It checks whether you're running Brave by name. It hunts for a rival anti-detection tool called AdShield by checking whether core browser functions have been tampered with, and if it thinks they have, it opens a hidden iframe and lifts clean, untampered functions out of that iframe to route around the interference. There is also, tucked into the same selector list as the ad-blocking checks, a set of tests for whether you are blocking cookie-consent banners and Google's "One Tap" sign-in prompt. Not adverts. Consent tools.

None of that runs if you're not blocking anything. Which brings us to the joke that isn't funny once you think about it for more than a second: a second module, on the same domain, loads only if the detector concludes you are running a blocker. Its entire job is to work out which one, by name, along with any VPN or anti-malware browser extension you have installed. NordVPN and Malwarebytes Browser Guard are both explicitly on its checklist. Neither of those is remotely an ad blocker. One protects your traffic, the other watches for malware. Both got enumerated anyway, because both happen to interfere with something the script is testing for.

The people subjected to the most detailed profiling, in other words, are precisely the people who took active, deliberate steps to avoid being profiled. I have spent over thirty years watching organisations build incentive structures on purpose and by accident, and I have rarely seen one this neatly inverted: the more effort you put into protecting your privacy, the more closely you get watched for having done so.

 

And then there's the small matter of the privacy policy

Here is where this stops being merely clever and becomes, in the technical and increasingly expensive sense of the word, a problem.

The Telegraph's own published cookie and privacy policy, in the section covering ad-blocker detection, states plainly: "By detecting ad blockers, we do not store any information on your device and we do not process any of your personal data."

What Jamie measured, sitting on his own machine, was four cookies set on the Telegraph's own domain with a lifespan of 395 days (the maximum Chrome will accept), two localStorage entries, and a session-storage buffer. The payload posted back to bigwetbrush.com on every page view included the page URL, the full referrer with query string intact, the article's title, description, author and up to fifty scraped keywords, every UTM tracking parameter, the timezone offset, consent identifiers, and a full profile of which blocker and filter lists you're running, alongside the IP address and browser fingerprint that ride along with any web request anyway.

That is not "no information." That is a fairly complete dossier. Admiral itself is named nowhere in the Telegraph's policy, and neither is bigwetbrush.com or its two sibling domains (merequartz.com and succeedscene.com, used for a tracking pixel and a fallback loader respectively). Which is odd, because the same policy is perfectly happy to name Google, Facebook, LiveRamp, Sourcepoint and half a dozen other vendors by name elsewhere. This is not a document allergic to naming names. It simply doesn't name this one.

So Jamie went and read Admiral's own privacy policy too, on the theory that maybe the disclosure lives there instead. It doesn't. Admiral's policy covers Admiral's own website and CRM, its own sign-up forms, its own Stripe billing, and closes with the line "this policy relates solely to this Application." There is, per Jamie's careful reading of both documents, no published notice anywhere that actually covers what happens to a reader on a page where Admiral's tag is running. One document says the processing doesn't happen. The other doesn't mention that it does. Between the two of them sits a fairly large, silent gap, occupied by your data.

Under the UK's Privacy and Electronic Communications Regulations (PECR), storing anything on a reader's device requires informed consent, and that gap is not a technicality. If the controller has told you in writing that nothing is stored, you cannot meaningfully have consented to the four cookies that were, in fact, stored. There is no informed consent to be found, because the information given to form that consent was wrong. It is exactly the sort of gap the UK's data protection regulator, the Information Commissioner's Office, exists to close.

 

 

How many sites are we talking about?

This is the part I want to be careful with, because precise figures for Admiral's deployment footprint aren't public, and I'm not going to invent them. What is public: Admiral's own blog has, at various points, publicised milestones of hundreds of billions of ad impressions "monitored and protected" through its platform, and the company describes its customer base as running to thousands of publishers worldwide, from major mastheads down to niche regional titles. That is Admiral's own marketing, not an independent audit, so treat it as an upper-bound vibe rather than a number to cite in a filing. But even taken conservatively, a company operating at that scale, deploying the same "one-tag" script architecture across its whole customer base, is not a boutique concern. If the pattern Jamie found on the Telegraph is structural to how the tag is configured, rather than a one-publisher misconfiguration, the interesting question is not "is this happening on one site" but "how many of those thousands of sites have a section 8.2 that says the same thing this one does."

That is precisely the kind of question a regulator, or a sufficiently annoyed journalist with a FOI template, is rather well placed to answer, and I doubt this remains one.

 

An open message to the people who cover this for a living

I have watched Meta get walked through the EU's regulatory machinery for cross-border data transfer failures and come out the other side considerably lighter in the wallet, to the tune of a €1.2 billion fine in 2023, still the largest GDPR penalty issued to date, imposed off the back of the Court of Justice of the EU's Schrems II ruling. GDPR's maximum is 4% of global annual turnover, and Europe's regulators and courts have shown no particular reluctance to reach for it when a controller's stated practices and its actual practices part company this visibly. I am not a lawyer, and nothing in this post should be read as a legal conclusion about anyone's guilt. But I have been around long enough to recognise the early shape of a case, and this has it: a documented discrepancy between policy and behaviour, a named vendor, an undisclosed data flow to a third country, and now a formal subject access request and complaint already in the DPO's inbox. Somewhere out there, a firm of media and data protection lawyers is about to have a very good year, and I don't think it will be the publisher's shareholders footing the celebratory dinner.

 

What to actually do about it

If you want the practical version rather than the outraged one: open your browser's developer tools on a news site you subscribe to, filter the network tab for a domain you don't recognise, and see what shows up about ninety seconds after the page loads. If you keep DNS logs at home, and I'd wager a fair few readers of this blog do, sort for a domain queried on a metronomic interval by a small number of devices, with nothing else queried around it, resolving over QUIC rather than plain HTTPS. That signature will outlive bigwetbrush.com specifically; Jamie has already watched the whole set of domains rotate once, within 48 hours of his first post going up. The behaviour is durable even when the hostnames aren't.

And if you find it, tell someone who can do something with it. Preferably someone with a masthead, a legal budget, and a healthy appetite for asking a company that fingerprints your VPN why its client's privacy policy says it doesn't.

Don't panic. Do, however, check what's talking to bigwetbrush.com.

All Posts