Top
Best
New

Posted by todsacerdoti 1 day ago

How I protect my Forgejo instance from AI web crawlers(her.esy.fun)
166 points | 84 commentspage 2
frogperson 19 hours ago|
I think it would be really cool if someone built a reverse proxy just for dealing with these bad actors.

I would really like to easily serve some markov chain non-sense to Ai bots.

jakewil 18 hours ago|
perhaps Iocaine [1] is what you're looking for. See the demo page [2] for what it serves to AI crawlers.

1. https://iocaine.madhouse-project.org/

2. https://poison.madhouse-project.org/

philipwhiuk 17 hours ago|||
For images you have stuff like https://nightshade.cs.uchicago.edu/whatis.html
opem 15 hours ago||||
This site blocked me right away, seems quite agressive
gkbrk 13 hours ago|||
Seems like a good way to waste tons of your bandwidth. Almost every serious data pipeline has some quality filtering in there (even open-source ones like FineWeb and EduWeb). And the stuff Iocaine generates instantly gets filtered.

Feel free to test this with any classifier or cheapo LLM.

apples_oranges 1 day ago||
HTTP 412 would be better I guess..
jsheard 23 hours ago|
You shouldn't really serve aggressive scrapers any kind of error or otherwise unusual response, because they'll just take that as a signal to try again with a different IP address or user agent, or a residential proxy, or a headless browser, or whatever else. There's no obligation to be polite to rude guests, give them a 200 OK containing the output of a Markov chain trained on the Bee Movie script instead.
loloquwowndueo 18 hours ago||
Unless your output is static, you’d then be paying the cost of running the markov generator.
stronglikedan 16 hours ago||
> Unfortunately this means, my website could only be seen if you enable javascript in your browser. I feel this is acceptable.

I wouldn't be surprised if all this AI stuff was just a global conspiracy to get everyone to turn on JS.

reconnecting 1 day ago||
tirreno (1) guy here.

Our open-source system can block IP addresses based on rules triggered by specific behavior.

Can you elaborate on what exact type of crawlers you would like to block? Like, a leaky bucket of a certain number of requests per minute?

1. https://github.com/tirrenotechnologies/tirreno

reconnecting 1 day ago||
I believe there is a slight misunderstanding regarding the role of 'AI crawlers'.

Bad crawlers have been there since the very beginning. Some of them looking for known vulnerabilities, some scraping content for third-party services. Most of them have spoofed UAs to pretend to be legitimate bots.

This is approximately 30–50% of traffic on any website.

notachatbot123 1 day ago|||
The article is about AI web crawlers. How can your tool help and how would one set it up for this specific context?
reconnecting 1 day ago||
I don't see how an AI crawler is different from any others.

The simplest approach is to count the UA as risky or flag multiple 404 errors or HEAD requests, and block on that. Those are rules we already have out of the box.

It's open source, there's no pain in writing specific rules for rate limiting, thus my question.

Plus, we have developed a dashboard for manually choosing UA blocks based on name, but we're still not sure if this is something that would be really helpful for website operators.

Roark66 1 day ago|||
>It's open source, there's no pain in writing specific rules for rate limiting, thus my question.

Depends on the goal.

Author wants his instance not to get killed. Request rate limiting may achieve that easily in a way transparent to normal users.

mmarian 13 hours ago|||
> count the UA as risky

It's trivial to spoof UAs unfortunately.

mmarian 13 hours ago||
> block IP addresses based on rules triggered by specific behavior

Problem is, bots can easily can resort to resi proxies, at which point you'll end up blocking legitimate traffic.

