fingerprint-chromium: a fingerprint-spoofing Chromium built on Ungoogled Chromium

What the fork actually changes in the browser

Most fingerprinting countermeasures run as a JavaScript shim that rewrites values after page load. This project works differently, because it is a fork of Ungoogled Chromium with the patching applied underneath Blink and the networking stack. That distinction decides what it can and cannot fix. A script hook can lie about `navigator.userAgent` easily and can lie about canvas output, but it cannot change how Chromium talks to a server, and a sufficiently careful detection script can notice that a value changed after the fact. Engine-level patching does not have that problem, because the value was never real.

The release notes show the scope concretely. The Chrome 142 notes list an updated implementation for `navigator.userAgent` and `navigator.userAgentData`, an improved audio fingerprint implementation, and improved canvas fingerprint modification described as being for better anti-detection. The Chrome 148 notes add a randomized device memory fingerprint, where `navigator.deviceMemory` is no longer fixed at 8 but chosen at random from 8, 16 or 32, seeded from the `--fingerprint` value. And GPU spoofing now simulates WebGL and GPU parameters using real GPU parameter sets, so the reported renderer looks like hardware that actually exists rather than an obviously synthetic string.

That consistency angle is the part worth dwelling on. A naive spoof that reports an NVIDIA card with 16 device memory and a screen resolution no laptop has is worse than no spoof at all, because the disagreement between attributes is the signal. Simulating from real parameter sets is an attempt to keep the whole surface coherent.

Command-line flags for turning spoofing off in specific areas

The flag surface is unusually good for a project of this size, and it has been refactored once in a way that shows the author cared about it. The Chrome 144 release introduced a unified `--disable-spoofing` parameter taking comma-separated values, with `font`, `audio`, `canvas`, `clientrects` and `gpu` as the accepted set. An example given in the notes is `--disable-spoofing=font,gpu`, which disables font and GPU spoofing and leaves the rest active.

That replaced an earlier, narrower flag called `--disable-gpu-fingerprint`, which the Chrome 142 notes had recommended as a workaround because GPU fingerprinting could cause problems in some scenarios. The same 144 release removed two legacy parameters, `--fingerprint-gpu-vendor` for customizing the GPU vendor string and `--fingerprint-gpu-renderer`. So the project's own history contains a correction: a workaround flag replaced by a general one, and specific tuning knobs pulled out in favour of a single granular parameter.

Having an escape hatch per subsystem matters more than it sounds. If you are running under a virtual machine with a software rasterizer, spoofing a hardware GPU can break rendering or produce inconsistent screenshots. Being able to disable exactly one subsystem, rather than the whole patch set, is the difference between a tool you can debug and one you cannot.

Prebuilt binaries per Chromium version, not a source build

This repository does not ship a build script. The tree is four entries: `LICENSE`, `README.md`, `README-ZH.md` and an image file. The patches live on branches named after the Chromium version they target, and the README's download table links to each of those branches as the source code for the corresponding release. In practice the supported workflow is to download a binary, not to compile Chromium.

Each Chromium major version gets its own release, and each release offers Windows, Linux and macOS builds, though not uniformly. For the current Chrome 148 line, Windows gets both an installer and a zip, Linux gets an AppImage and a tar.xz, and macOS gets a dmg. The Linux AppImage for that release is the file to grab on a Linux box:

wget https://github.com/adryfish/fingerprint-chromium/releases/download/148.0.7778.215/ungoogled-chromium-148.0.7778.215-1-x86_64.AppImage

On macOS the equivalent artifact is a disk image rather than an archive, which is the normal packaging convention there:

wget https://github.com/adryfish/fingerprint-chromium/releases/download/148.0.7778.215/ungoogled-chromium_148.0.7778.215-1.1_macos.dmg

The table also shows that platform support is not always in step across versions. Chrome 138 and 136 list a plain tar.xz for Linux with no AppImage, and Chrome 144 has no macOS entry at all. If you need a specific platform, check the table for that version rather than assuming parity. The last push was on 2026-06-21 and the repository is not archived, and the release tagged 148.0.7778.215 went out the same day.

