← Back to apps

AerCaptcha

An invisible human check. No puzzle unless something looks off.

How it works

1
Hand liveness phone only Reads the gyroscope and accelerometer while you hold the device and looks for the micro-tremor a living hand always has. The decision is made by our trained IMU model — the same one behind the liveness app, currently at 95.5% balanced accuracy with zero false positives on held-out sessions. A phone lying on a desk, or a script with no phone at all, cannot produce the signal.
2
Behavioural scoring every device Pointer movement, touches, typing, scroll depth and reading time, plus a SHA‑256 proof-of-work your browser solves in the background and a fingerprint check that penalises automation flags.
3
Fallback puzzle rare Only appears when the first two land somewhere ambiguous. Most people never see it.

Test it on a phone

Layer 1 is the interesting one and it needs a real gyroscope, which this browser does not have. Scan to open this page on your phone, then hold it normally and run the check.

QR code linking to https://www.aernet.dev/aercaptcha/
www.aernet.dev/aercaptcha/ Sign-in is not required — the check itself is public.

Try it on yourself

What it measures

Points are added and subtracted from a running total, out of about 14. Every signal is the shape of behaviour — how much you moved, how long you paused — never what you typed or who you are.

Pointer >10 events, or >3 touches+2
…any pointer or touch at all+1
Pointer travelled >500 px+2
…more than 100 px+1
Typed >10 keys+2
…more than 3+1
Scrolled — >3 events and >200 px deep+1
Paused >3 s before running (you read it)+2
…more than 1.5 s+1
Proof-of-work solved — a SHA‑256 puzzle your browser grinds in the background, costing a bot real CPU per attempt+3
Fingerprint sane — screen size and timezone present, no automation flag+2
Hand tremor detected (phone only)+3
Zero pointer and zero touch — the strongest bot tell there is−4
navigator.webdriver set — the browser admitting it is automated−3
Clicks with no movement — teleporting cursor−2

How the total becomes a verdict

On a phone the hand decides it, and nothing else can overrule it. The capture is cut into five windows and each is judged on its own:

2 or more windows read as a living handHUMAN
1 window — could be you picking the phone upUNCERTAIN
0 windows — it was never heldBOT

The behavioural tests above still run, and they are 40% of the score you see — the hand is the other 60%. But they cannot move the verdict on a phone. Faking touches and scrolls is cheap; faking a living hand is not, so the hand is what the answer rests on.

There is deliberately no puzzle on a phone. A sum a bot can also solve would defeat the point of having a sensor check. If you get UNCERTAIN, lift the phone and run it again.

On a desktop there is no gyroscope, so behaviour is the whole score: 8+ → HUMAN, 4–7 → UNCERTAIN and a puzzle decides, under 4 → BOT.

On a desktop there is no gyroscope to read, so the score alone decides. 8+ → HUMAN. 4–7 → UNCERTAIN. Under 4 → BOT.

Why three answers and not two

Because a wrong guess is expensive in both directions. Call a real person a bot and you have locked out a customer; call a bot human and you have let it in. UNCERTAIN is the honest answer in between, and the only case where you ever see a puzzle.

Where the thresholds came from

Real traffic on our own signup form, not guesswork. The phone rules (>60% of quiet windows in hand, gyro ≥0.42) were tuned against genuine hands versus phones on tables. The desktop cut-offs are the newer half and still being tuned against live results.

Checking what this device can do…

Side by side: tick hCaptcha, then run the check — both verdicts appear below.

Liveness, window by window

Motion data is scored and discarded. Nothing about this check is stored against you — the log keeps the scores and a coarse fingerprint for threshold tuning, never your email or the raw sensor stream.