immibis 1 day ago||
My issue with Gitea (which Forgejo is a fork of) was that crawlers would hit the "download repository as zip" link over and over. Each access creates a new zip file on disk which is never cleaned up. I disabled that (by setting the temporary zip directory to read-only, so the feature won't work) and haven't had a problem since then.

It's easy to assume "I received a lot of requests, therefore the problem is too many requests" but you can successfully handle many requests.

This is a clever way of doing a minimally invasive botwall though - I like it.

userbinator 1 day ago||
Each access creates a new zip file on disk which is never cleaned up.

That sounds like a bug.

isodev 22 hours ago||
I think that’s been fixed in Forgejo a long time ago
GrayShade 3 hours ago|||
It used to be like that, but they've changed it to a POST request a while ago.
bob1029 1 day ago||
> you can successfully handle many requests.

There is a point where your web server becomes fast enough that the scraping problem becomes irrelevant. Especially at the scale of a self-hosted forge with a constrained audience. I find this to be a much easier path.

I wish we could find a way to not conflate the intellectual property concerns with the technological performance concerns. It seems like this is essential to keeping the AI scraping drama going in many ways. We can definitely make the self hosted git forge so fast that anything short of ~a federal crime would have no meaningful effect.

idontsee 1 day ago|||
> There is a point where your web server becomes fast enough that the scraping problem becomes irrelevant.

It isn't just the volume of requests, but also bandwidth. There have been cases where scraping represents >80% of a forge's bandwidth usage. I wouldn't want that to happen to the one I host at home.

immibis 13 hours ago||
Sure but how much bandwidth is that actually? Of course if your normal traffic is pretty low, it's easy for bot traffic to multiply that by 5, but it doesn't mean it's actually a problem.

The market price for bandwidth in a central location (USA or Europe) is around $1-2 per TB and less if you buy in bulk. I think it's somewhat cheaper in Europe than in the USA due to vastly stronger competition. Hetzner includes 20TB outgoing with every Europe VPS plan, and 1€/TB +VAT overage. Most providers aren't quite so generous but still not that bad. How much are you actually spending?

spockz 1 day ago|||
Maybe it is fast enough but my objection is mostly due to the gross inefficiency of crawlers. Requesting downloads of whole repositories over and over, leading to storing these archives on disk wasting CPU cycles to create them and storage space to retain them, and bandwidth to sent them over the wire. Add this to the gross power consumption of AI and hogging of physical compute hardware, and it is easy to see “AI” as wasteful.
KronisLV 1 day ago||
We should just have some standard for crawlable archived versions of pages with no back end or DB interaction behind them etc., for example if there's a reverse proxy, whatever it outputs is archived and it wouldn't actually pass on any call in the archive version. Same for translating the output of any dynamic JS into fully static HTML. Then add some proof-of-work that works without JS and is a web standard (e.g. server sends header, client sends correct response, gets access to archive) and mainstream the culture for low-cost hosting for such archives and you're done, also make sure that this sort of feature is enabled in the most basic configuration for all web servers and such, logged separately.

Obviously such a thing will never happen, because the web and culture went in a different direction. But if it were a mainstream thing, you'd get easy to consume archives (also for regular archival and data hoarding) and the "live" versions of sites wouldn't have their logs be bogged down by stupid spam.

Or if PoW was a proper web standard with no JS, then ppl who want to tell AI and other crawlers to fuck off, they could at least make it uneconomical to crawl their stuff en masse. In my view, proof of work that would work through headers in the current day world should be as ubiquitous as TLS.

agentifysh 14 hours ago||
never heard of forgejo, should one switch from gitea
tuananh 3 hours ago|
it's a fork of gitea.
justsomehnguy 15 hours ago||
A similar approach can be done by writing a cookie by the proxy/webserver itself by visiting some path ie: example.net/sesame/open.

For a single user or a small team this could be enough.

Roark66 1 day ago||
I'm glad the author clarified he wants to prevent his instance from crashing not simply "block robots and allow humans".

I think the idea that you can block bots and allow humans is fallacious.

We should focus on a specific behaviour that causes problems (like making a bajillion requests one for each commit, instead of cloning the repo). To fix this we should block clients that work in such ways. If these bots learn to request at a reasonable pace why cares if they are bots, humans, bots under a control of an individual human, bots owned by a huge company scraping for training data? Once you make your code (or anything else) public, then trying to limit access to only a certain class of consumers is a waste of effort.

Also, perhaps I'm biased, because I run a searXNG and Crawl4AI (and few ancillaries like jina rerank etc) in my homelab so I can tell my AI to perform live internet searches as well as it can get any website. For code it has a way to clone stuff, but for things like issues, discussions, PRs it goes mostly to GitHub.

I like that my AI can browse almost like me. I think this is the future way to consume a lot of the web (except sites like this one that are an actual pleasure to use).

The models sometimes hit sites they can't fetch. For this I use Firecrawl. I use MCP proxy that lets me rewrite the tool descriptions so my models get access to both my local Crawl4ai and hosted (and rather expensive)firecrawl, but they are told to use Firecrawl as last resort.

The more people use these kinds of solutions the more incentive there will be for sites not to block users that use automation. Of course they will have to rely on alternative monetisation methods, but I think eventually these stupid capchas will disappear and reasonable rate limiting will prevail.

popcornricecake 21 hours ago||
> I think this is the future way to consume a lot of the web

I think I see many prompt injections in your future. Like captchas with a special bypass solution just for AIs that leads to special content.

asfdasfsd 1 day ago|||
And people who block AI crawlers on moral grounds?
szundi 23 hours ago||
[dead]
mintflow 19 hours ago|
recently I just noticed github trying(but failed) to charge the self host runners, I find a afternoon to setup a mini PC to install freeBSD and gitaea on it, then setup tailscale to let it only listen on the 100.64.x.x IP address.

Since I do not make this node public accessable, so no worry for AI web crawlers:)