Fraud · May 25, 2026

Telltale: an experiment
in client-side fraud signals.

And why I wouldn't bet on them in 2026.


I built a small thing to scratch an itch: how much of the modern client-side fraud-signal surface still works in 2026?

The result is Telltale, a dependency-free JavaScript library that watches how a checkout form is filled and what environment fills it, then emits a compact risk hint alongside the payment intent.

The signal is two things stitched together: client-side observations about how the form was filled, and signals about the environment that filled it.

Behavioral sub-signals: dwell time per field, paste-vs-type ratio, field re-edit patterns, tab-vs-mouse navigation, and CVV input speed. The CVV one is the cleanest tell. Humans almost never paste a CVV; scripts do.

But the human-vs-script gap is narrower than it once was. Browser autofill, password managers, and digital wallets compress legitimate flows into seconds, while stealth browsers like Puppeteer-extra emulate human input convincingly. So don't treat raw speed alone as decisive. The strongest signal isn't speed. Faking one signal in a request is easy; faking all of them so they stay consistent with each other is much harder. When parts of the same request disagree, that's where bots give themselves away.

Device sub-signals: discrepancies between the claimed user-agent and the actual rendering environment. A request claiming iPhone Safari with desktop-scale viewport, Linux-style font rendering, and a WebGL renderer string of ANGLE (Intel...) is spoofed, regardless of how human the typing looked.

The most stable client-side fingerprinting surfaces today are WebGL renderer, AudioContext fingerprinting (an offline oscillator → compressor render hash, nothing actually plays), font enumeration, and time-zone-vs-claimed-locale consistency. The Battery Status API often cited in older fraud literature was deprecated in major browsers years ago and is no longer usable, a reminder that this surface keeps shrinking.

⚠️ The honest part, and the reason I'm calling this an experiment, not a product:

This is a receding signal category. Mature anti-detect tooling and privacy-law headwinds are eroding it. Treat client telemetry as a weak corroborator and push real bot detection toward the network/TLS and identity-graph layers.

Every structural force points the same way: anti-detect browsers (Multilogin, Kameleo, undetected-chromedriver) now ship coherent fake environments that specifically defeat consistency-style detection. Browser vendors keep narrowing the API surface (ITP, resist-fingerprinting, Privacy Sandbox). False positives correlate with privacy-conscious users, corporate-managed devices, and assistive-tech users, exactly the populations a merchant least wants to block. And stronger signals already exist server-side: JA3/JA4 TLS fingerprints and HTTP/2 SETTINGS frame ordering catch the same automation tools more reliably, on the very first request, without JS, consent, or GDPR exposure.

So Telltale is illustrative, not load-bearing. A reference for the shape of the signal, not a recommendation to center a fraud strategy on it. If you're actually defending checkout traffic in 2026, the work belongs at the network/TLS layer and in your identity graph, not in keystroke timers.

Code + live demo: https://seattlecyclist.github.io/telltale/

End of article · 3 min read
  • Fraud
  • Browser
  • Anti-Bot
  • Detection