this post was submitted on 26 Jul 2025
236 points (98.4% liked)
Linux
15082 readers
330 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments

Yeah, tarpits. Or, even just intentionally fractionally lagging the connection, or putting a delay on the response to some mime types. Delays don't consume nearly as much processing as PoW. Personally, I like tar pits that trickle out content like a really slow server. Hidden URLs that users are not likely to click on. These are about the least energy-demanding solutions that have a chance of fooling bots; a true, no-response tarpit would use less energy, but is easily detected by bots and terminated.
Proof of work is just a terrible idea, once you've accepted that PoW is bad for the environment, which it demonstrably is.
Tarpits suck. Not worth the implementation or overhead. Instead the better strat is to pretend the server is down with a 503 code or that the url is onvalid with a 404 code so the bots stop clinging to your content.
Also we already have non-PoW captchas that dont require javascript. See: go-away for these implemwntations
Good luck detecting bots...
It's actually not that hard. Most of these bots are using a predictable scheme of headless browsers with no js or minimal js rendering to scrape the web page. Fully deployed browser instances are demonstrably harder to scale and basically impossible to detect without behavioral pattern detection or sophisticated captchas that also cause friction to users.
The problem with bots has never rested solely on detectability. It's about:
A. How much you inconvenience the user to detect them
B. Impacting good or acceptable bots like archival, curl, custom search tools, and loads of other totally benign use cases.