What Browsers Do in the Shaders: A Measurement Study of WebGPU Privacy

Source: arXiv:2606.26412 · Published 2026-06-24 · By Igor Santos-Grueiro

TL;DR

This paper presents WGPULENS, a measurement framework to systematically evaluate privacy-related information leakage surfaces exposed by WebGPU in browsers. WebGPU improves GPU programmability for web pages, but despite strong API validation and memory safety, persistent browser, driver, OS, and GPU state can reveal sensitive signals that enable cross-origin inference or fingerprinting. The study decomposes observations into controlled microbenchmarks, a field participant study, and a large-scale crawl. Controlled experiments reveal that pipeline compilation state—whether pipeline creation hits or misses cached compilation results—is the clearest and most persistent source of privacy leakage, with near-perfect separability under same-page timing measurements (AUROC ~0.98 on AMD and NVIDIA GPUs). Browser/native co-residency experiments also show WebGPU queryable observables reveal native GPU activity state (macro-F1 up to 0.95). By contrast, other WebGPU resource probes (memory, queue, atomics) provide weaker and less consistent signals. The participant study finds WebGPU active usage is highly distinctive at fingerprinting granularity, but repeated visits show reduced stability of exact signatures. A Tranco crawl of public websites finds WebGPU use mostly limited to static adapter querying, with no active shader workloads detected at page load. Finally, mitigation pilots evaluate partitioning pipeline caches by source-level key separation to reduce leakage while balancing performance and compatibility. Overall, WGPULENS demonstrates the need for finely targeted, surface-specific WebGPU privacy analysis and for browsers to measure cross-boundary GPU state leakage with cost-aware mitigations.

Key findings

• Pipeline compilation state is the strongest leakage surface: same-page cold/warm pipeline creation separability achieves AUROC 0.986 (AMD/RDNA-3) and 0.961 (NVIDIA/Lovelace) under high-resolution timing (Table 2).
• Pipeline-state leakage persists across origins, profiles, browser variants, and cross-browser Apple/Metal pairs with AUROC around 0.7 (M1 cross-browser), but is near chance in same-origin cross-tab controls (~0.50 AUROC).
• Browser/native co-residency experiments detect native GPU activity states through WebGPU observables with macro-F1 up to 0.946 on M1/Metal and 0.782 on Windows/NVIDIA (Table 3).
• Active WebGPU usage fingerprinting in the participant study yields 7.136 bits of empirical entropy beyond classic browser/WebGL features over 1095 samples, with deterministic components stable within runs but lower exact repeat stability across visits.
• A Tranco top-10k crawl finds only 56 WebGPU-positive page-load records, mostly adapter probing and static support code, with no observed active shader, pipeline, queue, query, or map activity at load time.
• Non-pipeline GPU resource probes (memory, bandwidth, atomics, queues) produce weaker, platform-specific positive results (e.g., Windows AMD Chrome queue-progress AUROC 0.684) that support but do not challenge pipeline-state prominence.
• Source-level key-separation mitigation pilots reduce pipeline-state leakage while tracking costs in compilation latency, runtime overhead, and compatibility issues.
• Pipeline-state signals require high-resolution timing observables; coarse or timerless measurements degrade detection (e.g., M1 cross-browser AUROC drops from 0.718 to ~0.512 for coarse timing).

Threat model

An adversary controls one web origin and executes ordinary JavaScript and valid WGSL WebGPU workloads in the browser context. They have no native code execution, browser extensions, privileged or exploit access, hardware counters, or victim memory reads. Victims may reside in other origins, browser tabs, profiles, windows, or native GPU applications co-resident on the same machine. The adversary aims to infer victim GPU activity states, pipeline cache reuse, or fingerprint device/browser characteristics solely through browser-exposed WebGPU API observables within the valid use boundary.

Methodology — deep read

