Coherence is the whole game: an antidetect browser teardown

Pass every "am I a bot" check and you can still be trivially unmasked — not because a signal was faked, but because two honest-looking signals contradict each other. We ran four representative antidetect browsers through the same detector on the same US residential proxy. Every one of them had at least one coherence break. Here's the teardown, and what it takes to stay consistent.

Coherence beats coverage

Modern fingerprinting doesn't just collect values — it cross-checks them. Does the WebGL renderer match the claimed OS? Do the fonts match the locale? Does the timezone match the exit IP? A profile can be internally "clean" on every individual axis and still scream farm the moment two axes disagree.

Four real coherence breaks

A US persona that leaks a Chinese system font

Three of the four browsers we tested exposed Microsoft YaHei UI in their platform-hint fonts — a Chinese Windows system font — while presenting as a US English user. The underlying build machine was Chinese; the persona was American; the two didn't match. A custom probe that reads the system UI font catches this instantly. The fix is to normalize the UI font to the persona's platform default (Segoe UI for a US Windows profile) and to control the enumerable font set so real-machine CJK fonts like SimSun don't leak under aggressiveoffsetWidth enumeration.

A 2008 GPU running Chrome 139

One commercial browser reproduced its claimed GPU's entire WebGL parameter set so faithfully that the detector fully trusted it — except the GPU was an Intel Q45/Q43 Express from 2008, with a maxTextureSizeof just 4096, "running" Chrome 139. Self-consistent, yes; plausible, no. Ancient hardware on a brand-new browser is a tiny anonymity set and an easy rule to write. Coherence means picking a common, moderndevice — and reproducing its full parameter set, not just the renderer string.

Plugins frozen in the past

That same browser advertised only two PDF plugins on an old MIME model (application/x-google-chrome-pdf) while claiming Chrome 139. Every modern Chrome (≥ v94) ships a fixed set of five PDF plugin entries on application/pdf. Claimed version and plugin surface didn't agree. The plugin face has to track the claimed version.

A US IP with a Singapore timezone

The most dangerous break of all. One build's automatic geo-timezone silently resolved toAsia/Singapore while the exit IP was in the United States. Another used a static profile timezone (America/Chicago) two zones off its actual Los Angeles exit. Any risk engine that cross-checks IP against timezone catches a US IP + Singapore clock in milliseconds. The timezone must reliably follow the proxy exit IP — across the main thread, workers, Date, Intl and Accept-Language— with a validated geo lookup, not a best-effort guess.

The signal-by-signal scorecard

Reading across the four builds we tested, the pattern is consistent — nearly everyone gets some of it right:

How Maskole stays coherent

Every profile is drawn as one persona and kept self-consistent end to end: the user agent matches the platform, the platform matches the WebGL vendor, the fonts match the locale, and the timezone matches the proxy. Workers read the same config as the main thread, so nothing disagrees across threads. WebRTC exposes only the exit IP. The system font normalizes to the persona; the enumerable font set is controlled per profile; colorDepth is the modern24; the GPU is a common modern part with its full parameter set reproduced; and the timezone follows the proxy's current exit IP rather than a static setting.

Being self-consistent and being believable are two different things. A mask has to be both — coherent across every signal, and plausible for a real device that exists in large numbers.

That is the quiet, unglamorous work that decides whether a hundred accounts read as a hundred strangers or as one farm. It's the whole game.