DEV Community: Alex Oliinyk

Six ways an auto clicker gives itself away, using nothing but timestamps

Alex Oliinyk — Sat, 10 Oct 2026 22:26:20 +0000

I run a small click speed test, CPSBench. Once a site has a leaderboard, the first entries that look too good arrive almost before the real ones do. I can't see anyone's hand. The browser gives me a list of numbers: when each click landed, relative to the first one. Everything below is about squeezing a verdict out of that list.

What the server actually receives

{
  "tool": "cps", "mode": "10", "hits": 74, "ms": 10000,
  "stamps": [0, 131, 262, 401, 527, 664, 790, 931, ...]
}

Hits are stamped with performance.now() on pointerdown, rounded to whole milliseconds. Before any of the checks run, the boring validation happens: count matches, first hit at zero, strictly increasing, nothing after the end, score recomputed on the server. A forged payload that fails those never reaches the interesting part.

What makes the rest work is that people and scripts produce differently shaped gap lists, even at the same average speed.

1. The metronome

The laziest auto clicker fires every N ms. Browser timing adds a millisecond of noise, but the coefficient of variation of the gaps (standard deviation over mean) stays tiny.

const gaps = stamps.slice(1).map((t, i) => t - stamps[i]);
const mean = gaps.reduce((a, b) => a + b) / gaps.length;
const sd = Math.sqrt(gaps.reduce((a, g) => a + (g - mean) ** 2, 0) / (gaps.length - 1));
if (sd / mean < 0.03) reject('machine-even gaps');

The steadiest person I could model still sits around 5 to 6 percent. Three percent is a comfortable line.

2. The favourite number

Round every gap to a whole millisecond and count. If one value covers more than 45% of the gaps, or two values together cover more than 75%, it's a timer, possibly one that alternates between two intervals to dodge check #1. Hands never repeat themselves that faithfully.

3. Flat-topped randomness

The smarter clickers pick each interval at random, say anywhere between 60 and 100 ms. The coefficient of variation looks human. The histogram doesn't: it's a flat plateau with hard edges, while human gaps pile up in a lopsided hump with a long tail of slow ones.

Two classic statistics catch that shape. A uniform distribution has zero skew and an excess kurtosis of about -1.2. People are skewed right and rarely go below -0.5.

const m2 = gaps.reduce((a, g) => a + (g - mean) ** 2, 0) / gaps.length;
const m3 = gaps.reduce((a, g) => a + (g - mean) ** 3, 0) / gaps.length;
const m4 = gaps.reduce((a, g) => a + (g - mean) ** 4, 0) / gaps.length;
const skew = m3 / m2 ** 1.5;
const kurt = m4 / m2 ** 2 - 3;

The trap here is butterfly clicking. Two fingers alternate on one button, so the gaps go short, long, short, long: two humps, and a two-humped histogram also has negative kurtosis. Luckily it also has strongly negative lag-1 autocorrelation (each gap predicts the opposite of the next one), while a random clicker has none. So the rule only fires when the autocorrelation is close to zero:

reject when n ≥ 40 and kurt < -1.1 and |skew| < 0.35 and |lag1| < 0.2

Before I added that last condition, 4% of simulated butterfly runs were being thrown out.

4. Nobody stays fresh

Go flat out for ten seconds and your last two seconds are slower than your first two. Every time. A macro tuned to look human usually forgets that.

For runs of 10 seconds or more above 11 clicks a second, I compare the first and last quarter of the hits. Less than 3% difference and a low coefficient of variation together means rejection. Either on its own happens to real people.

5. The ceiling

Some numbers aren't worth analysing. Every test and length has a cap on average speed, and anything above it is refused before the shape checks:

test	1 s	10 s	60 s
mouse	22	19	14
spacebar	20	17	13
drag click	50	35	24

Drag clicking gets its own row because it really does produce 30+ clicks a second: the finger slides across the button and the switch bounces. It also produces gaps under 30 ms, which the drag test expects and the other tests treat as suspicious.

6. The replay

The cheapest cheat of all is to copy someone else's payload. I hash the first 60 gaps and keep the hash. A second run with an identical sequence gets refused, whoever sends it.

How well it works

I generated 1000 runs per case and per length (5, 10 and 30 seconds):

simulated run	flagged
one finger, 3 to 9 CPS, with fatigue	0 to 0.1%
jitter clicking, 12 CPS	0 to 0.1%
butterfly, 13 CPS	0%
fixed interval, any speed	100%
two alternating intervals	100%
uniform random interval	52 to 93% (longer runs, more certain)
15 CPS, near-even, no fatigue	99 to 100% at 10 s and up
Gaussian noise at 9 CPS	about 0%

That last row is the honest part. A script that adds normally distributed noise at a believable speed looks like a calm, consistent human, and nothing that only sees timestamps will tell them apart. The point was never to stop a determined person. It's to stop the free auto clicker everyone downloads first, and to keep impossible numbers off the board.

When a run fails, the player sees which check it failed, in plain words. Anyone who clicks like a robot and is human anyway can email me, and so far nobody has needed to.

Same data, friendlier use

The timestamps are also good for something other than suspicion. The jitter test runs a gentler version of the same maths to guess how you clicked:

If you've built anti-cheat for anything input-based, I'd like to hear which signals held up for you and which ones fell over the moment real users arrived.

Building a fullscreen countdown timer in vanilla JS: accurate time, Wake Lock, and a WebAudio alarm

Alex Oliinyk — Thu, 13 Aug 2026 19:15:52 +0000

