A New Technology for Handling Subversions – What Anti-Detect Developers Don’t Tell You About Core Updates and Why Proper Variability Matters

Introduction

What could be simpler and more insignificant than your browser’s version number? For an ordinary user, it’s just a string of digits changing somewhere in the background. But for modern anti-bot systems, it’s one of the key markers by which they surgically distinguish a real person from an artificial profile.

Many users and even developers of anti-detect browsers still believe that simply having the latest Chrome core version is enough for successful masking. This is a dangerous misconception. In reality, the browser version is a complex, dynamic structure, and spoofing it incorrectly has become one of the most widespread and easily detectable vulnerabilities on the market. A static, “frozen” fingerprint, even if it was relevant yesterday, is already an anomaly and a red flag for user analysis systems today.

In this article, we’ll first dissect the anatomy of the Chrome version and show how anti-bot systems detect spoofing through the smallest details. Then we’ll present the results of a large-scale study of nine popular anti-detect browsers, which clearly demonstrates why most of them create not digital camouflage but an easily detectable target. If you’re already familiar with the theory, feel free to jump straight to the second part and explore the research results. Finally, of course, we’ll show how Linken Sphere’s new, innovative approach solves this problem, creating a truly live fingerprint indistinguishable from that of a real user.

Anatomy of the Chrome Version

Before we dive into detection methods, let’s examine the object of our study itself. The full browser version isn’t merely a set of numbers; it’s a digital passport with several layers of protection. Understanding the role of each is the key to proper fingerprint spoofing.

137 — Major version (released roughly every ~4 weeks).

• This is the most important number in the string. Its increment signals a significant browser update.
• Typically, a new major version includes noticeable changes for users: new features, UI updates, significant performance improvements, or web standards enhancements.
• Major updates also often include significant changes to the JavaScript V8 engine and the Blink rendering engine.

0 — Minor version (usually does not change).

• Historically, this number was used for small feature updates released between major versions.
• In Chrome’s modern rapid-release model, this number is almost always zero.
• Google prefers to roll all changes into the next major release (e.g. 138.0.x.x) rather than release interim minor versions.

7151 — Build number.

• This number increases with every new build compiled from the Chromium project’s source code (the foundation of Chrome).
• It’s directly tied to the specific state of the codebase in the version control system.
• Every time developers make changes to the code and trigger an automated build process, this number increments.

120 — Patch/Subversion. This part changes most frequently to fix vulnerabilities.

• When a critical vulnerability is discovered, Google cannot wait four weeks for the next major release.
• Imagine a serious zero-day vulnerability is found in version 137.0.7151.104. Google will urgently release an update 137.0.7151.120 (or another incremented final number) containing only the vulnerability fix without affecting other components.
• This is why it’s crucial always to update your browser to the latest available version.

Detection Vectors: From User-Agent to Client Hints

Now that we understand what the full version number consists of, we need to look at how exactly risk analysis systems obtain this data. After all, the anatomy of the version is only one piece of the puzzle; the second, equally important, is the channels through which it’s transmitted. For a long time, the main source was the User-Agent header, but in the modern web ecosystem, it has been replaced by a new, more sophisticated and controlled mechanism.

Chrome began its gradual transition to User-Agent Reduction around version 95 (late 2021), and this process became more aggressive in versions 100–110 (throughout 2022–2023). By 2025, this mechanism is fully operational.

Previously, every browser request to a website contained a User-Agent header that looked roughly like this: User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.1234.56 Safari/537.36

This string contained a lot of unique information: the exact browser version, operating system, and its architecture. This allowed websites to easily track users by creating their “passive” digital fingerprint.

User-Agent Reduction is Google’s initiative to “freeze” and shorten this string. Now, by default, a website sees a much more generic version: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36

Note that the minor versions and build numbers have been replaced with zeros (93.0.0.0). This makes the User-Agent less unique and complicates passive tracking. To obtain precise data, a website now has to rely on a new, more transparent mechanism.

The main modern method is the technology called User-Agent Client Hints (UA-CH). It works on the principle of active requests initiated by the server.

1. User’s First Request to the Website
   The browser initially sends only basic “hints” (low-entropy client hints) that don’t carry much unique information. These are sent by default in new headers:
   1. Sec-CH-UA: "Google Chrome";v="137", "Chromium";v="137", "Not/A)Brand";v="24" (Brand and major version)
   2. Sec-CH-UA-Mobile: ?0 (This is not a mobile device)
   3. Sec-CH-UA-Platform: "Windows" (Operating system name)
2. Server Response Requesting Detailed Information
   If a website (e.g. a detection system) needs more precise data, it must include a special Accept-CH header in its response to the browser. In this header, it lists which specific “high-entropy client hints” it wants to receive. “High entropy” means these data points are more unique.
   Example of a server header requesting the full version and architecture: Accept-CH: Sec-CH-UA-Full-Version-List, Sec-CH-UA-Arch, Sec-CH-UA-Platform-Version
3. Subsequent Requests to the Website
   After receiving this header, the user’s browser will include the requested headers in all subsequent requests to the same website.
   Example of the headers the browser will send in response to the above request:
   1. Sec-CH-UA-Full-Version-List: "Google Chrome";v="137.0.7151.120", "Chromium";v="137.0.7151.120", "Not/A)Brand";v="24.0.0.0"
   2. Sec-CH-UA-Arch: "x86"
   3. Sec-CH-UA-Platform-Version: "15.0.0"

Thus, the website receives the precise browser version—but only after explicitly requesting it. This makes the data collection process more transparent.

Distribution of Real Users Across Chrome Versions

Contrary to popular belief, at any given moment real users are not all running a single “current” Chrome version. Instead, we observe a dynamic distribution across multiple versions, driven by Google’s official_release_strategy

As described in developer documentation, the company uses a staged rollout model. This approach minimizes risk: the update is initially released to 1–5% of users, and only after confirming stability and the absence of critical issues does the rollout gradually increase to 100% over several days or even weeks.

As a result, at any point in time, there are at least two or three stable Chrome versions actively in use, each with different share percentages—a fact clearly illustrated by services like Chromium_Dash. Other key factors also influence the final distribution model:

• Automatic updates — Chrome downloads updates in the background and applies them after the browser restarts. The majority of users with auto-updates enabled form the peak on the latest versions.
• User habits — a significant share of users (especially on desktops) leave their browsers running for weeks without closing them, using sleep or hibernate modes. These users remain on the version that was current when they last launched their browser. This creates a considerable “tail” of users on the previous stable version.
• Enterprise segment — in business environments, long-term support (LTS) versions or pinned versions are often used, which are updated much less frequently.

To understand what constitutes a “normal” fingerprint, it’s not enough to simply know the latest version. It’s essential to understand how users are distributed across the most recent builds. It’s important to remember that this distribution is constantly changing. The snapshot we recorded on 2 July 2025 will look different just a week later. At the time of our research, the situation was as follows:

• 138.0.7204.97 — This is the newest stable version, released just two days ago. Thanks to the staged rollout policy, it is rapidly gaining popularity and is already becoming dominant. Anti-bot systems are starting to use it as a primary marker of “normalcy.”
  Release date: 30 June 2025
  User share: 48%
• 137.0.7151.120 — The last stable release on the 137 engine. Google is gradually phasing it out in favor of the newer version, so its share is steadily declining. Nevertheless, it’s still a very popular version.
  Release date: 18 June 2025
  User share: 32%
• 138.0.7204.50 — The first stable release on the 138 engine, available to users for about a week. Users are now waiting for the next minor update to version .97, which is a completely normal and natural stage in the update lifecycle.
  Release date: 24 June 2025
  User share: 17%
• Earlier versions — A statistical margin of error. This includes devices that have been offline for a long time or systems where auto-updates are forcibly disabled. A concentration of fingerprints on these versions is a clear sign of an artificial fingerprint.
  Release date: May 2025 and earlier
  User share: ˂ 3%

There is no single “correct” version of Chrome. Instead, we see a healthy, dynamic ecosystem in which at least three different builds (.97, .120, .50) coexist simultaneously in significant proportions, collectively covering 97% of all users.

This distribution is merely a snapshot in time. A week ago, it looked different, and in just a few days—as version .97 spreads further—it will change again: the shares of .120 and .50 will continue to decline. It’s precisely this natural, dynamic distribution that constitutes the “healthy” fingerprint expected by risk management systems.

Reaction of Trust and Security Systems

When assessing a user, modern predictive analysis platforms pay attention to a wide range of parameters—and the browser version is one of them. Its significance increases dramatically when it correlates with other anomalies within a group of accounts.

The exact algorithm may vary depending on the specific system, but there’s a common set of suspicious patterns that often negatively impact the success of your operations. Let’s look at examples of red flags that can be detected during version checks.

Outdated Major Version

One of the most obvious signs that something is wrong with the user.

Example: The current stable version of Chrome is 138, but the user is running version 135.

The vast majority of browsers update automatically and in the background. Disabling auto-updates is not a trivial task for an average user. A significant lag (by 2 or more versions) almost always points either to a corporate environment with strict policies or to the use of old software for automation or fingerprint spoofing.

The system compares the detected version with the current stable version worldwide. If the difference exceeds a certain threshold (e.g. 2–4 major versions), the risk assessment increases sharply.

Use of Nonexistent Versions

A direct indication of spoofing and one of the strongest signals for the system.

Example: A user is running version 134.0.6984.1, but in reality, no stable Chrome release has ever existed with that version number.

This is direct proof that the version was modified manually or generated by a low-quality tool. A real browser would never send a version that has never existed (e.g. 134.0.6984.1, 134.0.6990.0, etc.).

Anti-bot systems maintain a database of all publicly released builds for popular browsers. The detected version is simply checked against this list. A missing match is practically a 100% red flag that can lead to immediate blocking or a request for additional verification (CAPTCHA, SMS, KYC).

Use of Outdated or Unpopular Subversion

This is a subtler but highly effective detection method.

Example: The current version of Chrome 137 is 137.0.7151.120 (17 June 2025), but the user is running 137.0.7151.56 (27 May 2025), a lag of more than three weeks.

Google releases security updates and patches for stable Chrome branches quite frequently. This means that within a few weeks after version 137.0.7151.56 is released, the majority of real users will have automatically updated to .69, .104, .120, and so on. If, some time after the release of .120, the system sees a spike in registrations using version .56, that’s an anomaly.

An analytics system collects statistics not just for the major version but for full version strings. The system knows that >95% of Chrome 137 users are currently running builds xxxx.120 and newer. An account with version xxxx.56 falls into the remaining 5%, and if there are many such accounts, it’s almost a guaranteed sign of a farm using the same outdated “snapshot” profile.

Anomalous Concentration on a Specific Version

This method allows systems to detect entire account farms. This pattern has two main variations:

• Concentration on a rare or outdated version. Example: The system sees that, over the past hour, 200 accounts have been created, all reporting the version Chrome/137.0.7151.68—an intermediate release that was current for less than half an hour. The likelihood of such coincidence among real users is zero. This is direct proof of using the same “frozen” and defective fingerprint in terms of distribution.
• Concentration on the current version. Example: As of 2 July, the current version is 138.0.7204.97. If the system records that 50 new registrations are coming from a single IP address or within a single affiliate campaign, all with exactly the same version, this is also a strong signal. Even real users who update promptly, due to staged rollouts, will be distributed across several recent builds (.97, .50, and remnants of .120). Perfectly identical versions are a sign of multi-accounting.

The risk assessment system tracks the entire release history with high precision, including the timing of releases and their rollouts. Sometimes, between two public builds, there are one or more intermediate (transient) builds that were compiled but either never rolled out to users or were available via auto-update for only a very brief period—from a few minutes to a couple of hours—before being replaced by the next, more stable build.

Research: How Popular Anti-Detect Browsers Spoof the Browser Version

Theory is good—but how does this play out in practice? To get an objective picture of the market, we conducted an extensive study of nine popular anti-detect browsers, using a methodology that anyone can replicate.

How to Test Your Anti-Detect Browser?

Data Collection

• Create a session/profile with the latest available engine.
• Go to link.
• Look for the uaFullVersion (or Sec-CH-UA-Full-Version) parameter and note its value.
• Repeat the procedure and collect data from five different sessions/profiles.

You should end up with a list of five versions, for example:

138.0.7204.50 138.0.7204.97 138.0.7204.50 138.0.7204.97 138.0.7204.97

Analysis

So, you now have five Chrome versions collected from your anti-detect browser. How do you know if they’re genuine? For that, we need a reference. All information about real Chrome versions, their release dates, and target platforms (Windows, macOS, Linux, Android) is published in the official Google Chrome Releases blog.

To assess how well your anti-detect browser is spoofing, compare your collected data against this source by answering the questions in the checklist below. The more “yes” answers you get, the harder it will be for anti-bot systems to distinguish you from a real user.

• Is the browser using the engine of the current version?
• Do the versions actually exist?
• Are the versions current (not older than 1.5–2 weeks)?
• Are the versions dynamic (are there at least two different ones)?

Results of Our Research

To objectively assess the current state of the market, we conducted our own research on nine popular anti-detect browsers as of 2 July 2025. The results were mixed and revealed several fundamental approaches to version spoofing, each with its own advantages and critical vulnerabilities.

Instead of analyzing each product in detail, we grouped them by their typical issues, which makes it easier to understand the general trends and mistakes made by developers.

Group 1: “Lagging Behind by an Entire Era”

Outdated browser engine

Let’s start with the most crude and unforgivable mistake. At the time of the research, the current stable version of Chrome was 138. However, GoLogin offers users a core based on version 135, and MoreLogin even uses version 134. Any serious trust system immediately flags such a browser as anomalous because 99% of real users have long since migrated to newer versions thanks to auto-updates.

MoreLogin deserves special attention because it not only uses an outdated core but also generates build and patch numbers that never existed. This is the least effective approach, as it creates a unique, artificial fingerprint that is not just outdated but has never matched any real browser ever released.

Group 2: “Stuck in the Past”

Outdated browser versions

This group of products (Adspower, Multilogin X) demonstrates a more subtle but equally significant problem. Technically, they use the 137 major version, which is still seen among some real users (for example, 137.0.7151.120 has a 32% share). However, the devil is in the details: the specific subversions they use (.55, .56, .68) have been outdated for over a month.

For anti-bot systems that analyze version distributions, this is a clear anomaly. Most real users running the 137 version have long since updated to the latest security patch, while these browsers continue to generate fingerprints from builds that are no longer in active use. The situation is worsened by the static nature of Multilogin X, where all profiles are created with exactly the same outdated version. Additionally, Adspower (.55) and Multilogin X (.68) rely on intermediate releases that were never widely distributed among real users, making the focus on them even more anomalous.

Group 3: “Current but Static”

Static browser version across all profiles

Undetectable and Vision, and more recently Dolphin Anty, represent a significant step forward. All three products use the current engine version (138) and substitute real and current subversions for spoofing. One or two profiles created in such a browser will appear perfectly plausible. However, their key flaw is their static nature. When analyzing 10–15 profiles, they all show the exact same browser version (.97 in the case of Undetectable, .50 for Vision and Dolphin Anty). Combined with unique behavioral factors—which we discussed in the article about the human-like_typing_function — this becomes a classic pattern through which analytics systems detect account farms.

The vulnerability of this approach is clearly illustrated by our preliminary tests conducted on 26 June. At that time, Undetectable and Vision were offering users version 137.0.7151.104. This release took place on 11 June and was indeed current for about a week. However, by the time we conducted our tests, most real users had either updated to a newer build within the same major version (137.0.7151.120) or had moved on to the new 138 version.

The situation with Dolphin Anty before its recent update was even more telling. It, too, used a static version, but an even older one—137.0.7151.56 (released on 28 May). By the end of June, this fingerprint was not just outdated but anomalously old. This example perfectly illustrates the fundamental flaw of a static approach: even an initially valid fingerprint inevitably becomes an easily detectable anomaly over time, exposing the entire network of accounts to risk assessment systems.

Group 4: “Progressive but Flawed”

Anomalous distribution across rare versions Octo Browser demonstrates the most advanced yet paradoxically flawed approach. It correctly uses the current core (138) and, crucially, ensures dynamic version changes across different profiles. At first glance, this seems like the perfect strategy.

However, a closer analysis reveals a critical flaw. The developers included in their spoofing pool all Chrome subversions, including:

• Intermediate builds (e.g. .96, .49, .51), which were available to real users for only a very short time (sometimes less than 20 minutes) before the next patch was released.
• “Early Stable” releases (e.g. .35), which were rolled out to a very limited percentage of devices prior to full deployment.

The key flaw is that the distribution of these versions does not take into account their real-world market share. You have roughly the same chance of getting a widespread, stable build (.50 or .97) as you do of receiving a very rare “Early Stable” version that, in reality, was seen by fewer than 1% of users.

For any anti-bot system, this is a glaring marker. While real traffic is dominated by one or two of the most widespread subversions, Octo Browser creates an anomalous concentration of rare builds. It’s like trying to prove your “normalcy” by constantly paying with rare collectible coins: yes, they’re real, but using them regularly in everyday life is an obvious anomaly that immediately draws attention. Thus, the most progressive approach, in practice, creates an easily detectable pattern, revealing the artificial origin of the fingerprints.

Linken Sphere: How an Ideal Version Spoofing Mechanism Should Work

Our research clearly demonstrates that the anti-detect browser market is full of compromise solutions. Instead of comprehensive protection, users face a set of critical vulnerabilities—from using hopelessly outdated browser cores to spoofing nonexistent or long-obsolete subversions. Even advanced solutions suffer either from static fingerprints, making it easy to cluster user profiles, or from generating an anomalous concentration on rare versions, which is also a red flag for trust platforms.

Precisely to comprehensively solve these issues, the latest update of Linken Sphere introduced a fundamentally new, innovative mechanism for handling browser versions. Its goal is not merely to create a plausible fingerprint but to simulate the natural evolution of a real user’s digital fingerprint.

It’s based on three key principles:

1. Relevance and Realism
   We don’t just use the latest engine version. Our system continuously monitors official stable releases of Google Chrome, analyzing their real-world percentage distribution across the web. We select only widespread, existing versions.
2. Dynamic Generation
   When creating a new session (profile), it is assigned a random but guaranteed existing and currently relevant subversion from a pool of valid versions. This eliminates the problem of static fingerprints, which anti-bot systems can use to group your profiles. Similarly, when upgrading the engine (e.g. from v137 to v138), the session also receives a randomly selected new, relevant subversion.
3. Automatic Fingerprint Evolution

And most importantly: as Google releases new patches, the subversions in your existing profiles are updated automatically and in the background, mimicking natural user behavior.

For example, suppose you created a session when version .56 was current. Then Google releases the next patch .69; your session doesn’t update immediately, simulating the behavior of real users. However, once another release comes out—for instance, .104—and the gap between your session’s version and the current one becomes significant, the system triggers the evolution mechanism. At that point, your older sessions begin to update, but not uniformly: some transition to the intermediate version .69, while others jump directly to the latest .104, creating a highly natural and diverse distribution.

Thus, you don’t need to wait for a client update for your sessions to receive current subversions. This process in Linken Sphere happens seamlessly and automatically, whereas updating the client itself is only necessary for global transitions to the next Chrome engine version.

This creates not merely a static “snapshot” but a living, evolving digital fingerprint that consistently matches the behavior of real users online.

Conclusion

The arms race between detection systems and anonymity tools has long entered a new level. The days when simply having an up-to-date engine version was enough for successful operation are gone for good. As our research has shown, modern risk assessment systems analyze not just the major version, but its entire structure, paying special attention to the last digits—the build and patch numbers. It is precisely in these details, in the dynamics of their updates and their distribution among real users, that the key to a natural fingerprint lies.

Most antidetect browsers on the market offer users a static version—a “frozen” snapshot that, even if current at the time of creation, inevitably becomes outdated, turning into yet another detection vector. Linken Sphere offers a fundamentally different, proactive approach. It’s not merely camouflage—it’s full-scale mimicry. Your sessions don’t just look real—they live and evolve alongside the Chrome ecosystem, automatically and invisibly receiving the latest security patches just as millions of ordinary users do. Your fingerprint ceases to be a static target and becomes an indistinguishable part of the natural digital landscape.

Stop relying on fingerprints frozen in time. In a world where everything is constantly updating, any static pattern is an anomaly. And every anomaly is only a matter of time before detection and blocking. Ask yourself: does your tool create digital camouflage—or a digital target?