Anubis took a year to ship WebAssembly for its AI-scraper proof-of-work challenge

A year for one feature

The Anubis project has documented a milestone that took twelve months to deliver: WebAssembly support inside its anti-scraper tooling. The post, dated September 6, 2026 and picked up on the Hacker News front page, is titled simply "It took a year to ship WebAssembly in Anubis" — a headline that reads as much a statement about the web as a release note.

In a fitting demonstration of its own reach, the blog post announcing the feature is itself served behind an Anubis challenge. Loading it presents the project's interstitial, which explains that the site's administrator deployed Anubis to protect the server from aggressive scraping by AI companies — traffic the project says can and does knock websites offline and make their resources unreachable for everyone.

What Anubis actually does

According to the project's description, Anubis puts a proof-of-work challenge in front of visitors, modeled on Hashcash, the decades-old proposal for fighting email spam with computation. The economics are deliberately lopsided: a single human solving a single challenge pays a negligible cost, while a scraper working at volume pays it on every request, which multiplies its expenses dramatically.

The project is candid that this is scaffolding rather than a destination. It describes the challenge as an interim measure, to be retired once Anubis gets better at fingerprinting headless browsers — for example through the way they render fonts — so that visitors who already look human can skip the proof of work entirely.

There is also an explicit compatibility price. Anubis depends on modern JavaScript features that privacy-hardening extensions such as JShelter deliberately disable, and the project asks users to turn those extensions off for Anubis-protected domains. Proving you are not a bot can mean switching off the very tooling that limits how trackable you are.

Where WebAssembly fits

The headline does not enumerate the obstacles, and the challenge page does not elaborate, but the technical logic is straightforward to reconstruct. A proof-of-work gate is hashing-bound: the visitor's browser grinds through hash computations until one satisfies the difficulty target. Plain JavaScript is a poor vehicle for that kind of tight numeric loop, while WebAssembly executes at close to native speed. Moving the computation across should shorten the wait for legitimate visitors, and it pushes scrapers to run — or faithfully reimplement — a WebAssembly module instead of pasting a short script into a headless browser.

The more revealing datum is the calendar. A single performance feature in a defensive tool consumed a year of effort, which says something about both the difficulty of shipping WASM across the wild variety of browsers in use and the intensity of the arms race that makes the tool necessary at all.

The trade-offs stack up

Anubis presents itself as a compromise, and its own notes are frank about the costs. Challenge middleware inserts a checkpoint between people and content, and it assumes a modern browser with JavaScript fully enabled — and now, presumably, WebAssembly too. Anything outside that envelope, from hardened privacy setups to older browsers and non-browser clients, can find protected resources simply unreachable. The project's stated hope is that better detection of automated browsers will eventually let it take humans off this path altogether.

Why it matters

Anubis exists because unthrottled AI crawling has made plain web serving operationally risky for many site owners. That a defense project spent a year landing one feature is a small, concrete measure of how the scraping epidemic taxes engineering capacity across the web — effort spent building walls rather than products. And each new brick, WebAssembly included, narrows the set of clients that can still pass through the gate. The milestone is not really the story; the cost of reaching it is.