The authors design a measurement system, WGPULENS, composed of three complementary datasets to answer distinct questions about WebGPU privacy surfaces: (1) Controlled experiments test microbenchmarks under known browser, GPU adapter, origin, and profile boundary conditions to isolate leakage and mitigation signals. (2) A participant field study collects opt-in measurements from deployed browsers to assess heterogeneity, compatibility, and fingerprinting potential. (3) A large-scale Tranco top-10k page-load crawl surveys real-world WebGPU usage patterns. The threat model assumes an attacker controls a single web origin running valid JavaScript and WGSL shaders against victims running in other WebGPU contexts, native GPU apps, or other profiles, without any native code, extension, or privileged access. Valid API boundaries and memory safety are maintained, excluding exploits or memory disclosure attacks.

Controlled experiments fix browser profiles and origins, place victims at boundaries (same origin, cross-origin iframe, cross-tab, cross-profile, browser/native), and vary adapter configurations (AMD RDNA-3, NVIDIA Lovelace on Windows; Apple M1 Pro Metal). Tasks include binary classification of pipeline cold/warm compilation state (pipeline cache hits), active/idle native GPU activity classification, and multiclass synthetic workload or render phase classification. Measurements collect high-resolution JavaScript timing, coarse browser observables (frame counts, queue completion), and timerless ordinal indicators.

Probe specs define valid WGSL shaders exercising pipeline creation, compute/render workloads, atomics, barriers, and others to isolate resource contention and pipeline caching behaviors. The pipeline-state probe sequence creates a pipeline family under cold conditions, then recreates it under warm conditions, recording timing and completion signals to infer cache state. Controls include mutated/unrelated shader families, same-origin cross-tab placements, and label permutation baselines.

The participant study captures 1,095 distinct active WebGPU signatures from voluntary clients, measuring fingerprint uniqueness, entropy, and repeatability within browser sessions. The Tranco crawl logs page-load WebGPU API calls, shader compilation events, and pipeline creations across the top 10k sites.

Evaluation metrics include AUROC for cold/warm pipeline inference, macro-F1 for multiclass workload and native activity classification, entropy and anonymity set size for fingerprinting, and latency/overhead costs for mitigations. Multiple repeats across days validate stability. Permutation and negative controls ground conclusions. All experiments run on commodity hardware, major browsers (Chrome, Brave, Firefox, Safari). The WGPULENS code and normalized data are publicly released.

End-to-end example: for pipeline-state inference, a controlled WebGPU page requests pipeline compilation of a known WGSL shader family under cold conditions, measuring timing to build a baseline; later, recreates the same pipeline expecting cache hits, measuring significantly faster completion with AUROC >0.98 that confirms persistent pipeline cache reuse crossing browser and profile boundaries. This signal forms a persistent side channel that can reveal prior WebGPU activity not authorized for sharing.

Overall, the approach thoroughly maps WebGPU privacy leakages by dissecting GPU pipeline caches, active contention, and cross-boundary inference mechanisms using a multi-layered empirical framework with controlled microbenchmarks, naturalistic deployment evidence, and web-scale site crawling.

Technical innovations

• Development of WGPULENS, a reusable framework combining controlled microbenchmarks, participant field data, and large-scale web crawling to systematically measure WebGPU privacy leakages.
• Identification and isolation of persistent pipeline compilation cache state as the strongest WebGPU privacy surface accessible from JavaScript and WGSL within API validation bounds.
• Demonstration that native GPU activity state (active/idle, phases) can be inferred from browser-visible WebGPU observables under controlled co-residency with synthetic native GPU workloads.
• Evaluation of source-level key separation as a mitigation strategy proxy for partitioning pipeline caches to reduce cross-origin pipeline-state leakage while quantifying performance and compatibility tradeoffs.

Datasets

• Controlled microbenchmarks — hundreds to thousands of traces per configuration across multiple platforms (Windows AMD/NVIDIA, Apple M1) — synthetic labeled workloads with explicit placements and probes.
• Participant field study — 1,095 deduplicated completed runs from opt-in deployed browsers measuring real WebGPU usage heterogeneity and fingerprintability.
• Tranco top-10k crawl — 10,000 most popular websites scanned for WebGPU API exposure, static support code, and runtime shader activity.

