Fingerprint test results

Known issues in 3.5.5, the current macOS beta

3.5.5 has leaks that 3.5.6 fixes: dates and times on a page still showed this computer’s timezone, the first page of a launch could load before the fingerprint was in place, pages could find a marker and other tells that identify XDLogin, Web Workers saw this computer, and a proxy’s password could be sent to a website that asked for a login. The macOS beta stays on 3.5.5 until a newer build is added; on Windows and Linux, the current build on the download page has the fixes. The changelog has the details.

No third-party run published

No third-party run has been published for any release yet, including 3.5.6, 3.5.7 and 3.5.8. This page shows no scores rather than placeholder ones.

What we have checked ourselves

Our own coherence probe, run on 27 September 2026 in headless Chrome 154 against the pre-release engine for desktop 3.5.6. It is not a run of a release build, and no third-party site was involved.

It makes 50 checks: that the user agent, platform, client hints, CPU cores, memory, touch points, screen, WebGL renderer and timezone are the device model’s; that canvas and audio hashes stay the same when read twice; that a Web Worker and an iframe report the same values as the page; and that common tells, such as navigator.webdriver, are absent.

Every failure is a Web Worker started from a blob: URL, which the engine can’t reach yet (see the limitations below). The same worker loaded from a URL passed all of its checks. The Windows model scores higher only because that worker’s platform and core count happen to match the test machine’s.

• WebGL capability parameters follow the host GPU. The vendor and renderer strings are the profile’s device, but the numeric limits behind them — MAX_TEXTURE_SIZE, viewport dimensions, shader precision, the extension list — still come from the graphics card actually in your machine. A profile claiming a phone GPU reports desktop-class limits, and every profile on one computer reports the same ones. Faking these would mean inventing numbers for every GPU in the catalogue, which is the same contradiction one layer down, so we publish it instead.
• Some Web Workers still see this computer. A worker loaded from a URL gets the profile’s fingerprint on desktop 3.5.6 and Android 1.3.0-beta.1; desktop 3.5.5 fingerprints no workers at all. Workers built from in-page code (blob: and data: URLs) and service workers are not covered on either platform, and on desktop neither are workers started by another worker or whose script a site’s service worker supplies. Those report this computer’s CPU cores, memory and platform. On desktop their network requests still carry the profile’s user agent.
• Service workers may not get the profile’s timezone. Pages and ordinary workers do. A service worker runs in a process of its own, and we have not measured it yet.
• Font metrics are the host’s. Font availability is answered from the profile’s operating system, so an Android profile no longer claims Calibri. Font rendering — measuring the width of a rendered string — goes through the real machine’s rasteriser and is not spoofed.
• TLS fingerprint (JA3/JA4) is the host browser’s. Profiles run in a real Chrome, so the TLS handshake is a real Chrome handshake — the Chrome on your machine, which since 3.5.6 is also the version the profile’s user agent announces. But it is the same handshake for every profile on that computer, and a desktop handshake even for a phone profile. Changing this needs a TLS-rewriting proxy, which XDLogin does not ship.
• On Edge or Brave, a profile still says “Google Chrome”. XDLogin prefers Chrome and falls back to Edge, then Brave. On that fallback the client hints still name Google Chrome, while the TLS handshake and a few browser-specific details are Edge’s or Brave’s. Installing Chrome, or setting a Chrome path in Settings, removes the mismatch.
• “WebRTC: disabled” is itself detectable. That mode removes RTCPeerConnection, and every real Chrome has one. It closes the IP leak, but a site can see that the API is missing. Altered, the relay-only mode, closes the same leak with the API still present, and is the mode we recommend. New profiles start on Disabled, so switch them.
• The built-in engine is weaker. With no Chrome, Edge or Brave installed, desktop 3.5.7 and earlier open profiles in their own built-in engine; 3.5.8 doesn’t launch them and says why, unless you choose that engine in Settings. It is a window with no address bar and no automation endpoint, where every profile shares one language setting and one WebRTC policy.
• Three leaks still open in desktop 3.5.8. The very first request of a tab opened with a middle-click or Ctrl+click carries this computer’s user agent and language headers; the CSS of an iframe from another site sees your monitor’s size; and a service worker’s own script request carries this computer’s user agent. The changelog tracks them.
• Android: the X-Requested-With header. The Android System WebView attaches a header naming the app package to every request, below the layer any app code can reach. See the download page for the current state and what we tried.