Hi HN,
We built conversion.business, a drop-in replacement for traditional captchas (like reCAPTCHA and hCaptcha) that uses 2 - 5 -second HTML5 micro-games instead of traffic lights and blurry crosswalks.
Why we built this: We were frustrated by the amount of friction traditional captchas introduce to sign-up flows. More importantly, we disliked the privacy implications of modern captchas that require extensive background telemetry, behavioral tracking, and cross-site cookies just to prove humanity.
How it works technically: We wanted to prove humanity without tracking the human.
Zero Telemetry: The widget uses zero cross-site tracking cookies and zero local storage. We don't track mouse curves or micro-interactions.
Game Randomization: We serve unpredictable, multi-game challenge rotations on every page load to prevent attackers from training targeted machine-learning bots for a single puzzle type.
Verification: The widget measures total solve time, checks WebGL renderer signatures to block headless browsers/software renderers (like SwiftShader or llvmpipe), and validates User-Agents.
Cryptographic Seal: When a game is solved, the payload is verified on our backend, and we return an HMAC SHA-256 signature keyed to your server’s secret. You verify this signature before accepting the form submission.
Accessibility: It is 100% ADA/WCAG 2.1 AA compliant. There is a strictly rate-limited, keyboard-navigable accessibility bypass for screen readers.
We just released our official React NPM package (react-gamified-captcha) which compiles to standard ESModules/CommonJS and is fully SSR-safe for Next.js.
We know developers are rightly skeptical of third-party widgets, so we set up a live CodeSandbox where you can see exactly how much code it takes to implement and play the games right in the browser: https://codesandbox.io/s/github/oops-games-llc/conversionhub-integration-examples/tree/main/sandbox-template
I'd love to hear your feedback on the architecture, the game mechanics, or any edge cases we might have missed!
Top comments (2)
Interesting approach. From a pentesting perspective, the WebGL renderer check is clever but not airtight — headless browsers can now spoof GPU profiles or use software rendering that mimics real hardware. Bot operators also commonly use anti-detect browsers that expose exactly the fingerprint you're checking. The real strength here is the combination of short-lived game randomization plus the HMAC signature; that raises the cost for attackers who just replay solutions or train a generic solver.
One thing I'd keep an eye on: the accessibility bypass, even with rate limiting, often becomes the path of least resistance in automated attacks. I've seen audio challenges abused this way. If the rate limit is per-IP, residential proxy pools chew through it fast. Might be worth binding it to a server-side session token rather than solely IP. Are you planning to open-source the verification side or keep it SaaS-only? That transparency would help with trust.
Thanks for the analysis, Mdm. You hit the nail on the head regarding the WebGL checks—fingerprinting is ultimately a cat-and-mouse game against modern anti-detect browsers. As you noted, our core philosophy isn't to build an impenetrable fingerprinting wall, but rather to exponentially raise the computational and time cost of solving the dynamic, short-lived game states, backed by the HMAC signature.
Your point on the accessibility fallback is well taken. Residential proxy pools absolutely shred standard IP rate-limiting. Binding that specific fallback vector to a more robust server-side session token/fingerprint rather than relying solely on IP is excellent feedback and something we are actively looking at for the next iteration of the rate-limiter to prevent audio-challenge farming.
Regarding open-sourcing: the core heuristic engines and game-state generators will remain SaaS-only for now. Keeping those proprietary makes it significantly harder for bot operators to spin up local instances to train generic solvers against our exact models. However, we've open-sourced all of the client-side wrappers, SDKs, and the cryptographic verification examples so developers can see exactly what data is being passed and how the HMAC validation works on their own servers.
Really appreciate the deep dive from a pentesting perspective! If you want to poke around how the integration and signature validation is structured, the source for the wrappers is ove