Timers look trivial until you actually build one that people rely on. "Just setInterval and decrement a number," right? That gets you a timer that quietly drifts, silently dies when the tab sleeps, and forgets to make a sound at zero.

I recently built a fullscreen countdown timer as a plain-JS canvas widget (it powers the timer pages on blankscreen.io), and three things turned out to be more interesting than expected:

Keeping accurate time without setInterval drift
Stopping the screen from sleeping mid-countdown (Screen Wake Lock API)
A clean alarm beep with WebAudio — no audio files

Here's how each part works, with code you can drop into your own project.

1. Don't trust setInterval for the clock

The naive version:

let remaining = 300; // seconds
setInterval(() => {
  remaining -= 1;
  render(remaining);
}, 1000);

setInterval is not a metronome. The browser throttles it in background tabs, and even in the foreground each tick can arrive late. Over a 30-minute timer those errors accumulate into visible drift.

The fix is to stop counting ticks and start measuring elapsed real time. Store performance.now() and subtract the actual delta each frame:

let remaining = total;      // seconds
let running = false;
let last = 0;

function start() {
  running = true;
  last = performance.now();
}

function tick() {
  if (running) {
    const now = performance.now();
    remaining -= (now - last) / 1000; // real elapsed, not "1"
    last = now;
    if (remaining <= 0) { remaining = 0; running = false; onDone(); }
  }
  render(remaining);
  requestAnimationFrame(tick);
}
requestAnimationFrame(tick);

Now the displayed time tracks the wall clock regardless of frame rate or minor jank. I render on a <canvas> with requestAnimationFrame because the same loop also draws a progress bar and a "time's up" flash, but the timekeeping idea is framework-agnostic — it works just as well updating a DOM node.

Formatting is the boring-but-fiddly part (show hours only when needed):

function fmt(s) {
  s = Math.max(0, Math.ceil(s));
  const h = Math.floor(s / 3600),
        m = Math.floor((s % 3600) / 60),
        ss = s % 60;
  const p = n => String(n).padStart(2, '0');
  return total >= 3600 ? `${h}:${p(m)}:${p(ss)}` : `${m}:${p(ss)}`;
}

2. Keep the screen awake with the Wake Lock API

A timer the user is watching should not let the phone dim and lock 30 seconds in. The Screen Wake Lock API handles this, and it's refreshingly small:

let wl = null;

async function keepAwake() {
  try {
    if ('wakeLock' in navigator && !wl) {
      wl = await navigator.wakeLock.request('screen');
      wl.addEventListener('release', () => { wl = null; });
    }
  } catch (e) { /* denied or unsupported — fail silently */ }
}

function releaseAwake() {
  if (wl) { wl.release(); wl = null; }
}

Two gotchas worth knowing:

The lock is auto-released when the tab loses visibility. So re-request it when the user comes back:

document.addEventListener('visibilitychange', () => {
  if (!document.hidden && running) keepAwake();
});

Request it in response to the user starting the timer (a user gesture), and release it on pause/reset so you're not holding the screen on for a paused timer.

Support isn't universal, so treat it as a progressive enhancement — wrap it in a try/catch and never let a rejection break the timer.

3. An alarm beep with zero audio assets

Shipping an alarm.mp3 means a network request, autoplay-policy headaches, and a file that can fail to load exactly when you need it. WebAudio can synthesize the beep on the fly:

let ac = null;

function ensureAudio() {
  if (!ac) ac = new (window.AudioContext || window.webkitAudioContext)();
  if (ac.state === 'suspended') ac.resume();
}

function beep() {
  const o = ac.createOscillator();
  const g = ac.createGain();
  const t = ac.currentTime;

  o.type = 'sine';
  o.frequency.setValueAtTime(880, t);        // two-tone: A5...
  o.frequency.setValueAtTime(660, t + 0.18); // ...then E5

  // quick fade in/out to avoid clicks
  g.gain.setValueAtTime(0.0001, t);
  g.gain.exponentialRampToValueAtTime(0.35, t + 0.02);
  g.gain.exponentialRampToValueAtTime(0.0001, t + 0.5);

  o.connect(g); g.connect(ac.destination);
  o.start(t); o.stop(t + 0.52);
}

The key autoplay detail: create/resume the AudioContext inside the user gesture that starts the timer, not at page load. Browsers block audio that isn't tied to interaction, so if you wait until zero to spin up the context, the beep gets swallowed. Prime it on "Start", then at zero just call beep() on a short interval until the user dismisses it:

function onDone() {
  ensureAudio();
  beep();
  const id = setInterval(beep, 900);
  // clear `id` on reset/pause
}

Putting it together

The full widget is ~80 lines: the requestAnimationFrame loop, a THEMES object for a light/dark toggle, a progress bar (elapsed / total), and a red flash + "Time's up" state at zero. No dependencies, no build step.

If you want to see it running across a bunch of durations, I made a page per common preset (1-minute up to 3-hour) over on blankscreen.io — same canvas widget, just seeded with a different starting time. It's also where I keep a few other no-install browser utilities (color screens, white noise, screen tests) if that's your kind of thing.

Takeaways

Measure elapsed time with performance.now() deltas — never count setInterval ticks.
Screen Wake Lock is tiny and worth it, but re-request on visibilitychange and treat it as optional.
Synthesize the alarm with WebAudio and prime the AudioContext on the start gesture.

What would you add — a stopwatch mode, interval/Tabata support, keyboard shortcuts? Curious how others handle background-tab timing.