BrowserFM: 16,000 Parameters to Identify Your Browser

Until recently, browser anonymity seemed almost naive by today's standards. In the early 2010s, changing your IP address, running Tor, and tinkering with your browser was enough to transform you into a new user for many systems. Then came Canvas, WebGL, AudioContext, WebRTC, Client Hints, WebAssembly, WebGPU, and dozens of other signal sources, and antifraud software stopped looking at a single parameter and started looking at a combination of them.

BrowserFM takes things much further. Instead of just another fingerprint, it attempts to build a model of the user's browser environment, collecting up to 16,000 different attributes. And this is where things get really interesting—because for affiliates, multi-account users, advertisers, bonus hunters, or simply anyone who believes that "a new IP plus a new browser profile equals a new user," the rules of the game are quietly changing.

What is BrowserFM?

FM has nothing to do with radio here: BrowserFM stands for Browser Future Model. The project's idea is quite radical: why pick a few dozen "good" browser characteristics when you can collect virtually everything a browser can tell you about the device? It's based on the so-called BOM Enumeration, or Browser Object Model Enumeration: the system traverses the objects available to the browser and extracts characteristics from a variety of sources—Window, Navigator, Screen, Performance, CSS, GPU, window size, display parameters, DPI, resolution, available APIs, software environment features, and dozens more. In total, it accumulates around 16,000 attributes.

Many traditional solutions look for a relatively small set of the most informative features. BrowserFM operates on the opposite philosophy: if the browser provides a parameter, why not use it? Therefore, considering BrowserFM "another fingerprint" isn't entirely accurate. It's more like a construction kit that can be used to assemble a huge number of independent fingerprints.

One print turns into a tree

Imagine an anti-fraud system taking 16,000 values ​​and simply compressing them into a single SHA-256 hash. DPI changes—a new hash. Window size changes—another new one. Chrome updates—another one. Such a system would be extremely sensitive and practically useless for long-term identification. BrowserFM does something smarter: all parameters are distributed across branches—Window, Navigator, Screen, CSS, GPU, Performance, and others—and each branch describes its own part of the environment.

This is a fundamental shift. Now, anti-fraud can compare not only "is fingerprint A equal to fingerprint B?" but also ask a much more subtle question: "Which parts of fingerprint A are similar to B, and how statistically significant is this similarity?" This has a direct consequence. Let's say a user upgraded their graphics card, and the classic fingerprint, heavily tied to WebGL and WebGPU, has noticeably changed. Why throw away the rest of the data? BrowserFM allows us to say, "The GPU branch is different—okay, let's ignore it for now and compare everything else." If Window, Navigator, Performance, CSS, and a host of other characteristics still match, the system has reason to believe it's the same user with updated hardware. There's no need to look for a complete match—matching individual parts of the model is sufficient.

Fuzzy Hashing: Why Changing a Few Parameters Isn't Enough

The main problem isn't even the number of characteristics. Did you know the system analyzes screen resolution? Change it. Did you know about hardware concurrency? Change it. And even more so about user agent. If the fingerprint were a simple hash of a set of parameters, changing the input data would be enough to get a completely different output value. But BrowserFM relies on the idea of ​​fuzzy hashing—a fuzzy comparison. Instead of requiring an exact match, the system looks for a similar fingerprint.

In other words, a fingerprint isn't a password: it doesn't need to match bit for bit. The system needs to understand how similar two environments are, and the model allows for significant variability in some characteristics. Therefore, changing a few obvious parameters doesn't necessarily mean breaking the connection with the old environment. BrowserFM claims an identification accuracy of approximately 99.7% under appropriate test conditions—and that's far more impressive than the "16,000" figure alone.

A clear example. First run: 1920x1080, 96 DPI, Chrome, NVIDIA graphics card, 8 CPU threads, a specific set of fonts, and specific performance metrics. Second run: 1366x768, 120 DPI, the same Chrome, the same NVIDIA graphics card, the same 8 threads, almost the same fonts, and similar performance metrics. Looking only at the screen print, we're looking at different users. Looking at the entire model, it's far from certain. Moreover, the branches have different weights: an easily changeable parameter shouldn't be valued as highly as a characteristic that's difficult to consistently fake. And here we come to perhaps the most interesting part of BrowserFM.

