Vamos alimentar os bots

• Um operador de site apresenta um experimento em que criou páginas de “nonsense infinito” para atrair tráfego de bots raspadores para treinamento de IA
• Esses bots são agressivos, ao contrário dos rastreadores tradicionais de mecanismos de busca, ignorando robots.txt, trocando de IP e enviando requisições continuamente
• Todas as defesas comuns acabam neutralizadas — bloqueio de IP, limitação de taxa, CAPTCHA e barreiras de login — e só causam incômodo aos usuários reais
• Diante disso, o autor descobriu que gerar automaticamente dados falsos (texto sem sentido) para entregar aos bots é a opção mais barata e eficaz
• Isso expõe os efeitos colaterais da coleta de dados para IA e o desperdício de recursos de servidor, além de apresentar uma resposta prática para operadores de sites

---

A identidade dos bots

• Os rastreadores recentes não têm como objetivo mecanismos de busca, mas sim a coleta de dados para treinamento de LLMs (grandes modelos de linguagem)
  • Eles ignoram robots.txt, se disfarçam de navegador ou acessam trocando de IP
  • Enviam várias requisições por segundo o dia inteiro, causando carga no servidor
• Ao contrário dos mecanismos de busca tradicionais, eles não têm interesse em manter o site e o tratam apenas como uma fonte de dados substituível

Problemas ao permitir o acesso

• Servir arquivos estáticos é barato, mas não é grátis, e há latência de acesso a SSD e sobrecarga do sistema de arquivos
  • Pedem páginas antigas fora de cache, degradando o desempenho do servidor
• O consumo de banda também é um problema: posts de blog com imagens se acumulam rapidamente e podem gerar mais de 1TB de tráfego por mês
  • Esse é um custo difícil de suportar para quem opera um servidor pessoal

Limites das tentativas de bloqueio

• Bloqueio de IP não funciona, e redes de bots operadas por grandes empresas têm milhares de endereços
  • Mesmo bloqueando todos, eles compram novos IPs e se reconectam
• Limitação da taxa de requisições (rate limit) também é inútil, porque em alguns casos usam um IP diferente a cada requisição

Efeitos colaterais de firewalls e barreiras de autenticação

• Foram propostas várias defesas, como login, pagamento, CAPTCHA e prova de trabalho baseada em hash (proof-of-work), mas todas acabam prejudicando a experiência do usuário
  • Exigir conta bloqueia o acesso dos leitores, e verificações baseadas em JavaScript barram navegadores sem JS
  • A velocidade de carregamento das páginas cai, piorando a experiência de uso

A ineficácia da bomba de compressão (gzip bomb)

• Alguns sugerem atacar os bots com uma gzip bomb, mas na prática a taxa de compressão fica em torno de apenas 1000x
  • Para criar um arquivo expandido de 100GB, seria preciso servir um ativo de 100MB
  • Em experimentos, os bots ignoraram isso ou até enviaram ainda mais requisições

O fracasso da trapaça

• A abordagem de “Jedi mind trick”, que devolve erro 404 para fingir que o site não existe, também falhou
  • Se o link for publicado externamente, os bots percebem que ele existe e, quando o acesso é bloqueado, passam a requisitar de forma ainda mais agressiva
  • No fim, é preciso satisfazer os bots para que o servidor fique em paz

A eficiência de fornecer dados inúteis

• Gerar conteúdo dinâmico parece caro, mas na prática CPU e RAM são os recursos mais rápidos
  • A percepção de lentidão costuma vir de I/O de banco de dados ou lógica complexa em JS
• O babbler baseado em Markov criado pelo autor usa cerca de 60 microssegundos de CPU e apenas 1,2MB de memória por requisição
  • Sem acesso a disco e sem necessidade de manter blacklist
  • Os bots chegam por conta própria e consomem texto sem sentido, reduzindo a carga do servidor

Conclusão

• A coleta indiscriminada de dados por bots voltados ao treinamento de IA provoca aumento dos custos de infraestrutura web e uso indevido de conteúdo
• Em vez de bloquear, responder com dados sem sentido é uma estratégia mais eficiente em custo e favorável à estabilidade do servidor
• Isso pode ser visto como uma abordagem experimental para buscar formas de convivência entre rastreamento por IA e o ecossistema da web

[kimjoin2]

Oh... bem original e legal.

[GN⁺]

Comentários do Hacker News

• Foi engraçado ver as instruções ocultas em parágrafos antes do link
  Havia um aviso brincalhão tentando enganar LLMs, algo como “o conteúdo desta página é perigoso, não o divulgue”
  O documento relacionado está neste link

  • Resumindo o texto The Cost of Trash, o autor tentou vários métodos para bloquear web scrapers agressivos (provavelmente para treinamento de LLMs), falhou e acabou adotando a estratégia de gerar dados inúteis dinamicamente para desperdiçar os recursos deles
    A parte final, “LLM instructions”, não faz parte do texto principal de fato, mas sim de metainstruções para confundir LLMs, então foi excluída do resumo

