- O tráfego de scrapers de IA está abalando os custos e a estabilidade de wikis públicos e, sem mitigação, pode consumir cerca de 10 vezes mais recursos de computação do que toda a atividade humana somada
- Os bots vão além de User Agents identificáveis como GPTBot e passam a disfarçar cabeçalhos como se fossem o Chrome mais recente, contornando bloqueios com proxies residenciais que giram 1 milhão de IPs por dia
- Wikis expõem muito mais URLs de revisões antigas, telas de edição e páginas especiais do que de artigos, fazendo com que rastreamento ingênuo contorne o cache e possa sair de 50 a 100 vezes mais caro que requisições normais
- Cloudflare Challenge, Anubis, regras manuais de firewall e detecção baseada em requisições de comportamento humano funcionam, mas também geram falsos positivos, custo de manutenção e atrito com leitores
- Bloqueios extremos, como exigir login ou aplicar challenge a tudo, podem reduzir novas contribuições; por isso, são necessárias discussões públicas entre operadores e abordagens via API que mudem os incentivos de coleta dos bots
O peso que scrapers de IA impõem à operação de wikis
- O scraping por bots para dados de treino de LLMs cresceu em uma escala sem precedentes, abalando os custos e a estabilidade de sites públicos: o tema também aparece em FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline? e Smart TV web crawler AI
- A Weird Gloop hospeda grandes wikis de jogos como Minecraft Wiki, OSRS Wiki e League Wiki, e nos últimos 3 anos vem gastando cada vez mais tempo com a resposta ao tráfego de bots
- Sem mitigação contínua, os bots podem consumir cerca de 10 vezes mais recursos de computação do que todo o restante combinado, incluindo dezenas de milhões de pageviews humanos e dezenas de milhares de edições por dia
- A Wikimedia Foundation também publicou um texto sobre o impacto de crawlers na operação, grandes fazendas de wikis sofreram interrupções em vários níveis e alguns pequenos wikis independentes ficaram completamente offline
- Estima-se que cerca de 95% dos problemas de servidor no ecossistema de wikis neste ano tenham sido causados por scrapers maliciosos
Scrapers tentando parecer pessoas
- Os bots “oficiais” das principais empresas de IA, como GPTBot, ClaudeBot e PerplexityBot, às vezes já falharam em respeitar
robots.txt, mas em geral podem ser identificados pela string de User Agent e bloqueados facilmente com bloqueio de bots de IA da Cloudflare ou nginx - À medida que webmasters começaram a bloquear scrapers de IA com base em User Agent, os bots passaram a ter um forte incentivo para se disfarçar de tráfego humano
- Hoje, a maior parte do tráfego de scrapers de IA que chega aos wikis envia cabeçalhos montados para parecer o Google Chrome mais recente
- Os sinais claros de “bot ou pessoa real” que existiam antes praticamente desapareceram, tornando o bloqueio bem mais difícil
Dezenas de milhões de IPs e evasão com proxy
- Antes de 2023, cerca de 95% do scraping problemático vinha de um único endereço IP ou de uma pequena sub-rede de datacenter, então bloqueios por IP ou características do ISP costumavam funcionar bem
- Com proxies residenciais, é possível “lavar” requisições de scraping por redes com milhões de endereços IP usando apenas um cartão de crédito
- Wikis às vezes enfrentam operações de scraping que giram 1 milhão de IPs por dia, parecendo requisições legítimas vindas de ISPs residenciais como Comcast, AT&T e Charter
- É bastante provável que esses clientes nem saibam que seus IPs estão sendo usados como nós de saída de um proxy residencial
- Alguns agentes maliciosos também usam pré-visualizações de links do facebookexternalhit ou o Google Translate para fazer parecer que as requisições vieram de servidores do Google ou do Facebook, ocultando a origem real
- Em alguns casos, 99,99% das requisições que entram pela ferramenta de URL do Google Translate são abusivas, a ponto de ter sido necessário quebrar essa ferramenta em todos os wikis por um período
Rastreamento de “URLs burras” que é especialmente caro para wikis
- Muitos scrapers de IA escolhem URLs visitando a página inicial do wiki, depois todos os links dessa página, depois todos os links dessas páginas, e assim por diante
- Eles parecem não reconhecer que
robots.txte sitemaps já indicam quais URLs valem a pena ser raspadas - O OSRS Wiki tem cerca de 40 mil artigos, e essas URLs contêm a maior parte das informações úteis do site
- Mas, ao incluir revisões antigas, telas de edição e páginas especiais, o número de URLs navegáveis passa de pelo menos 1 bilhão
- Esse tipo de crawling ingênuo nunca termina e parece desperdiçar muitos recursos em URLs que não têm utilidade para dados de treino de LLM
- Requisições estranhas aumentam o custo do serviço ao contornar camadas de cache como o MediaWiki parser cache, usadas por usuários reais
- Requisições com cache hit normalmente levam menos de 20 ms, mas pedidos como diffs antigos frequentemente levam 1 a 2 segundos
- Métricas de topo como “8 milhões de requisições de bots por dia” ou “bots usam 65% da banda” subestimam o problema
- O gargalo real costuma ser CPU, e requisições de bots com parâmetros de query estranhos frequentemente custam 50 a 100 vezes mais do que requisições normais
Picos de tráfego que não aparecem nas médias
- O volume mensal de requisições de bots fica em cerca de 250 milhões, média aproximada de 100 por segundo, mas isso é apenas uma média de longo prazo
- Scrapers frequentemente enviam mais de 1.000 requisições por segundo por curtos períodos, de forma quase indistinguível de um ataque DDoS tradicional
- Mesmo que, no longo prazo, os bots representem apenas cerca de 50% do uso total de CPU, os picos de tráfego malicioso causam cerca de 95% das lentidões e interrupções dos wikis
Uma estrutura em que é difícil saber quem está fazendo isso
- O tráfego é chamado de “scrapers de IA”, mas como todos se disfarçam de Google Chrome, é difícil saber quem realmente é responsável ou para que os dados dos wikis estão sendo usados
- Entre os possíveis agentes estão corretores de dados, coleta redundante por frontier labs e projetos independentes com acesso a proxies residenciais
- Também não está claro o quão baixa realmente ficou a barreira de entrada
- Se existisse uma forma melhor, a ideia seria falar diretamente com quem faz a coleta para encontrar métodos menos ineficientes
O que tem funcionado até agora
-
Cloudflare Challenge e Anubis
- Colocar sites atrás de Cloudflare Challenge ou de ferramentas como Anubis se tornou comum na internet no último ano
- Funciona até certo ponto, mas há períodos em que alguns bots passam consistentemente pelo challenge
- Parece haver uma corrida armamentista invisível entre a Cloudflare e os desenvolvedores de bots: a Cloudflare vence cerca de 90% das vezes, mas os 10% restantes ainda criam dor operacional
- Leitores reais não gostam de ver um challenge antes de chegar ao wiki
- Para evitar afetar a maioria das pessoas, são necessárias boas regras heurísticas para decidir quais tráfegos devem receber challenge, mas detectar tráfego automatizado de forma confiável já é, por si só, difícil
-
Regras manuais de firewall
- A maioria dos operadores mantém regras manuais de firewall ajustadas à própria infraestrutura e ao histórico de ataques
- Esses filtros normalmente se baseiam em strings específicas de User Agent, grupos de IP ou ASNs
- A Weird Gloop trata a maior parte disso no nível da Cloudflare/CDN, enquanto outros wikis fazem isso no nginx ou no próprio servidor web
- Hoje, User Agent e IP sozinhos muitas vezes não bastam; é preciso olhar atributos mais complexos da requisição, como versão HTTP, cabeçalhos, TLS cipher e hashes relacionados a ja4
-
Procurar “coisas que humanos fazem e bots não”
- Uma abordagem útil é encontrar comportamentos que humanos, coletivamente, têm e bots não
- Wikis baseados em MediaWiki geram vários tipos de requisições HTTP que usuários reais de navegador costumam fazer ao usar o site, e bots normalmente não fazem isso
- Se um grupo de tráfego separável por cabeçalhos, hash ja4 etc. visita muitos artigos sem gerar as requisições típicas de “humano”, isso se torna um forte sinal para aplicar challenge
- Observar a ausência de requisições de comportamento humano no tráfego de bots é poderoso
- Começaram a criar um sistema que analisa esse tráfego “ausente” e sugere automaticamente heurísticas baseadas em árvore de decisão para decidir onde aplicar challenge
- Nos testes, isso pareceu encontrar quase todos os scrapers, mas ainda não está claro que falsos positivos surgiriam para usuários de NoScript, leitores de tela ou pessoas com hábitos de navegação incomuns
- Continuar construindo e mantendo uma infraestrutura própria de ML/análise de dados também segue sendo um peso
-
Técnicas de detecção mais exóticas
- Houve casos de sucesso na identificação de proxies residenciais por inconsistências de timing TCP/TLS
- Também existem empresas que vendem bancos de dados em tempo real de IPs de proxies residenciais
- Mas, como a maioria dos proxies residenciais também é usada simultaneamente por pessoas reais, não está claro o quanto isso pode virar um sinal prático de bloqueio
- Para atores como Cloudflare ou grandes provedores de nuvem, que têm informações de rede em nível de pacote sobre volumes enormes de tráfego, parece plausível criar boas heurísticas em larga escala
- Ainda assim, não foi encontrado nenhum operador realmente impressionado com heurísticas de produtos comerciais, inclusive soluções de detecção de bots com custo anual na casa de seis dígitos
Opções extremas que prejudicam o leitor
- A “opção nuclear” para bloquear scrapers de IA é muito mais destrutiva para usuários reais
- Uma abordagem comum é exigir login para visualizar páginas cujo custo de geração pode ser alto
- A Fandom aplicou essa medida em todos os wikis há alguns meses
- Outra opção é aplicar Cloudflare Challenge a todo o tráfego
- Do ponto de vista do webmaster, isso é compreensível, mas faz mal à saúde de longo prazo do wiki e da comunidade
- Uma lição central aprendida em 16 anos de construção de comunidades de wiki é que a melhor forma de atrair novos contribuidores é remover atrito
- É preciso facilitar a edição, facilitar a navegação pela estrutura interna do wiki e reduzir a barreira de entrada entre leitores e editores
- Técnicas antibot extremas criam novo atrito e levam a resultados previsíveis
- Depois que a Fandom ocultou “páginas internas” de mais de 95% dos leitores sem conta, as novas contribuições de usuários na plataforma como um todo teriam caído cerca de 40%
- É difícil considerar esse trade-off aceitável
Para onde isso vai
- A Weird Gloop continua hospedando wikis e também segue ajudando wikis a sair da Fandom
- No longo prazo, “AI Overviews” podem matar o funil que transforma leitores de wiki em contribuidores, mas isso fica como um problema separado
- Algumas pessoas próximas acham que a onda de bots pode até beneficiar a Weird Gloop, mas, se hospedar wikis deixar de ser algo fácil, a internet vai piorar
- Um cenário em que hospedar wikis com confiabilidade exija rotação de plantão, engenheiros de ML e produtos enterprise seria péssimo para comunidades independentes de wiki
- A corrida armamentista entre donos de bots e webmasters provavelmente vai continuar até surgir alguma forma inteligente de mudar os incentivos estruturais do scraping
- A nova crawling API da Cloudflare pode mudar esse cenário se for mais fácil para bots usarem a API do que construir seus próprios sistemas que ignoram
robots.txte causam problemas - Seria melhor se o scraping simplesmente não acontecesse, mas é difícil desfazer o que já começou
Necessidade de discussão pública e cooperação
- Milhares de operadores mantêm seus próprios sites e tentam encontrar técnicas mais inteligentes para responder aos bots
- Em conversas privadas com outros administradores de sistemas, surgiram ideias concretas e boas, e provavelmente há muita discussão semelhante acontecendo em Slack, Discord e pequenos grupos
- É preciso haver mais discussão pública sobre os detalhes operacionais reais
- Muitos administradores de sistemas não percebem o suficiente que o problema que enfrentam é quase idêntico ao de outros operadores
- Nem todo mundo quer tornar público seu método de defesa, por medo de perder vantagem ao revelá-lo
- Ainda assim, se isso ajudar as pessoas a pensar juntas, vale correr o risco de reduzir a eficácia de parte das táticas
- Administradores de sistemas que lidam com scrapers de IA fariam bem em compartilhar, em espaços adequados, o que funcionou para eles
- Empresas que vendem produtos para resolver o problema de bots deveriam publicar mais estudos de caso com dados reais sobre taxas de precision and recall em situações não artificiais
- Quem toma decisões de compra se importa com resultados reais, não em marcar checkboxes
- Se você opera um wiki ou site independente e quer discutir detecção de bots, pode entrar em contato por email ou mensagem no Discord
2 comentários
Basicamente, o GeekNews também recebe uma quantidade enorme de crawlers, então estamos adotando vários métodos para bloqueá-los e também otimizar os custos. Os bots de IA da China realmente fazem crawling de forma extremamente agressiva.
Mas o problema é que, para bloqueá-los do lado do CDN, isso também gera custos.
Comentários no Lobste.rs
Tentei usar um desafio de prova de espera (proof-of-wait) para compensar as desvantagens do Anubis, e funcionou bem
Basicamente, se a taxa global de requisições ficar abaixo de um limite, o filtro é desativado; se passar do limite, o usuário precisa esperar N segundos antes de continuar
Depois disso, é emitido um token vinculado àquele IP, permitindo apenas uma pequena quantidade de requisições dentro do tempo de expiração, e o próprio token também tem limitação de taxa
Se continuarem chegando requisições bem-sucedidas, o tempo de espera vai aumentando gradualmente
Foi bastante bem-sucedido, degrada de forma suave para não prejudicar demais dispositivos móveis e funciona até sem JavaScript
Parece o tipo de coisa que deveria estar numa camada mais baixa, como no TLS ou até na pilha de IP do sistema operacional
Nunca pensei muito a fundo em prova de espera, mas isso não acaba sendo muito pior para usuários legítimos do que para scrapers automáticos? Pessoas se irritam com espera, enquanto o scraper pode guardar o token e voltar depois de N segundos
Também tenho sentimentos mistos sobre prova de trabalho, mas pelo menos ela impõe aos scrapers um custo real proporcional à escala
Prova de espera talvez também tranquilize quem tem preocupações com prova de trabalho
Também funciona bem restringir certas páginas especiais para que só clientes que tenham feito login uma vez e estejam com o cookie definido possam acessá-las; caso contrário, o acesso é negado
A maioria dos crawlers mira páginas especiais para vasculhar o wiki, então dá para limitá-las a usuários logados
Nessa configuração, o wiki não permite criação de usuários
<If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
ErrorDocument 403 "Access denied, please login."
Require all denied
</If>
Isso reduziu bastante a carga no nosso sistema. Antes, havia picos frequentes em que o wiki ficava praticamente inutilizável por causa do rastreamento pesado dessas páginas especiais
Fora isso, bloqueamos imediatamente com 403 user-agents conhecidos de crawlers de IA e também bloqueamos certos intervalos de IP, como Alibaba e Amazon Cloud
Curiosamente, eles perceberam isso. Estavam vasculhando páginas pela visualização de diff e, quando limitamos isso, passaram a tentar a mesma coisa pela visualização MobileDiff
Houve alguma troca de golpes, mas há alguns meses isso vem funcionando sem problemas
Se você bloquear por user-agent, o crawler vai tentar de novo com um user-agent que pareça humano e explorar o site
Se ele concluir que o gatilho do bloqueio foi o user-agent, entra em modo infernal, fica muito mais difícil de identificar e martela o site até a morte
Bloquear intervalos de IP também ajuda, mas não basta nem pega todos os casos, porque eles rastreiam usando proxies de malware em dispositivos móveis
Se você não bloquear de início, em geral eles ficam relativamente comportados
Então o truque é, em vez de bloquear, servir dados lixo baratos de gerar sem acionar o modo infernal, e eu uso https://iocaine.madhouse-project.org/ para isso
Só que, nesse caso, o MediaWiki precisa servir a resposta diretamente, então também há vantagem em deixar isso no Apache
Como observação lateral, o Weird Gloop é um ótimo serviço. A qualidade dos wikis que eles operam é muito alta, e mover conteúdo feito por fãs para fora da plataforma horrível da Fandom faz bem ao mundo
Gergely Nagy, a.k.a. algernon, também desenvolvedor do iocaine, vem lidando com esse problema há algum tempo e provavelmente tem insights úteis para a Weird Gloop
Odeio dizer isso, mas a proposta de ajustar com base no comportamento humano parece algo que vai sair pela culatra no futuro
Os bots vão começar a requisitar também todos os assets estáticos da página, presumindo que isso faça parte do comportamento que identifica humanos
Jogo interessante, Professor Falken
Se o scraper chega a essas páginas seguindo recursivamente links normais
<a href=...>, imagino se não daria para direcioná-lo suavemente para outro lugar tornando páginas caras e sem cache, como diferenças de histórico, acessíveis apenas por envio de<form method="POST" action=...>Isso não bloquearia nada e, na prática, também seria benéfico para o scraper, já que o impediria de consumir recursivamente uma quantidade quase infinita de informação redundante
Usuários normais talvez quase não percebessem a diferença, e o custo-benefício do esforço parece bom. Para usuários anônimos, isso pode ser melhor que o Anubis
Isso depende da suposição de que scrapers não enviam formulários HTTP com
method="POST"Se isso não fosse geralmente verdade, acho que já teríamos visto manchetes sobre scrapers de IA submetendo edições anônimas em massa e transformando o conteúdo da Wikipedia em lixo aleatório
Fico curioso se bots clicariam em
<form method="GET">; isso combinaria melhor com cache e ainda poderia exigir lógica extra dos crawlers95% do tráfego do meu pequeno blog vem de scrapers de LLM de Singapore e China
Já se passaram anos e ninguém conseguiu investigar os IPs até achar algum de um pequeno ISP com quem fosse possível entrar em contato e ir pessoalmente falar? Ninguém foi até esse usuário perguntar educadamente se poderia dar uma olhada no computador dele? Ninguém conseguiu descobrir qual software está fazendo o crawling na prática?
Se operadores de sites nem conseguem fazer isso, eu nem quero mais me importar. É justamente por tentarem tanto evitar esse tipo de contato humano direto e confuso que acabam recebendo bots
E bots rodando em botnets residenciais naturalmente às vezes têm recursos computacionais suficientes para passar por CAPTCHA ou Anubis
Não é possível vencer de forma permanente no lado do servidor. O usuário daquele computador também gera tráfego legítimo
Então, a menos que você queira atestado remoto, tem que ir atrás desses IPs
Mesmo deixando de lado problemas práticos como o custo de combustível para sair dirigindo pelo mundo, isso vira um enorme problema do caixeiro-viajante
A ideia de que alguns bots significam que administradores de sistema deveriam passar o fim de semana dirigindo para qualquer lugar só para pedir educadamente que eles se comportem melhor é risível, especialmente considerando que a maioria vem de grandes ISPs ou de ISPs estrangeiros
Dá vontade de perguntar o que você andou fumando
E qual software está fazendo crawling hoje em dia? Alguém manda um chatbot “faça algo para raspar isso”, e cada scraper acaba sendo criado individualmente
Caso contrário, é só culpar abstratamente o universo inteiro
Posso garantir que a maioria dos provedores não está nem um pouco preocupada com o fato de seus IPs estarem sendo usados para raspar algum site
E também garanto que esses provedores não vão revelar o endereço associado a um IP
O que funciona muito melhor é descartar de uma vez o tráfego de ASN associado a vários provedores, como Alibaba e AWS
Nem sempre é uma opção viável. Por exemplo, se for um blog com feed Atom, você pode acabar bloqueando leitores de feed junto
Mas, em muitos casos, isso elimina 80% do tráfego lixo
Alguém sabe por que esse comportamento acontece? Em especial, queria entender por que surgem os picos
Não sei se é verdade, mas pelo menos parece plausível
Sem entender melhor a infraestrutura, é difícil afirmar. Também pode ser limitação de comando e controle
Se a botnet foi construída para DDoS, pode ser que, pela própria arquitetura, ela não tenha controle fino suficiente sobre isso