Baselines vs proposed

• Windows AMD Chrome same-page cold/warm pipeline AUROC = 0.986 vs proposed baseline of 0.986 (calibration row).
• Windows NVIDIA Chrome same-page cold/warm pipeline AUROC = 0.961 vs baseline 0.961.
• Windows AMD cross-origin iframe pipeline AUROC = 0.918 vs label-permutation baseline 0.581.
• M1 Brave→Chrome cross-browser pipeline AUROC = 0.744 vs permuted baseline 0.542.
• Browser/native activity inference (M1/Metal) active/idle macro-F1 = 0.946 vs permutation control max 0.695.
• Browser/native activity inference (Win NVIDIA) active/idle macro-F1 = 0.782 vs permutation control max ~0.454.
• Workload classification on M1 Chrome/Brave render phases macro-F1 = 0.731 vs permutation max accuracy 0.583.
• Non-pipeline queue progress contention Windows AMD Chrome AUROC = 0.684 (weaker than pipeline cache signals).

Limitations

• Controlled experiments focus primarily on synthetic victims running known workloads; real-world victim workload diversity and complex websites remain less explored.
• WebGPU deployment at scale is still nascent; the Tranco crawl found few pages actively compiling shaders or creating pipelines at page load, limiting generalization.
• Pipeline-state leakage signals rely heavily on high-resolution JavaScript timing, which may be restricted or degraded in some browser privacy modes.
• The exact browser/GPU stack layer responsible for pipeline cache persistence is not fully localized—could involve browser code, backend/Dawn/wgpu policies, driver caches, OS filesystem caches, or GPU hardware caches.
• Mitigation evaluation is preliminary and based on source-level key separation simulation; full implementations and impacts on user experience require further work.
• No adversarial or adaptive attacker analysis; results reflect passive inference under controlled, labeled conditions without active evasion or exploitation.
• Participant study repeatability shows reduced exact stability across visits, indicating variability in fingerprinting resilience over time.

Open questions / follow-ons

• How can browsers design fine-grained pipeline cache partitioning or keying policies that block cross-origin leakage without unacceptable compilation latency or compatibility regressions?
• What is the precise layering (browser, backend, driver, OS, GPU hardware) responsible for persistent pipeline cache leakage signals, and how can that layering be hardened?
• How effective are existing and future timer mitigations (precision restrictions, clamp timers) at reducing pipeline-state and native activity inference without breaking legitimate use cases?
• Can adaptive or adversarial attackers exploit WebGPU scheduling, resource contention, or pipeline caching in the wild for real-time cross-origin tracking or data extraction?

Why it matters for bot defense

For bot-defense and CAPTCHA professionals, this study highlights a novel and underexplored privacy attack surface stemming from WebGPU pipeline cache state and cross-boundary resource contention observable from browser JavaScript. Since WebGPU is designed for programmable GPU workloads beyond graphics, it expands the hardware fingerprinting and cross-origin inference surface significantly compared to WebGL. Bot detection systems relying on hardware-level fingerprinting or usage patterns should consider incorporating WebGPU metrics while also accounting for the nuanced timing dependencies and mitigations discussed.

The paper’s controlled and real-world measured signals inform threat modeling for bot or fraudster detection leveraging GPU side channels. Mitigation pilots illustrate potential ways to isolate pipeline caches to mitigate tracking, but with nontrivial performance costs, a vital consideration for UX-sensitive CAPTCHA workflows that rely on rapid challenge solving. Understanding which GPU state crosses boundaries and how observable it is under typical deployment greatly informs defense design and risk assessments in browser-based bot detection and CAPTCHA systems.

Cite

@article{arxiv2606_26412,
  title={ What Browsers Do in the Shaders: A Measurement Study of WebGPU Privacy },
  author={ Igor Santos-Grueiro },
  journal={arXiv preprint arXiv:2606.26412},
  year={ 2026 },
  url={https://arxiv.org/abs/2606.26412}
}

Read the full paper

• arXiv:2606.26412 (abstract)
• arXiv:2606.26412 (PDF)