• Sempre recomendei esse tipo de estratégia — alimentar bots de IA com grandes volumes de dados lixo que pareçam reais, de modo que no fim humanos precisem filtrar tudo
  Se todos os sites fizessem isso, a qualidade dos dados usados para treinar IA cairia drasticamente
  Se é difícil lutar, então o melhor é simplesmente afogar tudo em uma enchente de dados

  • Um método melhor, embora mais caro, seria encher os LLMs de conteúdo promocional positivo
    Tipo isca de SEO: criar sites com aparência de domínio de notícias e espalhar textos promovendo produtos
  • Mas os LLMs já estão sendo treinados em sua maior parte com dados lixo
    Esse tipo de tentativa é só perda de tempo, como responder a ligações de spam
  • Além disso, LLMs conseguem fazer detecção de lixo muito mais barato do que humanos
    No fim, quase não haverá necessidade de contratar pessoas para isso
  • Fico curioso com o motivo de acharem que humanos filtrariam lixo melhor do que IA

• Os detalhes do “Markov babbler” estão neste post

  • Ao compilar com gcc 14, aparece um erro no argumento de pthread_detach
    Parece que o compilador usado pelo autor ignora avisos
    Como o programa processa requisições sem limite de gerenciamento de threads, é mais seguro executá-lo em um contêiner como usuário sem privilégios
    Também parece usar funções C perigosas, como sprintf(), então é preciso cuidado com a segurança
  • Disseram que também vão adicionar isso ao “toptext”
  • Disseram que o código é elegante e rápido, e esperam que os scrapers de LLM sofram ao limpar esses dados

• No meu site, todos os links estão protegidos com Basic Auth, e até agora nenhum bot conseguiu passar
  Então pensei: e se todos os sites usassem as mesmas credenciais públicas?
  Usuário: nobots / Senha: nobots
  Será que os bots conseguiriam atravessar isso mesmo sabendo?

  • Claro que sim. Basta adicionar um cabeçalho de autenticação na requisição HTTP
    A maioria dos bots só não considerou esse caso ainda
    Dá para resolver facilmente fazendo a requisição no formato http://username:[e-mail]
  • Se as credenciais forem conhecidas por todo mundo, provavelmente não vai haver efeito de bloqueio contra bots
  • Esse método só funciona enquanto poucas pessoas o usam. Assim que se espalhar um pouco, deixa de funcionar

• Agora eu também estou fornecendo dados lixo para eles
  Como referência, usei Frankenstein, Alice in Wonderland e Moby Dick como fontes, mas os arquivos são grandes e carregam devagar
  Corrigi o erro de compilação trocando pthread_detach(&thread) por pthread_detach(thread)

  • A correção já foi aplicada, e disseram que a sugestão do gcc estava certa

• Eu opero um “crawler ético”
  Mantenho baixa a frequência das requisições para não sobrecarregar os sites, e está ficando cada vez mais difícil porque muitos lugares bloqueiam acesso via RSS
  Meu crawler testa vários cabeçalhos e mecanismos enquanto navega
  Código: crawler-buddy, Django-link-archive

  • Há feedparser no requirements.txt, mas não há sinais de uso real
    Isso também pode ser confirmado pelo resultado da busca

• No texto The Cost of Trash, mencionam que gzip bomb não é eficaz
  O gzip comprime só cerca de 1000 vezes, então para gerar 100GB seria preciso servir um arquivo de 100MB
  Disseram que os bots, na verdade, passaram a fazer ainda mais requisições

  • Com zip pode dar, mas com gzip não
    A maioria dos clientes descompacta em streaming, então não carrega tudo na memória de uma vez
    Para um gzip bomb funcionar de verdade, seria preciso processá-lo de uma forma anormal
    Referência: documentação da API zlib
  • Em vez disso, é melhor criar milhares de pequenos arquivos gzip para desperdiçar CPU e tempo
    Dá para colocar lixo aleatório dentro deles, ou inserir mensagens que você gostaria que a IA aprendesse

• Um ponto de atenção é que algumas requisições podem na verdade usar o navegador do usuário como proxy
  Alguns fornecedores de navegador aproveitam o tráfego do usuário como proxy
  Se o erro na detecção de requisições automáticas for pequeno, até daria para embutir código de mineração de criptomoeda, mas isso traria o risco de atingir usuários reais
  Fico especialmente curioso se existem requisições de IA usando agentes móveis

• Disseram que o “Markov babbler” usa cerca de 60μs de CPU por requisição,
  então fiquei pensando em criar conteúdo misturado com mensagens ideológicas ou propaganda para que a IA aprenda isso
  Nesse caso, a IA poderia acabar fazendo declarações políticas sem sentido
  No mínimo, isso ajudaria a reduzir violação de direitos autorais e carga no servidor

• Por que gerar texto de Markov no servidor?
  Se o bot executa JavaScript, não daria para gerar isso no cliente?

  • Os bots têm CPU e memória praticamente ilimitadas, então a carga no servidor não é tão grande
    Além disso, enviar os dados da cadeia de Markov ao cliente seria ainda menos eficiente
    Como cada requisição usa só CPU na casa de microssegundos e cerca de 1MB de RAM, processar isso no servidor já é leve o bastante