🔗 https://stephvee.ca/blog/updates/the-scraping-problem-is-worse-than-i-thought/

The extreme amount of unethical #scraping that's occurring all over the web right now *definitely* won't be solved by limiting nice features for good-faith visitors; for that reason, I've reinstated my full-text RSS feed. Apologies for truncating it in the first place -- that was dumb of me. More about that in my latest blog post.

#indieweb #scrapers #fuckai

No outages in the latest Apache logs. However, there is plenty of suspicious activity.

The log has 16,033 lines.

Of these, 1,559 lines feature the "RecentChanges" function for my wikis. Which is something regular users _might_ call up from time to time, but I suspect that #scrapers are the more likely culprits.

The vast majority of these requests come from a random assortment of IP addresses, and they usually end with something on the lines of:

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"

So yeah, "anonymous bot nets scraping the Interwebs for nefarious purposes" would be by first guess.

Army of Bots

For some months now I have a simple detection against "bad" bots in place. Bots that scrape *everything* they find and very likely are vacuuming all the contents they get to feed the data grinders that train the LLMs of the world. Bots that not only ignore the "robots.txt" protocol, but actively see entries in the robots.txt file as an invitation to visit the contents that are listed there as "disallowed".

I always had a hunch that stating addresses in a publicy reachable text file and flagging those as "please stay out of there" wasn't the best idea, but well, it was the only thing we've got back in the days where the only bots out there were the crawlers of the search engines.

(…) There are two important considerations when using /robots.txt:
robots can ignore your /robots.txt. Especially malware robots that scan the web for security vulnerabilities, and email address harvesters used by spammers will pay no attention.
the /robots.txt file is a publicly available file. Anyone can see what sections of your server you don't want robots to use.
robotstxt.org

Now with all the content-sucking and scraping that the "AI" corporations let lose on the web, it is not unusual to haver a massive spike in bot-related visits even in the personal-website-space. And those scrapers are ruthless, they hammer the servers in high frequency and repeatetly, and are killing the web as we know it along the way.

(…) Many of these scrapers are so sophisticated that it is hard, or impossible, to detect them in action. They often ignore the websites’ programmatic pleas not to be scraped, and are known to hit the more fragile parts of a website repeatedly. opendemocracy.net

I created a directory with a random name in the top-level of my website.

I then added this directory in the robots.txt file with a disallow. This directory is not linked anywhere. Its name is so random and cryptical that it is highly unlikely that a "name guessing" bot will find it (like those exploit-searching idiot scripts that hammer on "wp-admin" or "typo3" URLs even on sites that don't use WordPress or TYPO3…). Inside the directory is a index script that

a) sends me an email,
b) logs the visit with user-agent-string and IP address and
c) saves the data in a nosql db.

In front of my website I have a script that will check the current visitor's IP address against the nosql and if the IP matches, a HTTP 403 status is served.

Here's a best-of user agent strings that recently "visited" my hidden dir.
That last one is superb, considering that this one alone is several times in my log, of course with a different IP each time:

PetalBot
Googlebot/2.1
Claude-SearchBot/1.0
Thinkbot/0 +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.

Plus, there's a load more that pretend to be "normal" web browsers, of course. 🙄

It is a crude, a symbolical fist shaking yelling at clouds kind-of thing, especially compared to the things that Matthias Ott shared in his post, but it is better than nothing.

#Bots #getoffmylawn #LLM #scrapers

https://webrocker.de/?p=29781

Dear friends,
You may have noticed that our website is often unavailable. We are facing a massive load from anonymous scrapers, with over 30,000 IP addresses sending requests every day. We are fighting against AI bots! To find out more: https://velvetyne.fr/news/they-are-trying-to-kill-the-free-web/

#DDoS #Scrapers #AI

Velvetyne

Libre fonts for everyone

Long Time No Post

A traditional rant as one would expect for this kind of delay

https://mmn.ca/~/English/Long%20Time%20No%20Post/

@puniko after all, @MattKC / #MattKC got #DDoS'd by #ByteDance (the creators of #TikTok) despite paying #ClownFlare protection money.

#CloudFlare #Scrapers #AI #bots

The creators of TikTok caused my website to shut down

YouTube
https://OpenStreetMap.org has been disrupted today. We're working to keep the site online while facing extreme load from anonymous scrapers spread across 100,000+ IP addresses. Please be patient while we mitigate and protect the service. #OpenStreetMap #DDoS #Scrapers #AI
OpenStreetMap

OpenStreetMap is a map of the world, created by people like you and free to use under an open license.

OpenStreetMap
Looks like those nasty AI scraper cannot follow 30x redirects
#webmaster #scrapers #website