Performance Fingerprinting: A computer gives away its speed

You can replace a string. You can change a JavaScript API value. You can tell a website a different resolution. But getting a computer to perform reliably like other hardware is an incomparably more difficult task. BrowserFM pays special attention to the Performance section: in the demo checker, this category alone includes dozens of different performance metrics. The logic is simple: if two devices claim identical specifications but perform the same operations fundamentally differently, an additional signal is generated. This is especially evident in the case of virtualization and artificially assembled browser environments.

You could say, "I'm a typical home computer." But Performance Fingerprinting asks a different question: "Do you really work like a typical home computer?" Therefore, the Performance branch potentially receives more weight than the easily modifiable Window or Navigator. This is a key shift in fingerprinting: antifraud gradually shifts from the question "What does the browser report about itself?" to the question "How do the browser and device actually behave?"

A new User-Agent no longer means a new browser.

If your anonymization plan still relies heavily on "spoofing the User-Agent," we have bad news. The User-Agent is just one signal among many, and the browser engine reveals itself through completely different APIs. A classic example is AudioContext fingerprinting: differences in the implementation of the audio stack and the engine create characteristics that cannot be consistently changed with a single User-Agent string.

Now add to this Canvas, WebGL, WebGPU, WebAssembly, CSS, Performance, fonts, Navigator, Screen—and thousands of less obvious characteristics. It turns out to be simple: you can tell a website you're using a different browser, but the other 15,999 parameters must agree with you too. Consistency is one of the central problems of modern fingerprinting.

A "clean" system is also a fingerprint

There's a detail that's often underestimated. Let's say you've indeed set up a brand-new machine: a fresh Windows installation, a fresh browser, a new IP address, and no cookies. It would seem like the perfect new user. But an unexpected problem arises: ordinary people almost never use perfectly clean computers. Over months and years, digital junk accumulates on the machine—programs, fonts, extensions, office suites, graphics editors, utility applications—and all of this gradually changes the environment the browser sees. Therefore, a completely clean Windows installation can itself be an interesting anti-fraud signal.

Fonts are the biography of the system

Font fingerprinting has been around for a long time, but it becomes especially useful in a large-scale system like BrowserFM. The set of available fonts indirectly reveals the system's localization, installed software, the age of the environment, and the nature of computer usage. Microsoft Office brings its own fonts, Adobe applications leave a different set of artifacts, and language packs a third. It all adds up to a unique history of the system's life.

Imagine a user who claims, "I'm just an ordinary American who's been using this Windows computer for a long time." But the user's environment looks like a system installed twenty minutes ago—minus the user's signature software and with a completely different locale's fonts. Each individual sign proves nothing, but that's exactly how fingerprinting works in the 21st century: weak signals add up to a strong conclusion.

VPS, Windows server, and virtual machines

For some scenarios, it's convenient to use a VPS or remote server, install a browser, and work through it—and from a network perspective, everything might look flawless. But the network is only one layer. A system like BrowserFM analyzes the characteristics of the environment itself: a server version of Windows differs from a typical home version, a fresh installation has a distinctive profile, and a virtualized environment adds another set of signals. A high-quality residential IP address doesn't, by itself, turn a server into a home laptop. It can be put quite simply: the IP tells the website where you're coming from, and the fingerprint tries to understand how you arrived—and antifraud is interested in both answers.

Virtual machines are a different story. VMs were once a nearly universal tool for separating environments; today, virtualization itself is becoming part of risk scoring. BrowserFM is interesting here because it doesn't try to find a single magic flag like "isVirtualMachine = true," but rather collects a multitude of indirect indicators: GPU, Performance, fonts, screen, available APIs, software environment, browser behavior, and system features. Individually, each signal is perfectly legitimate, but their combination can create a distinctive virtual machine profile—and this is much more difficult to fix with a single setting.

Antidetect now collects not values, but a system

Historically, the task of an anti-detect browser looked something like this: obtain a fingerprint, modify the fingerprint, create an independent profile. But the more independent sources of information a browser incorporates, the more difficult it is to maintain their mutual consistency. Let's say anti-detect changes the GPU—great. But does that GPU's Performance match? Does the WebGPU match it? Does the number of CPU cores correlate with performance? Does the Screen match the advertised device? Is the font set compatible with the operating system and locale? Does the specified browser version support a specific set of APIs? Generating plausible values ​​is no longer enough—we need to generate a plausible system of interconnected values. And the difference here is enormous.

