FingerprintJS: 1 bundled file set off anti_detect_browser

Fingerprint's demo page shows a commercial fraud and bot vendor's verdict openly, field by field. That makes it a useful mirror and a harsh one. In July 2026 it called our packaged engine an anti-detect browser, and the cause turned out to be neither a patch nor a persona value but one folder that shipped with the browser.

What is FingerprintJS?

FingerprintJS is an open-source JavaScript library that reads a browser's properties and computes a visitor identifier in the browser itself; Fingerprint Pro is the commercial service built by the same company, which computes the identifier on its servers and adds Smart Signals such as bot and tampering detection. The two share a name and a history, and they answer different questions.

The FingerprintJS repository describes itself as "the most advanced free and open-source browser fingerprinting library", and as of September 2026 its latest npm release was 5.2.0 on 7 April 2026. The flag this case is about lives only in Pro.

What makes Fingerprint Pro flag an anti-detect browser?

Fingerprint Pro flags an anti-detect browser through its tampering signal, which combines two methods. The Smart Signals reference names "statistical anomaly detection, which identifies browser signatures that are unusually rare compared to the overall population", and "antidetect browser detection, which combines heuristic (rule-based) methods with a machine learning model to identify known antidetect browsers". The response carries the result in five fields.

Fingerprint also folds the signals into one Suspect Score, and its weights table gives the antidetect browser signal a weight of 8 on the web. A verdict like this is one of the heuristics behind a bot verdict: a rule that fires on a pattern, added to a score that other layers feed as well. What a Cloudflare 403 forbidden means for an AI agent is covered in Cloudflare 403 forbidden for an AI agent.

What set off the flag on our engine?

A Widevine DRM module bundled next to the browser binary set off the flag, and nothing else. On 28 July 2026 we loaded Fingerprint's public demo page six times in alternating order, three times with the module's folder in place and three times with it renamed, on the same binary, the same machine and the same connection. Five earlier runs had given the same split.

(opens in a new tab)

The table reads like Fingerprint's own documentation. Low confidence with a model score of 0 is the case where only the heuristic fired, and the 8 points between 17 and 25 are the weight Fingerprint documents today for the antidetect browser signal. The other 17 points came from signals that were the same in both states. Without the module, Fingerprint rated the same browser clean with high confidence.

Before the A/B series we narrowed it down build by build, all on Chromium 148 within one hour. An official vanilla Chromium snapshot was not flagged. Our build with all of our changes and the module was flagged, and so was a build with none of our changes plus the module. Removing only the module cleared it. The heuristic reacted to what shipped beside the browser, not to how the browser was modified.

Since 28 July 2026 our engine package ships without the module. When a profile later receives it the ordinary way, into its own profile folder, 13 of 15 runs on 2 August read anti_detect_browser: false; in the two others the browser's CreepJS fingerprint was unchanged, so the browser does not explain them. On 25 August, 18 alternating runs across Fingerprint Pro, deviceandbrowserinfo and CreepJS, with the module in the profile as the only variable, showed no reaction in either direction.

How does Fingerprint Pro detect a Chromium fork?

Fingerprint Pro detects known anti-detect browsers through rules and a model it does not publish, and our case shows that a rule can fire on the package rather than on the patches. A fork is more than its source changes: every file that ships beside the binary is part of what a page can learn about it. In our bisection the patches made no difference at all, and one bundled component made all of it.

After the fix, the same demo page had nothing to say. In a dashboard A/B series on 10 and 12 August 2026, 3 runs per side, all eight readings on Fingerprint's demo were the same on both sides: bot, browser tampering, developer tools, virtual machine, privacy settings, incognito and VPN "Not detected", confidence 1. Developer Tools stayed "Not detected" while a CDP session was open on the profile. These are readings of one demo page on a few runs, and they say nothing about how a customer of Fingerprint weighs its own traffic.

Does leaving out Widevine break DRM video?

Leaving the module out of the package does not remove DRM for good, because Chrome's component updater delivers it into the profile folder, where a real Chrome installation receives it too. That delivery took time: a fresh profile answered requestMediaKeySystemAccess for Widevine with false, and a profile after the updater had run answered true with SW_SECURE_DECODE, the same robustness real Chrome 150 reported. Since version 0.19.2 of 28 September 2026 the app keeps the copy the updater put on the computer and gives it to every new profile before it starts. H.264 and AAC video do not depend on the module and play either way. There was a second reason to stop bundling it: the licence Google ships next to the module states that "You may not use, modify, sell, or otherwise distribute the Software without a separate license agreement with Google". The engine page of the documentation lists what the signed package deliberately does not carry.