HeCAPTe as a DDoS Protection System ? #1

Thanks for the kind words, and 98% is a genuinely nice number to hear!

Short version of my answer: as a feature of HeCAPTe itself, no, and I’ll explain why. As something you build using HeCAPTe, absolutely viable! You wouldn’t even need much code. But if what you want is “turn it on and the site is protected,” Anubis is the right answer.

Why it won’t be a feature: A whole-site gate needs one primitive HeCAPTe deliberately doesn’t have: success carryover. Solve once, get waved through for the next hour (or whatever other unit of time you configure). Whatever you sign it with, that thing is a session, and the project is committed to statelessness toward the protected service: no cookies, no IP logging, nothing following the user around. /verify is server-to-server with your secret key as the bearer credential, so the “you solved it, here’s your pass” step can never be issued by HeCAPTe to a browser directly. Somebody’s backend has to mint that pass.

It would be pretty easy to build that into your backend, actually:

1. A middleware or small proxy in front of the site that checks for a valid pass cookie and serves an interstitial when it’s missing
2. The interstitial page itself, which is mostly the same pattern as the demo page (worker.js, solver.wasm, fetch the challenge) rendered as a blocking screen
3. One endpoint on your server that takes the posted solution, calls /verify with the secret key, and on success sets your own HMAC-signed cookie with whatever expiry you like
4. The boring policy bits (which paths are gated, letting static assets through so the interstitial can even load, etc.)

Maybe a day or two, if your stack is friendly to it? The puzzle machinery, which is the difficult cryptographic part, already exists in HeCAPTe.

As far as what issues you might run into: Challenges carry a 60-second TTL from issuance to valid solution, which might be tight on a first-ever page load from an old phone at the Recommended preset. You’d probably want to tune difficulty down for gate use or handle re-issue mid-solve (which HeCAPTe doesn’t currently do).

HeCAPTe and Anubis are actually direct opposites here: Anubis is basically a mature policy engine with a quick, somewhat-inadequate puzzle bolted on (more on that later). HeCAPTe + your DIY gate would be a rock-solid puzzle with an amateur policy engine.

Why you might still want HeCAPTe + DIY: Anubis uses a fast SHA-256 puzzle. It’s not designed to be memory-hard at all: it’s deliberately cheap, and as a security gate, it doesn’t function as much more than proof you can run JavaScript. Its real teeth are the policy engine, not the PoW. Equihash is memory-hard, so against a scraper farm or botnet that’s actually motivated, a HeCAPTe-fronted gate is the much tougher puzzle to solve, and one that meaningfully slows down and discourages this kind of automated attack. Whilst I am admittedly gratified by that, for generic crawler deterrence, most of them die at “must execute WASM” no matter what you use.

Basically, if you want it to Just Work, I would go with Anubis for sure. If you want the memory-hard asymmetry and enjoy manual tinkering, build it on HeCAPTe (and I’d love to see what you come up with!). A documented gate recipe (interstitial template plus a short gate-handler sketch) is something I’m open to adding to the repo’s documentation, since it would bless exactly this pattern without touching the statelessness commitment of the core software.

One terminology thing, since it changes expectations: neither a HeCAPTe gate nor Anubis is DDoS protection. A volumetric flood sails straight past anything at the application layer; you need network-level mitigation for that through a provider like Cloudflare. What PoW gates actually kill is scraper and crawler floods, like the LLM training swarm and mass email spammers. Sending a simple GET / flood without specific DDoS protection is going to kill any server, with or without Anubis.