> how many people in tech are feeling a deep malaise for various reasons

Pretending that everything that has happened will always happen is just brain atrophy, which is why it's mistaken for maturity.

I quickly looked over my access logs just now (eyeballs and grep, not goaccess) and see a couple of patterns...

One, there are indeed lots of bots - over a thousand hits from Claude. Some from search, some from users.

There are some bots I've never even heard of (mj12bot?).

There are some things which look like legitimate traffic coming from a common household Web browser, looking at blog posts and such, until suddenly they make a 404 request for a nonexistent API endpoint and go away.

And there are _so many_ requests for `.env` files, `swagger.json`, `backup.sql`, `phpinfo.php`, WordPress (always!)... Sorry folks, it's nginx in a container, serving a bunch of static content.

That's for a search engine that has been around before the AIpocalypse.

Because the world isn’t so much violently destroyed as it is… quietly cold, barren and lifeless.

https://infosec.exchange/@rebane2001/117601277347377053

Writing software or english in the AI era is the same feeling as playing a video game without cheat codes you already beat using cheat codes.

The game is not ruined permanently.

It’s like walking in the park when everyone else is zipping past you on scooters, and there’s nobody going your speed for you to talk with or even smile at.

That implies having a "service provider" in the first place, which is itself a bastardization of the open web.

That said, a CDN is only good for standard web traffic, not some custom game/chat/video service you might invent, but then again crawlers aren’t hitting those.

You're feeding bots poison without rate limiting them all to some small fraction of your pipe?

You should not traffic shape the egress lest you run out of workers handling legitimate traffic. You should also make sure connections are appropriately terminated on your side for the same reason.

I haven’t seen an installation where the operator is tracking customer impact. They check the logs and say “see , we’ve screened 80% of the AI bots”. Meanwhile , among the 80% of bot traffic is a few percent of customers who are aggressively being punished without the operator being aware.

anyway, if you really want to block scrappers, give up Anubis. it just about real users and do nothing against bots. simple block ISN that belong to cloud providers. it's that simple.

What really pisses me off was Meta’s bots ignoring robots.txt when I tried to prevent high levels of traffic hitting meaningless URL variants on a Mediawiki site. Everybody else stopped hitting those URLs but not Meta which was flooding me with so much traffic it was impacting site performance. There source IPs and user agents are now banned.

Can anyone corroborate this?

It works too well.

[1]: https://news.ycombinator.com/item?id=48635954

Here's just one example. It's kindof rude, especially for legit people behind corporate firewalls but such people should not be on my site anyway. Adjust as needed. It's just a silly example.

    if ($server_protocol = HTTP/2.0) { set $limit_rate 384k; set $ok 1; }
    if ($http3 != "") { set $ok 1; } # no rate limit for quic
    if ($ok != 1) { set $limit_rate 32; limit_rate_after 128; set $trace "${trace}not-h2h3 "; add_header Content-Type text/html;return 200 '<!DOCTYPE html><html><head><title>Welcome to nginx!</title><style>body{width:35em;margin:0 auto;font-family:Tahoma,Verdana,Arial,sans-serif;}</style></head><body><h1>Welcome to nginx!</h1><p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p></body></html>'; }

I have noticed among my tech friends that one spectrum you can put us on is "sysadmin vs. not" - some people love tinkering with home labs, setting up systems, being able to reboot things from their watches, etc. And some people, like me, would strongly prefer not to be on-call for their hobby.

Hell, my personal server has been down for at least a week now because I started upgrading Ubuntu (that was very, very far behind), and one upgrade caused it to lose network connectivity, and I just haven't bothered to even start troubleshooting. If I had to guess, I'll probably be arsed to get it up sometime in December, though 2027 isn't out of the question.

    dmesg -T; lspci -vv; lsmod; ip link;

 to a thumb drive and paste it into an LLM if you are not feeling like debugging such things.  I used to call that lazy but I was corrected and now call it efficient.

Absolutely. Most of the bots are simple but a few of them were created and actively maintained by clever people that are here on HN. I like to think it's a playful arms race.

I think it might be lacking context being posted here and emotionally resonates more with the actual intended viewership?

The only thing I am holding on to (like someone else said) is that they might include my writings in the training data, and bias towards my opinions ever so slightly as a result. :')

For the fun of it, I'm developing my own anti-bot solution which acts as a proxy between nginx and the application, and is able to modify and override application responses (I anubis works the same way). What I've tried so far:

- Introducing a tarpit - infinite amount of cheap dynamically generated interlinked garbage pages, a hidden nofollow+noindex link to which is added to legitimate pages. - Ability to introduce artificial response delays to tarpit or other pages. - Ban IPs accessing a tarpit (and some other broken path patterns which browsers will never visit). - Set a simple boolean cookie to know whether session has already visited the site. - Set another boolean cookie for clients accessing a tarpit (in case bots learn to store cookies or reuse sessions; not tried to use it). - For heaviest application endpoints (which need protection the most), require either "already visited" cookie, or show simple captcha. - Also show captcha to banned IPs.

Each of these seems to help to some extent, and there's a lot of room for both experiments and for the case where bots adapt to some of these mechanisms.

Findings: - Tarpit seems to divert a lot of traffic from legitimate pages. - However, bots understood how well it performs and increased request rate from 40 to 160 rps. - Introducing a delay helped with that. 9 sec delay has brought the rate down to 40 rps immediately. Longer delay makes bots timeout and drop the connection - not useful in my case as I want to feed more garbage links to them. - It suggests the important idea of that the botnet has some centralized rate control mechanism which adapts to site performance, so you just need to make the site look slow and underperforming to bots. - Most basic cookie based logic works great (for now). No need for cryptography or complex captchas, just set already_visited=1, or passed_captcha=1, where "captcha" is just an automated js which sets a cookie and reloads the page. - IP bans work too, but simple `HashMap<IpAddr>` does not scale. Will try to come with more clever solution someday, probably involving a tree of IP address space regions, or a registry of nets from WHOIS, gathers statistics on per-network basis and acts based on that. For instance, nets with no legitimate requests over large period of time may be banned on firewall to reduce server load. Other nets with high rate of bot hits may be considered untrusted and always require captcha. - Botnets ignore a `rel="nofollow noindex"`, so you can probably safely use these to guide the botnet to tarpit, while legitimate crawlers should not be affected.

Bot-resistant application design wisdom: - Obviously, make it fast. You can no longer afford the application to perform slow (over 100ms) SQL queries. That's ok for humans, but bots will crush you. You can no longer afford slow backend language. I've rewritten repology to rust a couple of years ago, which resulted in around 10-100x performance and memory optimization. Had I not done it, the site would already be down by now. - Don't ignore dynamic solutions. I myself am an oldschool who prefers to generate HTML on backend and avoid javascript. Guess it's time to reconsider. In my case, doing pagination in js would a) hide most pages from the botnet b) avoid generating infinite amount of distinct pagination pages, while these pages being heaviest on the site. - Nginx before the application currently consumes more CPU than the application and anti-bot solution combined, so I'm considering retiring it.

Questions to community: - I'm not satisfied with tarpit pages with just links to other tarpit pages. Any ideas of feeding the botnet with actual content to poison the dataset? I can come up with fake API reference pages with nonexistent methods.

There really isn’t that much of a delay, and once a visitor is confirmed, the rest of the site can still be zippy AF.

The downside with Anubis is that a properly-secured web browser will not be able to run its anti-AI code, and will fail. Not “you are a bot” fail, but “cannot run our checks” fail.

This is at a much more stringent level than CloudFlare’s maliciously invasive and user-hostile “protections”, so even fewer site visitors will be impacted, but can still be annoying to a privacy-oriented user.