WebGPU's build constants are identical in every realm
Check id webgpu-sync-surface-vs-realm
What an ordinary browser yields
Every realm that exposes navigator.gpu reports the same preferred canvas format and the same SET of WGSL language features. The order they are listed in is not asserted — it legitimately varies by realm.
What a detector infers
WebGPU's cheapest fingerprint is not the GPU at all. navigator.gpu.getPreferredCanvasFormat() and navigator.gpu.wgslLanguageFeatures are compiled-in build constants — no adapter, no device, no await, no GPU involved — which is why DataDome collects them in the first handful of fields in its payload and still gets them on hardware where the adapter path fails entirely. A build constant cannot vary by realm: the worker and the iframe are running the same binary as the page. So this check reads both in every realm it can reach and requires them to agree, and because nothing here calls requestAdapter, a null or blocklisted adapter cannot influence the answer. The presence/absence case is deliberately reported rather than counted, and that distinction is the interesting part: Brave with Shields disabling WebGPU, and privacy extensions whose content script deletes navigator.gpu, both run in the MAIN world, while a worker built from a blob URL keeps the native object — so a realm that has the API next to one that does not is the signature of a page-world blocker, which is an honest configuration. Two realms both exposing a working API and disagreeing about its VALUE is a different animal, and that is what earns a contradiction: the preferred format is a two-value enum that is worthless to farble, and nothing shipping farbles the WGSL language feature set. Only MEMBERSHIP is asserted, and that limit was set by a measurement rather than by taste: on a stock Chrome 150 the page and a fresh iframe list these features in the same order, but a dedicated worker lists the same ten in a different one. wgslLanguageFeatures is a setlike and nothing specifies its iteration order across realms, so an order assertion describes how each realm happened to populate its registry rather than anything about the build — it would have failed an ordinary browser on the first run. This check also carries a reading lesson. The field DataDome ships is snake_case, which makes it wgslLanguageFeatures — the WGSL language extension set — and not the kebab-case GPUAdapter.features. Our own field map had that mislabelled, and a check built on the wrong one would have targeted an API DataDome cannot even reach.
How to resolve it
These two values are decided when the browser is compiled. A worker and an iframe run the same binary as the page, so a realm answering differently means the answer is being generated rather than reported — and whatever is generating it reaches only the page world. This is also why they are the cheapest WebGPU signals for a detector to collect and the hardest to fake coherently.
Read in the wild by
DataDome
Collects both adapter-free WebGPU reads in the first handful of fields in its payload — before anything requiring an adapter — because they are compiled-in build constants that still populate when the adapter path fails on real hardware. On the capture we read, the adapter-dependent fields came back "NA" while these two did not.
payload idx 4 J61tIH="bgra8unorm" (navigator.gpu.getPreferredCanvasFormat) and idx 5 ahijox="packed_4x8_integer_dot_product,unrestricted_pointer_parameters,pointer_composite_access,readonly_and_readwrite_storage_textures" — snake_case, so navigator.gpu.wgslLanguageFeatures, NOT the kebab-case GPUAdapter.features; adjacent tBmLbP/zMWDvj both "NA"
glizzykingdreko/datadome-encryption — a real 232-field captured payloadEvery attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Render & GPU
- clientWidth and offsetWidth equal the box the element itself reports
layout-box-arithmeticclientWidth and offsetWidth are not opinions the browser offers — CSSOM defines them as arithmetic over values the same element hands you… - a box placed at the viewport origin measures its origin as zero
client-rect-origin-vs-positionZero is scale-invariant, and that single property is the whole check. - SVG's screen matrix agrees with the element's client rect
svg-ctm-vs-client-rectTwo independent routes to a single fact. getScreenCTM maps an SVG element's user space into viewport coordinates, and getBoundingClientRect… - IntersectionObserver's rect agrees with getBoundingClientRect
client-rect-vs-observerA third account of where one element sits, from the most ordinary API that has one. - the GL limits the driver reports are limits the driver will actually honour
webgl-limits-vs-driverEvery other WebGL check on this page reads what getParameter SAYS. - ANGLE's translated shader is written in the dialect the renderer string implies
shader-backend-vs-rendererThe UNMASKED_RENDERER_WEBGL string is a label — a piece of text a page can rewrite to name any GPU and any graphics backend. - every extension WebGL advertises can actually be instantiated
webgl-extensions-vs-drivergetSupportedExtensions() returns a list a page can rewrite; getExtension(name) either hands back a real extension object or null, and that… - the clear path and the shader path paint opaque red to the same bytes
webgl-draw-path-invarianceOpaque red can be produced two ways: the fixed-function clear path, and a fragment shader emitting vec4(1,0,0,1).
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Render & GPU checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Render & GPU — the family webgpu-sync-surface-vs-realm belongs to.