By ByteBot
Anubis, the open-source bot-blocking proxy protecting GNOME, FFmpeg, the Linux kernel archives, Wine, and thousands of self-hosted projects, shipped WebAssembly-based challenge support this week — after nearly a year of development work. The milestone is trending on Hacker News with 263 upvotes and 133 comments as of September 7, 2026. The headline upgrade: Argon2id proof-of-work, a memory-hard algorithm, now replaces SHA-256 as the default challenge mechanism. That distinction matters more than it might sound.
SHA-256 Proof-of-Work Had a Dirty Secret
Anubis’s original SHA-256 proof-of-work was always asymmetric in the wrong direction. A browser solves SHA-256 hashes at roughly 1-5 million per second using Web Workers. A native solver written in C, Go, or Rust achieves 100-500 million hashes per second. A GPU-accelerated solver hits billions. Security researcher Tavis Ormandy documented the gap: native code defeats SHA-256 PoW “far more efficiently than browser implementations” — the actual differential is two to three orders of magnitude.
The math is unforgiving. At difficulty-5 (five leading zero hex digits, requiring roughly one million expected attempts), a browser takes about one second. A native solver finishes the same challenge in under two milliseconds. Any scraper operator willing to write a few hundred lines of Go can run through Anubis challenges faster than a human could blink. For large-scale, indiscriminate scrapers, the friction was real. For targeted, motivated attackers, it was negligible.
Why Argon2id Changes the Economics
Argon2id, the 2015 Password Hashing Competition winner, is deliberately memory-hard. Every iteration accesses a large, non-sequential memory region, making the algorithm resistant to parallelization in a way SHA-256 is not. The problem with CUDA-based acceleration is not compute — it is memory bandwidth. A GPU cluster might have thousands of cores, but those cores share the same memory bus. More cores do not add more memory bandwidth.
The Anubis WebAssembly implementation uses Argon2id with 333 memory pages per challenge — roughly 21 megabytes. Running 1,000 simultaneous Argon2id challenges requires approximately 21 gigabytes per second of memory bandwidth. That is a genuine physical constraint, not just a computational one. A CUDA solver that could hammer through SHA-256 at billions of hashes per second now faces real hardware limits. The full implementation in PR #1684 also includes HashX as an alternative algorithm, giving administrators flexibility to tune challenge cost.
The WASM binary itself is compact: 32-40 kilobytes compressed. Browsers execute it natively, at two to three times the speed of equivalent JavaScript. For legitimate users, the challenge completes faster. For scrapers with native solvers, the game has changed in a way SHA-256 never could achieve.
Related: Cloud in a Bottle: Self-Hosting Finally Gets Unified Auth
Why It Took a Year to Ship
WebAssembly sounds simple in theory. In practice, modern Rust WASM toolchains emit features — specifically reference-types encoding — that silently break Chrome versions before 100. The solution was running wasm-opt to prune the binary down to MVP WebAssembly features, eventually achieving compatibility back to Chrome 75. That is not a trivial task: it means testing against 23 or more browser configurations and handling silent failures that do not throw errors, they just produce wrong outputs.
For browsers that disable WebAssembly entirely — hardened Firefox profiles, Tor Browser in strict mode, some corporate environments — the team implemented a wasm2js fallback that translates the WASM binary to JavaScript at build time. There was also an ARM64 bug in the wazero WASM compiler that required a conditional interpreter fallback. Xe Iaso acknowledged in the writeup that burnout and concern about community reaction from accessibility advocates also contributed to the extended timeline. Shipping robust WASM in production, it turns out, is its own compatibility tax.
Who Should Care and What to Change
If you are running Anubis in front of a Forgejo instance, a public documentation site, or any self-hosted service getting hammered by AI crawlers that ignore robots.txt, upgrading and switching to Argon2id is a straightforward improvement. The configuration change is one line: set CHALLENGE_ALGORITHM=argon2id. Version 1.27.0 (August 8, 2026) and later include the WASM runtime.
However, be honest about the ceiling. Anubis is friction, not a wall. A determined, well-resourced scraper operator — think large-scale commercial training data collection — will implement native solvers and adapt. Argon2id raises the cost substantially over SHA-256, but it does not make bypassing Anubis impossible. The tool remains best suited for what it was built to handle: the wave of indiscriminate, low-effort scrapers running off-the-shelf tools against small public services that cannot otherwise afford enterprise bot protection.
Key Takeaways
- Anubis shipped WebAssembly support with Argon2id challenges this week, making SHA-256 bypass via native solvers substantially more expensive
- SHA-256 proof-of-work was always vulnerable to native C/Go/Rust solvers running 100-500x faster than browsers — Argon2id’s memory-hardness addresses this at the hardware level
- The year-long timeline came down to browser compatibility: wasm-opt pruning for Chrome 75 support, a wasm2js fallback for WASM-disabled environments, and an ARM64 compiler bug
- Self-hosted operators on Forgejo, Gitea, public wikis, or Git mirrors should upgrade and enable Argon2id — the improvement is real and the migration is a one-line config change
- Anubis remains friction, not a wall: sophisticated adversaries with native solvers will adapt, but the economic barrier for mass scrapers just rose meaningfully