A good analogy is a passport. Name: John Smith. Country: USA. Year of birth: 1990. Everything seems normal. But then it turns out the passport was issued in France, the number is in German format, the photo was taken thirty years ago, and the issue date is tomorrow. Each parameter individually is plausible, but together they are absurd. The same thing happens with a browser fingerprint. Modern anti-fraud software is increasingly less concerned with the question "can this parameter be spoofed?" - it's much more important: "can thousands of parameters be spoofed and still remain consistent?" BrowserFM turns this problem into an architectural principle.

What about smartphones?

It seems that everything is simpler on smartphones: the model range is limited, millions of people have identical iPhones and Samsung phones, the hardware is unified, meaning the fingerprint should be less unique. Not necessarily. Android is particularly interesting: despite the hardware unification, the browser still receives a large number of characteristics from the software and hardware environment. Combine these into a larger model, add performance metrics, and the number of potential combinations increases dramatically. Therefore, technologies like BrowserFM can bridge the gap between browser fingerprinting and identification, which previously required installing an app. This is a particularly promising direction for mobile anti-fraud.

Why BrowserFM is beneficial to the antifraud itself

There's a side of technology that users don't usually consider: data storage costs money. This is especially true when you have hundreds of millions of daily events, not just a thousand visitors per month. Google, Amazon, advertising networks, banks, marketplaces, and major anti-fraud platforms handle colossal volumes of data. According to the stated architecture, BrowserFM's representation is stored much more compactly than standard JSON—data sources claim a savings of up to nine times.

For a single user, this is a small matter. For hundreds of millions of fingerprints, it's an infrastructural advantage. And often, the fate of a technology is decided not only by the question "how well does it work?" but also "how much does it cost to implement it on 500 million queries?" If a fingerprint is both more accurate and cheaper to store, the incentive to implement it increases dramatically.

A model that grows with the browser

And another unfortunate feature of the concept: it's not tied to today's APIs. A new browser interface has appeared—it's being added to the corresponding branch. A new way to obtain GPU information has appeared—another signal. A new Performance API—a few more characteristics. This is precisely why the name Future Model seems appropriate: it's not a fixed fingerprint, but an architecture to which new sources of information can be endlessly added. Today, there are 16,000 parameters. Tomorrow, there could be more.

What does this mean for multi-accounting – and the main idea

The conclusion is unpleasant, but useful: the era of combating fingerprinting by substituting a few popular parameters is ending. A modern system can simultaneously analyze the network environment, browser, hardware, performance, software environment, change history, consistency of characteristics, and user behavior. BrowserFM primarily covers a huge swath of the browser and hardware/software layers. Therefore, the question is gradually changing. Previously, the question was, "Has my fingerprint changed?" Now, a more accurate question is, "Does the new environment look like an independent, real device?" These are completely different questions.

It's especially important to remember this when working with fingerprint checkers. The user changes a parameter, refreshes the page, sees "Fingerprint ID changed," and happily concludes that the site now considers them a different person. But this can be a false sense of security. The full hash does change with even minor edits to the input data, but the anti-fraud solution doesn't necessarily need to use it as the sole identifier. It can separately store and compare the GPU, Performance, Navigator, Screen, and CSS profiles and evaluate the similarity between the old and new profiles. The question isn't whether the hash has changed—the question is how much the feature space itself has shifted.

And this brings us to BrowserFM's most fundamental idea, which is more interesting than any number. In a few years, "16,000" might seem completely mundane—what's important is something else: a browser fingerprint ceases to be an identifier and becomes a device model. And a model, by its very nature, is subject to change. A user might change their graphics card, update their browser, change their resolution, get a new monitor, or install Office. Real computers change constantly—and a good anti-fraud solution shouldn't lose a user after each such change. It must understand the nature of change: distinguish the natural evolution of a living system from a hastily assembled environment that only pretends to be real.

This raises a new, far more challenging question for anyone building independent profiles. Previously, it was "how do I get a new fingerprint?" Now it's "how do I build an environment that behaves like a truly different device and remains internally consistent, evolving over time just like a real computer would?" This isn't just a switch in the interface, but a full-fledged engineering challenge.