Captcha: client gates honor admin tolerance + touch loosening; default lenient - #19
Merged
Conversation
…fault lenient The admin "touch tolerance" only scaled the SERVER's acceptance — the client games kept fixed, stricter "feels aligned" gates (Slide ALIGN, Rotate ALIGN_DEG, the drop/connect/trace hit radii), so a lenient setting never felt lenient: a close-enough gesture got a "miss" shake and was never forwarded. Thread the tolerance multiplier to the client via the challenge DTO and apply it to every alignment gate, widened a further 1.25x on coarse (touch) pointers so an imprecise finger isn't pre-rejected before the server — which still holds the authoritative tolerance — ever sees the answer. Tap-match/sort have no gate and ignore it. Default the tolerance profile to LENIENT (was standard). The audience includes older/less-dexterous users and captcha security never rested on tight geometry (PoW + single-use + interaction risk + bindings). Admins can still pick strict.
…bump Review caught a client/server contract gap: a client-only coarse (touch) 1.25x bump, plus a guessed client base (Slide ALIGN=7, Rotate ALIGN_DEG=12) that doesn't match the server's per-difficulty secret tolerance, let the client accept gestures the server then rejected (e.g. Slide normal/hard, or anything on touch) — a confusing "looked right, try again". Carry each game's base acceptance (tol) in the public payload so the client gate is exactly server_base * adminTolerance — never over- or under-shoots. tol is not a secret: a bot submits the exact target regardless; tol only sets how forgiving imprecise human input is. Drop the client-only coarse multiplier (it had no server counterpart, and missed hybrid devices anyway); touch forgiveness now comes from the lenient default applied consistently on both sides. DragTarget/Connect/PathTrace already stayed within the server's padded gate and are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Follow-up to #18. A code review (codex) of the captcha's elderly/touch friendliness found the real bottleneck: the admin Touch tolerance setting only scaled the server's acceptance. The client games kept fixed, stricter "feels aligned" gates, so even with
lenientset, a close-enough gesture got a "miss" shake on the client and was never forwarded to the server. There was also no coarse-pointer (finger) loosening.What
CaptchaChallengeDTO.tolerance(= the admin profile,cfg.toleranceMult). Not a secret — the server still holds the authoritative tolerance and re-validates every answer.ALIGN, RotateALIGN_DEG, DragTarget ring radius, Connect target radius, PathTrace hit radius. Tap-match/sort have no gate and ignore it.(pointer: coarse)the client widens its gate a further1.25×so an imprecise finger isn't pre-rejected before the server sees the answer. This is client-UX only; on the rare over-shoot the server simply asks for a retry (its existing flow).docs/human-check-v3.md). Admins can still pick standard/strict.Security note
Loosening only widens the geometric "close enough" band (max client factor ≈ lenient 1.3 × coarse 1.25 = 1.625). The interaction-risk engine, PoW, single-use tokens, and bindings are unchanged, so the moat is intact. The client never over-accepts beyond what the server will: the server is the authority and re-checks with
cfg.toleranceMult.Verification
npm run typecheck— cleannpm run test:captcha— 119 passed, 0 failednpm run build— clean (HumanCheck stays a lazy ~12.7 kB gzip chunk)