What Browsers Do in the Shaders: A Measurement Study of WebGPU Privacy
arXiv:2606.26412v1 [cs.CR] 24 Jun 2026
Igor Santos-Grueiro International University of La Rioja
Abstract
shaders, create render and compute pipelines, and submit GPU work through a standard queue. This supports local ML inference, media processing, visualization, games, simulation, and editing [7, 28, 33, 45]. Canvas and WebGL already showed that graphics APIs expose browser and hardware variation: rendering hashes reveal graphics-stack differences [35], OS/hardware features enable cross-browser fingerprints [5], DrawnApart identifies GPUs from WebGL behavior [23], and renderer strings are privacy-sensitive [21, 31]. WebGPU expands this surface from rendering to programmable workloads, dispatch shape, atomics, pipelines, and queue progress. WebGPU validation protects memory safety: the API and WGSL validation reject invalid resource use, out-ofbounds access, uninitialized reads, and undefined shader behavior [59, 60]. That validation still leaves privacy-relevant signals. We measure what remains observable inside the valid API boundary: adapter exposure, resource contention, queue progress, completion behavior, and cold or warm shader/pipeline creation under ordinary JavaScript and valid WGSL. Recent work establishes browser-exposed GPUs as a practical privacy surface. GPU.zip shows cross-origin leakage through graphical compression [62]; WebGPU-SPY and Giner et al. build WebGPU cache attacks [12, 14]; AtomicIncrement and LockedApart use WebGPU or compute behavior for device fingerprinting [19, 24]; native GPU work shows timer-free cache primitives and residual-memory risks [52, 73]. Browsers and standards bodies need measurements that separate these mechanisms and name the boundary and observable for each result. We build WGPUL ENS to collect those measurements. WGPUL ENS generates valid WGSL probes, runs synthetic web and native victims, coordinates browser boundaries, records high-resolution, coarse, and ordinal observations, reconstructs participant uploads, audits page loads, and computes leakage, fingerprinting, and cost metrics. Controlled scenarios support leakage, boundary, browser/native, and mitigation claims. The participant field study measures deployment,
WebGPU lets ordinary web pages run GPU workloads through a validated programming model. Validation protects memory safety, but shared browser, driver, OS, and GPU state can still expose privacy-relevant signals. We present WGPUL ENS, a framework for measuring those signals across controlled scenarios, browser-native co-residency, a participant field study, public page loads, and mitigation policies. Our framework separates measurements: controlled scenarios support leakage, boundary, and mitigation claims; participant runs support deployment, compatibility, and fingerprintability; and a Tranco crawl measures WebGPU exposure in real-world pages. Our controlled results identify persistent pipeline compilation state as the clearest surface. Cold/warm pipeline probes reveal prior compilation state across selected origin, profile, and browser placements. Controlled browser/native experiments also show native GPU activity can be inferred from browser-visible observables under labeled workloads. Other resource probes provide weaker positive results and negative controls. The participant field study shows active WebGPU behavior is highly distinctive within the sample, with deterministic components stable within runs and lower exact stability across repeated visits. A page-load crawl finds WebGPU use mainly as adapter probing and static support code, with no observed page-load shader, pipeline, queue, query, or map activity. Mitigation pilots identify source-level key separation as a proxy for evaluating pipeline-cache partitioning. Overall, WGPUL ENS shows that WebGPU privacy analysis must be surface-specific: browsers need to measure which GPU state crosses which boundary, which browser-visible signals reveal it, and what the corresponding mitigations cost.
1
Introduction
WebGPU brings GPU computation to ordinary web pages. A page can allocate buffers and textures, compile WGSL 1
heterogeneity, fingerprintability, and repeated-run behavior. A Tranco top-10k crawl records page-load WebGPU exposure. Controlled results identify persistent WebGPU pipeline compilation state as the clearest surface. Windows samepage cold/warm calibration reaches AUROC 0.986 on AMD/RDNA-3 and 0.961 on NVIDIA/Lovelace, with selected web, profile, Chromium-family, and M1/Metal placements also positive. Browser/native experiments show synthetic native GPU activity visible through WebGPU under controlled co-residency, with M1 active/idle reaching macroF1 0.946 over coarse-frame observables. Secondary workload and non-pipeline rows are weaker and more platform-specific. The participant and crawl measurements complement the controlled results with evidence from deployed browsers and public pages. Across two participant campaigns, the 1,095 deduplicated completed records yield 1,095 distinct active WebGPU signatures. Relative to a browser/OS baseline, these features add 7.136 bits of empirical entropy. Repeated measurements show stable deterministic components within runs and more limited exact stability across repeated local-storage identifiers. The Tranco crawl finds 56 WebGPU-positive pageload records, mostly adapter probes and static support code, with no observed page-load shader, pipeline, queue, query, or map activity. We make the following contributions.
shader modules, build compute or render pipelines, record commands, and submit command buffers to a GPUQueue. This model is now deployed across major browser families, with backend and platform differences across Chrome, Edge, Firefox, and Safari [6, 7, 17, 33, 37, 63]. The logical object model abstracts over a shared software and hardware stack. Chromium-family browsers route WebGPU through Dawn; Firefox routes through wgpu; Safari/WebKit uses the Apple platform stack. These implementations translate WebGPU operations to D3D12, Metal, or Vulkan, then to drivers, OS GPU schedulers, memory managers, and physical resources shared with other tabs, origins, profiles, browsers, and native applications.
2.1
WGSL and WebGPU validation define the safety boundary. Shader code is typed, resource bindings are explicit, and shader-module or pipeline creation can fail before execution if validation constraints are violated [59, 60]. Our experiments stay inside this boundary: valid JavaScript and WGSL, no out-of-bounds accesses, uninitialized reads, undefined shader behavior, intentional data races, browser exploits, or driver memory disclosure. The privacy question starts after validation succeeds. A valid page can observe features and limits, queue progress, completion ordering, coarse frame behavior, and cold/warm shader or pipeline creation.
• Evidence design and measurement framework. WGPUL ENS measures static exposure, active contention, and persistent pipeline state with valid JavaScript/WGSL probes across controlled, participant, and crawl datasets.
2.2
• Controlled persistent-state and co-residency results. We show pipeline cold/warm separability, selected positive boundary rows, and controlled browser/native inference with synthetic OpenCL and Metal workloads.
Observable GPU State
WGPUL ENS measures static exposure, active contention, and persistent state. Static exposure includes availability, adapter metadata, features, limits, formats, shader support, timestampquery exposure, WebGL capabilities, and rendering signatures [21, 31, 32]. Active-contention probes stress storage buffers, textures, workgroup memory, arithmetic pipelines, dispatch shape, barriers, atomics, and queue progress. Persistent state focuses on shader and pipeline compilation: pipeline creation may follow a cold-compilation path or reuse cached state depending on browser, backend, driver, and cache policy. The WebGPU specification recognizes timing and workload-identification risks, including timestamp-query and constrained global resources shared by programs and pages [59]. We therefore measure explicit timing, coarse browser observables, and ordinal or categorical outcomes.
• Participant and page-load measurements. Participant runs show active WebGPU fingerprintability within the sample; the Tranco crawl shows page-load exposure mostly through adapter probing and static support code. • Mitigation case study. Source-level key separation approximates pipeline cache partitioning and measures leakage/cost tradeoffs. • Artifact availability. We release an anonymous artifact with code, normalized derived data, reproduction scripts, and the extension for the full study (https: //anonymous.4open.science/r/WGPULens/).
2.3 2
Safety and Observability
Background and Threat Model
Threat Model
The attacker controls one web origin and runs ordinary JavaScript and valid WGSL through WebGPU. The attacker has no native code, browser extension, privileged API, hardware counters, browser or driver exploit, or access to victim memory. Victims are controlled workloads placed in the same
WebGPU gives web pages a modern GPU programming model. A page can request a GPUAdapter, obtain a GPUDevice, create buffers and textures, compile WGSL 2
previous pipeline-family reuse. Table 10 gives the full surfaceto-impact map. Controlled experiments place the victim at explicit boundaries: same page, cross-origin iframe, cross-tab, profile/private mode, cross-browser, or browser/native. Participant runs are same-page measurements for deployment and fingerprinting; cross-tab leakage requires controlled labels and placement. The collector supports three observation modes. Highresolution timing serves as a calibration mode. Coarse browser observables include requestAnimationFrame boundaries, completed batch counts, queue completion promises, buffer mapping completion, frame drops, and duration buckets. Timerless measurements keep only orderings or categorical outcomes.
Table 1: Evidence design. Each dataset answers a different question. Dataset Controlled scenarios
Supports
Leakage, boundary, browser/native, workload, and mitigation claims under labeled placements Participant field Compatibility, study browser/GPU heterogeneity, sample-level fingerprintability, and repeated local-storage identifiers Page-load crawl WebGPU API exposure, static support code, and source context on public pages Mitigation Direction and leakage/cost pilots tradeoffs under matched controlled rows
Does not support Prevalence in deployed users or sites
Cross-context victim inference or mitigation claims
Leakage, intent, or interactive WebGPU workloads
3.2
Effectiveness of a browser-engine cache-key patch
The evaluation instantiates four tasks. Pipeline-state inference distinguishes cold and warm shader or pipeline creation under browser, profile, and cache boundaries. Native GPU activity inference classifies activity or phase while the WebGPU probe is co-resident with a controlled native GPU workload. Controlled workload classification distinguishes synthetic web workload families or render phases. Participant fingerprintability measures how WebGPU static exposure and active probes reduce anonymity sets beyond classic browser, canvas, and WebGL features. Table 9 lists the datasets and metrics. We define endpoints before reporting results. Primary endpoints support the main claims: pipeline cold/warm boundary AUROC, M1 cross-browser pipeline AUROC against permutation, browser/native active/idle macro-F1, participant WebGPU entropy, crawl exposure counts, and pipeline salting leakage/cost. Secondary endpoints explain heterogeneity; exploratory endpoints include small pairwise phase contrasts, pilot timer clamps, and dispatch caps. Binary leakage tasks use AUROC. Multiclass activity and phase tasks use accuracy and macro-F1. Repeated runs assess stability; bootstrap intervals quantify uncertainty where available. Label-permutation controls test closed-world classifiers under randomized labels. Participant fingerprinting uses uniqueness, collision rate, entropy, anonymity-set size, and repeat-run linkability. Mitigations report leakage reduction together with compilation latency, benchmark runtime, compatibility failures, or frame-level overhead.
page, another origin, an iframe, another tab, a private window, another browser, or a native GPU application. The evaluated inference targets are limited to activity, workload family, resource class, phase, scheduling state, or previous pipeline compilation state under controlled workloads. Real-user tracking, secret recovery, live-website victim fingerprinting, pixel stealing, and arbitrary data extraction are outside the evaluated claims.
3
WGPUL ENS Methodology and System
WGPUL ENS uses a single browser-side measurement core with three measurement paths. Controlled experiments fix browser, profile, GPU path, origin relation, victim placement, timer mode, and mitigation condition; hidden labels encode the boundary, victim state, pipeline state, workload class, and mitigation condition. Participant runs reuse the same core in an opt-in page to assess deployment, compatibility, heterogeneity, repeatability, and fingerprintability. The crawl records page-load WebGPU exposure. Table 1 sets the claim boundary used throughout the paper.
3.1
Tasks and Metrics
Surfaces, Placement, and Observables
WGPUL ENS measures three surface families. Static exposure covers WebGPU availability, adapter features, limits, formats, shader capabilities, timestamp-query availability, WebGL/WebGL2 properties, canvas signatures, and adapter metadata. Active contention stresses memory, bandwidth, textures, functional units, atomics, barriers, queue progress, visibility policy, and scheduling. Persistent state focuses on shader and pipeline compilation, where cold/warm behavior can reveal
3.3
System Design and Implementation
WGPUL ENS implements the methodology as a reusable browser/GPU measurement pipeline. The shared browser core collects metadata, initializes WebGPU, WebGL, and canvas contexts, executes probe batches, records progress events, and emits JSON traces. Controlled wrappers add victim placement and labels; participant wrappers add consent, upload, 3
Probe specs
ø
Placement
Victims
: Leakage AUROC, F1
C
[
Probe runner
Metadata Þ
A
A
Û
Event recorder
JSON trace
Analyzer
[ Fingerprint entropy
Browser measurement core
7 Cost latency
Figure 1: WGPUL ENS implementation architecture. and repeat-run metadata. Figure 1 shows the flow from probe specifications to analyzer outputs. Probes are generated from compact specifications that record surface, access pattern, workgroup size, dispatch shape, arithmetic mix, memory footprint, synchronization mode, observable mode, repetition count, and output condition. Generated WGSL must validate, stay in bounds, avoid uninitialized reads and intentional data races, and produce deterministic outputs where possible. Controlled victims are synthetic and labeled. Web victims include static pages, canvas animation, WebGL render loops, WebGPU render and compute loops, video-like rendering, map/tiles-style workloads, memory streaming, textureheavy rendering, local ML-style kernels, and pipeline compilation. Native victims include OpenCL on Windows and Metal on Apple platforms. Labels cover workload family, active/idle state, phase, resource, intensity, visibility, boundary, and coarse intervals. They are evaluator-only ground truth; the attacker page observes only its own WebGPU-visible behavior. The JSON trace is the interface between collection and analysis. Controlled traces include victim labels and placement metadata; participant traces add upload metadata and a participant-scoped repeat identifier. The analyzer reconstructs runs, decodes payloads, joins chunks, validates schema, separates compatibility failures from completed runs, deduplicates participant-scoped submissions, and extracts task-specific features. Controlled outputs feed leakage, boundary, and mitigation tables. Participant outputs feed deployment, compatibility, entropy, anonymity-set, and repeatability tables.
4 4.1
fication, pipeline-state, and mitigation claims. Participant and crawl rows supply deployment, compatibility, and fingerprinting evidence; leakage claims use labeled victim placement across a selected boundary. Host and browser roles. The setup separates adapter, browser, and backend roles. Windows is the same-host adapter comparison: Chrome and Edge run on the AMD/RDNA-3 default path and on a forced NVIDIA/Lovelace path. Brave adds Chromium-family application variation on the adapter configurations present in its traces. Firefox adds browser-family rows with valid WebGPU traces, but without normalized vendor/model fields in our data-collection pipeline. M1/Metal provides the Apple backend with Chrome, Brave, Firefox, and Safari/WebKit coverage. Appendix Table 11 gives the full host/browser matrix. Probe families. Pipeline-state experiments vary shader family, pipeline kind, cold/warm/mutated state, browser/profile boundary, adapter configuration, and observable mode. Browser/native runs coordinate the browser probe with OpenCL on Windows and Metal on M1. Other probes cover bandwidth, queues, atomics, textures, and render/compute signatures. Mitigation experiments repeat selected baselines under source-level key-separation simulations, timer-clamping variants, or dispatch-cap variants and record cost. Repeat checks. We rerun the main controlled experiment sets on later days to check whether the measured patterns persist across sessions. On Windows, the 2026-06-11 repeat follows the 2026-06-04 baseline and contains 528 valid traces across the AMD and NVIDIA configurations, covering pipeline state, controlled workload classification, and browser/native experiments. On M1, the 2026-06-11 repeat covers short stability measurements, cross-browser pipeline measurements, controlled workload classification, and Metal browser/native experiments. These repeats provide stability
Controlled Leakage Scenarios Controlled Setup
Claim scope. Controlled experiments use fixed browser profiles, fixed origins, fixed window states, selected adapter configurations, labeled victims, and explicit timer modes. They support boundary, browser/native, controlled workload classi4
signal: no out-of-bounds access, undefined shader behavior, driver exploit, or victim memory disclosure. The controls test simpler explanations such as generic warmup or trial-order drift. The protocol varies shader family, pipeline kind, mutated variants, unrelated families, browser profile, origin placement, adapter configuration, and trial order. Same-origin cross-tab rows are kept as negative boundary controls, and the M1 cross-browser aggregate is compared against a label-permutation baseline. These controls constrain the signal without fully localizing the layer that retains the state, which may live in browser code, Dawn/wgpu/WebKit policy, driver shader caches, OS filesystem caches, the GPU process, or a combination of those layers. We therefore attribute the signal only to the browser/GPU stack, not to a specific browser, backend, driver, or cache layer.
WGSL shader family
createShaderModule pipeline creation
browser backend Dawn, wgpu, WebKit
cold path compile/lower cache insert
warm path reuse/cache hit shorter path
attacker observes own completion signal
Figure 2: Pipeline-state probe.
Cold/warm state is separable on both Windows adapter configurations. The local baseline asks whether a WebGPU page can distinguish a cold pipeline family from one that has already been compiled. On the Windows hybrid-GPU host, same-page cold/warm separability is strong under highresolution JavaScript timing: AUROC reaches 0.986 on the default AMD/RDNA-3 configuration and 0.961 on the forced NVIDIA/Lovelace configuration. These are calibration rows for the rest of the pipeline-state study and establish measurability on both adapter configurations. The same-host comparison is useful because it holds the CPU, OS, browser install, and local environment fixed while changing the adapter configuration. The result is not specific to a single GPU: the browser pipeline-creation path exposes measurable cold/warm structure on both AMD and forced NVIDIA paths. The Apple M1 Pro/Metal results show that the surface is not Windows-only. In the M1 cross-browser experiment set, each browser-pair row uses 8 trace files and 480 high-resolution events split evenly between cold and warm states. Across the three browser pairs, the aggregate high-resolution AUROC is 0.718 versus a permuted p95 of 0.522. This is weaker than the Windows same-page rows, but it provides an independent Apple/Metal backend result.
evidence for the controlled claims; Appendix A.1 lists the repeat artifacts.
4.2
Pipeline Compilation State Leakage
The strongest controlled surface is WebGPU pipeline compilation state: whether creating a shader module, compute pipeline, or render pipeline behaves like a fresh compile or a cache hit in the browser/backend stack. That behavior can reveal earlier activity in a browser, profile, or cache even after the original workload has finished. Pipeline creation can expose persistent browser/GPUstack state. WebGPU creates shader modules and pipelines before submitting GPU work. The browser may still compile WGSL, translate it through the backend, and consult shader or pipeline caches before the call returns. We test whether a pipeline family is cold or warm. A contention probe checks for another workload using shared resources now. A pipeline-state probe checks whether related compilation state already exists, which can expose earlier activity across origins, profiles, browser variants, or backends. Private-mode cache behavior is still an open browserpolicy question.
Selected placements preserve pipeline-state signals. Pipeline-state leakage is boundary-dependent. Table 2 summarizes the primary rows. Same-origin cross-tab rows on Windows are near chance in the short-interval setting, while selected cross-origin, HTTPS iframe, cross-profile, Chromiumfamily application, and M1 cross-browser rows remain positive. The boundary determines the claim. Same-page rows are surface discovery; cross-origin or iframe rows test web isolation; cross-profile rows test browser-state isolation. The high Windows Brave/Chrome rows are Chromium-family cachepolicy results: the browsers differ at the application layer but share enough implementation, backend, driver, or cache
The probe uses valid WebGPU pipeline creation. The pipeline-state experiment uses a controlled cold/warm protocol. We create a valid WGSL shader or pipeline family under a cold browser, profile, or cache condition, re-create it under a warm condition, and optionally create mutated or unrelated families as closely related controls. The attacker records only its own observable: duration, coarse bucket, completion ordering, or ordinal category. All shader code is valid WGSL. The experiment uses ordinary pipeline creation and the attacker’s own completion 5
Table 2: Primary pipeline-state boundary rows. Evidence reports the sample size, repeat, or permutation control available in the derived artifact. Role
Configuration
Calibration Calibration
Win AMD, same-page, Chrome, high-res 3 files; 90/90 cold/warm; repeat 0.965 Win NVIDIA, same-page, Chrome, high- 3 files; 90/90 cold/warm; repeat 0.933 res
0.986 [0.961–0.999] 0.961 [0.929–0.985]
Web boundary Web boundary Profile boundary Negative control
Win AMD, cross-origin, high-res 3 files; 90/90 cold/warm; perm. p95 0.581 Win AMD, HTTPS iframe, high-res 3 files; 90/90 cold/warm; artifact aggregate Win AMD, Chrome cross-profile, high-res 3 files; 90/90 cold/warm; perm. p95 0.581 Win AMD, same-origin cross-tab, high- 3 files; 90/90 cold/warm; repeat 0.507 res Win NVIDIA, same-origin cross-tab, 3 files; 90/90 cold/warm; repeat 0.508 high-res
0.948 0.918 0.958 0.545
Negative control
Evidence
AUROC 95% CI
[0.907–0.981] [0.872–0.958] [0.927–0.982] [0.491–0.623]
0.506 [0.471–0.596]
Chromium-family, Win Brave → Chrome, high-res 1 file; 20/20 cold/warm 0.996 [0.985–1.000] small-n Chromium-family, Win Chrome → Brave, high-res 1 file; 20/20 cold/warm 0.999 [0.993–1.000] small-n M1 X-browser M1 Brave → Chrome, high-res 8 files; 240/240 cold/warm; perm. p95 0.542 0.744 [0.700–0.788] M1 X-browser M1 Firefox → Chrome, high-res 8 files; 240/240 cold/warm; perm. p95 0.543 0.712 [0.666–0.758] M1 X-browser M1 Chrome → Brave, high-res 8 files; 240/240 cold/warm; perm. p95 0.537 0.700 [0.653–0.747] Notes. CIs are 95% intervals: bootstrap over cold/warm samples where event vectors are retained, and analytic AUROC intervals for M1 rows whose derived artifacts retain counts and permutation controls but not event vectors. For A → B rows, A creates or warms the pipeline family and B performs the measured probe.
behavior to preserve the signal. With 20 observations per direction, they are small-n corroboration, not precise effectsize estimates. The M1 rows provide an Apple/Metal crossbrowser check. Only Firefox→Chrome crosses renderingengine families; Brave↔Chrome is a cross-application comparison within the Chromium family. The table supports controlled placement claims. Originonly causality requires another factorial experiment: the current design does not isolate origin as the sole causal factor. Origin, tab placement, process placement, and cache scope vary together in these comparisons.
under high-resolution timing, while coarse and ordinal modes are near chance. Timer restrictions can reduce this surface under several deployments. Timer precision is one axis of the measurement model: pipeline state is high-resolution-sensitive, while later browser/native rows show stronger coarse-frame signals. Controls and negative rows bound the claim. The pipeline-state claim relies on controls as much as on positive rows. The M1 cross-browser aggregate is compared to a label-permutation control: AUROC 0.718 versus a permuted p95 of 0.522. Negative or weak rows remain in the main table, including Windows same-origin cross-tab rows near chance for both AMD and NVIDIA. These controls keep the result precise: pipeline compilation state is strongly measurable locally, remains positive across selected controlled origin/profile, Chromium-family, and Apple/Metal cross-browser placements, and weakens sharply under coarse or ordinal observables in several M1 rows.
Controlled repeats preserve the pattern. We reran the primary pipeline rows on later collection days on both controlled platforms. The pattern is stable: Windows same-page pipeline state remains strong (AMD 0.986 to 0.965; NVIDIA 0.961 to 0.933), Windows same-origin cross-tab remains near chance (AMD 0.545 to 0.507; NVIDIA 0.506 to 0.508), and the M1 cross-browser aggregate remains positive (0.718 to 0.706). Safari same-page remains weak (0.536 in the repeat). These rows are part of a broader controlled multi-day repeat that also covers controlled workload classification and browser/native activity.
Pipeline state points to cache partitioning. Pipeline compilation state matters because it is a persistent-state surface. If pipeline cache reuse crosses controlled boundaries such as origins, profiles, or cross-browser placements, a page may infer that related shader activity has occurred before. Private-mode and restart behavior are important browser-policy questions for future experiments. The implication is persistent state inference, not only transient contention. For this reason, Section 7 treats pipeline cache partitioning and source-level key-separation simulations as first-class policies. The browser question is whether stacks can partition or
Pipeline state depends strongly on observation mode. The strongest measurements use high-resolution JavaScript timing. On M1, the cross-browser experiment set reaches aggregate AUROC 0.718 under high-resolution timing, while coarse-frame measurements fall to 0.512 and timerless ordinal observations are dominated by ties. Same-browser M1 rows show the same pattern: Chrome and Brave are positive 6
contains 288 valid Chrome/Apple-Metal traces. Four-phase classification reaches macro-F1 0.903 in the primary coarse frame-level timing + texture-sampling row with 32 samples and accuracy CI [0.813, 1.000]. Active/idle reaches macro-F1 0.946 over the broader coarse frame-level aggregate with 96 samples and accuracy CI [0.917, 0.990].
Table 3: Controlled browser/native activity inference. The rightmost column reports macro-F1. Evidence reports the sample size and the strongest available control for the headline row. CIs are accuracy CIs when the derived artifact reports accuracy intervals. Platform
Task
Evidence and control
Win AMD
Exploratory pairwise native phase Active/idle
Repeated timer aggregates; 48 0.875–0.937 samples per pair; supporting pairwise rows High-resolution aggregate; 96 0.738 samples Coarse RAF + barrier; 32 0.782 samples Coarse RAF + texture 0.903 sampling; 32 samples; accuracy CI [0.813, 1.000]; perm. max F1 0.452 Coarse RAF aggregate; 96 0.946 samples; accuracy CI [0.917, 0.990]; perm. max F1 0.695
Win NVIDIA Win Active/idle NVIDIA M1/Metal Four-phase native classification M1/Metal Active/idle
Macro-F1
Windows rows are more heterogeneous. AMD rows are strongest for exploratory pairwise phase contrasts, reaching 0.875–0.937 macro-F1 across repeated timer aggregates. NVIDIA rows are stronger for active/idle in the focused repeat, reaching 0.738 macro-F1 over 96 high-resolution traces and 0.782 macro-F1 in a coarse frame-level + barrier row. This heterogeneity motivates the multi-platform design: adapter, backend, driver, and scheduler behavior all affect performance on the same inference task. Controlled repeats keep active/idle as the stable result. The browser/native stability repeat preserves the main conclusion. On M1/Metal, active/idle inference remains the most stable browser/native result: the 2026-06-11 repeat reaches macro-F1 0.931 for coarse frame-level timing, 0.813 for queue-progress observables, and 0.786 for high-resolution JavaScript timing. The same repeat preserves a strong fourphase coarse frame-level + texture-sampling result at macroF1 0.914, but with only 12 samples; broader four-phase aggregates are weaker. The stable M1 claim is active/idle inference, with four-phase structure as supporting evidence. The Windows repeat shows the same pattern. Browser/native activity remains measurable in controlled OpenCL conditions on both AMD and NVIDIA, but the strongest phase pairs shift across repeats. This supports the heterogeneity framing and keeps small pairwise rows out of the headline claim.
normalize pipeline state at acceptable cost while preserving WebGPU functionality.
4.3 Inferring Native GPU Activity from WebGPU The second controlled result crosses the browser/native boundary. The attacker is a WebGPU page; the victim is a controlled native GPU workload. The result is activity and phase inference for synthetic native workloads, without victim memory or content. The boundary is browser WebGPU versus native GPU work. The Windows native victim uses OpenCL and exercises repeated compute and phase patterns under both the default AMD/RDNA-3 path and forced NVIDIA/Lovelace paths. On Apple, the M1 experiment uses a native Metal victim and a Chrome WebGPU probe. In both cases, victim labels are evaluator-only ground truth; the attacker observes only its own WebGPU progress, timing, or coarse completion. The victim is outside the browser process family, so positive rows indicate contention or scheduling effects visible through the shared OS, driver, backend, or GPU stack.
Permutation controls and synthetic victims bound the claim. Label-permutation controls keep the result grounded. The Windows focused four-class native-phase control has max macro-F1 0.454 across 20 seeds. The M1 native-phase control has max macro-F1 0.452, and the M1 active/idle control has max macro-F1 0.695. Pairwise rows are easier to overfit under permutation, so aggregate and repeated rows carry the main evidence. The M1 active/idle control is conservative because the compact repeat set preserves session and experiment structure; we compare against that higher control. The victims are synthetic and controlled. The browserpolicy result is that a WebGPU page can observe coarse native GPU activity under controlled conditions. That is the right unit for evaluating browser and GPU-stack isolation policy.
Synthetic native activity is inferable under controlled coresidency. The controlled browser/native rows cover activity and phase classification outcomes (see Table 3). Throughput slowdowns are supporting interference evidence, not classification results; Appendix Table 16 reports the exact rows.
4.4
M1/Metal is strongest for active/idle inference. Unlike the pipeline-state measurements, the strongest M1/Metal results use coarse frame-level signals. The native Metal repeat set
Other WebGPU Resource Surfaces
WGPUL ENS also measures memory, bandwidth, functional units, atomics, barriers, queues, textures, and controlled work7
load classification. These non-pipeline results provide context for the main pipeline-state finding: they are measurable but weaker, noisier, and more platform-specific.
help, but their effect is surface-specific: some scheduler rows collapse under coarse timing, some coarse browser/native rows remain strong, and timerless ordinal rows are weak in the current Windows non-pipeline dataset. Timer policy is one dimension of a broader measurement problem.
Non-pipeline contention is measurable but weaker. Table 12 in the appendix summarizes representative nonpipeline rows alongside the pipeline rows for scale. On the Windows host, AMD Chrome reaches AUROC 0.660 for a high-resolution bandwidth row and 0.684 for a queue-progress functional-unit row. Forced NVIDIA Chrome reaches 0.797 for a short-interval queue-progress functional-unit row. Timerless non-pipeline rows peak at 0.575 locally. These abovechance rows provide supporting coverage; the primary privacy claim rests on pipeline state. These rows give a clear ordering: pipeline state is the strongest controlled surface, browser/native activity is the strongest cross-boundary activity result, and non-pipeline contention provides coverage and negative evidence for future mitigations.
5
Participant Field Measurements
The opt-in participant field study measures three things: deployment and compatibility, active WebGPU diversity and sample-level fingerprintability, and repeatability through repeated local-storage identifiers.
5.1
Participant Coverage and Compatibility
The participant study is opt-in and same-page. The participant field study uses an opt-in benchmark deployed as a public page. The page presents a short disclaimer, asks for consent, runs after one button press, shows progress, and uploads a compressed JSON payload through a form endpoint. The participant protocol is same-page by design, with no victims, extra tabs, or native workload coordination. It records classic browser properties, canvas hashes, WebGL/WebGL2 capabilities, shader precision, extension counts, render hashes, WebGPU adapter features and limits, active WebGPU outputs, compact active timing summaries, dynamic same-page probe summaries, completion status, and a random localStoragescoped identifier for soft deduplication. That identifier is not a login, IP address, account identity, browsing history, or localfile identifier.
Controlled workload classification is measurable in synthetic settings. Controlled render-phase classification is possible in synthetic settings, but this task is substantially narrower than real-site fingerprinting. The M1 Chrome/Brave Apple/Metal dataset contains 576 validated traces across three render phases, three probe families, four timer modes, and eight repeats. The primary high-resolution row reaches accuracy 0.729 and macro-F1 0.731 with 95% bootstrap interval [0.660, 0.799]. Ten label-permutation controls over the same dataset have maximum primary accuracy 0.583. The Windows workload rows show the same caution. Controlled WebGPU render-phase workloads can be distinguished, with strength depending on adapter and observable. Realistic WebGL/canvas-style victims are near chance in the current pilot tests. We use this result as supporting evidence for controlled workload-structure measurement; open-world website fingerprinting requires a separate experiment.
Participant uploads reconstruct into completed records. Large gzip/base64 payloads are chunked across participantupload rows, so we reconstruct logical browser runs before analysis. The export contains 7,999 participant-upload rows, 1,534 reconstructed logical runs, 1,127 completed runs, 1,095 deduplicated completed records, and 80 local-storage identifiers seen more than once; Appendix A.2 gives the funnel. The 118 decode errors are incomplete chunk groups, not malformed completed payloads, and are excluded from primary metrics.
Controlled repeats preserve the moderate workload claim. Repeated experiments preserve this moderate interpretation. The hidden label is a synthetic WebGPU workload or render phase. On M1/Metal, the 2026-06-11 repeat classifies controlled render phases with macro-F1 0.740 under coarse_raf, 0.700 under high_res_js, and 0.696 under queue_progress. The timerless_ordinal row remains below baseline at macro-F1 0.213. On Windows, the repeated workload-classification experiment remains strong on the AMD path (macro-F1 0.963 for both high_res_js and coarse_raf) and weak on the forced NVIDIA path. This repeat supports a controlled workload classification claim.
Compatibility follows browser and adapter exposure. Compatibility failures are part of the result: a browser where navigator.gpu is unavailable or requestAdapter returns null is counted as an unavailable WebGPU configuration. Completion varies by browser: Chrome completes 678 of 898 decoded runs, Safari 151/211, Edge 115/132, Firefox 84/137, Chromium-family variants 64/112, and other browsers 35/44. The strongest split is by adapter exposure. When a concrete GPU vendor is exposed, completion is high: Intel 402/413, AMD 137/139, NVIDIA 123/124, Apple 297/297, Qualcomm 42/57, and ARM 35/35. Unknown adapters complete only 84
Timer effects are surface-specific. The non-pipeline rows reinforce the timer results from Section 4.2. Timer restrictions 8
of 462 decoded runs. WebGPU exposure depends on browser, platform, and adapter configuration. The second campaign expands mobile and Apple coverage: the completed set includes 145 iOS runs and 78 Android runs.
Table 4: Standalone WebGPU anonymity sets over 1,095 completed deduplicated participant records. Output-only rows use render, compute, and pipeline hashes without active timing summaries. WebGPU signature
5.2 Active WebGPU Signals and Fingerprintability Signatures separate static exposure, active outputs, and timing. We compute signatures for four families of features. Classic signatures include browser, OS, version, screen, timezone, hardware, fonts, canvas, and WebGL. WebGPU static signatures use support, adapter features, limits, and metadata that the browser exposes before active work. WebGPU active signatures are reported in two layers: output-only render/compute/pipeline hashes, and an active WebGPU signature that adds stability flags and compact duration summaries. Dynamic same-page summaries capture coarse behavior from the short WebGPU probe suite.
Sets
Entropy bits
Largest set
Static exposure 122 Render output hash 9 Compute output hash 14 Pipeline output hashes 1 16 Render + compute + pipeline outputs Active signature (outputs + tim- 1,095 ing)
5.188 2.548 3.219 0.000 3.250
168 329 238 1,095 238
10.097
1
Table 5: Sequential participant fingerprinting ablation over completed deduplicated participant records. Features
Sets Entropy ∆ bits Singleton fraction
Browser + OS 16 + browser/OS versions 80 + screen/timezone/hardware 901 + canvas 938 + fonts 977 + WebGL metadata 1027 + WebGL render hashes 1028 + WebGPU static 1031 + WebGPU active 1,095
Analysis signatures exclude upload and recruitment identifiers. Before computing anonymity sets, the analyzer canonicalizes feature objects and excludes fields that would trivially identify a run: participant identifier, local run index, upload filename, chunk count, form row metadata, collection or completion timestamps, completion code, participant-platform completion metadata, and recruitment URL parameters. The standalone active WebGPU signature is built from deterministic render, compute, and pipeline outputs, within-run stability flags, and compact duration summaries for pipeline creation, submission, and readback. The dynamic signature is reported separately and comes from the short same-page probe suite.
2.961 4.280 9.658 9.750 9.833 9.950 9.952 9.961 10.097
– 1.319 5.378 0.092 0.083 0.117 0.002 0.009 0.136
0.000 0.029 0.721 0.772 0.831 0.899 0.900 0.903 1.000
tinctive in this sample, while repeated local-storage identifiers show more limited exact stability. Static WebGPU fields and output hashes still leave collisions: render and compute hashes separate broad classes, while the pipeline output hash is stable across all completed runs. The active WebGPU signature places every completed deduplicated record in this sample in a singleton anonymity set, including major subsets: Windows 650/650, macOS 193/193, iOS 133/133, Android 77/77, Chrome 669/669, Safari 137/137, and known-GPU rows 1,011/1,011. This comes from WebGPU behavior itself, without the full classic browser fingerprint.
The participant protocol runs the same active probes without labels. The participant benchmark reuses the browserside probes used by controlled scenarios: render work, compute work, pipeline creation, compact timing summaries, and short dynamic same-page probes. In the participant protocol these measurements are unlabeled field observations. They support compatibility, active-signal diversity, fingerprintability, and repeatability across real stacks; controlled scenarios add labels and placement control.
Active behavior adds entropy over coarse baselines. The incremental value of WebGPU depends on the baseline. Against the full classic fingerprint, the increment is very small because the baseline is already nearly saturated at 1,091 anonymity sets and 10.089 bits, close to log2 (1,095) = 10.097. This is common in rich browser-fingerprinting datasets. Over coarser baselines, the active WebGPU signature adds 7.136 bits to browser/OS buckets, 5.817 bits to browser/OS/version buckets, and 4.909 bits to WebGPU static exposure alone. The last number shows that active execution behavior carries information beyond adapter features and limits. Table 5 shows the cumulative feature ablation. Final increments are small because earlier classic browser fields already
Active WebGPU is distinctive within this sample. The full classic fingerprint is nearly saturated in this export: 1,091 of 1,095 completed deduplicated records are unique. The main field result is standalone WebGPU fingerprintability. Static exposure is coarse; output hashes distinguish some graphics classes; the active WebGPU signature combines output hashes, stability flags, and compact timing summaries. Table 4 shows the ablation. Distinctiveness and repeat stability are different properties: timing-rich signatures are highly dis9
Table 6: Repeatability checks in the participant dataset. Rows with denominator 80 count local-storage identifiers seen more than once, not people or individual runs. Check Intra-run deterministic active components Repeated WebGPU static signature Repeated WebGPU active signature Repeated classic signature Repeated combined signature
Table 7: Page-load WebGPU exposure in the Tranco top-10k crawl. Counts are conservative; static and dynamic evidence can overlap.
Stable / comparable
Outcome
1,127/1,127 80/80 57/80 62/80 45/80
Attempted URLs Successful page-load records
10,000 Crawl scope. 7,477 Pages that reached the measurement point. WebGPU-positive records 56 Static or dynamic WebGPU evidence. Dynamic WebGPU-call evidence 33 Runtime calls observed during page load. Static WebGPU evidence 29 WebGPU tokens in fetched scripts. Adapter-probe-only records 32 Environment or capability probing. Device-probe records without 1 Device request observed, work but no submitted work. Static-reference-only records 23 Bundled or dormant WebGPU support code. Observed page-load WebGPU shader, pipeline, 0 No work queue, query, or map activity observed.
make almost every record unique in this sample. The full classic fingerprint includes additional classic fields not shown in the sequential ablation; Table 5 reports the ordered subset used for feature-attribution analysis. Entropy and anonymity-set values are empirical plug-in estimates over the 1,095 completed deduplicated records; we use them to compare feature sets within this export. Broader uniqueness and tracking claims would require a planned longitudinal sample.
5.3
Count Interpretation
Participant Stability and Repeats
Participant results support deployment, active diversity, and repeatability. The participant results show that the harness runs on real browsers, compatibility failures are structured, active WebGPU probes are high-entropy, and active components are stable within a run.
Local-storage identifiers provide a repeat-visit check. We use a first-party local-storage identifier to control repeated submissions. The study page stores a random identifier in local storage and includes it in later uploads from the same browser storage state. In the export, 125 completed runs carry a local-storage identifier already seen before. Those repeats map to 80 identifiers because some identifiers appear in three or more completed runs.
6
Page-Load WebGPU Exposure
The crawl asks whether public pages touch WebGPU during normal page load, and in what source context. We answer it with a Tranco top-10k crawl. The claim is page-load exposure of adapter probing and WebGPU-bearing source code; leakage and fingerprintability come from controlled rows and participant runs.
Deterministic components are stable within a run. All 1,127 completed runs report within-run stable deterministic WebGPU components: render hash present in 1,127/1,127 runs, compute hash present in 1,127/1,127, pipeline hash present in 1,127/1,127, and the active stability flag true in 1,127/1,127. This supports an intra-run claim for the deterministic output components. The active signature, including compact timing summaries, is used for empirical fingerprintability over completed deduplicated records (see Table 6).
The crawl measures page-load exposure. The crawler loads each site in Chromium and writes one bounded JSONL record per URL. It instruments selected WebGPU API calls, records bounded call stacks, scans fetched scripts for WebGPU, WebGL, and canvas markers, and stores source URLs and script hashes. Records omit HTML, JavaScript bodies, screenshots, browser profiles, account data, and browsing histories. The crawl is page-load only: no clicks, logins, attempts to complete consent dialogs, or application paths, so it is a lower bound on interactive WebGPU use. Appendix A.2 defines the static-reference, adapter-probe, device-probe, and observed-work evidence levels.
Repeated local-storage identifiers give a limited stability check. For rows with denominator 80, stable means that every completed run from the same first-party local-storage identifier produced the same signature. WebGPU static signatures are stable in 80/80 repeated identifiers, WebGPU active signatures in 57/80, classic signatures in 62/80, and combined signatures in 45/80. The 1,127/1,127 row supports within-run stability. Rows with denominator 80 show repeat stability: how often the same local-storage state produced the same signature in later completed runs. Planned follow-up across time, browser restarts, browser updates, and driver or OS changes is needed for longitudinal tracking.
Page-load exposure is mostly adapter probing and static support code. The crawl attempted 10,000 URLs, obtained 7,477 successful page-load records, and found 56 WebGPUpositive records: 33 with dynamic WebGPU calls and 29 with 10
static WebGPU evidence. Static and dynamic evidence can overlap. The positives consist primarily of adapter probes and static references. We observed no page-load compute workloads: no shader-module creation, pipeline creation, queue submission, query-set use, or buffer mapping. The most common runtime behavior is navigator.gpu.requestAdapter; one record reached requestDevice without submitting work (see Table 7).
Table 8: Measured pipeline-cache mitigation rows. Sourcelevel key separation approximates pipeline-cache partitioning as the main case study. Evidence reports the sample size or pilot status carried by the source artifact. Mitigation baselines are matched to their mitigation harnesses and may differ from the primary boundary rows in Table 2.
Source context contains fingerprinting-adjacent and capability markers. We classify source context conservatively because one crawled bundle can mix fingerprinting, antiabuse, analytics, graphics, and capability code. The largest group contains fingerprinting-adjacent source markers: 28 records contain WebGPU references near fingerprinting, WebGL, canvas readback, buffer readback, shader, or identifiers and strings containing fingerprinting-related names such as fp. Six records are anti-abuse or trust-safety context, six are media or player capability checks, four are analytics or generic capability checks, three combine media/player code with neighboring risk markers, and nine remain manual-review or unclear cases. Appendix A.2 lists the triage rules and representative source families.
Surface
Policy or condition
Pipeline
Windows source-key 2 traces; small-n 0.994→0.606 separation policy row (0.388)
Pipeline
M1 source-key sepa- 10 files; 150/150 0.759→0.520 ration cold/warm per con- (0.239) dition Chromium source 30-trial cross-origin 0.648→0.525 partition prototype (0.123)
Pipeline
Evidence
AUROC base→mit. (delta)
Cost
+6.05 ms warm compile +0.53 ms warm compile extensionlevel shim
Mitigations target different WebGPU surfaces. The prototype covers five defense families: source partitioning for pipeline cold/warm state, metadata bucketing for adapter exposure, observable padding for queue and completion timing, readback perturbation for active output fingerprints, and WebGPU gating for the strictest mode. The main measured policy is source-level key separation as a proxy for pipeline cache partitioning; Appendix A.3 lists the full defense taxonomy.
Representative positives reproduce across Chromiumfamily browsers. A focused reproduction pass on 13 representative positives, repeated three times across Chromiumfamily targets, reproduced runtime WebGPU calls on 12 targets; the remaining target stayed negative. Across Chrome, Edge, and Brave, outcomes and call counts were stable across the three repetitions, and 11 targets retained the same callsite family. This supports a narrow deployment claim: adapter probing appears in crawled scripts and is reproduced across the tested Chromium-family browsers.
The prototype demonstrates policy choices, not browser patches. The extension prototype lets the same stress page run with defenses enabled or disabled, records active defenses, and shows what each policy changes. Measured source-level key-separation rows are policy simulations and extensionlevel demonstrations; browser-engine cache-key patches are the production target. In these experiments, modifying the WGSL source prevents reuse of an identical source-derived key across the tested boundary, approximating cache-key separation. This is closer to cache busting than a production browser implementation. A production implementation would attach origin, top-level site, profile, private-mode, or session state to an internal browser/backend cache key and measure the same leakage/cost tradeoff.
The crawl gives browsers concrete exposure points. The crawl connects the controlled and participant evidence to real web pages. Some crawled scripts query WebGPU as an environment signal, mostly through adapter probing and bundled support code, with no page-load shader, pipeline, queue, query, or map activity. This gives browser vendors a concrete place to evaluate metadata exposure, adapter availability, permission, visibility rules, and source partitioning.
Mitigation: Pipeline Cache-Key Separation
Measured rows compare leakage reduction with cost. Table 8 reports rows with both a baseline and a mitigated condition. We evaluate each defense as leakage reduction plus cost: compile latency, frame latency, jank, compatibility loss, correctness loss, or loss of WebGPU functionality. Source-level key separation is the measured case study for pipeline cache policy; timer and dispatch rows are exploratory pilots.
Controlled results point to pipeline cache policy: the signal comes from cold/warm reuse, calling for cache partitioning or source-level key separation. The key mitigation question is what browser-controlled state should be partitioned, bucketed, delayed, perturbed, or gated, and at what cost.
Pipeline cache policy is the clearest measured direction. On Windows, the small-n policy-simulation row reduces cold/warm AUROC by 0.388 at +6.05 ms warm-compile cost. On M1, the larger M1 experiment reduces AUROC by 0.239, moves the mitigated result below the 95th-percentile
7
11
permutation threshold, and adds +0.53 ms warm-compile overhead. The extension prototype supports the same direction at page level: AUROC drops from 0.648 to 0.525 in a local cross-origin priming row. These rows support a direct browser question: should shader and pipeline caches be reused across origin, profile, session, or private-browsing boundaries?
scheduling. For each state, browsers should vary the boundary, the observable, and the cost. The relevant boundaries include same page, cross-origin placement, tab, profile, private session, browser application, restart, and native co-residency. The relevant observables include high-resolution timing, framelevel events, queue or map completion, output hashes, and ordinal outcomes. The relevant costs include compile latency, frame pacing, jank, fallback behavior, and correctness for applications that expect exact GPU readback. This is why timer clamping, metadata bucketing, cache partitioning, readback perturbation, and access gating cannot be evaluated as one defense.
Timer and dispatch policies are exploratory. Timer clamping is mixed: a 32 ms clamp collapses one scheduler row and weakens one bandwidth row, while an 8 ms clamp gives inconsistent separability. The current dispatch-cap experiments validate the instrumentation but do not show a conclusive mitigation effect. Timer clamps and dispatch caps remain useful only when tied to a specific surface and cost. Appendix A.3 lists the exploratory rows.
Evidence boundaries. Table 1 defines what each dataset can support. Controlled rows support leakage, boundary, browser/native, workload, and mitigation claims because they include labels and explicit placement. Participant rows support compatibility, heterogeneity, sample-level fingerprintability, and repeated local-storage identifiers on deployed browsers. Page-load crawl rows support WebGPU exposure and source context on public pages. These roles keep controlled leakage, field distinctiveness, repeat behavior, and page-load exposure from being treated as the same claim.
Production defenses belong where browsers control the surface. Pipeline state needs shader and pipeline cache policy: origin/profile partitioning, private-mode clearing, or internal cache-key separation. Static exposure can be reduced by limiting or bucketing the features and limits exposed to pages. Timing surfaces need timestamp-query and completion semantics measured against latency and jank. Active output fingerprints need readback budgets or explicit privacy modes because changing readback data affects correctness.
External validity. The controlled victims are synthetic by design: they provide clean labels and avoid real user activity, but they do not cover all real workloads. Workload classification covers controlled render-phase inference; browser/native rows cover controlled native activity and phase inference. Windows AMD/NVIDIA and Apple M1/Metal are the strongest controlled experiment sets. Mobile, Safari, Intel, Qualcomm, and ARM coverage remain collection targets. Participant repeats show the same first-party local-storage state returning to the benchmark; planned follow-up is needed for stability across browser restarts, software updates, driver changes, and longer time windows [2, 15, 25, 29, 42, 57].
Mitigations need surface-specific testing. A WebGPU privacy test suite should implement a candidate policy, rerun the same rows, and report leakage reduction with user-visible cost. For the current data, pipeline cache partitioning is the strongest measured direction. Timer clamping, metadata bucketing, readback perturbation, and access gating remain useful when their surface and cost are explicit.
8
Discussion and Limitations
Browser policy. WebGPU privacy review should carry the WebGL lesson into compute. WebGL exposed adapter identity, rendering output, and graphics-stack variation. WebGPU adds programmable workloads, pipeline creation, queue progress, and backend scheduling. In our controlled matrix, persistent pipeline state is the clearest place to start: shader and pipeline cache reuse should be tested across origin, top-level site, profile, session, private-mode, restart, and application boundaries. Any policy must report both leakage reduction and user-visible cost, especially compile latency and compatibility for applications that rely on pipeline reuse [28, 30, 45].
Root cause and instrumentation. Browser GPU processes, Dawn/wgpu/WebKit policy, OS scheduling, drivers, filesystem caches, thermal state, and power policy can all affect the measured signals. WGPUL ENS records metadata and supports repeats, but full attribution requires browser and driver instrumentation. A platform test suite can make that work tractable: hold the workload, boundary, observable, and metric fixed while browsers, backends, drivers, and mitigation policies change [67–69].
9
What browsers should test. The same policy question should be applied to each WebGPU state separately: adapter metadata, shader-module state, pipeline-cache state, queue completion, buffer mapping, readback output, and background
Related Work
Web graphics fingerprinting. WebGPU extends a long web-graphics privacy line. Panopticlick introduced entropy and anonymity-set metrics [10]. Canvas/WebGL, OS, hardware, and graphics features distinguish browsers 12
[5, 35], and DrawnApart showed that WebGL execution behavior can identify GPUs [23]. WebGL also shaped mitigation and policy: Rendered Private rewrites GLSL, while WEBGL_debug_renderer_info is treated as privacysensitive adapter exposure [21, 31, 70]. WGPUL ENS measures the newer WebGPU surfaces: programmable workloads, queue progress, and pipeline state. WebGPU attacks and fingerprinting. WebGPU-SPY applies cache occupancy on Intel integrated GPUs to website fingerprinting [12]. Giner et al. automate drive-by WebGPU cache attacks across desktop GPUs and vendors [14]. AtomicIncrement and LockedApart use WebGPU or compute scheduling for device fingerprinting [19, 24]. WGPUL ENS complements these attacks with a measurement design that compares persistent compilation state, browser/native coresidency, non-pipeline probes, timer-degraded observations, participant field measurements, page-load adapter probing, and mitigation cost. Graphics and GPU side channels. GPU side channels predate WebGPU. Prior work covers page-content exposure from rendering vulnerabilities [26], web-exposed graphics and compute channels [13, 38], context-switching leakage [64], integrated CPU-GPU channels [8], and multi-GPU contention [9]. Browser graphics also exposes compression [62], frequency/power/temperature effects [54], SVG filter leakage [40], mobile pixel stealing [61], and Apple M-series cache effects [72]. Timerless GPU caches, uncore resources, and partitioned deployments add further resource families [18, 34, 73]. These results motivate WGPUL ENS’s memory, texture, functional-unit, atomic, queue, scheduler, and persistent-state probes. Browser timing and shared resources. Browser sidechannel work shows that ordinary APIs can expose sharedresource behavior. Timer mediation remains subtle [22, 49, 56]; generic computation can identify devices [48]; and JavaScript cache attacks remain practical under restrictive APIs [41, 50, 51]. OPFS contention [65] and extension-policy leakage [47] show similar patterns in other browser resources. Cookies from the Past combines timing, web-scale scanning, validation, stability tests, and countermeasures [46]. WGPUL ENS applies this measurement style to WebGPU with controlled labels, field traces, crawl data, and leakage/cost rows. Browser fingerprinting and measurement observatories. Large-scale fingerprinting studies provide the fieldmethodology baseline. FPDetective, Cookieless Monster, and OpenWPM measured web fingerprinting and standardized browser automation [1, 11, 39]. Hiding in the Crowd, surveys, FP-STALKER, FP-Scanner, FP-Inspector, FP-Radar, fingerprint dynamics, and long-term studies refine uniqueness, stability, countermeasure consistency, and linkability metrics [2, 15, 20, 25, 29, 42, 57, 58]. Static/dynamic measurement and emerging-technique work motivate evaluating new browser APIs during deployment [44, 53]. WGPUL ENS measures
WebGPU’s incremental fingerprintability beyond these established features. It also brings WebGPU measurement into the same deployment and field-study frame used by these observatory efforts. Correctness, memory safety, and mitigation context. Recent WebGPU and GPU-stack work studies bugs or correctness failures: LeftoverLocals demonstrates GPU localmemory disclosure [52], Whispering Pixels studies register residual leakage [43], and SafeRace, WebGlitch, and DarthShader study WGSL races, randomized WebGPU programs, and shader translation/compiler pipelines [3, 27, 66]. Mitigations such as GPUGuard propose spatial and temporal partitioning for contention channels [71]; W3C guidance, privacy budgets, Brave, Firefox RFP, and Tor Browser illustrate browser-side capability and fingerprinting policy [4, 16, 36, 55, 67–69]. These works provide context for evaluating WebGPU leakage and browser defenses. WGPUL ENS evaluates WebGPU mitigation as a surface-specific leakage/cost tradeoff.
10
Conclusion
WebGPU brings GPU computation into the web platform. Its validation rules protect memory safety, but they do not remove every privacy-relevant signal. The key question is: which state crosses which boundary, under which observable, and at what cost to mitigate it. WGPUL ENS answers that question with controlled scenarios, participant field measurements, and page-load crawl data. Persistent pipeline compilation state is the strongest measured surface. Browser/native active-idle inference is the strongest co-residency result under synthetic native workloads. Controlled workload classification and other resource surfaces are measurable but more platform-specific. Timer reduction helps some rows, especially pipeline-state rows, but it does not solve the problem by itself. Field participant runs show active WebGPU behavior is highly distinctive when compact timing summaries are included. Deterministic active components are stable within runs, while exact repeat stability across repeated local-storage identifiers is lower. The page-load crawl shows WebGPU in public-page scripts mainly as adapter probing and static support code, not as observed page-load shader, pipeline, queue, query, or map work. The first mitigation target is browser-controlled persistent state. Browsers should test shader and pipeline cache partitioning across origin, top-level site, profile, session, private-mode, and application boundaries. They should also measure adapter metadata, completion observables, active output hashes, and browser/native scheduling separately. Source-level key separation is a proxy, but it shows the leakage/cost tradeoff that browser cache policy must make explicit. 13
Ethical Considerations
back noise, and access gating. The artifact labels these prototype mechanisms “static masking” and “readback noise”; in the paper, we refer to the broader policy families as metadata bucketing and readback perturbation. These extension defenses are released as reproducible demonstrations and policy experiments; browser-engine isolation remains the production target. Code that could be repurposed as a turnkey attack against real websites is restricted or released in a nonoperational form. The artifact is organized around the evidence boundaries used in the paper. For controlled scenarios, it includes normalized pipeline-boundary, stability, browser/native, workload, and mitigation summaries sufficient to regenerate the reported AUROC, macro-F1, confidence-interval, count, and cost rows. For the participant field study, it includes privacy-reviewed aggregate and deep-analysis outputs for the ingestion funnel, entropy, anonymity sets, active WebGPU ablations, and repeat evidence. For the Tranco crawl, it includes bounded crawl summaries, provenance metadata, and the focused case analysis used to support the page-load exposure claims. Raw participant exports, completion metadata, high-entropy identifiers, full crawled JavaScript bodies, browser profiles, and private lab caches are not included in the anonymous artifact. Tiered checks can be run from the artifact root. The health tier verifies manifest hashes, sample traces, and dependencies. The derived tier regenerates the packaged summaries for pipeline state, browser/native activity, participant fingerprintability, page-load WebGPU exposure, and mitigation. Optional tiers cover local interactive demos and small machinedependent reruns. These local reruns are provided for inspection and usability; the paper metrics are reproduced from the normalized derived data.
Participant measurements are opt-in, synthetic, and local to the study page. The page explains the research purpose, requests consent, shows progress, and uploads only the benchmark payload. The payload excludes browsing history, page contents, account identifiers, keystrokes, contacts, local files, and real website activity. The collection was not reviewed by an IRB; participant-based claims are therefore limited to technical compatibility, sample-level fingerprintability, and repeat behavior observed within the benchmark data. The participant benchmark uses a random first-party localStorage identifier for deduplication and repeat checks; it is not a login, IP address, or real identity. In the CloudResearch deployment, a completion code is shown after upload and stored in the JSON so completion can be reconciled without platform participant IDs. Payment, approval, marketplace account state, eligibility, compensation, and account fields stay outside the released traces and are not analysis variables. Device targeting is used only to obtain browser and platform coverage. The upload mechanism uses Google Forms as transport for compressed JSON payloads. The benchmark payload excludes IP addresses and account identifiers, but Google may retain operational logs outside the research artifact. Raw response exports and decoded high-entropy traces are restricted to the research team and are not included in the release artifact. Public trace releases bucket or normalize high-entropy metadata, remove completion and provider metadata, and separate raw internal review material from reproducible artifacts. Clearing site storage prevents later runs from being linked through the previous local identifier; it does not remove submitted records. The page-load crawl uses public pages only. It does not log in, click through sites, complete consent dialogs, or interact with application workflows. Crawl records are bounded pageload WebGPU summaries: call metadata, bounded call stacks, source URLs, script hashes, and static markers. The artifact excludes full HTML, full JavaScript bodies, browser profiles, account data, and crawl screenshots. The runner uses perpage timeouts, a per-URL budget, one concurrent page load by default, and blocked image, media, and font resources.
References [1] Gunes Acar, Marc Juarez, Nick Nikiforakis, Claudia Diaz, Seda Gürses, Frank Piessens, and Bart Preneel. FPDetective: Dusting the web for fingerprinters. In Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security, pages 1129– 1140, 2013.
Open Science
[2] Pouneh Nikkhah Bahrami, Umar Iqbal, and Zubair Shafiq. FP-Radar: Longitudinal measurement and early detection of browser fingerprinting. Proceedings on Privacy Enhancing Technologies, 2022(2):557–577, 2022.
The anonymous review artifact is available at https:// anonymous.4open.science/r/WGPULens/. It packages the WGPUL ENS measurement code, WGSL probes, probe generator, browser runners, synthetic victims, participant benchmark tooling, schemas, participant decoders, analysis code, normalized derived data, Chromium and Firefox extension prototypes, and reproduction instructions. The extension artifact exposes the same defense families discussed in Section 7: source partitioning, static masking, observable padding, read-
[3] Lukas Bernhard, Nico Schiller, Moritz Schloegel, Nils Bars, and Thorsten Holz. DarthShader: Fuzzing WebGPU shader translators and compilers. In Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security, pages 690–704, 2024. 14
[4] Brave Software. Fingerprinting protections. https://github.com/brave/brave-browser/ wiki/Fingerprinting-Protections, 2026.
[15] Alejandro Gómez-Boix, Pierre Laperdrix, and Benoit Baudry. Hiding in the crowd: An analysis of the effectiveness of browser fingerprinting at large scale. In The Web Conference, pages 309–318, 2018.
[5] Yinzhi Cao, Song Li, and Erik Wijmans. (Cross)browser fingerprinting via OS and hardware level features. In Network and Distributed System Security Symposium, 2017.
[16] Google Privacy Sandbox. Privacy budget. https://privacysandbox.google.com/ protections/privacy-budget, 2024.
Chrome ships We[6] Chrome Developers. bGPU. https://developer.chrome.com/blog/ webgpu-release/, 2023.
[17] GPU for the Web Community Group. WebGPU implementation status. https://github.com/gpuweb/ gpuweb/wiki/Implementation-Status, 2026.
[7] Chrome for Developers. WebGPU is now supported in major browsers. https://web.dev/blog/ webgpu-supported-major-browsers, 2026.
[18] Cheng Gu, Reese Levine, Zhenkai Zhang, Tyler Sorensen, and Yanan Guo. Behind bars: A side-channel attack on NVIDIA MIG cache partitioning using memory barriers. In 35th USENIX Security Symposium. USENIX Association, 2026.
[8] Sankha Baran Dutta, Hoda Naghibijouybari, Nael B. Abu-Ghazaleh, Andres Marquez, and Kevin J. Barker. Leaky buddies: Cross-component covert channels on integrated CPU-GPU systems. In 48th ACM/IEEE Annual International Symposium on Computer Architecture, pages 972–984, 2021.
[19] Konrad Hohentanner, Nils Kemmerzell, and Steffen Florschütz. Unveiling privacy risks in WebGPU through hardware-based device fingerprinting. In Proceedings of the 18th ACM Conference on Security and Privacy in Wireless and Mobile Networks, pages 65–75, 2025.
[9] Sankha Baran Dutta, Hoda Naghibijouybari, Arjun Gupta, Nael B. Abu-Ghazaleh, Andres Marquez, and Kevin J. Barker. Spy in the GPU-box: Covert and side channel attacks on multi-GPU systems. In 50th ACM/IEEE Annual International Symposium on Computer Architecture, pages 45:1–45:13, 2023.
[20] Umar Iqbal, Steven Englehardt, and Zubair Shafiq. Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors. In IEEE Symposium on Security and Privacy, pages 1143–1161, 2021.
[10] Peter Eckersley. How unique is your web browser? In Privacy Enhancing Technologies Symposium, pages 1–18, 2010.
WEBGL_debug_renderer_info. [21] Khronos Group. https://registry.khronos.org/webgl/ extensions/WEBGL_debug_renderer_info/, 2014.
[11] Steven Englehardt and Arvind Narayanan. Online tracking: A 1-million-site measurement and analysis. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 1388– 1401, 2016.
[22] David Kohlbrenner and Hovav Shacham. Trusted browsers for uncertain times. In 25th USENIX Security Symposium. USENIX Association, 2016. [23] Tomer Laor, Naif Mehanna, Antonin Durey, Vitaly Dyadyuk, Pierre Laperdrix, Clémentine Maurice, Yossi Oren, Romain Rouvoy, Walter Rudametkin, and Yuval Yarom. DRAWN APART: A device identification technique based on remote GPU fingerprinting. In Network and Distributed System Security Symposium, 2022.
[12] Ethan Ferguson, Adam Wilson, and Hoda Naghibijouybari. WebGPU-SPY: Finding fingerprints in the sandbox through GPU cache attacks. In Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, pages 158–171, 2024.
[24] Tomer Laor and Yossi Oren. Poster: LockedApart: Faster GPU fingerprinting through the compute API. https://www.uasc.cc/proceedings25/ uasc25-laor.pdf, 2025.
[13] Pietro Frigo, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi. Grand pwning unit: Accelerating microarchitectural attacks with the GPU. In 2018 IEEE Symposium on Security and Privacy, pages 195–210, 2018.
[25] Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, and Gildas Avoine. Browser fingerprinting: A survey. ACM Transactions on the Web, 14(2), 2020.
[14] Lukas Giner, Roland Czerny, Christoph Gruber, Fabian Rauscher, Andreas Kogler, Daniel De Almeida Braga, and Daniel Gruss. Generic and automated drive-by GPU cache attacks from the browser. In Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, pages 128–140, 2024.
[26] Sangho Lee, Youngsok Kim, Jangwoo Kim, and Jong Kim. Stealing webpages rendered on your browser by exploiting GPU vulnerabilities. In IEEE Symposium on Security and Privacy, pages 19–33, 2014. 15
[27] Reese Levine, Ashley Lee, Neha Abbas, Kyle Little, and Tyler Sorensen. SafeRace: Assessing and addressing WebGPU memory safety in the presence of data races. Proceedings of the ACM on Programming Languages, 9(OOPSLA2):697–725, 2025.
[38] Hoda Naghibijouybari, Ajaya Neupane, Zhiyun Qian, and Nael Abu-Ghazaleh. Rendered insecure: GPU side channel attacks are practical. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 2139–2153, 2018.
[28] Reese Levine, Rithik Sharma, Nikhil Jain, Abhijit Ramesh, Zheyuan Chen, Neha Abbas, James Contini, and Tyler Sorensen. Llamas on the web: Memoryefficient, performance-portable, and multi-precision LLM inference with WebGPU. https://arxiv.org/ abs/2605.20706, 2026.
[39] Nick Nikiforakis, Alexandros Kapravelos, Wouter Joosen, Christopher Kruegel, Frank Piessens, and Giovanni Vigna. Cookieless monster: Exploring the ecosystem of web-based device fingerprinting. In IEEE Symposium on Security and Privacy, pages 541–555, 2013. [40] Sioli O’Connell, Lishay Aben Sour, Ron Magen, Daniel Genkin, Yossi Oren, Hovav Shacham, and Yuval Yarom. Pixel thief: Exploiting SVG filter leakage in firefox and chrome. In 33rd USENIX Security Symposium. USENIX Association, 2024.
[29] Song Li and Yinzhi Cao. Who touched my browser fingerprint? A large-scale measurement study and classification of fingerprint dynamics. In Internet Measurement Conference, pages 370–385, 2020.
[41] Yossef Oren, Vasileios P. Kemerlis, Simha Sethumadhavan, and Angelos D. Keromytis. The spy in the sandbox: Practical cache attacks in JavaScript and their implications. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015.
[30] J˛edrzej Maczan. Characterizing WebGPU dispatch overhead for LLM inference across four GPU vendors, three backends, and three browsers. https://arxiv.org/ abs/2604.02344, 2026. [31] MDN Web Docs. WEBGL_debug_renderer_info extension. https://developer.mozilla.org/en-US/ docs/Web/API/WEBGL_debug_renderer_info, 2024.
[42] Gaston Pugliese, Christian Riess, Freya Gassmann, and Zinaida Benenson. Long-term observation on browser fingerprinting: Users’ trackability and perspective. Proceedings on Privacy Enhancing Technologies, 2020(2):558–577, 2020.
[32] MDN Web Docs. GPUAdapterInfo. https: //developer.mozilla.org/en-US/docs/Web/API/ GPUAdapterInfo, 2026.
[43] Frederik Dermot Pustelnik, Xhani Marvin Saß, and JeanPierre Seifert. Whispering pixels: Exploiting uninitialized register accesses in modern GPUs. In IEEE European Symposium on Security and Privacy, pages 345–360, 2024.
[33] MDN Web Docs. WebGPU API. https://developer. mozilla.org/en-US/docs/Web/API/WebGPU_API, 2026.
[44] Valentino Rizzo, Stefano Traverso, and Marco Mellia. Unveiling web fingerprinting in the wild via code mining and machine learning. Proceedings on Privacy Enhancing Technologies, 2021(1):43–63, 2021.
[34] Yuanqing Miao, Yingtian Zhang, Dinghao Wu, Danfeng Zhang, Gang Tan, Rui Zhang, and Mahmut Taylan Kandemir. Veiled pathways: Investigating covert and side channels within GPU uncore. In IEEE/ACM International Symposium on Microarchitecture, pages 1169– 1183, 2024. [35] Keaton Mowery and Hovav Shacham. Pixel Perfect: Fingerprinting canvas in HTML5. In Proceedings of W2SP 2012, 2012.
[45] Charlie F. Ruan, Yucheng Qin, Xun Zhou, Ruihang Lai, Hongyi Jin, Yixin Dong, Bohan Hou, Meng-Shiun Yu, Yiyan Zhai, Sudeep Agarwal, Hangrui Cao, Siyuan Feng, and Tianqi Chen. WebLLM: A high-performance inbrowser LLM inference engine. https://arxiv.org/ abs/2412.15803, 2024.
[36] Mozilla. Resist fingerprinting. https: //firefox-source-docs.mozilla.org/ toolkit/components/resistfingerprinting/ resistfingerprinting/index.html, 2026.
[46] Iskander Sanchez-Rola, Davide Balzarotti, and Igor Santos. Cookies from the past: Timing server-side request processing code for history sniffing. Digital Threats: Research and Practice, 1(4), 2020.
[37] Mozilla Gfx Team. Shipping WebGPU on Windows in Firefox 141. https: //mozillagfx.wordpress.com/2025/07/15/ shipping-webgpu-on-windows-in-firefox-141/, 2025.
[47] Iskander Sanchez-Rola, Igor Santos, and Davide Balzarotti. Extension breakdown: Security analysis of browsers extension resources control policies. In 26th USENIX Security Symposium, pages 679–694. USENIX Association, 2017. 16
[48] Iskander Sanchez-Rola, Igor Santos, and Davide Balzarotti. Clock around the clock: Time-based device fingerprinting. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1502–1514, 2018.
[58] Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, and Romain Rouvoy. FP-STALKER: Tracking browser fingerprint evolutions. In IEEE Symposium on Security and Privacy, pages 728–741, 2018. [59] W3C GPU for the Web Community Group. WebGPU. https://www.w3.org/TR/webgpu/, 2026.
[49] Michael Schwarz, Clémentine Maurice, Daniel Gruss, and Stefan Mangard. Fantastic timers and where to find them: High-resolution microarchitectural attacks in JavaScript. In Financial Cryptography and Data Security, pages 247–267, 2017.
[60] W3C GPU for the Web Community Group. WebGPU Shading Language. https://www.w3.org/TR/WGSL/, 2026. [61] Alan Wang, Pranav Gopalkrishnan, Yingchen Wang, Christopher W. Fletcher, Hovav Shacham, David Kohlbrenner, and Riccardo Paccagnella. Pixnapping: Bringing pixel stealing out of the stone age. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 3266–3280, 2025.
[50] Anatoly Shusterman, Ayush Agarwal, Sioli O’Connell, Daniel Genkin, Yossi Oren, and Yuval Yarom. Prime+Probe 1, JavaScript 0: Overcoming browserbased Side-Channel defenses. In 30th USENIX Security Symposium, pages 2863–2880. USENIX Association, 2021.
[62] Yingchen Wang, Riccardo Paccagnella, Zhao Gang, Willy R. Vasquez, David Kohlbrenner, Hovav Shacham, and Christopher W. Fletcher. GPU.zip: On the sidechannel implications of hardware-based graphical data compression. In IEEE Symposium on Security and Privacy, pages 3716–3734, 2024.
[51] Anatoly Shusterman, Lachlan Kang, Yarden Haskal, Yosef Meltser, Prateek Mittal, Yossi Oren, and Yuval Yarom. Robust website fingerprinting through the cache occupancy channel. In 28th USENIX Security Symposium. USENIX Association, 2019.
[63] WebKit. WebKit features in Safari 26.0. https://webkit.org/blog/17333/ webkit-features-in-safari-26-0/, 2025.
[52] Tyler Sorensen and Heidy Khlaaf. LeftoverLocals: Listening to LLM responses through leaked GPU local memory. https://arxiv.org/abs/2401.16603, 2024.
[64] Junyi Wei, Yicheng Zhang, Zhe Zhou, Zhou Li, and Mohammad Abdullah Al Faruque. Leaky DNN: Stealing deep-learning model secret with GPU context-switching side-channel. In 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, pages 125–137, 2020.
[53] Junhua Su and Alexandros Kapravelos. Automatic discovery of emerging browser fingerprinting techniques. In The Web Conference, pages 2178–2188, 2023. [54] Hritvik Taneja, Jason Kim, Jie Jeff Xu, Stephan van Schaik, Daniel Genkin, and Yuval Yarom. Hot Pixels: Frequency, power, and temperature attacks on GPUs and ARM SoCs. In 32nd USENIX Security Symposium, pages 6275–6292. USENIX Association, 2023.
[65] Hannes Weissteiner, Tobias Weiser, Roland Czerny, Sudheendra Raghav Neela, Fabian Rauscher, Jonas Juffinger, and Daniel Gruss. FROST: Fingerprinting remotely using OPFS-based SSD timing. In DIMVA, 2026.
[55] Tor Project. Fingerprinting protections in Tor Browser. https://support.torproject.org/tor-browser/ features/fingerprinting-protections/, 2026.
[66] Matthew K. L. Wong and Alastair F. Donaldson. WebGlitch: A randomised testing tool for the WebGPU api. In 39th European Conference on Object-Oriented Programming, pages 39:1–39:26, 2025.
[56] Tom van Goethem, Wouter Joosen, and Nick Nikiforakis. The clock is still ticking: Timing attacks in the modern web. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 1382–1393, 2015.
[67] World Wide Web Consortium. Mitigating browser fingerprinting in web specifications. https://www.w3. org/TR/fingerprinting-guidance/, 2025. [68] World Wide Web Consortium. Threat model for the web. https://www.w3.org/TR/threat-model-web/, 2026.
[57] Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, and Romain Rouvoy. FP-Scanner: The privacy implications of browser fingerprint inconsistencies. In 27th USENIX Security Symposium, pages 135–150. USENIX Association, 2018.
[69] World Wide Web Consortium. Web platform design principles. https://www.w3.org/TR/ design-principles/, 2026. 17
Table 11: Controlled host/browser matrix.
[70] Shujiang Wu, Song Li, Yinzhi Cao, and Ningfei Wang. Rendered private: Making GLSL execution uniform to prevent WebGL-based browser fingerprinting. In 28th USENIX Security Symposium, pages 1645–1660. USENIX Association, 2019.
Host
Edge
Brave
Firefox
[72] Tianhong Xu, Aidong Adam Ding, and Yunsi Fei. EXAM: Exploiting exclusive system-level cache in apple M-series SoCs for enhanced cache occupancy attacks. In Proceedings of the 20th ACM ASIA Conference on Computer and Communications Security, pages 1294–1308, 2025.
Chrome M1/Metal Brave Firefox
[73] Zhenkai Zhang, Kunbei Cai, Yanan Guo, Fan Yao, and Xing Gao. Invalidate+Compare: A Timer-Free GPU cache attack primitive. In 33rd USENIX Security Symposium, pages 2101–2118. USENIX Association, 2024.
Safari
Table 9: Measurement tasks, datasets, and metrics. Dataset
Pipeline state
controlled
Metric
Surface/platform
Representative row
Windows AMD pipeline
same-page high-res cold/warm same-page high-res cold/warm aggregate high-res cold/warm queue-progress functional unit queue-progress functional unit ordinal row
Windows NVIDIA non-pipeline Windows AMD non-pipeline Windows timerless non-pipeline
Metric 0.986 AUROC 0.961 AUROC 0.718 AUROC 0.797 AUROC 0.684 AUROC 0.575 AUROC
for the listed role. Chrome is the anchor browser. Chrome and Edge carry the Windows same-host AMD/NVIDIA comparison. Brave carries Chromium-family variant coverage. Firefox carries browser-family coverage because Firefox/wgpu did not expose normalized gpu_vendor or gpu_model fields in our data-collection pipeline. Safari is Apple-only WebKit coverage. Multi-day repeats are versioned in docs/windows-lab-stability-2026-06-11.md, docs/m1-lab-stability-2026-06-11.md, and the matching artifact/derived/*20260611* summaries.
Persistent state
features, limits, adapter bandwidth, ALU, atom- shader and pipeline metadata, graphics ics, queues, texture/frame cold/warm creation state hashes observables entropy and anonymity AUROC, accuracy, cold/warm boundary sepsets macro-F1, slowdown arability
A.1
anchor Apple browser; main Apple/Metal path for surface, pipeline, browser/native, and cross-browser rows Apple/Metal via Chromium-family Apple/Metal variChromium ant; Brave rows and Brave↔Chrome pipeline valid Firefox/wgpu browser-family coverage, includtraces; vendor/model ing selected non-pipeline and not exposed Firefox→Chrome pipeline rows; no vendor-specific Apple/Metal claim from Firefox-probe rows Safari/WebKit Apple Apple-only WebKit manual smoke stack row
M1 cross-browser pipeline
Table 10: Surface-to-impact map. Placement and observable mode determine which claim each surface supports. Active contention
Apple/Metal
Windows NVIDIA pipeline
Use in the paper
AUROC, CI, permu- cold/warm boundary tation p95 and cache-reuse evidence Browser/native activ- controlled macro-F1, slow- synthetic native activity down, samples ity and phase inference Other WebGPU re- controlled AUROC, accuracy, surface coverage and sources macro-F1 negative rows Participant finger- participant field entropy, anonymity sample-level active printability study sets, repeats WebGPU distinctiveness Page-load exposure Tranco crawl static/dynamic public-page WebGPU counts, triage touching Mitigation controlled and AUROC reduction, pipeline cache policy extension latency cost direction
Static exposure
Role in controlled matrix
Table 12: Representative controlled surface rows.
Technical Appendix
Task
Adapter attribution
AMD/RDNAanchor Windows browser; supports 3 default; same-host AMD/NVIDIA compariNVIDIA/Lovelace son across pipeline, web-boundary, forced profile, browser/native, and mitigation rows AMD/RDNAsecond Windows Chromium3 default; family application for the same NVIDIA/Lovelace AMD/NVIDIA comparison; forced Windows-only coverage NVIDIA/Lovelace Chromium-family variant covreported by local erage: same-page, cross-tab, Brave traces iframe, normal/private CDP, and Brave↔Chrome pipeline; not used for AMD/NVIDIA comparison valid Firefox/wgpu browser-family coverage: sametraces; vendor/model page, cross-tab, iframe, and not exposed Firefox↔Chrome pipeline; no vendor-specific AMD/NVIDIA claim
Windows
[71] Qiumin Xu, Hoda Naghibijouybari, Shibo Wang, Nael Abu-Ghazaleh, and Murali Annavaram. GPUGuard: Mitigating contention based side and covert channel attacks on GPUs. In Proceedings of the ACM International Conference on Supercomputing, pages 497–509, 2019.
A
Browser Chrome
Reading pipeline placements. Pipeline rows differ in what they vary. The same-page rows calibrate the surface. Boundary rows change origin, iframe, profile, application, or browser placement. Negative rows keep the main claim bounded.
Controlled Scenario Support
Controlled scenarios use fixed browser profiles, fixed origins, fixed window states, selected adapter configurations, labeled victims, and explicit timer modes. Table 11 lists the host/browser matrix used for the main controlled claims. A row means that the browser produced valid WebGPU traces
Metric protocol. Rows use the smallest metric needed for the claim. AUROC is used for binary cold/warm or idle/active separation. Macro-F1 is used for phase classification. Entropy 18
Table 13: Pipeline-state controls. Control
Purpose
Table 17: Participant funnel and crawl interpretation rules.
Coverage
Item
Mutated and unrelated shader families Negative same-origin cross-tab rows Permutation controls
separates exact reuse from pipeline protocol and CI generic warmup rows bounds boundary language AMD and NVIDIA nearchance rows checks separability under M1 cross-browser and narandomized labels tive matrices Multi-day repeats checks one-session sensi- Windows and M1 2026-06tivity 11 repeats Multiple adapter configu- avoids a single-adapter AMD/RDNA-3, rations story NVIDIA/Lovelace, and M1/Metal paths Retaining-layer analysis localizes the claim to browser, backend, driver, browser/GPU-stack state and cache layers remain separated by controls and policy rows
Interpretation
1,095 completed deduplicated denominator for field fingerprintability and enrecords tropy rows 80 repeated local-storage iden- repeat evidence for the same local browser stortifiers age state Static crawl reference WebGPU terms in fetched scripts; bundled support, feature detection, or dormant logic Adapter/device probe runtime requestAdapter or requestDevice; environment signal, not submitted work Observed work shader, pipeline, queue, query, or map activity; count is zero in the page-load crawl fingerprinting, anti-abuse, media/player, analytSource-context labels ics, or unclear context; source context only
Table 18: Participant repeat and signature semantics. Object
Table 14: How to read pipeline placement rows. Placement row
What changes
Use
same origin, page, profile, surface calibration and adapter and browser comparison Cross-origin or origin and page placement web-boundary placement eviiframe dence Same-origin cross- tab placement only in the negative control for broad boundtab short-interval setting ary claims Cross-profile Chrome profile state browser-state boundary evidence Chromium-family application wrapper with small-n cache-policy confirmaA→B shared stack components tion Apple/Metal A → B browser placement on the cross-browser backend check same Metal stack
Table 19: Crawl hook coverage.
Table 15: Metric and uncertainty protocol. Metric
Pipeline cold/warm
AUROC
Support shown
cold/warm counts, 95% CI, repeats or permutation p95 where available Browser/native activ- macro-F1, slowdown sample counts, accuracy CI for ity M1 rows, permutation maxima representative positive and weak Non-pipeline probes AUROC or accuracy rows, kept below pipeline in the claim hierarchy Participant finger- entropy, sets, singleton completed deduplicated denomiprints fraction nator and feature ablations AUROC reduction plus matched baseline, mitigated row, Mitigation rows cost latency or compatibility cost
Supporting row
Win NVIDIA
Native throughput; stress compute under scheduler pressure Native throughput; stress copy under bandwidth pressure
M1/Metal
Hook or scan point
Static WebGPU terms
fetched script scan
requestAdapter requestDevice Shader/pipeline work Queue/query/map work
Interpretation
bundled support, detection, or dormant code WebGPU considered by API presence hook page code adapter request hook capability or environment probe device request hook stronger capability probe shader-module and page-load WebGPU work pipeline hooks when present queue, query-set, and submitted or observable buffer-map hooks GPU work when present
participant identifiers, upload filenames, chunk counts, form metadata, timestamps, completion code, participant-platform metadata, and recruitment URL parameters.
Slowdown 8.365%
Repeat and signature semantics. The participant export uses a first-party local-storage identifier for repeat control. A repeated identifier means the same browser storage state returned to the benchmark. Fingerprint rows use analysis objects built after upload and recruitment fields are removed. The crawl records four evidence levels. Static references show that crawled code contains WebGPU terms. Adapter and device probes show runtime API use. Observed work requires shader, pipeline, queue, query, or mapping activity. The crawl attempted 10,000 Tranco URLs, obtained 7,477 successful page-load records, and found 56 WebGPU-positive records: 33 with dynamic WebGPU calls and 29 with static evidence. None showed page-load shader-module creation, pipeline creation, queue submission, query-set use, or buffer mapping. A focused reproduction pass on 13 representative positives reproduced runtime WebGPU calls on 12 targets; Chrome, Edge, and Brave preserved the same outcome and
7.077%
and anonymity sets are used only for participant fingerprints.
A.2
Observed surface
navigator.gpu access
Table 16: Supporting browser/native throughput interference rows. Platform
Use
one uploaded chunk or raw input to logical-run recompact payload row construction Logical run reconstructed browser completion and compatibilbenchmark execution ity accounting Deduplicated completed one completed record per fingerprintability denominarecord local-storage group for pri- tor mary field metrics Repeated local-storage same first-party storage repeat stability check identifier state seen again Output-only WebGPU render, compute, and deterministic active composignature pipeline output hashes nents Active WebGPU signa- outputs, stability flags, and sample-level active distincture compact timing summaries tiveness
Same page
Result family
Meaning
Participant-upload row
Participant and Crawl Support
The participant field study contributes deployment, compatibility, sample-level fingerprintability, and repeat evidence. The export contains 7,999 participant-upload rows, 1,534 reconstructed logical runs, 1,127 completed runs, 1,095 completed deduplicated records, and 80 local-storage identifiers seen more than once. The local-storage identifier describes the same browser storage state returning to the benchmark. It is separate from account, IP address, browser product, and physical-device identity. Signature construction excludes 19
Table 20: Defense families and browser targets. The extension implements these as demonstrations; production versions belong inside the browser, backend, or API policy layer. Defense fam- Target surface ily
Browser-level analogue
Source parti- pipeline origin/profile/private-mode tioning cold/warm pipeline-cache partitioning state or cache-key separation Metadata static adapter ex- feature, limit, adapter, and bucketing posure format bucketing
Table 23: WGPULens Shield operating modes. Mode
Enabled defenses
Observe
counters and page status
Functionality cost compile latency; less cache reuse
lower capability precision; possible compatibility fallback Observable queue, map, and delayed or bucketed comple- latency, frame pacpadding completion tim- tion semantics ing, and jank risk ing Readback per- active ren- explicit privacy mode correctness risk turbation der/compute or readback budget for for applications fingerprints fingerprint-sensitive surfaces that expect exact readback Access gating all WebGPU sur- permission, visibility, activa- highest compatibilfaces tion, or enterprise policy gate ity loss; blocks legitimate WebGPU
Table 24: Browser-engine mitigation targets. Browser target
State or observable
Cache-key partitioning
shader/pipeline caches include origin, profile, session, and private-mode policy state in reuse decisions adapter info, features, bucket or budget precise calimits pabilities while preserving common compatibility tiers pipeline, queue, map coarsen, budget, or normaltiming ize completion observables by privacy mode mapped GPU results keep exact by default; use strict anti-fingerprint behavior with compatibility signaling adapter availability use permission, visibility, privacy budget, or enterprise policy when WebGPU access is unavailable
Metadata reduction Async observable policy
Table 21: Exploratory timer and dispatch mitigation rows. Surface
Policy or condition
AUROC base→mit. Cost (delta)
Scheduler Bandwidth
32 ms timer clamp pilot 8 ms timer clamp pilot
Scheduler
dispatch-cap pilot
0.637→0.500 (0.137) 32 ms precision 0.588→0.644 (- 8 ms precision 0.056) 0.506→0.546 (- cap machinery 0.039) only
Readback policy
Access policy
Patched WebGPU surface
Pipeline partition
shader-module creation
Static masking Observable padding Readback noise
WebGPU gate
Purpose and tradeoff
appends a valid modulescope constant derived from location.origin; reduces cross-origin shader/pipeline reuse and may add compilation work adapter request/info proxy buckets adapter metadata, features, and limits; active probes remain possible async pipeline, queue, and resolves promises on coarse 32 map promises ms buckets; preserves results but adds latency mapped buffer readback perturbs sparse mapped bytes to disrupt active output hashes; can affect exact compute correctness adapter request returns null; strongest extension option and largest compatibility cost
Partition granularity. The pipeline measurements separate reuse within a privacy boundary from reuse across one. Browser implementations should treat shader and pipeline reuse as a privacy-policy decision, not only as a compiler optimization. At minimum, the cache key should include the selected top-level site or origin partition, profile, privatemode/session state, adapter/backend identity, and pipeline descriptor material. Same-boundary reuse preserves most cache benefit. Cross-boundary reuse exposes the persistent-state signal measured in Table 2. Timer coarsening and readback policy address different observables; they do not replace cachekey separation for persistent pipeline state. The shim runs as a main-world content script and installs once WebGPU types are available. Its direct coverage is page code after injection. Worker coverage, native applications, and OS-level GPU state require browser-engine support. A browser-engine version would move partitioning into shader/pipeline cache keys and expose metadata, timing, and readback policy through browser privacy controls.
call count for all 13 targets.
A.3
Engineering decision
Extension operating modes. The extension exposes each defense as a check. Presets combine them into three practical modes: balanced keeps outputs exact, strict perturbs readback, and gate removes WebGPU from the page.
Table 22: Extension-level mitigation mechanics in WGPULens Shield. Defense
Compatibility profile
demonstration and comparison Balanced pipeline partition, static mask, exact render/compute observable padding outputs; added latency and metadata reduction Strict anti- balanced mode plus readback active-output hashes fingerprinting noise change; exact readback can change Gate adapter request unavailable strongest reduction; highest functionality cost
Mitigation Mechanics
Mitigation rows are policy simulations and extension-level demonstrations. The Windows source-level key-separation row reduces AUROC from 0.994 to 0.606 at +6.05 ms warmcompile cost. The stronger M1 condition-level row reduces AUROC from 0.759 to 0.520 at +0.53 ms warm-compile cost. The Chromium extension source-partition prototype reduces AUROC from 0.648 to 0.525. These rows point to pipeline cache partitioning as the clearest measured direction; timer clamping and dispatch caps remain exploratory. 20