A single WebGL extension does most of the damage. WEBGL_debug_renderer_info exposes two constants, UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL, that return the GPU's vendor and renderer as plain, human-readable strings, with no dialog and no visible sign to the user (Crawlex, 6 months ago).

On Windows that string can get remarkably specific. Chromium routes WebGL through ANGLE, which translates OpenGL calls into Direct3D and writes its own translation details into the same field, so the value returned can include the exact GPU SKU, the graphics backend, and the shader-model version all at once (Crawlex, 6 months ago).

A second technique works differently. A script renders an offscreen image, reads the pixels back with readPixels or toDataURL, and hashes the result. That hash varies between devices because of non-deterministic floating-point rounding inside the GPU driver, according to 2019 USENIX Security research cited by Crawlex. Notably, a driver update alone can shift the rounding behavior enough to move the hash, which means this signal is contributive rather than permanently fixed (Crawlex, 6 months ago).

The scale of the problem isn't hypothetical. A 2016 study collected close to 119,000 browser fingerprints and found 89.4% of them unique, with canvas and WebGL attributes ranking among the higher-entropy contributors (Crawlex, 6 months ago).

The distinction that shapes everything below: the renderer string is a static value the driver reports on request, while the pixel hash is a computed value the GPU produces fresh each time. A defense built for one doesn't automatically touch the other.

The central claim, according to the alexi.sh guide, is that Brave varies canvas, WebGL, and AudioContext output by site and by session, tuned so a user won't notice any visual difference but a tracker gets an unreliable read across sites (alexi.sh, 2 months ago). The stated goal isn't to make every device look identical. It's to make the output inconsistent enough that stitching sessions together across origins stops working.

What the guide doesn't specify is operationally important: whether a given site sees a stable output for the life of a session and a fresh one after Brave restarts, or a different output on every single visit. That detail decides whether ordinary site functionality survives the noise while cross-site linkage still breaks. No available source resolves it.

There's a second, separate gap. The alexi.sh guide describes altering output; it does not specify how Brave handles the static WebGL fields Crawlex documents, such as the renderer string, the extension list, or the shader-precision values. If those remain unmodified, a tracker that skips the randomized canvas hash and reads the renderer string directly may not be affected by this protection at all.

The same source reports Brave also strips third-party Referer headers, enforces storage partitioning, and randomizes hardwareConcurrency and deviceMemory (alexi.sh, 2 months ago). Those are separate correlation paths, and they shouldn't be read as evidence that the GPU-output noise itself is more thorough than described.

There's also an acknowledged limit. Because the noise is scoped per site, a tracker can reportedly still correlate activity within a single session; the model is aimed specifically at breaking links across sites (alexi.sh, 2 months ago). That's the same failure mode the W3C describes: a fingerprint can function like a cookie across origins even when cookie policy blocks direct data sharing (W3C, last year).

Firefox has taken a documented, testable approach since version 91 shipped in 2021: instead of reporting the exact GPU model, it groups hardware into broad families. One measurement found this cut distinct renderer values from 83,705 down to 131, a reduction of better than 99% (Crawlex, 6 months ago).

Firefox's opt-in Resist Fingerprinting mode goes further still, disabling the debug-renderer extension outright and interfering with canvas readback so a script can't get the raw rendered image back (Crawlex, 6 months ago).

Tor Browser sits at the strict end of that same spectrum. An update to Tor Browser, version 8.5.1, disabled the readPixels call that image-hash fingerprinting depends on (Crawlex, 6 months ago). No source here confirms whether current Tor builds behave the same way, so treat this as historical context rather than a live comparison point.

There's a catch running through all of this, and it cuts against the strict approach. A renderer string reading SwiftShader, llvmpipe, or a fixed placeholder is rare enough in the wild that it becomes its own identifying signal (Crawlex, 6 months ago). Separately, the same research notes that a browser running the Firefox-RFP or Tor minimal-capability profile belongs to a small enough population that the protection itself works as a label (Crawlex, 6 months ago). Those are two related but distinct problems, not one and the same claim.

Brave's described approach tries to sidestep that trap differently, by varying output rather than converging on one distinctive, restrictive profile. That's a plausible design choice given how the underlying APIs work, but it hasn't been tested independently against real tracking scripts.

Canvas and WebGL noise addresses rendered output. WebGPU opens a channel that kind of defense wasn't built for. Its requestAdapter call returns a limits structure with dozens of numeric capability values, a larger version of the same static parameter block WebGL exposes (Crawlex, 6 months ago). Chrome currently reports tiered limits rather than exact hardware ceilings, which reduces the entropy without eliminating it, since the tiers still partition the population.

Timing is a separate channel entirely. Research published in early 2025 introduced LockedApart, an attack that measures GPU-thread contention directly through WebGPU's compute access, reporting results up to 310 times faster and 1.8 times more accurate than the earlier DrawnApart technique (uASC, early last year). The researchers describe this as a new avenue opened specifically by WebGPU's added hardware access.

A related preprint describes a GPU cache side channel reaching up to 90% precision in distinguishing visits among the top 100 websites tested (WebGPU-SPY preprint, undated). That's evidence GPU hardware leaks timing information at a granular level, not evidence of tracking one user across unrelated sites over time.

No source available confirms whether Brave's canvas and WebGL noise extends to either of these WebGPU channels. That's an open question, not a demonstrated failure, and it's the one part of this story with no documentation at all.

The pieces that are well established here don't depend on Brave at all. Cross-origin fingerprints can function like cookies regardless of cookie settings, and GPU-related signals are consistently documented as meaningful contributors to that fingerprint (W3C, last year).

What remains unverified is narrower but important: whether Brave's per-site noise is sufficient to break cross-site correlation in practice. It's a plausible mechanism, consistent with how the underlying rendering APIs behave, but it's described by a single source with no version number, no match-rate test, and no confirmation that static WebGL identifiers are randomized alongside the rendered output (alexi.sh, 2 months ago).

Brave, Firefox, and Tor are solving for different threat models here, and nothing in the available evidence tests them head-to-head under identical conditions. As WebGPU's capability disclosure and timing channels sit entirely outside what canvas and WebGL noise was designed to address, that's where any browser's fingerprinting defense faces its next real test, and it's a surface none of the documentation reviewed here has caught up to yet (uASC, early last year).