What fingerprinting can and cannot do

A browser that has not been patched at the source level cannot be made genuinely undetectable from JavaScript. That is not a limitation of Ward's implementation. It is a property of how the checks work, and it applies equally to every tool that launches a browser it did not build.

What Ward does instead is real and worth having: it makes each profile internally consistent, plausible as a description of a machine that exists, and different from your other profiles. Those three properties are what actually separate one profile from another. They are not the same thing as invisibility, and this page is careful never to imply that they are.

The tools that genuinely defeat fingerprint checks do it by shipping a modified browser binary. Multilogin builds Mimic and Stealthfox, GoLogin builds Orbita, AdsPower builds SunBrowser. Those are forks of Chromium and Firefox with the values changed inside the engine, below the layer any page script can reach.

That is why they work. When the value is changed in the C++ that implements the property, there is no JavaScript wrapper to find, because there is no wrapper - the engine simply reports something different.

Overrides applied from script are a different thing. Redefining a property on a prototype leaves evidence: the property descriptor changes shape, the function's toString no longer reads as native code, the prototype chain gains something that was not there, and the order in which properties enumerate can shift. A check that looks for the override rather than for the value finds it. Several public ones do exactly that.

Ward does not build a fork. It launches a browser - Camoufox, Ungoogled Chromium, Brave, Chromium, or Chrome or Edge if you turn them on. Maintaining a browser fork is a serious, permanent engineering commitment, and we would rather tell you we have not made it than imply we have.

One entry in that list is the exception, and it is why it is first. Camoufox is an open source Firefox build whose anti-fingerprinting values are patched into the C++, which is the category described above. Ward did not write those patches and does not claim them; what Ward does is launch it with a generated user.js, the same profile directory model and the same proxy relay as everything else. If the paragraph above is the reason forks work, Camoufox is the one option here that gets that benefit.

On a Chromium build, everything Ward applies goes on over the DevTools Protocol and leaves a descriptor. That includes navigator.webdriver. It is worth spelling out why that property is patched at all rather than left alone: on current Chrome, --remote-debugging-port alone sets it to true, with no automation flag anywhere and no client attached. The debugging port is how the identity is applied in the first place, so it cannot be dropped, and the property is corrected with the rest. That answers the check every bot script runs first. It does not answer a check written to look for the correction.

Each profile gets one coherent identity, generated once and reused on every launch. The right-hand column is the part that matters: every value is derived from something, not rolled at random.

Random values would be worse than none. A browser claiming a 4K screen, three CPU cores, a mobile platform string and an integrated GPU from 2011 describes no machine that has ever existed, and internal inconsistency is a much stronger signal than any single attribute. Coherence is the whole design.

The timezone deserves its own sentence. It is derived from the address your proxy exits from, so it cannot contradict the IP - a browser reporting Europe/Warsaw from a São Paulo address is a contradiction that costs nothing to detect and is one of the most common ways a proxied session gives itself away.

Values are applied through the Chrome DevTools Protocol before any page script runs, rather than by injecting an extension or a content script. The emulation domain covers the user agent, the timezone, the locale and the device metrics; a document-level script registered to evaluate on every new document covers the handful of values the protocol does not expose directly.

Ordering is what makes this work at all. A script that runs after the page has begun executing is racing the page for the first read, and it loses often enough that the result is not worth having. Registering before navigation means the values are in place before the first line of page script sees them.

Firefox has no equivalent protocol surface here, so what Ward can apply to it is narrower: the preferences written into the generated user.js, and no more. Plain Firefox therefore gets the narrowest identity of the five, and a Chromium engine is the choice when you want Ward applying the identity itself.

Camoufox is the exception, and it is why this does not simply read “use Chromium”. Its anti-fingerprinting values are compiled into the engine rather than applied over a protocol, so what it reports does not depend on how much of the browser Ward can reach - which is the argument that puts it at the top of the engines list. The narrow surface described above is a statement about what Ward applies to Firefox, not about how well a Firefox holds up.

Concretely, here is what remains visible to a check that is looking for it.

• The override itself. Property descriptors, prototype shape and function toString output can all reveal that a value was replaced rather than reported. A determined check can tell that something is emulating.
• Deep engine behaviour. Floating-point results, JIT timing, exact error message text, and the precise ordering of certain APIs are all engine-level and are all visible from a page.
• TLS and HTTP/2 fingerprints. These are properties of the connection, not of JavaScript, and they identify the browser build regardless of what the page is told.

Fingerprint tuning is the part of this subject that gets written about, and it is not the part that decides outcomes. In rough order of impact:

1. Proxy quality. A residential or mobile address with a clean history beats every setting in this application. A datacentre address shared by hundreds of people cannot be rescued by anything.
2. Consistency over time. The same profile arriving from the same country with the same identity, week after week, is ordinary. A profile whose address, timezone and screen size all change between sessions is not.
3. Real isolation. Cookies, storage and cache genuinely separated, which is the thing Ward does completely and with no caveats at all.
4. Behaviour. Timing, navigation patterns and interaction rhythm are heavily weighted by systems that are actually looking, and no profile manager influences them.
5. Fingerprint coherence. Necessary - an incoherent one is a signal all by itself - but last on this list, not first.

Do not take our word for any of this. Launch a profile and point it at the public fingerprinting test pages - browserleaks.com, amiunique.org and the widely-used CreepJS test are the usual three. Read what they report.

You should expect to see, roughly:

• the identity you configured reported back consistently, and a timezone that agrees with the exit address;
• no WebRTC candidate carrying your real local or public address;
• two different profiles producing two clearly different reports;
• and, on the tests that look for it, some indication that emulation is present. That is the expected result, not a bug - see the ceiling above.

If any of the first three fails, that is a real defect and we want to hear about it. The fourth is the honest state of the art for any tool that does not ship its own browser.

Every one of those is either unfalsifiable or false, and all of them are common in this category. Here is what we will say instead: