The GPU Serial Number: How Brave Is Fighting the Next Generation of Web Tracking

Brave 1.93 is taking aim at one of the web’s most persistent tracking surfaces: GPU fingerprinting. Modern websites can use WebGL and WebGPU to learn surprisingly detailed information about a device’s graphics stack, including GPU vendor and renderer information, supported extensions, adapter descriptors and other hardware-related signals. Combined with other browser characteristics, these signals can help trackers distinguish one device from another without relying on cookies or locally stored identifiers.

Instead of disabling WebGL and WebGPU, Brave is using a technique called farbling to make these signals less useful for tracking. The browser replaces identifying WebGL vendor and renderer information with generic values, empties WebGPU adapter descriptors and randomizes WebGL extension information across different browsing contexts. The goal is straightforward: preserve the graphics capabilities that legitimate websites need while making the GPU a much less reliable identifier.

This article goes deep into how that works. We’ll look at how WebGL and WebGPU expose GPU information, how trackers turn those signals into fingerprints, why simply blocking graphics APIs creates its own problems, how Brave’s farbling is scoped across sessions and sites, what the protection does and does not stop, and what developers need to know about building WebGL and WebGPU applications in an increasingly privacy-conscious browser ecosystem.

Fingerprinting After Cookies

A cookie is a piece of state. A fingerprint is an inference.

With cookies, the tracking problem is relatively concrete: a server writes an identifier into the browser, and later reads that identifier back. Privacy defenses therefore focus on preventing the write, preventing the read, isolating the storage, or deleting it entirely.

Fingerprinting flips the model. Instead of giving the browser an identifier, the tracker derives an identifier from what the browser already reveals. The browser is constantly communicating details about itself because the web is a dynamic environment. Sites need to know how to lay out content, what media formats are supported, what rendering capabilities exist, what input methods are available, and how to optimize experience. Those same signals can be combined into a profile.

A fingerprinting system typically collects a vector of attributes:

screen.width
screen.height
devicePixelRatio
timezone
language
platform hints
user agent hints
canvas rendering output
audio context output
WebGL vendor string
WebGL renderer string
WebGL extension list
WebGPU adapter descriptors
WebGPU feature and limit values
font enumeration signals
hardware concurrency
device memory hints

Individually, many of these signals are not uniquely identifying. A timezone is shared by millions of people. A screen resolution is common. A language setting is common. A GPU vendor is common.

But the combination is often rare.

If a tracker knows that a device has a particular screen size, a particular time zone, a particular language, a particular GPU model, a particular driver-reported renderer string, and a particular list of WebGL extensions, the set of matching devices can become very small. In some cases, it collapses to one.

This is why fingerprinting is so durable. There is no cookie to clear. There is no storage partition to isolate. The identifier is reconstructed from the environment.

The GPU is especially dangerous in this model because GPU hardware is relatively stable. Users do not replace their graphics cards every day. Laptop users often cannot replace the GPU at all. Driver updates can change some details, but the underlying vendor, model family, architecture, and feature set tend to remain stable enough for tracking.

Research cited by Brave from Ben-Gurion University found that WebGL fingerprinting alone could identify a device with 98% accuracy in 150 milliseconds. Even if real-world conditions vary, the point is clear: graphics APIs are not a minor fingerprinting side channel. They are a primary identification surface.

Why the GPU Is Such a Strong Identifier

A modern GPU is not just “a graphics card.” It is a highly specific combination of hardware, firmware, driver, operating system integration, and browser translation layer.

At the highest level, a GPU fingerprint can include:

1. Vendor
   NVIDIA, AMD, Intel, Apple, Qualcomm, ARM, Broadcom, and others.
2. Device family or model
   RTX 4090, Radeon RX 7900 XTX, Apple M3 Pro, Intel Iris Xe, Adreno 740, Apple M5 Max, and so on.
3. Driver version and behavior
   Different driver versions expose different extensions, report different strings, or behave subtly differently under rendering tests.
4. Supported graphics extensions
   WebGL extensions represent optional capabilities. The exact list depends on the GPU, driver, OS, and browser.
5. Renderer string
   A string that may describe the underlying renderer, driver backend, or translation layer.
6. Shader and capability limits
   Maximum texture size, maximum viewport dimensions, number of texture units, supported precision formats, floating-point capabilities, and more.
7. Active rendering behavior
   How the GPU rasterizes a hidden image, how it handles antialiasing, how it rounds floating-point values, how it compresses textures, how quickly it completes certain operations, and how it produces pixel readbacks.

Some of these are passive metadata: strings and lists that can be queried directly. Others are active signals: the tracker asks the GPU to render something and observes the result.

Brave’s new rollout focuses primarily on the passive metadata exposed through WebGL and WebGPU: vendor strings, renderer strings, adapter descriptors, and extension lists. These are among the easiest signals for trackers to collect and among the most directly identifying.

The reason is simple: they often contain human-readable hardware descriptions.

A tracker does not need to perform expensive rendering tests if the browser is willing to say, in effect, “I am an Apple MacBook Pro with an M-series GPU using Metal.” That is a massive head start.

WebGL: The Classic GPU Fingerprinting Surface

WebGL is the browser’s API for hardware-accelerated graphics based on OpenGL ES. It allows JavaScript to create a rendering context, compile shaders, allocate GPU buffers, bind textures, issue draw calls, and render 2D or 3D content directly in the browser.

It powers games, maps, data visualizations, product configurators, virtual showrooms, CAD viewers, machine learning demos, creative tools, and countless other experiences.

From a privacy perspective, WebGL is interesting because it sits at the intersection of JavaScript and the GPU process. A webpage does not talk to the GPU directly in the raw hardware sense. The browser mediates that access. But the mediation still exposes a great deal of information.

A WebGL context is usually created like this:

const canvas = document.createElement("canvas");
const gl = canvas.getContext("webgl") || canvas.getContext("experimental-webgl");

Once the context exists, scripts can query the WebGL state machine.

For example, OpenGL historically exposes strings such as VENDOR and RENDERER. In WebGL, scripts can call getParameter with specific constants. In addition, the WEBGL_debug_renderer_info extension historically exposed more detailed unmasked strings.

A simplified fingerprinting query might look like this:

const gl = canvas.getContext("webgl");
const debugInfo = gl.getExtension("WEBGL_debug_renderer_info");
if (debugInfo) {
  const vendor = gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
  const renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);
  console.log(vendor, renderer);
}
const extensions = gl.getSupportedExtensions();
console.log(extensions);

That is technically simple, but privacy-wise powerful.

The WEBGL_debug_renderer_info extension is especially important. Brave’s post notes that WebGL can expose highly detailed debug strings such as:

ANGLE (Apple, ANGLE Metal Renderer: Apple M5 Max)

on an Apple MacBook Pro with an M-series chip, as tested on EFF’s Cover Your Tracks tool.

That string is not just “Apple GPU.” It includes the platform translation layer, the backend, and a detailed device identifier. It can tell a tracker a lot about the hardware and software environment.

The history is also instructive. According to Brave, this debug extension was originally exposed by Google Chrome for Google Maps before becoming available to all websites. That is a common pattern on the web: a capability is introduced for a legitimate use case, and then becomes part of the general web platform surface. Once exposed, it can be abused.

ANGLE and the Hidden Complexity of WebGL Renderer Strings

Many users think of WebGL as “OpenGL in the browser.” In practice, browsers often do not expose the system OpenGL stack directly. They use translation layers.

The most famous is ANGLE, which stands for Almost Native Graphics Layer Engine. ANGLE translates OpenGL ES API calls into native graphics backend calls. On different platforms, the backend might be Direct3D, Metal, Vulkan, or another native API.

This is necessary for portability, security, sandboxing, and driver compatibility. But it means the WebGL renderer string can reveal not only GPU information, but also the browser’s graphics stack.

For example, a WebGL renderer string might contain:

ANGLE (NVIDIA, NVIDIA GeForce RTX 4090 Direct3D11 vs_5_0 ps_5_0, D3D11)

or:

ANGLE (Apple, ANGLE Metal Renderer: Apple M5 Max)

or:

ANGLE (Intel, Intel(R) Iris(R) Xe Graphics Direct3D11 vs_5_0 ps_5_0, D3D11)

These strings are extremely useful for debugging. They help developers understand why a graphical effect fails on a specific device. But they are also excellent fingerprinting material.

A tracker can parse the string and extract:

• Vendor: NVIDIA, Intel, AMD, Apple
• GPU model or family: RTX 4090, Iris Xe, M5 Max
• Backend: Direct3D, Metal, Vulkan, OpenGL
• Shader model or feature hints
• Browser-specific formatting patterns

Even if the browser masks some values, the structure of the string can leak information. That is why simply truncating a string is often not enough. A robust privacy defense needs to replace the entire value with something generic and uniform.

Brave’s approach does exactly that for WebGL vendor and renderer strings: it replaces them with a single generic string, ensuring all Brave users get identical values.

This removes a large amount of device-specific entropy.

WebGL Extensions: A Compact Hardware Signature

The WebGL extension list is another major fingerprinting surface.

WebGL extensions are optional capabilities exposed by the GPU, driver, browser, or platform. They are not guaranteed to exist on every device. Some extensions are widely supported. Others are rare. Some are vendor-specific. Some are tied to texture formats, shader features, compression schemes, floating-point behavior, or debugging facilities.

Examples include:

OES_texture_float
OES_texture_float_linear
OES_element_index_uint
WEBGL_compressed_texture_s3tc
WEBGL_compressed_texture_etc
WEBGL_compressed_texture_astc
EXT_texture_filter_anisotropic
EXT_color_buffer_float
WEBGL_draw_buffers
WEBGL_depth_texture
WEBGL_debug_renderer_info
WEBGL_lose_context

The exact list varies depending on the combination of:

• GPU hardware
• GPU driver
• Operating system
• Browser vendor
• Browser version
• Graphics backend
• Security restrictions
• Power-saving mode in some cases
• Whether the context is WebGL1 or WebGL2

A tracker can call:

gl.getSupportedExtensions()

and receive an array of strings.

At first glance, an extension list may seem less identifying than a renderer string. After all, many extensions are common. But fingerprinting does not require each signal to be rare. It requires the combination to be rare.

Consider a simplified example:

Device A:
["OES_texture_float", "WEBGL_compressed_texture_s3tc", "EXT_texture_filter_anisotropic"]
Device B:
["OES_texture_float", "WEBGL_compressed_texture_etc", "EXT_color_buffer_float"]

Those differences may reflect different hardware vendors, operating systems, or GPU capabilities. A tracker can sort the list, serialize it, and hash it:

hash(sorted(extensions.join("|")))

That hash becomes a compact identifier.

If the extension list is stable across sessions, it is valuable. If it is stable across sites, it becomes cross-site tracking material. If it is combined with other signals, it becomes even stronger.

Brave’s defense is to inject randomization into the WebGL extension list. The goal is not to make the browser report no extensions, which would break functionality and create an obvious fingerprint. The goal is to make hash-based fingerprinters see different values per session, per site, and per storage area.

That changes the threat model fundamentally.

Instead of a stable extension hash, the tracker gets a moving target.

WebGPU: A Newer API, a Newer Fingerprinting Surface

WebGPU is the next-generation browser GPU API. It is designed to give websites more direct and efficient access to modern GPU capabilities, especially for compute shaders, machine learning, advanced rendering, and high-performance graphics.

Where WebGL is modeled on OpenGL ES, WebGPU is modeled on modern explicit graphics APIs such as Vulkan, Metal, and Direct3D 12. It exposes concepts like adapters, devices, queues, command encoders, render pipelines, compute pipelines, bind groups, and shader modules.

From a fingerprinting perspective, the most important early object is the adapter.

Conceptually, a script can ask the browser for a GPU adapter:

if (navigator.gpu) {
  const adapter = await navigator.gpu.requestAdapter();
}

The adapter represents a GPU or GPU-like device. Historically and depending on implementation, adapters can expose descriptors such as vendor, architecture, device, description, and other metadata.

Brave gives an example of WebGPU returning descriptors like:

{
  "vendor": "apple",
  "architecture": "metal-3"
}

That is already a strong signal.

A WebGPU adapter may reveal:

• Whether the device is Apple, NVIDIA, AMD, Intel, Qualcomm, or another vendor
• The architecture family
• The device identifier or device class
• Backend hints such as Metal, Direct3D, Vulkan
• Feature support
• Limit values

Some of this is necessary for developers. Web applications that perform GPU compute may need to know whether certain features are available. A machine learning demo may need to know whether the adapter supports a particular texture format or shader capability. A game may need to choose rendering paths based on GPU limits.

But trackers do not need full functionality to exploit these signals. They only need enough metadata to identify the device.

Brave’s mitigation is direct: it empties out the WebGPU adapter descriptors. In other words, the fields that would otherwise reveal vendor, architecture, or device identifiers are scrubbed.

This is a major privacy improvement because WebGPU is likely to become increasingly important. As more sites use WebGPU for compute, graphics, and AI workloads, protecting it from fingerprinting is not a niche concern. It is foundational.

How a Tracker Turns GPU Signals into an Identifier

To understand Brave’s defenses, it helps to think like a fingerprinting system.

A tracker does not necessarily want to know your name. It wants to assign a stable pseudonym to your device. If it can recognize the same device on Site A, Site B, and Site C, it can build a behavioral profile.

A simplified GPU fingerprinting pipeline looks like this:

1. Create a hidden canvas.
2. Request a WebGL or WebGPU context.
3. Query vendor and renderer strings.
4. Query supported extensions.
5. Query feature flags and limits.
6. Normalize values.
7. Hash the result.
8. Combine with other fingerprinting signals.
9. Store the resulting identifier in a server-side database.
10. Match future visits against the same fingerprint.

The tracker does not need to store a cookie on the user’s machine. The fingerprint is regenerated each time.

For example, a tracker might collect:

renderer: "ANGLE (Apple, ANGLE Metal Renderer: Apple M5 Max)"
extensions: ["EXT_color_buffer_float", "WEBGL_compressed_texture_astc", ...]
maxTextureSize: 16384
maxVertexUniformVectors: 1024
timezone: "Asia/Kolkata"
language: "en-IN"
screen: "2560x1600"

It then hashes the combination.

If the same device visits another site with the same tracker, the same values reappear. The tracker recognizes the device even if cookies are blocked.

This is why fingerprinting is often described as a probabilistic identification problem. The tracker may not always be 100% certain, but it does not need perfection. High confidence is enough for advertising networks, fraud scoring, bot detection, price discrimination, or cross-site profiling.

Brave’s goal is to remove the stability that makes this possible.

Why Blocking WebGL and WebGPU Entirely Is Not the Right Answer

The most obvious privacy defense is to block the APIs entirely.

If WebGL and WebGPU are disabled, trackers cannot query them. Problem solved, right?

Not quite.

Blocking graphics APIs has three major problems.

It breaks the web

WebGL and WebGPU are not only used by trackers. They are used by legitimate sites for essential and valuable functionality.

Examples include:

• Interactive maps
• 3D product configurators
• Browser games
• Data visualization dashboards
• Virtual tours
• Educational simulations
• Video and image editing tools
• Web-based CAD
• Machine learning demos
• Scientific visualizations
• Creative coding environments
• WebAssembly graphics engines

Blocking WebGL or WebGPU by default would make large parts of the modern web unusable. That is not an acceptable tradeoff for a general-purpose browser.

It creates its own fingerprinting signal

If a browser completely blocks WebGL, that absence is itself a signal.

A fingerprinting script can detect:

if (!window.WebGLRenderingContext) {
  // unusual
}
const canvas = document.createElement("canvas");
const gl = canvas.getContext("webgl");
if (!gl) {
  // also unusual
}

If only a small population disables WebGL, that population becomes more identifiable, not less. Privacy protections that are rare or opt-in can inadvertently make users stand out.

It sacrifices usability for a false sense of privacy

A browser that breaks popular websites in the name of privacy may protect against some tracking, but it also pushes users toward disabling protections. If privacy comes at the cost of a broken web, many users will turn it off.

Brave’s philosophy, as described in the post, is that this is a false tradeoff. Strong privacy should not require expert users to enable hidden flags, use special modes, or install extensions that introduce their own security and privacy risks.

That is why Brave uses farbling instead of blanket blocking.

Farbling: Plausible Values, Unstable Fingerprints

Brave’s term for this approach is farbling.

Farbling is not merely lying randomly. Random lying is easy, but random lying can break websites or reveal the browser’s privacy defenses. The challenge is to return values that are privacy-preserving but still functional.

Brave’s new GPU protections have three main components:

1. Replace WebGL vendor and renderer strings with a single generic string.
2. Empty out WebGPU adapter descriptors.
3. Inject randomization into the WebGL extension list.

Each addresses a different fingerprinting channel.

Together, they reduce the stability and uniqueness of GPU-derived identifiers.

Replacing WebGL Vendor and Renderer Strings

The first protection targets the most obvious identifier: the WebGL vendor and renderer strings.

In a normal, unprotected browser, these strings can reveal detailed information about the GPU and graphics stack. A renderer string may include the GPU vendor, model, backend, and translation layer. That is almost a hardware serial number for fingerprinting purposes.

Brave replaces these strings with a single generic string.

The privacy benefit comes from uniformity. If all Brave users report the same generic value, then that value stops being a differentiator within Brave’s user base. It may still indicate that the browser is Brave, or that the browser has certain privacy protections enabled, but it no longer reveals the exact GPU model.

This is an important distinction.

Fingerprinting defense operates on multiple levels:

• Reduce uniqueness among privacy-protected users.
• Remove stable hardware identifiers.
• Prevent cross-site correlation.
• Preserve enough functionality for websites to work.

A generic WebGL string may still tell a site that the browser supports WebGL. That is necessary. If the browser reported no renderer string at all, many sites would fail. But the exact model is no longer exposed.

For example, instead of revealing:

ANGLE (NVIDIA, NVIDIA GeForce RTX 4090 Direct3D11 vs_5_0 ps_5_0, D3D11)

the browser can report something generic. The precise string is less important than the fact that it is common across Brave users.

The tracker loses a high-entropy signal.

Emptying WebGPU Adapter Descriptors

WebGPU descriptors are another direct hardware identification channel.

If a WebGPU adapter reports:

{
  "vendor": "nvidia",
  "architecture": "turing",
  "device": "0x2684"
}

or:

{
  "vendor": "apple",
  "architecture": "metal-3"
}

then a tracker can immediately classify the device.

Brave empties these descriptors.

This is conceptually similar to replacing WebGL renderer strings, but it is adapted to WebGPU’s object model. Instead of modifying a string, Brave removes or empties the descriptor fields that would otherwise expose identifying information.

This is especially important because WebGPU is newer. If privacy defenses arrive after an API is widely abused, the ecosystem normalizes fingerprinting. If privacy defenses are present early, they can shape the web platform’s practical privacy baseline.

There is also a compatibility angle. WebGPU developers should generally use feature detection and capability checks rather than parsing vendor or architecture strings. If a site needs to know whether a particular texture format or compute capability is supported, it should query that capability in a structured way. Relying on raw adapter descriptors is fragile and privacy-hostile.

By emptying descriptors, Brave encourages better engineering practices.

Randomizing the WebGL Extension List

The third protection is more subtle: randomizing the WebGL extension list.

Vendor and renderer strings are high-entropy identifiers, but they are also obvious. Extension lists are more dangerous because they appear technical and harmless. A list of supported extensions seems like capability information, not identity information. But for fingerprinting, capability information is identity information.

Brave injects randomization into the extension list so that hash-based fingerprinters see different values:

• per session,
• per site,
• per eTLD+1,
• and per storage area.

This is a carefully designed threat model.

Let’s break it down.

Per Session

If the extension list changes every browser session, long-term tracking becomes harder. A tracker that sees one extension hash today cannot assume the same hash tomorrow.

This does not eliminate tracking completely. A sophisticated tracker might try to probabilistically match based on other signals. But the GPU extension hash is no longer stable across restarts.

Per Site

If the extension list differs per site, then cross-site correlation becomes harder.

Suppose site-a.com and site-b.com both include the same tracker. If the tracker receives the same GPU extension hash on both sites, it can link the visits. If the values differ by site, that link is broken or weakened.

This is the same general idea as storage partitioning, applied to fingerprinting signals.

Per eTLD+1

The eTLD+1, or effective top-level domain plus one label, is the registrable domain. For example:

www.example.com
shop.example.com
blog.example.com

all share the eTLD+1:

example.com

Using eTLD+1 helps preserve functionality within the same site while separating different sites. A page on shop.example.com can still behave consistently with www.example.com, but a different registrable domain does not automatically get the same fingerprint values.

Per Storage Area

The post also specifies randomization per storage area. This is important because browsers have multiple storage and session contexts. Storage partitions can be used to prevent different contexts from correlating state.

If a fingerprinting value is tied to a storage area, it becomes harder to use that value as a universal identifier across contexts.

The exact implementation details are not the important part for users. The important part is the principle: the randomization must be scoped so that it does not create new correlation channels.

Why Randomization Must Be Deterministic Enough to Preserve Functionality

Randomization sounds simple: return random values.

But browsers cannot return fully random values on every call.

If a site checks for an extension once, then later checks again and receives a different answer, the site may break. If a feature detection routine sees an extension as present, tries to use it, and then later sees it as absent, rendering may fail. If a graphics engine caches capabilities at startup, it expects those capabilities to remain stable during the session.

Therefore, fingerprinting randomization must be carefully scoped.

It needs to be:

1. Unstable across sites
   So trackers cannot correlate visits across different domains.
2. Unstable across sessions
   So long-term hardware identifiers cannot be built.
3. Stable enough within a site
   So websites can perform feature detection and render content.
4. Plausible enough for real graphics work
   So sites do not immediately detect that they are being protected against fingerprinting.
5. Not so random that it becomes a fingerprint itself
   If a browser’s randomization pattern is unique or detectable, it can become a signal.

This is why Brave’s approach is not just “shuffle the extension list.” It is a scoped farbling system.

A useful mental model is a keyed pseudo-random function:

output = f(session_key, site_key, storage_area_key, signal_name)

The actual implementation may differ, but the concept is similar. The output is deterministic for a given context, but unpredictable to cross-site trackers.

This is hard to do well. It requires balancing privacy, compatibility, and performance.

The Privacy Value of Uniformity

One of the most important ideas in anti-fingerprinting is uniformity.

A signal is only useful to a tracker if it separates users into small groups. If every user reports the same value, the signal has no identifying power.

For example, if every Brave user reports the same WebGL renderer string, that string cannot distinguish one Brave user from another. It may distinguish Brave users from Chrome users or Safari users, but browsers are already partly identifiable through user agent data and other platform signals. The key privacy win is removing the device-specific part.

This is why Brave replaces vendor and renderer strings with a single generic value rather than a set of many fake values.

Fake values can be tempting, but they have problems:

• They may be implausible.
• They may break sites.
• They may create rare fingerprints.
• They may be detectable by fingerprinting services.
• They may not match actual GPU capabilities.

Uniform values are cleaner. They reduce entropy by making users indistinguishable on that signal.

Randomized extension lists complement this by attacking stability. Uniformity makes a signal less unique. Randomization makes it less persistent.

Together, they reduce both linkability and uniqueness.

What Brave Is Not Necessarily Solving Yet

It is important to be precise about the scope of the new protections.

Brave’s post focuses on:

• WebGL vendor strings
• WebGL renderer strings
• WebGL extension lists
• WebGPU adapter descriptors

These are critical metadata signals.

But GPU fingerprinting can also be active.

Active fingerprinting involves asking the GPU to perform work and observing the result. For example:

• Render a hidden image and hash the pixels.
• Draw shapes with antialiasing and measure edge behavior.
• Use floating-point operations that expose precision differences.
• Measure timing of GPU operations.
• Compare texture compression behavior.
• Test shader compilation quirks.
• Read back pixels and compare rounding errors.
• Use WebGL2 or WebGPU features to infer driver behavior.

These techniques can be more expensive and more visible than simple metadata queries, but they are still possible.

Brave’s post acknowledges that graphics APIs remain an active area of fingerprinting research and that the team plans to keep expanding coverage. One future item mentioned is randomizing WebGPU’s supported extensions.

This is the right technical posture. Fingerprinting defense is not a one-time patch. It is an ongoing arms race.

How This Compares to Other Browsers

Brave’s post makes a pointed comparison:

• Chrome does not do this by default.
• Safari does some of it.
• Firefox does some of it behind a hidden setting.
• Brave does it by default with Shields up.

The exact behavior of other browsers can vary by version, platform, and configuration. But the broader point is about default posture.

Many browsers that care about privacy fall into one of two categories:

1. Opt-in protections
   The user must enable a special mode, toggle a setting, install an extension, or change hidden preferences.
2. Compatibility-sacrificing protections
   The browser blocks powerful APIs entirely, breaking legitimate functionality.

Brave argues that this is a false tradeoff.

The argument is strong because most users will never change advanced privacy settings. If protection is opt-in, it protects only the small technical minority that knows how to enable it. If protection is default, it protects everyone who uses the browser.

Default protections also improve the privacy of the broader web ecosystem. When a large number of users report similar privacy-preserving values, individual users become harder to isolate.

This is the difference between personal privacy and collective anonymity. A privacy feature that only experts use can make experts more identifiable. A privacy feature that everyone uses provides stronger herd protection.

Why Default Protection Matters More Than User Control

User control is still important. Brave explicitly provides controls: users can turn off graphics protections on a specific site, disable fingerprinting protection, or switch off Shields altogether.

But the default matters most.

Most users do not understand fingerprinting. They do not know what WebGL is. They do not know what an eTLD+1 is. They do not know that a GPU renderer string can be used to track them across sites. They simply want the browser to be private by default.

A browser that requires users to become privacy experts before it protects them fails the majority of users.

This is especially true for fingerprinting, because the threat is invisible. A user can see a cookie in browser settings, at least in principle. A user cannot easily see that a script queried WEBGL_debug_renderer_info and hashed the result.

Default protection changes the baseline.

Instead of asking, “Should I enable anti-fingerprinting?” the question becomes, “Does this site genuinely need an exception?”

That is a much better privacy model.

How Brave Can Preserve Compatibility

Brave says it has rolled out these protections across Nightly and Beta channels before the broader rollout and is optimistic that the approach reduces breakage while combating fingerprinting.

This matters because compatibility is the hardest part of anti-fingerprinting.

A privacy feature that breaks websites is not just inconvenient. It can create incentives for users to disable privacy protections. That can make them less safe overall.

Brave’s strategy includes several compatibility mechanisms.

First, the values remain plausible. The browser does not simply refuse to participate in WebGL or WebGPU. It returns values that allow graphics contexts to exist.

Second, the protections can be adjusted per site. If Brave discovers that a particular site genuinely breaks, it can apply exceptions or adjustments.

Third, users retain control. If a specific site requires real GPU metadata for a legitimate reason, the user can disable the relevant protection for that site.

This layered approach is common in security engineering. You want strong defaults, but you also need escape hatches. The escape hatches should be narrow, explicit, and user-controlled.

That is exactly what Brave describes.

What This Means for Trackers

For trackers, Brave’s GPU farbling creates several problems.

The GPU model is no longer easily readable

The renderer and vendor strings no longer provide a clean hardware identifier.

The WebGPU adapter is less descriptive

Adapter descriptors are emptied, reducing a direct identification channel.

Extension hashes become unstable

If the extension list changes by session, site, and storage area, the tracker cannot rely on it as a stable cross-site identifier.

Cross-site correlation becomes harder

A tracker embedded across many sites may see different values depending on the site context. This weakens identity resolution.

Fingerprinting becomes more expensive

Trackers may need to combine more signals, use active rendering tests, or rely on probabilistic matching. That raises cost and reduces reliability.

This does not make fingerprinting impossible. No browser can make fingerprinting impossible while remaining compatible with the open web. But Brave’s protections raise the bar significantly.

That is the realistic goal: make tracking harder, less stable, less accurate, and less economical.

What This Means for Web Developers

Web developers should pay close attention to these changes.

The most important lesson is simple: do not treat GPU metadata as a reliable identity signal or capability signal.

Renderer strings are fragile. Vendor strings are fragile. Extension lists can be privacy-protected. WebGPU descriptors can be scrubbed. The web platform is moving toward capability-based design, not hardware-string sniffing.

Developers should follow several best practices.

Use feature detection, not GPU model sniffing

Instead of checking whether the renderer string contains “RTX 4090” or “Apple M3,” check whether the required feature exists.

For WebGL, this means checking extensions, WebGL2 availability, shader precision, texture formats, and limits.

For WebGPU, this means checking features and limits on the device or adapter.

Handle generic or missing strings gracefully

If a browser reports a generic WebGL renderer string, do not treat that as an error. It is a privacy-preserving value. Your site should still work.

Do not hash GPU metadata for analytics

Hashing WebGL strings or WebGPU descriptors creates a fingerprint. Even if your intent is harmless, the resulting identifier can be privacy-invasive. Avoid building user-level identifiers from GPU metadata.

Cache capabilities carefully

If you cache GPU capability data, cache it for the session or for a short period. Do not assume that privacy-protected browsers will provide stable values across sessions.

Provide fallbacks

If a required extension is unavailable, provide a lower-quality path, a software path, or a clear error message. Do not assume every GPU feature exists everywhere.

Test with privacy protections enabled

If your site only works when anti-fingerprinting protections are disabled, it may fail for a growing number of privacy-conscious users. Test your graphics features in Brave and other privacy-focused configurations.

Respect user exceptions

If a user disables a protection for your site, use that access only for the functionality that requires it. Do not abuse the exception to build a profile.

The web ecosystem needs to move away from GPU string sniffing and toward robust capability detection. Brave’s changes accelerate that transition.

The Role of EFF Cover Your Tracks

Brave suggests testing the protections with EFF’s Cover Your Tracks tool.

This is a good recommendation because Cover Your Tracks is designed to show how identifiable a browser is based on its exposed signals. It reports the WebGL vendor and renderer strings and gives a sense of how unique the browser appears.

With Brave’s protections enabled, users should see the WebGL vendor and renderer values collapse to a generic value once the rollout reaches their browser.

This is a concrete way to validate the protection.

However, users should also understand that one tool cannot capture every possible fingerprinting vector. Cover Your Tracks is excellent, but fingerprinting is a broad category. A browser can reduce WebGL entropy while still having other fingerprinting surfaces.

Privacy is therefore a systems problem. Brave’s GPU protections are one important layer, but they work best alongside tracker blocking, cookie protection, storage partitioning, HTTPS upgrades, script blocking, and other shields.

Brave’s post makes this point by reminding users that Brave already protects against state-based tracking like cookies and blocks known-dangerous scripts and resources. GPU farbling is not a standalone fix. It is part of a defense-in-depth strategy.

The Technical Significance of the 1.93 Rollout

Brave says these protections are on by default in desktop and Android browsers, starting in version 1.93, with a phased rollout over several days. That means users may not see the feature immediately, even on the correct version.

Default-on rollout is significant because it immediately protects users without requiring action.

Android inclusion is also significant. Mobile GPUs are fingerprintable too. Mobile devices often have fixed hardware, stable operating system configurations, and widespread use of WebGPU-capable browsers. Protecting Android is not a secondary concern; it is essential.

The phased rollout is a normal engineering practice. Privacy features that affect graphics compatibility need careful observation. If a popular site breaks, the browser team needs to detect and respond quickly. A phased rollout allows Brave to monitor compatibility and adjust per-site policies if necessary.

From a security engineering perspective, this is the right way to ship risky platform-level protections.

Why GPU Fingerprinting Is Harder Than Cookie Tracking

Cookie tracking is binary and stateful. If the cookie is gone, the identifier is gone.

GPU fingerprinting is continuous and environmental. The GPU exists whether or not the browser wants to expose it. The question is how much detail the browser reveals.

This creates a difficult design problem.

The browser must expose enough information for websites to function. Games need to know whether certain texture formats are available. Maps need hardware acceleration. Machine learning demos need compute capabilities. Visualization tools need shader support.

But every exposed detail can become a fingerprint.

The solution is not to hide all details. The solution is to expose only what is necessary, in a privacy-preserving form.

Brave’s approach follows that principle.

• The browser still supports WebGL.
• The browser still supports WebGPU where available.
• The browser still allows graphics rendering.
• But the identifying metadata is scrubbed or randomized.

This is a more sophisticated model than simple blocking.

The Difference Between Identification and Capability

A key conceptual distinction is between identification and capability.

A website often needs capability information:

• Can this browser render WebGL2?
• Is compressed texture format X supported?
• What is the maximum texture size?
• Does the GPU support floating-point render targets?
• Does WebGPU support a particular feature?

These are legitimate questions.

A website usually does not need identification information:

• What is the exact GPU model?
• What is the precise driver renderer string?
• What is the hardware device ID?
• What is the exact architecture string?
• What is the full unmasked debug string?

The problem is that many APIs historically mixed these together. Debug extensions exposed renderer strings for legitimate debugging and compatibility purposes, but those strings became tracking signals.

Privacy engineering requires separating capability from identity.

Brave’s protections move in that direction. Generic vendor and renderer strings preserve the fact that a graphics context exists without revealing exact hardware. Extension randomization preserves functionality while making hashed extension lists unstable. Empty WebGPU descriptors remove identifying fields while leaving the adapter usable.

This is the future of web privacy: capability without identity.

Why Hashing Makes Extension Lists Dangerous

A common misunderstanding is that a list of extensions is not identifying because each extension is public and shared.

But hashing changes the game.

A tracker can take the entire list, normalize it, sort it, and hash it. The resulting hash is a compact identifier.

For example:

extensions = ["A", "B", "C"]
serialized = "A|B|C"
hash = SHA-256("A|B|C")

If another visit produces the same hash, the tracker assumes the same device.

Even if the extension list is not unique alone, it becomes powerful when combined with other signals. A tracker might combine:

GPU extension hash + screen size + timezone + language + user agent hints

The combined fingerprint can be highly unique.

Randomizing the extension list disrupts the hash. If the hash changes by session, site, or storage area, the tracker cannot use it as a persistent identifier.

This is why randomization is such an important tool. It attacks stability, not just uniqueness.

A fingerprint can be somewhat common but still useful if it is stable. Remove stability, and tracking becomes much harder.

The Threat of Active GPU Fingerprinting

Brave’s current GPU protections are primarily about metadata: strings, descriptors, and extension lists.

But active GPU fingerprinting remains an important research area.

Active fingerprinting asks the GPU to perform operations and observes the results. Because GPUs are complex hardware and software stacks, they can produce subtle differences in rendering, timing, precision, and behavior.

Examples include:

Pixel hashing

A script renders a hidden image or shape, reads back the pixels, and hashes the result. Different GPUs or drivers may produce slightly different pixels.

Floating-point precision

