The author demonstrated that the challenge can be solved in 17ms however, and that is only necessary once every 7 days per site. They need less than a second of compute time, per site, to be able to send unlimited requests 365 days a year.
The deterrent might work temporarily until the challenge pattern is recognised, but there’s no actual protection here, just obscurity. The downside is real however for the user on an old phone that must wait 30 seconds, or like the blogger, a user of a text browser not running JavaScript. The very need to support an old phone is what defeats this approach based on compute power, as it’s always a trivial amount for the data center.
The deterrent might work temporarily until the challenge pattern is recognised, but there’s no actual protection here, just obscurity.
Anubis uses a proof-of-work challenge to ensure that clients are using a modern browser and are able to calculate SHA-256 checksums. Anubis has a customizable difficulty for this proof-of-work challenge, but defaults to 5 leading zeroes.
Please tell me how you’re gonna un-obscure a proof-of-work challenge requiring calculation of hashes.
You just solve it as per the blog post, because it’s trivial to solve, as your browser is literally doing so in a slow language on a potentially slow CPU. It’s only solving 5 digits of the hash by default.
If a phone running JavaScript in the browser has to be able to solve it you can’t just crank up the complexity. Real humans will only wait tens of seconds, if that, before giving up.
This here is the implementation of sha256 in the slow language JavaScript:
const msgUint8 = new TextEncoder().encode(message); const hashBuffer = await window.crypto.subtle.digest("SHA-256", msgUint8); const hashHex = new Uint8Array(hashBuffer).toHex();
You imagined that JS had to have that done from scratch, with sticks and mud? Every OS has cryptographic facilities, and every major browser supplies an API to that.
As for using it to filter out bots, Anubis does in fact get it a bit wrong. You have to incur this cost at every webpage hit, not once a week. So you can’t just put Anubis in front of the site, you need to have the JS on every page, and if the challenge is not solved until the next hit, then you pop up the full page saying ‘nuh-uh’, and probably make the browser do a harder challenge and also check a bunch of heuristics like go-away does.
scrubbles@poptalk.scrubbles.tech 1 day ago
That’s counting on one machine using the same cookie session continuously, or they code up a way to share the tokens across machines. That’s now how the bot farms work
deffard@lemmy.world 1 day ago
It will obviously depend heavily on the type of bot crawling, but that is not hard coordination for harvesting data for LLM’s, as they will already have strategies to prevent nodes all crawling the same thing - a simple valkey cache can store a solved JWT.
scrubbles@poptalk.scrubbles.tech 23 hours ago
but the vast majority of crawlers don’t care to do that. That’s a very specific implementation for this one problem. I actually did work at a big scraping farm, and if they encounter something like this,they just give up. It’s not worth it to them. That’s where the “worthiness” check is, you didn’t bother to do anything to gain access.