Bom artigo sobre o problema dos bots de IA vasculhando e copiando a internet inteira, deixando estrago em muitos lugares onde passam. Coloco a tradução em português direto aqui no post:

Combate ao problema dos bots coletores de IA

Por Jonathan Corbet
14 de fevereiro de 2025

Existem muitos desafios envolvidos na gestão de um site como o LWN. Alguns deles, como encontrar a coragem para escrever para pessoas que sabem mais sobre o assunto do que nós, simplesmente fazem parte do território que escolhemos. Mas outros surgem como uma surpresa indesejada; a tarefa contínua de repelir bots determinados a vasculhar toda a Internet para (aparentemente) alimentar o insaciável moedor de carne do treinamento de IA é certamente um deles.

Os leitores, às vezes, expressam curiosidade sobre essa luta e como estamos lidando com ela; continue lendo para obter uma descrição dessa praga moderna.

Treinar os modelos para os sistemas de IA generativa que, segundo informações confiáveis, vão transformar nossas vidas para melhor, requer grandes quantidades de dados. As empresas mais proeminentes que trabalham nessa área deixaram claro que sentem um direito inalienável a quaisquer dados que possam obter virtualmente.

Mas essas são apenas as empresas que estão sendo pelo menos um pouco públicas sobre o que estão fazendo. Sem exemplos específicos para apontar, sinto-me bastante certo de que, para cada empresa que trabalha sob os holofotes, há muitas outras com programas de construção de modelos sobre os quais não falam a ninguém. Estranhamente, essas operações não parecem se comunicar entre si ou compartilhar os dados que saqueiam de sites na internet.

O sistema de gerenciamento de conteúdo da LWN contém mais de 750.000 itens (artigos, comentários, alertas de segurança, etc.) que datam da adoção do “novo” código do site em 2002. Ainda temos em nossos arquivos tudo o que fizemos nos mais de quatro anos em que operamos antes da mudança. Além disso, os arquivos da lista de discussão contêm centenas de milhares de e-mails. Resumindo, se você for tomado por um desejo irresistível de baixar tudo do site, terá que gerar uma grande quantidade de tráfego para obter tudo. Se, por algum motivo, você sentir a necessidade de fazer esse download repetidamente, caso algo tenha mudado desde ontem, seu tráfego será multiplicado de acordo. Leve em consideração um número desconhecido de outras pessoas fazendo a mesma coisa, e isso pode resultar em uma quantidade avassaladora de tráfego.

O LWN não é operado por um conjunto enorme de máquinas esperando para manter os robôs de scraper felizes. O site é, em nossa opinião, escrito de forma razoavelmente eficiente e geralmente responsivo. Mas quando os picos de tráfego ficam grandes o suficiente, os efeitos são sentidos por nossos leitores; é quando começamos a ficar mais irritados do que o normal. E não somos apenas nós; esse problema tem sido sentido por mantenedores de recursos em toda a nossa comunidade e além.

Em discussões com outras pessoas e por meio de nossos próprios esforços, analisamos várias maneiras de lidar com esse problema. Algumas delas são mais eficazes do que outras.

Por exemplo, a primeira sugestão de muitos é colocar os scrapers ofensivos no robots.txt, dizendo-lhes educadamente para se retirarem. No entanto, essa abordagem oferece pouca ajuda. Embora os scrapersbot baixem avidamente qualquer conteúdo que encontrem no site, a maioria deles evita religiosamente olhar para o robots.txt. As pessoas que operam esses sistemas não têm absolutamente nenhum interesse na nossa opinião sobre como devem acessar nosso site.

Para deixar isso ainda mais claro, a maioria desses robôs faz de tudo para evitar se identificar como tal; eles se esforçam ao máximo para parecer apenas mais um humano com um navegador da web. O throttling é outra solução frequentemente sugerida. O site LWN implementou o throttling básico baseado em IP há anos; mesmo nos dias pré-IA, era comum que alguém tentasse baixar o site inteiro, de preferência em menos de cinco minutos.

Existem também sistemas como o commix que tentam explorar todas as vulnerabilidades de injeção de comando que seus desenvolvedores conseguem imaginar, a uma taxa de milhares por segundo. O throttling é necessário para lidar com esses agentes, mas, por motivos que abordaremos em breve, ele é relativamente ineficaz contra a atual safra de bots.

Outros sugerem tarpits, como o Nepenthes, que conduzem os bots de IA a um pequeno labirinto sinuoso de páginas de lixo, todas iguais. Soluções como essa trazem um risco adicional de aprisionar scrapers legítimos de mecanismos de busca que (normalmente) seguem as regras. Embora a LWN não tenha experimentado tal solução, acreditamos que ela também seria ineficaz.