Verifying a spoof, and where the self-check ends

The release notes point at a specific external fingerprint checking site, pixelscan.net, as the place to verify the effect of the audio fingerprint changes. That is a reasonable pointer and also the honest limit of what the project offers. There is no automated test suite, no pass or fail criteria shipped with the release, and no documentation of which detection systems are or are not defeated.

That matters, because fingerprint resistance is not a property you can assert once. Detection vendors maintain their own signals, some of which this project does not touch at all: TLS and HTTP2 characteristics, connection timing, IP reputation and account behaviour all sit outside the browser engine. Spoofing browser attributes is one layer of a much larger problem, and a browser that presents a perfectly coherent fake GPU while connecting from a datacenter IP range on an unusual TLS stack is still identifiable.

So the honest framing is that this project raises the cost of naive detection, not that it makes a browser anonymous. Anyone evaluating it should decide what they are actually trying to achieve before installing it. For managing multiple distinct identities from one machine it is directly useful. For evading a sophisticated anti-bot vendor, no amount of local canvas consistency substitutes for the other layers.

One maintainer, no support, explicit scam warning

The README opens with a notice that deserves to be quoted rather than paraphrased, because its tone is unusual: the project provides no technical support, the maintainer asks not to be contacted for help, and anyone who contacts you asking for payment is a scammer. That last warning exists because this category of software attracts people selling services around it.

Practically, it means there is no issue tracker culture to rely on, no documentation site and no compatibility matrix. The repository carries 28 open issues against roughly 3,000 stars, which is not a support load in any meaningful sense. The 26 open topics include `anti-bot`, `anti-detection`, `scraping` and `privacy`, so the intended use is stated plainly rather than hidden, but the project offers no help with it.

The licence is the one bit of paperwork that is unambiguous: BSD-3-Clause, which is permissive and imposes no obligation on redistribution beyond the notice in `LICENSE`. Compared with the licensing position of Chromium itself, which carries a BSD-style licence with additional provisions for the bundled components, this is a straightforward redistribution story. For a maintained fork of a large browser where you did not write the code, a permissive licence with no support commitment is a coherent package rather than a suspicious one.

Where this sits against other anti-detection browsers

There are three broadly different approaches to browser fingerprint resistance, and this project sits in one specific place among them. Extension-based tools rewrite JavaScript-visible values after load: cheap, portable, installable in any browser, and detectable by any script that watches for late changes or inconsistencies with WebGL and network behaviour. Kernel-level and VM-level tools change the whole stack beneath the browser, which is far harder to detect and far harder to operate. This project is engine-level patching of a single browser, which is a middle path with a much better effort-to-result ratio than a virtual machine and a much narrower guarantee than one.

Against commercial fingerprint browsers, which bundle a manager UI, profile switching, proxy assignment and proxy rotation into a paid product, this repository offers only the browser. There is no dashboard, no profile database and no proxy handling. You get a spoofing browser and you wire up everything else yourself.

What it does have over most alternatives is per-subsystem control at the flag level, which most commercial products do not expose at all. If your problem is a specific broken interaction between spoofed GPU values and your own rendering stack, the ability to turn off exactly one subsystem is worth more than a feature list. The comparison to draw is therefore not feature against feature, but control against convenience.

Editorial conclusion

This project is for one job: making a Chromium instance report a device that stays internally consistent while differing between profiles. It does that at the engine level rather than through an extension, which is why the interesting control surface is command-line flags such as `--disable-spoofing=font,gpu` rather than a settings panel. Two things to weigh before adopting it: the repository publishes prebuilt binaries and README patches, not a build you compile yourself, and the maintainer states plainly that no technical support is provided and that anyone asking you for payment is a scammer. The licensing question is settled for you, since the project is BSD-3-Clause. Start by downloading the Chrome 148 build for your platform, then compare `navigator`, canvas and WebGL output against a stock Chrome before drawing conclusions.

Frequently asked questions

Official sources

1. adryfish/fingerprint-chromium on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases