WebGPU Atomic Fingerprint: How the GPU Becomes a New Data Source for Antifraud Systems

Until recently, GPU fingerprinting in browsers was primarily associated with WebGL: a website would force the browser to render a given scene, analyze the result, and receive an additional signal to identify the device. Anti-detect browsers have long since learned to bypass such checks by changing declared parameters, interfering with rendering, adding noise, or simply altering the result. With the advent of WebGPU, the story becomes much more interesting.

The new API gives web pages much more direct access to the GPU's computing power—meaning the GPU is transformed from a device for rendering images into a tool that can be given work and then watched. For antifraud, this is a fundamental difference. It's one thing to ask the browser, "What graphics card do you have?" It's quite another to give that graphics card a task and watch how the actual hardware performs it. This is precisely the idea behind WebGPU Atomic Fingerprint, discussed in the Vektor T13 webinar.

For the average user, the technology is almost invisible. However, for anti-detection browser developers, multi-account specialists, and, increasingly, for the infrastructure of browser AI agents, it is of significant interest. The more browser automation migrates to VPS, virtual machines, and server farms, the wider the gap between what the browser claims to be running on and the hardware it actually runs on. WebGPU gives anti-fraud a new way to detect this gap.

The old approach: ask the browser who it is

Classic browser fingerprinting is primarily based on reading environmental characteristics: what browser, what operating system, what screen resolution, what fonts are installed, how Canvas behaves, what WebGL renderer is available, what hardware capabilities the system reports. The weakness of this approach is obvious: if data comes through an API, there's always a software layer between the website and the actual device—and that layer can theoretically be modified.

This is precisely what anti-detection browsers do: they try to show the website a consistent set of characteristics that differs from the actual machine configuration. The browser may be running on a server, but the website sees the profile of a regular home computer running Windows and a popular NVIDIA GeForce graphics card. At the simple API level, this seems quite convincing. But if you ask a different question—not "What kind of device is this?" but "Let the device figure something out"—then the game changes entirely.

Why a long hash is not yet a fingerprint

One of the useful insights from the webinar concerns a common mistake when working with fingerprint checkers. If a service displays a nice, long hash next to the "WebGPU" label, it's easy to assume it's a unique hardware fingerprint. In fact, the mere presence of a hash proves nothing: a hash is simply the result of transforming a set of data, and if the original data is nearly identical across millions of devices, a seemingly complex string doesn't become a magical identifier.

Therefore, when analyzing any checker, it's much more useful to look not at the final string, but at the data from which it's compiled. If a service uses a standard set of WebGPU limits and features, most of these parameters will match across a huge number of machines—such a hash is convenient for comparing configurations, but it can't be automatically considered a unique fingerprint for a specific graphics card. Hence the simple but important habit: ask not "what hash did the checker show?" but "what exactly does it measure?"

From declaration to behavior

The value of WebGPU is that it allows one to move some fingerprinting from the declaration domain to the behavioral domain. Instead of reading yet another parameter, one can launch a computational task. The test in question uses compute shaders and atomic operations: multiple parallel threads work with a shared counter via Atomic Add. For the average developer, this is simply a mechanism for synchronizing parallel computations. For fingerprinting researchers, something else is of interest: how exactly the GPU organizes and schedules this parallel work.

A modern graphics card isn't just a set of identical computing units: the distribution of tasks is based on a complex hardware and software architecture, and the resulting behavior is influenced by the GPU generation, drivers, load scheduler, performance settings, and environmental factors. It's a kind of experiment. The website doesn't ask, "Do you have an RTX 2080?" – it says, "Here's the task, run it," and then analyzes the execution profile. That's the point: a declaration can be replaced with a string, but the behavior of real hardware is much more difficult to fake.

What does this change for anti-detection browsers?

Let's take a typical configuration. The profile tells the website that the user is working on a regular home computer with a discrete NVIDIA graphics card, the User Agent matches the standard Chrome browser on Windows, and the other parameters are also carefully selected. But the browser is actually running on a VPS, which doesn't have the stated graphics card. Up to a certain point, this discrepancy can be hidden at the API level: querying the GPU model returns the desired value, checking the WebGL renderer returns the correct result.

A computational test poses a different question: if the claimed hardware actually exists, why does the actual computational behavior resemble it so differently? This doesn't mean that a single WebGPU test can definitively declare "we have an anti-detect"—anti-fraud software almost never works so crudely. But another strong signal emerges, and these are precisely the signals needed by modern risk assessment systems. The most interesting thing here isn't identifying the graphics card model, but finding a contradiction: the browser claims one thing, but the hardware's behavior says something else. It is precisely these internal inconsistencies in the digital identity that increasingly interest anti-fraud software.

Why 70% accuracy is a lot

The webinar cites a figure of approximately 70% identification accuracy for this approach. Without a description of the methodology, this shouldn't be taken as a universal characteristic of any WebGPU Atomic Fingerprint, but the very formulation of the question clearly illustrates the anti-fraud logic. An outsider might think, "Only 70%? That means the test is unreliable." For anti-fraud, this is flawed logic—it doesn't need a single, perfect signal with 100% accuracy.

Imagine a system that simultaneously monitors browser characteristics, User-Agent, IP type and reputation, ASN, geography, behavioral parameters, Canvas, WebGL, WebGPU, CPU and GPU performance, signs of virtualization, and account history. Each indicator alone can be wrong, but their combination yields a completely different result. It's like an investigation: a single piece of evidence rarely solves the case, but a dozen independent facts pointing in the same direction carry a completely different weight. Therefore, even a moderately accurate hardware signal proves truly useful.

A checker is not an anti-fraud tool.

This is a particular pain point for the anti-detection browser market. A user opens a public checker, sees green values, and concludes that the browser has passed the test. But a checker and a real anti-fraud system solve different problems. A public checker needs to provide a user-friendly result; a real system may not even disclose which signals it collects and what weight it assigns to each. Moreover, it doesn't necessarily need to compare your fingerprint with some "correct" standard—it's enough to notice a statistically unusual combination of characteristics.

Therefore, when testing an anti-detection environment, the correct question is not "Did I pass the checker?" but "Does the actual device behavior match the profile the site sees?" The difference between these questions is enormous.

Randomization also leaves a mark

When a new fingerprint appears, the market's initial reaction is predictable: it needs to be randomized. This works for some fingerprint types, but with computational characteristics, a fundamental problem arises. If the change occurs not naturally, at the hardware and driver level, but artificially—inside the browser—a new layer of behavior is introduced. And this layer can also be explored.

Instead of asking "is the fingerprint identical?", the anti-fraud system begins asking other questions: how stable is the result, is it consistent with other hardware characteristics, does it plausibly change between runs, is the declared GPU model even capable of demonstrating such behavior. It's an endless race: we hide one signal, and the system begins analyzing the very mechanism by which it's spoofed. This is precisely why primitive randomization gradually reaches a dead end: for a stable profile, the internal consistency of the environment is more important than a random result.

The test does not necessarily load the video card to 100%

There's another important detail. When it comes to GPU fingerprinting through computation, it's easy to imagine a heavy benchmark: fans spin up, graphics card load jumps to 100%, and the user immediately senses something is wrong. But the test doesn't necessarily have to be heavy. In the webinar demo, Atomic Fingerprint runs quite quickly and doesn't cause a noticeable load spike—and that's the key point.

Fingerprinting doesn't require a full-scale GPU performance measurement; a small, tailored computing task may be sufficient for identification. This is convenient for the website: the test is integrated into the regular page load, preventing a visit to the online store from turning into a FurMark launch, and the user may not notice anything at all. This is precisely why WebGPU is so attractive to antifraud software: it allows access to relatively low-level computations directly from the web page, without the need to install a separate application.

From multi-accounting to AI agents

Several years ago, the main audience for such research was anti-detection browser developers, affiliate marketers, and multi-account specialists. Now, another huge category has joined them: browser AI agents. Such agents constantly interact with regular websites: search for information, fill out forms, use SaaS, manage dashboards, and test interfaces—usually using Playwright, Chromium, and other automation frameworks. And all of this is most often run not on the user's laptop, but in the cloud.

A single server can host dozens of browsers: the orchestrator creates and destroys containers, sessions migrate between nodes, each browser is assigned its own profile, and externally, they all appear as separate devices. This is usually sufficient for classic automation, but not for serious device fingerprinting. The logical identity of the agent begins to diverge from the physical identity of the machine: the agent considers itself one device, the browser profile describes another, the GPU belongs to a third infrastructure, the IP comes from a fourth network—and all of this is simultaneously available to the risk assessment system.

This gives rise to a new class of correlation signals. Imagine a platform that runs hundreds of browser agents in parallel: each with its own profile, cookies, local storage, and screen resolution, so at the application level, these are 100 independent users. But physically, they could all be running on several identical servers. And if dozens of supposedly independent devices exhibit very similar low-level computing behavior, the system has reason to suspect a common source of infrastructure. For multi-accounting, this is an old problem in a new form; for the AI ​​agent industry, it's a problem whose scale is only just beginning to emerge. And it affects even those who run agents completely legally: sooner or later, we'll have to understand why websites perceive such infrastructure as suspicious automation.

It's becoming increasingly difficult to pass off a VPS as a regular PC

A virtual server is convenient for almost everyone: it's inexpensive, available 24/7, easily cloned, and ideal for automation. But it doesn't have to look like a regular user computer—and the more hardware specifications become accessible through a browser, the harder it is to ignore this difference. Previously, you had to work mostly with what the system reported; now you can test how it actually behaves.

WebGPU Performance shows one side of the question—how fast certain GPU operations execute. Atomic Fingerprint adds another—how parallel execution behaves. And such tests will likely become more common over time, and not just for the graphics card: CPU, memory, timers, scheduler features, virtualization, the graphics stack—a modern browser presents a vast surface area for measurement.

WebGL is here to stay

The original webinar describes WebGL fingerprinting as a technology that should give way to WebGPU, and it's worth clarifying here. The emergence of a stronger signal doesn't usually mean that the old one is immediately stopped being collected: a cheap additional anti-fraud feature is almost always useful. Therefore, it's more correct to view WebGPU not as a button that will "replace WebGL," but as the next layer of hardware fingerprinting. WebGL provides one set of features, WebGPU another, performance testing a third, and User-Agent and Client Hints a fourth. Anti-fraud doesn't need to choose just one; the system's strength lies in the combination.

For the same reason, the opposite approach—disabling WebGPU completely—is also ineffective. This is useful as a diagnostic technique: you can compare a site's behavior with and without the API and determine whether anything depends on its availability. But as a permanent strategy, disabling it is less effective, since the absence of technology is also a characteristic. If WebGPU becomes a standard feature of modern browsers, a profile with the API completely disabled may stand out from the crowd. Moreover, WebGPU is increasingly needed not for fingerprinting, but for graphics, computing, and a growing number of web applications, including some AI workloads directly in the browser. This leads to a familiar trap: indefinitely increasing privacy by simply disabling the API won't work—at some point, the very set of disabled features becomes a fingerprint.

Antifraud doesn't look for the "bad," but for the strange.

Perhaps this is the most important takeaway from the whole WebGPU story. Antifraud is often presented as a set of detectors: VPN is bad, proxy is bad, WebGPU mismatch is bad, automation is bad. Real systems are more complex. A corporate network user is perfectly legally connected to a VPN; a developer is working inside a virtual machine; a cloud gaming service provides a remote GPU; an AI agent is, by definition, automation. Therefore, one fact alone isn't enough—the system tries to understand the context and evaluate the plausibility of the entire combination. And this is where poorly assembled environments begin to have problems: the browser claims one thing, the GPU shows another, performance a third, IP tells a fourth story, and user behavior a fifth. Each characteristic is acceptable individually, but together they create a device that is difficult to find in the real world.

This is precisely why the era of static fingerprints is gradually ending. The market has long lived with the idea that a fingerprint is a set of values: Canvas hash, WebGL hash, AudioContext, fonts, screen resolution, hardware concurrency. Collect these values, glue them together, and you get an identifier. A more interesting trend today is active fingerprinting, where a website doesn't simply ask a device about its characteristics, but assigns it a task and monitors its response. This is much closer to behavioral biometrics, except the object is a computer rather than a person: how quickly an operation is performed, how the parallel load is distributed, how stable the result is, how the system behaves under changing conditions, and whether all of this matches the declared hardware. Forging the answers to such questions is relatively easy. Forging the entire physics of a system's behavior is much more difficult.

What does this mean for the market?

For anti-detect browser developers, the conclusion is rather unpleasant: fingerprinting is moving ever further down the stack. Simply changing the JavaScript API is no longer sufficient—the closer the measurement gets to actual hardware behavior, the more difficult it is to construct a plausible abstraction. For multi-account specialists, this means that the quality of the infrastructure is becoming more important than the number of switches in the anti-detect interface: a green checker alone guarantees nothing. Arbitration teams should assess infrastructure risk separately from the quality of the IP and browser profile—an expensive residential proxy does not resolve inconsistencies at the device level.

For AI agent developers, the problem is even broader: they must design not only the agent's intelligence but also its interaction with the external digital environment. If thousands of autonomous browsers operate in the cloud, websites will inevitably learn to distinguish such infrastructure from regular user devices. This doesn't necessarily mean blocking—with time, proper mechanisms for identifying legitimate agents may well emerge. But until they do, browser automation exists within an infrastructure historically designed for humans—and antifraud software sees this contradiction.

WebGPU is just the beginning

Atomic Fingerprint itself shouldn't be seen as a new, universal technology that will wipe out anti-detection browsers tomorrow. Anti-fraud technology evolves differently: a new signal emerges, it's analyzed, then methods for normalization and protection emerge, the anti-fraud technology learns to analyze these methods, and then another source of information is discovered. WebGPU is more important as a directional indicator. The browser is becoming an increasingly powerful computing platform, which means that a website can not only read information about a device but also experiment with it.

For specialists, this changes the very approach to fingerprinting. The main question is no longer "What does the browser report about the computer?" but "Does the computer's behavior match what the browser reports?"—and the difference between the two is enormous. In the world of static fingerprints, one could focus on the correct values; in the world of active fingerprinting, one must think about the correct behavior of the entire environment. Therefore, WebGPU Atomic Fingerprint is of interest even to those who never plan to write their own GPU checker: it clearly demonstrates where modern anti-fraud is heading—from checking individual parameters to checking the internal consistency of the device. For an affiliate marketer, this means that looking only at IP addresses and green indicators is no longer enough; for an anti-detection developer, it means the boundary between the browser and the hardware is becoming increasingly important; for an AI agent engineer, it means the execution infrastructure itself is becoming part of the agent's identity. And for anti-fraud, it's another way to ask the device a simple question: "Are you really the computer you claim to be?"