Hacker News Reader

Comment by sgsjchs | Hacker News Reader

Ironically, defense by obscurity may be the way to go here.

Fork Anubis. Slightly modify the hash function it computes. Deploy. Do not try to make your fork widely adopted. Do not even publish it.

You've just defeated ASICs and any craweler that's special-cased Anubis (currently all of them). If enough people do this, the only recourse they will have is either genuinely executing served js code like a real user or building some unholy pipeline that uses ai agents to compile it to a GPU kernel for every host.

View on HN

> Fork Anubis. Slightly modify the hash function it computes. Deploy. Do not try to make your fork widely adopted. Do not even publish it.

A more robust solution would be to keep a few patches handy with different versions of the algorithm, and rotate which one is in use. This would keep the crawlers on their toes if they wise up to the changed algorithm. One could even imagine automatically rotating witch algorithm to use on a weekly basis.

Render page in headless browser with JS, cache challenge solution, re-use on all your non-browser requests. Won't really change anything and it will auto-adapt to any new challenge that is being thrown.

It's not reusable from a different IP.

I was thinking about this. Would it be possible for Anubis to have a code gen process that would make every deployment of itself sufficiently unique such that it's "annoying" to work around?

I do wonder about the premise as well: are people special casing for Anubis?

It's not really defense by obscurity (the JavaScript is public), more like defense by... being different?

Snowflake defense

It doesn't matter what the hash is if it is inherently cheaper for a bot farm to compute the hashes than it is for a human to do it on their device. The human pays a greater cost in annoyance, wasted time, battery, and that means the PoW has failed its function. The bot farm owner does not care.

Reply on news.ycombinator.com