Entre outras coisas, esses bots parecem não se importar se estão recebendo lixo ou não, e servir lixo para bots ainda consome recursos do servidor. Se vamos queimar quilowatts e aquecer o planeta, gostaríamos que o esforço servisse a um objetivo melhor do que esse.

Mas há uma razão mais profunda pela qual tanto o throttling quanto os tarpits não ajudam: os scraperbots foram escritos com essas defesas em mente. Eles espalham sua atividade HTTP por um conjunto de endereços IP para que nenhum deles atinja o limite de throttling. Em alguns casos, esses endereços vêm claramente da mesma sub-rede; uma certa tranquilidade foi obtida ao tratar toda a Internet como um conjunto de sub-redes de classe C e aplicar um limite de throttling a cada uma delas. Alguns operadores podem ser desacelerados a um ritmo razoável dessa forma. (Curiosamente, os scrapers quase nunca usam IPv6).

No entanto, cada vez mais, o tráfego dos scrapers não se encaixa nesse padrão. Em vez disso, o tráfego vem de literalmente milhões de endereços IP, onde nenhum endereço específico é responsável por mais de duas ou três visitas ao longo de uma semana. Observando o tráfego no site, é possível perceber facilmente os esforços de scraping que estão buscando uma lista ordenada de URLs em uma sequência óbvia, mas o mesmo endereço IP não aparece duas vezes nessa sequência. Os endereços específicos envolvidos vêm de todo o mundo, sem nenhum padrão evidente.

Em outras palavras, esse scraping está sendo feito por botnets, muito provavelmente compradas em mercados clandestinos e consistindo em máquinas comprometidas. Realmente não há nenhuma outra explicação que se encaixe nos padrões observados. Antigamente, os sistemas comprometidos eram usados para minerar criptomoedas; agora, ao que parece, há mais dinheiro a ser ganho com o scraping repetido das mesmas páginas da web. Quando uma dessas redes de bots enlouquece, o resultado é indistinguível de um ataque distribuído de negação de serviço (DDOS) — é um ataque distribuído de negação de serviço.

Se alguém tiver dúvidas sobre a integridade moral das pessoas que operam esses sistemas, basta observar as técnicas que elas utilizam para que a situação fique bastante clara.


Isso leva à última sugestão que se ouve com frequência: usar uma rede comercial de entrega de conteúdo (CDN). Essas redes estão trabalhando para adicionar proteções contra scraperbots às proteções DDOS que já possuem. Pode chegar a esse ponto, mas não é uma solução que favorecemos. Expor nosso tráfego (e nossos leitores) a outro intermediário parece indesejável. Muitas das técnicas que eles utilizam para repelir os scraperbots — como exigir que o usuário e/ou navegador responda a um desafio baseado em JavaScript — vão contra a forma como desejamos que o site funcione.

Portanto, por enquanto, estamos contando com uma combinação de limitação e alguns ajustes na configuração do servidor para eliminar alguns gargalos de desempenho. Esses esforços tiveram o efeito de estabilizar a carga e, por enquanto, eliminar os atrasos que estávamos enfrentando no site. Nada disso impede a atividade em questão, o que é frustrante por vários motivos, mas evita que ela interfira no funcionamento legítimo do site.

Parece certo, porém, que essa situação só vai piorar com o tempo. Todos querem seu próprio modelo especial, e os governos não demonstram interesse em impedi-los de forma alguma. É um problema em toda a rede e está se tornando cada vez mais insustentável. O LWN nasceu na época em que a liberdade de colocar um site na Internet era uma alegria. Essa liberdade foi reprimida de várias maneiras desde então, mas ainda existe em grande parte.

No entanto, se chegarmos a um ponto em que a única maneira de operar um site de qualquer complexidade for escondê-lo atrás de um dos poucos grandes provedores de CDN (cada um dos quais provavelmente tem suas próprias iniciativas de IA), a rede se tornará um lugar realmente triste. Os humanos terão sido expulsos (é verdade que alguns podem ver isso como algo positivo) e tudo o que restará serão sistemas de IA copiando páginas uns dos outros de forma incestuosa.

#ia #bots #scrapers

lwn.net/Articles/1008897/

Fighting the AI scraperbot scourge

There are many challenges involved with running a web site like LWN. Some of them, such as fin [...]

LWN.net
@leyrer then I'd rather recommend to firewall judiciously like @SunTzuCyber advises and literally blocklist all #ASN|s that run "#AI" or #Scrapers and any IP that violates limits re: connections...