Rendering on Real Silicon: GPU Render-Timing as a Passive, AI-Resistant CAPTCHA Signal David Noever and Forrest McKee PeopleTec, Inc., {david.noever, forrest.mckee}@peopletec.com
arXiv:2607.23389v1 [cs.CR] 25 Jul 2026
Abstract
Enclave) proves device identity through a signed challenge— at the cost of enrollment, a persistent identifier, and a trust chain that excludes many legitimate clients—a render-timing test asks only that the client behave like real silicon while executing an ordinary graphics workload. No enrollment, no persistent identity, no key material. We make three contributions:
Conventional CAPTCHAs pose puzzles that modern AI systems increasingly solve, while behavioral and cryptographicattestation defenses carry privacy or enrollment costs. We investigate an orthogonal signal: the physical timing behavior of a client’s GPU under a controlled WebGL rendering workload. Unlike WebGL fingerprinting, which hashes pixel output into a static device identifier, we measure render-timing dynamics to classify rather than identify, leaking no persistent identifier. We characterize the in-the-wild adversary with a 12hour passive deployment (207 unsolicited requests; 86% automated; 85% of browser-claiming clients failed HTTP headerconsistency checks). We then collect labeled GPU-timing samples through a single public endpoint exercised by real browsers (positive class, 13 distinct GPUs) and by keyed headless automation across a render-backend matrix (negative class). Software-rendered automation—empirically the dominant real-world adversary—separates from genuine GPUs by roughly 5× in mean render time. On a confound-controlled comparison (identical GPU family and browser engine, differing only in headless vs. interactive execution), headless automation on real hardware still exhibits a distinct timing signature, separating from human samples by 75–106% on frame jitter, timer-quantization ratio, and coefficient of variation. We report these as pilot-scale findings on a single GPU architecture and outline the cross-architecture collection required to establish generalization.
1
1. An empirical characterization of the automated traffic reaching an exposed endpoint, establishing that the operative adversary is overwhelmingly render-free. 2. A single-endpoint methodology that gathers identicallymeasured timing samples from real browsers and from keyed headless automation, with trustworthy negativeclass labels. 3. A pilot analysis showing clean separation of softwarerendered bots, and a measurable, confound-controlled timing signature distinguishing even headless automation on real hardware, on one GPU architecture.
2
Related Work
We organize prior work into five strands and state our relationship to each. Figure 1 summarizes the contrast. Visual and cognitive CAPTCHAs, and AI solvers. The dominant CAPTCHA paradigm presents perceptual or cognitive challenges [3, 4]. Their security has collapsed against modern AI: generative and adversarial solvers defeat text and image challenges [5], and recent agentic VLM systems such as Halligan [2] generalize across visual challenge types, solving unseen CAPTCHAs by parsing an objective, abstracting the challenge, and synthesizing an interaction program. Notably, that threat model explicitly assumes the CAPTCHA is not vulnerable to side channels and that the attacker operates “vision-level only.” Our method is complementary: it adds a non-visual, physical signal that lies precisely in the gap such solvers exclude.
Introduction
CAPTCHAs were designed around tasks easy for humans and hard for machines. That asymmetry has eroded: visionlanguage models (VLMs) solve image, text, and audio challenges with reported accuracies of 96–99.8% [1, 2], CAPTCHA-solving services and human-in-the-loop APIs absorb the remainder, and even behavioral-biometric defenses face increasingly capable mimicry. The defensive frontier has shifted from posing harder puzzles toward verifying properties an automated client cannot cheaply reproduce. This paper examines one such property: the physical timing behavior of a real GPU. We position the approach (Figure 1) as a passive, physical-layer variant of hardware attestation. Where cryptographic attestation (TPM, WebAuthn, Secure
Behavioral biometrics. Production systems (reCAPTCHA v3, Cloudflare Turnstile, hCaptcha) score sessions on mouse micro-movements, scroll velocity, keystroke cadence, and timing regularity [1, 6], and the research literature has extended 1
Figure 1: CAPTCHA families organized by the property a client must reproduce to pass. Prior families verify cognition (visual puzzles), behavior (biometrics), computational cost (proof-of-work), or device identity (WebGL fingerprinting), each with a known evasion. The proposed approach verifies that the client is executing on genuine GPU hardware by measuring physical render timing—a property automated clients lack rather than a puzzle they can solve.
this with synthetic-trajectory and keystroke-generation defenses [7, 8]. These observe human motor noise. We observe hardware execution physics; the two are orthogonal and combine naturally within a multi-signal risk score. A key practical difference: behavioral signals require interaction time and are vulnerable to replay and learned mimicry, whereas a rendertiming probe completes in a fixed sub-second window and measures a property the adversary cannot supply without real hardware.
user-agent fingerprints because it derives from hardware behavior [11]. Two distinctions define our contribution. First, purpose: fingerprinting performs identification (a persistent per-device hash, with attendant privacy concerns and tracking use), whereas we perform classification (human vs. automated) and retain no persistent identifier. Second, and decisively, signal: the entire fingerprint-evasion ecosystem— antidetect browsers, canvas-noise injection, renderer-string spoofing, low-level C++ patching [12]—targets the pixel hash and renderer string. None of it addresses render timing, because timing is not what these systems fingerprint. Our signal is therefore orthogonal to, and survives, the deployed spoofing stack: a tool that perfectly forges the renderer string and pixel output of an “NVIDIA RTX 4070” still cannot forge the timing distribution of one it does not physically possess.
Proof-of-work CAPTCHAs. Proof-of-work (PoW) systems such as ALTCHA and Arkose Labs impose a clientside computational cost, shifting attack economics through cost asymmetry [9, 10]. Critically, modern PoW deliberately uses memory-hard functions (Argon2id, scrypt) to narrow the performance gap between commodity devices and specialized hardware [9]. Our approach inverts this: we use a rendering workload not as a cost toll but as a measurement probe, and we exploit rather than erase the hardware gap—the physical timing distribution of the GPU executing the probe is the signal.
GPU timing side-channels. A peer-reviewed body of work establishes that GPU and browser timing carry exploitable hardware information. JavaScript microarchitectural attacks recover high-resolution timing despite browser timer coarsening [13], and WebGPU/WebGL timing has been used for cache attacks and website fingerprinting. These works use GPU timing offensively (to extract secrets or identify activity). We repurpose the same physical phenomenon defensively: the hardware-dependence of render timing that makes it a sidechannel risk is precisely what makes it a bot-classification signal. This literature grounds our core assumption—that render timing reflects physical hardware—in established results.
WebGL fingerprinting. The closest-named prior art renders a hidden scene and hashes pixel output, combined with the WEBGL debug renderer info string, into a stable device identifier [11]. This is widely deployed for tracking and bot detection, and is recognized as harder to spoof than canvas or 2
3
Threat Model: What Reaches the 4.3 Features Endpoint Per session we derive distributional statistics: mean and median render time; dispersion (standard deviation, coefficient of variation [CV], inter-quartile range); shape (skewness, kurtosis); frame-to-frame jitter (mean absolute first difference); and a timer-quantization indicator (distinct timing values / frame count).
Before measuring GPU timing, we characterized the adversary empirically. A public endpoint on commodity cloud infrastructure passively logged unsolicited traffic over a 12-hour window, recording for each request the source address, autonomous system (resolved via Team Cymru), requested path, User-Agent, and the HTTP headers a conforming browser emits. The endpoint received 207 unsolicited requests; the first arrived 12.6 s after launch. Although 192/207 (93%) presented a browser-like User-Agent, only 28 (15% of those) were consistent with a genuine browser once presence of Sec-Fetch-*, Accept-Language, and a content-specific Accept header was required—matching the header-based detection used in practice [6]. The remaining 85% declared a browser identity while omitting headers no real browser omits. In aggregate, 86% of requests were automated; requested paths were dominated by secret- and configuration-discovery probes; exactly one request touched a data-collection path and none reached any rendering endpoint. The operative finding: the in-the-wild adversary is render-free. These clients do not execute client-side JavaScript and never reach a rendering stage, so a render-gated challenge filters them by construction—but they also yield no timing data, so characterizing evasive bots that do render requires the deliberate collection described next.
4.4
Negative-class backend matrix
The sweep navigates to the page across automation stacks and backends: Chromium over SwiftShader and SwANGLE (software), Chromium with GPU disabled (CPU fallback), headless Firefox and WebKit, and Chromium acquiring a physical GPU in headless mode. The last cell is the hard negative— automation on real hardware—and prevents a classifier from succeeding merely by keying on a software-renderer string. Because headless Chromium frequently falls back to software, the page self-gates this cell, posting only sessions in which a genuine hardware renderer was acquired.
4.5
Evaluation discipline
Any classifier is evaluated under a device-held-out split: entire GPUs are assigned to train or test, never individual samples. Training on some GPUs and testing on GPUs unseen in training is the only honest measure of generalization; a persample split would leak device identity and inflate accuracy.
4
Methodology
4.6
4.1
Single-endpoint collection
The threat-model measurement passively recorded metadata (source address, autonomous system, requested path, headers) of unsolicited requests arriving at infrastructure we control; no challenge or payload was returned beyond a static page, and no third-party service was probed. Positive-class timing samples were contributed by visitors who affirmatively consented on the collection page after disclosure of what is transmitted; records contain no cookies, account data, or persistent identifiers, consistent with the classification-not-identification design. Negative-class sessions were generated exclusively by automation we operated against our own endpoint.
A single public page serves a shared WebGL harness and accepts session records at one endpoint. Both classes flow through the same instrument, eliminating measurement confounds between them. Real visitors open the page and, with consent, post a timing record (positive class). Headless automation is driven to the same URL by a sweep tool carrying a server-side secret, so its label is trustworthy at collection (negative class). The server stamps each record with receiveside metadata the client cannot forge, including the headerconsistency signal above.
4.2
5
The harness
Ethical considerations
Results
We group usable sessions into three classes: human (real GPU, interactive), software bot (software-rendered headless), and hard negative (real GPU, headless). Table 1 summarizes the pilot dataset.
The harness issues a deterministic, fragment-shader-bound WebGL workload and records per-frame render time across a fixed window after warm-up. Each frame forces pipeline completion via a synchronous pixel read-back, so measured time reflects GPU execution rather than asynchronous queue submission. The raw per-frame series is retained; features are derived offline so they can be revised without recollection. The harness also records the unmasked renderer string, browser/platform metadata, and the observed timingsource resolution.
5.1
Software automation separates widely
Software-rendered bots render the workload far more slowly than genuine GPUs—26.3 ms vs. 5.1 ms, a 5.2× gap—with higher jitter and quantization (Figure 2). As this population 3
Table 2: Confound-controlled comparison: Intel GPUs, Chromium/ANGLE, headless bot vs. interactive human.
Table 1: Pilot dataset summary by class. Group Human (real, interactive) Software bot Hard negative (real, headless)
n
GPUs
mean (ms)
jitter
26 273 20
13 4 2
5.09 26.28 8.25
0.42 2.03 0.91
Feature distinct-value ratio frame jitter (ms) coeff. of variation mean render (ms)
Human (n=14)
Bot (n=20)
Sep.
0.076 0.351 0.112 5.78
0.249 0.912 0.247 8.25
106% 89% 75% 35%
Figure 3: Per-feature distributions, Intel GPUs under matched engine. Headless execution shows higher timer-quantization ratio, jitter, and CV than interactive use of the same hardware.
Figure 2: Mean frame render time by class (log scale). Software bots are ∼5× slower than genuine GPUs; hard negatives overlap the human range on this feature and require other features to separate.
is also the entire in-the-wild adversary, a simple render-time may compress the timing differences below measurability. We threshold filters realistic automated traffic. make no cross-architecture claim. Pilot scale. The positive class spans 13 GPUs / 26 sessions;
5.2
Headless on real hardware leaves a signa- the hard negative spans 2 GPUs / 20 sessions. These support separability in principle on the measured devices, not a trained ture discriminator with characterized error rates.
The harder question is whether automation on a genuine GPU is distinguishable from a human on the same hardware. Comparing across browser engines would confound the result, since engines differ in WebGL implementation and timer behavior. We therefore restrict to one confound-controlled condition: the same GPU family (Intel integrated) and engine (Chromium/ANGLE), differing only in headless vs. interactive execution (Table 2, Figure 3). Headless sessions show 3.3× higher quantization ratio, 2.6× higher jitter, and 2.2× higher CV than interactive sessions on the same hardware. The direction is consistent with a physical mechanism: a headless browser lacks the display compositor and refresh pacing that regularize frame timing in interactive use, so it renders with more timing roughness, not less—the opposite of the naive intuition that automation is flatter, and the reason a single CV threshold is insufficient (Figure 4).
6
Adversary adaptation. An adversary can render on real hardware (raising cost, not enabling free evasion) or inject synthetic jitter to mimic interactive timing. The method is best understood as a low-friction, hard-to-spoof signal within multisignal risk assessment, and as a near-complete filter against the render-free automation that dominates real traffic. Timer hardening. Browsers that coarsen or jitter highresolution timers compress the signal; the harness records observed timer resolution per session, but the population-level impact is not yet quantified.
7
Conclusion
The in-the-wild automated adversary does not render, so a render-gated challenge filters it almost entirely. Beyond that, even headless automation on genuine hardware leaves a measurable timing signature relative to interactive use of the same hardware, at least on the Intel GPUs measured here. Establishing cross-architecture generalization is a matter of continued, architecture-stratified collection, for which the single-endpoint methodology described here is designed; the immediate targets are matched human/hard-negative pairs on discrete NVIDIA and AMD GPUs and on Apple Silicon.
Limitations and Scope
Single architecture. The confound-controlled signature is shown on Intel integrated GPUs only—the single family for which we hold both human and hard-negative samples. Whether it replicates on discrete NVIDIA/AMD and Apple Silicon is the central open question; the mechanism is architecture-independent in principle, but faster discrete GPUs 4
Surv. 54(9), 2021. [4] N.D. Trong et al. New Cognitive Deep-Learning CAPTCHA. Sensors 23(4):2338, 2023. [5] G. Ye et al. Yet Another Text CAPTCHA Solver: A GANBased Approach. ACM CCS, 2018. [6] KnowledgeSDK. Anti-Bot Detection in 2026, 2026. [7] A. Acien et al. BeCAPTCHA-mouse: Synthetic Mouse Trajectories and Improved Bot Detection. Pattern Recognition 127:108643, 2022. [8] D. DeAlcala et al. BeCAPTCHA-type: Biometric Keystroke Data Generation for Improved Bot Detection. CVPR Workshops, 2023. Figure 4: Two-feature space (jitter vs. quantization ratio). Humans cluster at low jitter and low quantization; software bots spread across high jitter; hard negatives form a distinct band of elevated quantization at low jitter.
[10] Arkose Labs. Proof of Work: Invisible Economic Barrier, 2026.
References
[11] Spidra. WebGL Fingerprinting and How to Bypass It When Scraping, 2026.
[1] ScopeDesign. Why Can’t Bots Solve CAPTCHA? Bot Detection Guide 2024–2025, 2025.
[12] Browserless. Browser Fingerprinting Guide: Detection & Bypass Methods, 2025.
[2] J. Teoh et al. Halligan: A Generalized Visual CAPTCHA Solver via VLM Agents. USENIX Security, 2025.
[13] Z. Wang et al. WebGPU-SPY: Finding Fingerprints in the Sandbox through GPU Cache Attacks. arXiv:2401.04349, 2024.
[9] ALTCHA. Proof-of-Work CAPTCHA Documentation, 2024. https://altcha.org.
[3] M. Guerar et al. Gotta CAPTCHA’em All: A Survey of 20 Years of the Human-or-Computer Dilemma. ACM Comput.
5