FCaptcha – A modern CAPTCHA system designed to detect everything(github.com)
github.com
FCaptcha – A modern CAPTCHA system designed to detect everything
https://github.com/WebDecoy/FCaptcha
3 comments
I worry that using mouse pointer analysis as part of CAPTCHA might pose issues to those using assistive technologies. I completely understand the desire to block intrusive scrapers, but worry about it costing accessibility.
Note: I have been professionally working on web scraping.
> SHA-256 > 500ms CPU time
I wonder if the author has calculated the total wasted CPU power for 1M users and the added latency.
> Mouse trajectory
Can be recorded, and there are users that prefer the keyboard and use remote connections. Also, the trajectory can be calculated (did that myself) and is not easily verifiable due to each mouse having different starting accuracy and then catching up.
> Micro-tremor detection
Not detectable on low DPI mouse. Also there are people who are using 125Hz Bluetooth mouse.
> Click precision
What if there is no click? There are keyboard users and you'd be making them angry if blocking them solely on the no-click basis.
> Pre-click
Can be recorded and can be calculated.
> Overshoot
Overshoot only applies to small sized elements. What I noticed, I don't care about overshoot when clicking the Claudflare captcha because the checkbox is big enough for me to hit every single time (from a distance of half-page).
> Web driver
Can be spoofed or using a build of Chromium that does not set webdriver to true.
> Canvas / WebGL / Audio fingerprint > Plugin and browser feature checks
It's testing if it's a real browser, not an automated one.
> Proof of Work timing
What does this solve?
> Interaction timing patterns > Event sequence analysis
Theoretically it's smart, practically it's bad due to the randomness.
> Programmatic form.submit() detection
Events can be made trusted by setting userGesture to true in CDP or running a browser that sets it to true regardless.
> Page load to interaction timing
What does this solve? It's very random.
> Time from page load to submission
Very unreliable due to the randomness.
> Textarea keyboard analysis
Can be recorded.
> Headless browser indicators
I wonder what that is. I hope it's not checking console/storage size.
> SHA-256 > 500ms CPU time
I wonder if the author has calculated the total wasted CPU power for 1M users and the added latency.
> Mouse trajectory
Can be recorded, and there are users that prefer the keyboard and use remote connections. Also, the trajectory can be calculated (did that myself) and is not easily verifiable due to each mouse having different starting accuracy and then catching up.
> Micro-tremor detection
Not detectable on low DPI mouse. Also there are people who are using 125Hz Bluetooth mouse.
> Click precision
What if there is no click? There are keyboard users and you'd be making them angry if blocking them solely on the no-click basis.
> Pre-click
Can be recorded and can be calculated.
> Overshoot
Overshoot only applies to small sized elements. What I noticed, I don't care about overshoot when clicking the Claudflare captcha because the checkbox is big enough for me to hit every single time (from a distance of half-page).
> Web driver
Can be spoofed or using a build of Chromium that does not set webdriver to true.
> Canvas / WebGL / Audio fingerprint > Plugin and browser feature checks
It's testing if it's a real browser, not an automated one.
> Proof of Work timing
What does this solve?
> Interaction timing patterns > Event sequence analysis
Theoretically it's smart, practically it's bad due to the randomness.
> Programmatic form.submit() detection
Events can be made trusted by setting userGesture to true in CDP or running a browser that sets it to true regardless.
> Page load to interaction timing
What does this solve? It's very random.
> Time from page load to submission
Very unreliable due to the randomness.
> Textarea keyboard analysis
Can be recorded.
> Headless browser indicators
I wonder what that is. I hope it's not checking console/storage size.
You're right that most of these signals are spoofable in isolation. FCaptcha doesn't make pass/fail decisions on any single signal. It's weighted ensemble scoring across ~50 signals, where the cost of spoofing all of them simultaneously is the actual defense.
Addressing a few specific ones:
PoW CPU cost: Difficulty is adaptive — 4 for residential IPs, 6+ for datacenter. On modern hardware that's ~200-800ms. For 1M users/day that's ~55-220 CPU-hours total, distributed across clients. It's comparable to what Cloudflare Turnstile does.
Keyboard-only users: Already handled. If keyEvents >= 2 and totalPoints === 0 (tabbed + Enter/Space), all mouse-based detections are skipped. No false positives on keyboard users.
CDP userGesture: true: Good catch. We detect CDP-specific artifacts (Runtime.evaluate residue, protocol binding flags), but you're right that a custom Chromium build sidesteps this entirely.
The honest answer: a sufficiently motivated attacker with a custom Chromium build can beat this. The goal is to make that cost high enough that it's cheaper to just solve the CAPTCHA legitimately or move to an easier target. Same tradeoff Cloudflare makes, but open source and privacy first.
Where I think the real gap is: server-side signals (IP reputation, TLS fingerprinting, rate patterns) and that's really what our paid bot detection is for. https://webdecoy.com
Addressing a few specific ones:
PoW CPU cost: Difficulty is adaptive — 4 for residential IPs, 6+ for datacenter. On modern hardware that's ~200-800ms. For 1M users/day that's ~55-220 CPU-hours total, distributed across clients. It's comparable to what Cloudflare Turnstile does.
Keyboard-only users: Already handled. If keyEvents >= 2 and totalPoints === 0 (tabbed + Enter/Space), all mouse-based detections are skipped. No false positives on keyboard users.
"Can be recorded/replayed": signals are SHA-256 hashed and bound into the PoW input before solving. You can't solve PoW first then attach recorded signals... the hash won't match. Replaying old signal sets also fails because each challenge has a unique nonce.
CDP userGesture: true: Good catch. We detect CDP-specific artifacts (Runtime.evaluate residue, protocol binding flags), but you're right that a custom Chromium build sidesteps this entirely.
The honest answer: a sufficiently motivated attacker with a custom Chromium build can beat this. The goal is to make that cost high enough that it's cheaper to just solve the CAPTCHA legitimately or move to an easier target. Same tradeoff Cloudflare makes, but open source and privacy first.
Where I think the real gap is: server-side signals (IP reputation, TLS fingerprinting, rate patterns) and that's really what our paid bot detection is for. https://webdecoy.com