Anti-detect browsers and the difference between spoofing and coherence

What the tool is actually solving

The problem is linkage. Ten accounts on one platform opened from one machine are trivially one person: the canvas hash, the graphics renderer, the font set and the network address are the same across all ten. Separate browser profiles do not help, because profiles separate storage, not hardware. Separate virtual machines do help, and are expensive at any scale.

An anti-detect browser tries to give each profile the observable properties of a distinct machine on a distinct network, cheaply, on one computer. Every design decision in the category follows from that goal, and so does every way these tools are caught.

Two ways to change a fingerprint

Almost every product in this space is a modified Chromium. The meaningful difference is where the modification sits.

The JavaScript overlay

The browser injects a script into every page before the page's own code runs, and that script redefines the properties a fingerprinting library reads: the getter for the platform string, the canvas readback methods, the graphics parameter function. It is quick to build, easy to update when a new surface appears, and it works against a straightforward collection script.

The native engine change

The browser's own source is modified so the value the engine computes is already the intended one: the rendering path produces the intended canvas output, the graphics layer reports the intended adapter, the network stack sends the intended headers and client hints. Nothing is patched at runtime because nothing needs to be — the engine is not lying about its state, its state is different.

The tells an overlay leaves

Detecting an overlay is not exotic. It is a set of well-known checks any competent script performs, and they exist because JavaScript is introspectable by design.

// A native function stringifies to a specific form. A replacement does not,
// unless the replacement also patched toString - which is itself detectable.
Function.prototype.toString.call(navigator.hardwareConcurrency);

// Where does the property live, and is it an own property when it should be
// inherited from the prototype?
Object.getOwnPropertyDescriptor(Navigator.prototype, 'platform');
Object.getOwnPropertyNames(navigator);

// A patched accessor usually adds a frame with a different script origin.
try { null.f(); } catch (e) { inspect(e.stack); }

// A fresh realm has a pristine copy of everything. If the overlay only patched
// the main window, the iframe tells the truth.
const frame = document.createElement('iframe');
document.body.append(frame);
frame.contentWindow.navigator.platform;

• Function identity. Native functions have a recognizable string form; a wrapper does not, and hiding that requires patching the very function used to check it.
• Property placement. Whether a property is own or inherited, its enumerability, its descriptor shape, and the order in which keys appear are all observable and all easy to get wrong.
• Fresh realms. A new iframe, a worker or a nested context has its own copy of the environment. Overlays that patch only the top-level window are exposed by one line of code.
• Surfaces outside JavaScript. Request headers, the ordering and casing of those headers, client hints, TLS handshake characteristics and media capability negotiation are decided by the network and platform layers, where page script cannot reach and an overlay therefore cannot follow.

Farbling, and why stability matters as much as noise

Farbling is the deliberate introduction of small, deterministic distortions into high-entropy readbacks — a few pixels nudged in a canvas image, the lowest bits of audio samples perturbed — so the value collected is not the machine's true one. The term comes from the privacy-browser world, where the goal is to prevent cross-site linking; anti-detect browsers use the same mechanism to give each profile its own consistent value.

The subtlety is in the key. Noise must be derived from something stable, or the cure is worse than the disease.

• Noise keyed per call: every read returns a different value. No real device does this, and it is trivially detected by reading the same surface twice.
• Noise keyed per session: stable within a visit, different tomorrow. Defeats long-term tracking, and makes a returning visitor look like a new device every time — a problem for an account that is supposed to be recognized.
• Noise keyed per profile: stable for as long as the profile exists, across sessions and restarts. This is what an anti-detect browser needs, because the entire point is that this profile is consistently this device.
• Noise keyed per profile and per site: stable for one site over time, different between sites, which additionally prevents two sites from comparing notes.

There is also a magnitude question: distortion large enough to be visible, or to produce a value no real hardware would, is itself a signal. Good farbling is imperceptible, invariant for the profile, and inside the range real devices produce.

Coherence across surfaces, sessions and devices

Getting individual surfaces right is the easy half. The half that fails in practice is keeping them consistent with each other, and consistent over time.

Across surfaces