Different GPUs may handle floating-point rounding differently. A shader can expose these differences.

Texture compression behavior

Different platforms support different texture compression formats. The presence and behavior of these formats can leak information.

Timing measurements

A script can measure how long certain GPU operations take. Timing can vary by GPU architecture, driver, and system load.

Shader compilation quirks

Shader compilers can behave differently across platforms. Error messages, compilation timing, or supported language features can leak information.

Canvas readback differences

Even 2D canvas operations can be influenced by GPU acceleration and produce subtle differences.

These active techniques are harder to defend against because they often arise from legitimate rendering behavior. If a browser completely prevents rendering or readback, it breaks functionality.

Brave’s future work will likely continue to address these areas. The post explicitly says graphics APIs remain an active area of fingerprinting research and that Brave will keep expanding coverage to new signals. It also mentions plans to randomize WebGPU’s supported extensions.

This is a long-term engineering effort.

Why “Plausible Values” Are Essential

A privacy protection that returns obviously fake values can fail.

If a browser reports a GPU that does not match actual capabilities, sites may break. If a browser reports an impossible extension list, fingerprinters can detect the anomaly. If a browser returns a random string that does not resemble a real renderer string, it becomes a fingerprint itself.

That is why Brave emphasizes plausible values.

The values must be good enough for websites to function. They must not cause graphics engines to take impossible code paths. They must not make the browser instantly recognizable as “the browser that returns weird GPU values.”

This is a hard constraint.

A farbling system must satisfy multiple properties simultaneously:

• Privacy: remove stable identifiers.
• Plausibility: values must look normal.
• Compatibility: sites must still work.
• Consistency: values must be stable enough within a context.
• Performance: randomization must not be too expensive.
• Detectability: the protection should not become a rare fingerprint.

This is why anti-fingerprinting is one of the hardest areas of browser engineering.

The Security Model: Denying a Stable Identifier

Brave’s stated goal is to deny trackers a stable identifier while leaving websites everything they need to render rich experiences.

That is the correct security model.

Tracking does not require perfect identification. It requires enough stability to connect observations over time. If the identifier changes unpredictably across sites and sessions, the tracker’s identity graph becomes noisy.

Noise is valuable.

In statistical tracking, noise reduces confidence. If a tracker cannot be sure whether two observations belong to the same device, its profile becomes less reliable. Advertising systems, fraud systems, and analytics systems rely on confidence. Reducing confidence reduces their power.

Brave’s GPU farbling introduces noise at a critical point: the graphics stack.

This is especially effective because GPU signals are normally highly stable. When a normally stable signal becomes unstable, trackers lose one of their best identifiers.

The Broader Privacy Philosophy

Brave’s post ends with a broader philosophy: privacy should be for everyone, not just technical users.

This is important because fingerprinting defenses often fail socially, not technically.

If a privacy feature is hidden behind advanced settings, only a small number of users enable it. Those users may become more identifiable, not less, because they stand out from the general population. If a privacy feature breaks sites, users disable it. If a privacy feature requires extensions, it introduces new attack surfaces.

Default protection avoids these problems.

It gives every user a stronger privacy baseline. It creates a larger anonymity set. It reduces the need for expert knowledge. It makes privacy the normal state rather than an exceptional state.

That is why Brave’s GPU protections being enabled by default matters as much as the technical details.

What Users Should Expect

For Brave users, the experience should be mostly invisible.

Websites that use WebGL or WebGPU for legitimate graphics should continue to work. Games should load. Maps should render. Product visualizations should display. Interactive demos should function.

But fingerprinting scripts will receive less identifying information.

In tools like EFF’s Cover Your Tracks, users should see the WebGL vendor and renderer strings collapse to generic values once the feature is available in their browser.

Because the rollout is phased, not every user will see the change immediately. If the feature is not visible right away, it may still be arriving.

Users who need to troubleshoot a specific site can use Brave’s controls to disable the relevant protections for that site. But for most users, the default should be the safest and most private choice.

Why This Is a Major Step

The web has spent years fighting cookies, third-party trackers, and storage abuse. Those defenses are important, but they are not enough.

Fingerprinting is the next layer.

GPU fingerprinting is especially dangerous because it is stable, detailed, and easy to query. WebGL and WebGPU are essential technologies for an open, vibrant web, but they also expose powerful identification surfaces.

Brave’s new protections represent a serious attempt to solve this problem without breaking the web.

The technical approach is nuanced:

• Generic WebGL vendor and renderer strings remove exact hardware identity.
• Empty WebGPU adapter descriptors prevent direct adapter identification.
• Randomized WebGL extension lists destabilize hash-based fingerprinting.
• Scoped randomization preserves site functionality.
• Default-on protection creates a broad anonymity set.
• Per-site exceptions preserve compatibility.
• Future work expands coverage to additional GPU signals.

This is not a magic bullet. Fingerprinting will continue to evolve. Active rendering fingerprints, WebGPU feature combinations, and other hardware signals will require ongoing work.

But the direction is clear: the browser should not hand trackers a stable GPU serial number.

Brave’s farbling turns that serial number into a moving target.

And that is exactly what privacy engineering on the modern web needs to do.