A profile claiming to be a particular Windows machine should have the font set that system ships, canvas output rasterized the way that platform rasterizes, a graphics renderer string belonging to hardware that exists, the extension list that renderer supports, a plausible processor count, matching client hints, and a time zone and locale that agree with the network address. Each is checkable independently, and a mismatch between any two is a stronger signal than an unusual value in any one.

Across sessions

The same profile must present the same device next week. That includes surviving a browser update: if the engine moves to a new version and the declared browser version moves with it while everything else stays put, the story still holds — real browsers update. What does not hold is a canvas hash that changes because the tool regenerated its seed, or a font list that grows because the host machine installed something.

Across devices

This is the one that surprises teams. Use a profile from a second computer and everything the tool does not control leaks the difference: the real screen geometry, the host's fonts if the engine falls back to them, the graphics stack if the profile's values derive from the host, and the network path. A genuinely portable profile has to carry its whole identity — storage, cookies and declared hardware — and the tool has to apply it the same way on both machines.

Headless and automation tells are a separate problem

“My fingerprint is detected” and “my automation is detected” are different problems, and a perfect fingerprint does not help with the second.

• The automation flag. Browsers driven by an automation protocol advertise it, and page script can read it. Removing the flag is necessary and nowhere near sufficient.
• Headless rendering differences. A browser with no real window historically differed in font rendering, media support, permission behavior and window geometry. Modern headless modes are much closer to the real thing, but “much closer” is not “identical”.
• Behavior. Perfectly straight cursor paths, typing at a constant interval, clicks in the exact center of every element, navigation that never scrolls. Behavioral signals are widely used and entirely independent of the fingerprint.

The practical consequence: evaluate the fingerprint and the automation surface separately, because a product can be excellent at one and irrelevant to the other.

How to evaluate one honestly

Marketing here is unusually unfalsifiable: “undetectable” is a claim about every website that exists, present and future. Replace it with tests you can run.

1. Read the same surface twice in one page and compare. Canvas, audio and font metrics must be identical within a session. If they are not, the tool is randomizing per call.
2. Restart the browser and read again. The values must be identical for the same profile. If they are not, the profile is a new device every morning.
3. Check every surface from a fresh iframe and from a web worker. Values that differ from the top-level window mean the change was applied per context rather than in the engine.
4. Compare the declared platform against what the engine actually does: fonts present, canvas rasterization, graphics extension list, media codec support, and the feature set implied by the claimed version.
5. Verify time zone, locale and the network address agree, and that the real-time communication stack does not disclose a different network path.
6. Test the automation surface separately, with the same checks a bot-detection script would use.
7. Ask the vendor how the change is implemented and how quickly they rebase onto new browser versions. An engine-level product that is several major versions behind is exposing a different, larger problem: a stale, unpatched browser.

Where Lobster Browser fits

For completeness, since we build one: Lobster Browser is an anti-detect browser built on a modified Chromium engine, and it takes the native approach described above. A profile's device identity is produced inside the engine rather than by a script injected into pages, and the same identity is applied to the surfaces page script can read and to the ones it cannot, such as request headers and client hints; each profile keeps its own storage and its own network route, and its values are stable across restarts. That describes the design, not any particular site's detection — the honest position in this category is that an implementation can be internally coherent and current, and that whether a given site accepts a given profile is that site's decision.

Summary

Spoofing changes an answer. Coherence changes the device that gives the answers, and only the second survives a collector that cross-checks. Overlays are cheap, leave introspectable traces, and cannot reach the network and platform surfaces at all; engine-level changes cost far more to build and remove those traces by construction. Farbling is useful only when its key is stable for exactly as long as the profile is. Consistency across sessions and machines is where most deployments fail, automation tells are a separate problem no fingerprint solves, and any product here should be judged by tests you run yourself.

Further reading

Named rather than linked, on purpose: specifications move and URLs rot, while a title and an author survive a search.

• The Tor Browser design document — the canonical treatment of fingerprint uniformity and the trade-offs it forces.
• Brave's published documentation on farbling and fingerprint randomization — the clearest public description of per-session, per-site noise.
• Mozilla's documentation for resistFingerprinting — a worked example of the reduction strategy in a shipping browser.
• W3C User-Agent Client Hints specification — the mechanism that moved high-entropy platform detail behind an explicit request.
• Our own earlier post, Browser fingerprinting, explained, for the surfaces this article assumes.