Quem o Anubis realmente impede?

 (fzakaria.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Anubis, que exige prova de trabalho (Proof-of-Work) antes do acesso HTTP, impõe um custo contínuo maior a usuários comuns, dispositivos de baixo desempenho e clientes sem suporte a JavaScript do que a scrapers de IA
  • O anubis-fetch, criado por um LLM, resolve diretamente a prova de trabalho e, se necessário, executa o Chromium, além de imitar a impressão digital TLS/JA3 do Chrome para passar até pelo bloqueio manual da Cloudflare
  • Scrapers podem armazenar em cache e reutilizar cookies emitidos, amortizando o custo ao longo de várias requisições, enquanto pessoas precisam arcar com segundos de espera e consumo de bateria a cada visita
  • A dificuldade padrão 4 exige, em média, 65.536 hashes; uma implementação nativa em Go leva cerca de 1,3 ms, e JavaScript no navegador cerca de 130 ms, mas o tempo percebido real de espera fica em torno de 1 a 5 segundos
  • Assumindo 2 segundos de tempo percebido e 20 J de energia por tentativa, 1 milhão de desafios por dia consomem, por ano, cerca de 23 pessoa-anos·2 MWh, e 100 milhões por dia, cerca de 2.300 pessoa-anos·200 MWh

O Anubis contornado pela IA

  • Enquanto trabalhava em um patch para dar suporte a $ORIGIN em PT_INTERP do interpretador via bpf do binfmt_misc no kernel Linux, o autor pediu a um LLM que lesse uma thread da lista de e-mails do kernel Linux
  • O lore.kernel.org havia adotado o Anubis, um proxy HTTP que exige prova de trabalho antes de acessar recursos
  • O LLM criou o anubis-fetch para lidar com essa restrição
    • Primeiro resolve a prova de trabalho de forma nativa e, se falhar, visita a URL com o Chromium
    • Imita a impressão digital TLS/JA3 do Chrome real com req, passando também pelo bloqueio manual da Cloudflare
    • anubis-fetch <URL> envia o HTML para a saída padrão, e a opção --text imprime texto simples em formato legível
  • IAs e bots, que são o alvo do Anubis, conseguem contorná-lo facilmente depois de adicionar suporte à prova de trabalho uma única vez
    • Scrapers resolvem o desafio e então armazenam em cache e reutilizam o cookie recebido, amortizando o custo ao longo de várias requisições
    • Já pessoas precisam esperar o spinner e gastar bateria a cada visita, sem poder dividir esse custo com outros usuários
    • Quanto mais limitado o dispositivo ou o smartphone, maior o ônus; w3m, lynx, leitores de tela e leitores RSS sem JavaScript não conseguem acessar
  • Um mecanismo criado para barrar IA acaba sendo facilmente contornado por ela, enquanto continua impondo custos a pessoas e à web aberta, funcionando como um ônus regressivo

Os custos de tempo e energia criados pela prova de trabalho

  • A dificuldade d é o número de caracteres hexadecimais zero à esquerda que o hash deve ter, e o trabalho esperado por solução é W = 16^d hashes
    • A dificuldade 4, um padrão comum, exige 65.536 hashes
      • Implementação nativa em Go a cerca de 50 MH/s: cerca de 1,3 ms
      • JavaScript no navegador a cerca de 0,5 MH/s: cerca de 130 ms
      • Tempo percebido, incluindo carregamento da página, execução de workers e recarregamento: cerca de 1 a 5 segundos
    • A dificuldade 5 exige 1.048.576 hashes
      • Implementação nativa em Go: cerca de 20 ms
      • JavaScript no navegador: cerca de 2 segundos
      • Tempo percebido: cerca de 5 a 15 segundos
  • Assumindo C como o número diário global de desafios Anubis resolvidos, t = 2 segundos como o tempo percebido por tentativa e E = 20 J como a energia do dispositivo, incluindo tela e CPU
    • O tempo humano anual é calculado como C × t × 365 / 3,15×10⁷
    • A energia anual é calculada como C × E × 365 / 3,6×10⁶ kWh
  • Com essas premissas, o custo anual é o seguinte
    • 1 milhão por dia: cerca de 23 pessoa-anos, cerca de 2 MWh
    • 10 milhões por dia: cerca de 230 pessoa-anos, cerca de 20 MWh
    • 100 milhões por dia: cerca de 2.300 pessoa-anos, cerca de 200 MWh
  • Todos os números são estimativas aproximadas; como fazendas de bots e ferramentas de IA usam ordens de grandeza mais energia, este cálculo não pretende sustentar um argumento ambiental
  • Para robôs, tempo não é uma restrição, mas o tempo das pessoas é finito; por isso, usuários acabam gastando coletivamente uma quantidade considerável de tempo esperando para acessar sites, algo que não existia antes da era da IA

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários no Lobste.rs

  • É difícil concordar com a afirmação de que os alvos do Anubis conseguem neutralizá-lo facilmente. O principal objetivo do Anubis não é bloquear agentes de LLM nem programas criados por vibe coding, mas sim impedir os web scrapers indiscriminados usados por empresas de LLM.
    Existem formas de contornar, e também dá para usar agentes ou LLMs, mas a maioria dos scrapers é simples, e seus operadores não se dão ao trabalho de contornar um pequeno número de sites que adotaram o Anubis. O objetivo é mais aumentar ligeiramente o custo de evasão para que a coleta deixe de valer a pena.

    • O Anubis deve funcionar bem para impedir situações em que scrapers usando proxies residenciais derrubam o servidor. As requisições de agentes individuais não são muito diferentes de um usuário navegando diretamente pelo site.
      Mas, para esse objetivo, o Anubis foi projetado de forma excessiva. Seria possível obter o mesmo efeito de proteção fazendo o usuário clicar uma vez em um botão e emitindo um cookie de acesso; implementei isso no Apache e funciona suficientemente bem sem prova de trabalho complexa.
    • O alvo não são tanto os scrapers de empresas de LLM, mas web scrapers malfeitos e abusivos em geral. Há apenas a suposição de que alguns deles sejam operados por empresas de LLM.
    • O aumento de tráfego nos sites não vem de lugares como OpenAI, Anthropic ou Meta, mas de outros atores, então não está claro o que se define como empresa de LLM.
      As ferramentas modernas de scraping que também uso em trabalhos de mineração de dados são boas o bastante para contornar quase todos os obstáculos, e o Anubis também pode ser contornado com facilidade.
    • Como também quero bloquear acesso via RAG a sites pessoais e software, apliquei um bloqueio básico por user agent. Testei pedindo ao ChatGPT para acessar diretamente o site, e ele foi bloqueado corretamente.
      Configurações muito específicas podem escapar, mas o objetivo é bloquear adversários preguiçosos, não mal-intencionados.
    • O que o Anubis bloqueia principalmente são scrapers rudimentares em Python requests que se disfarçam mal como Chrome; qualquer outro efeito de bloqueio é quase um bônus.

  • O Anubis não filtra bots; ele limita a velocidade das requisições do cliente.

  • O Anubis está mais para uma medida de defesa contra ataques de negação de serviço do que para algo que bloqueie o acesso de agentes de IA, e, na prática, também é difícil identificar e bloquear agentes de IA.
    Mas ele também bloqueia usuários como eu, que visitam sites desconhecidos em dispositivos móveis com JavaScript desativado.

  • Olhando para resultados reais em produção, é difícil concordar com a conclusão do texto. Eu servia o site do meu homelab por meio de um proxy público da fly.io e encaminhamento via Tailscale, e scrapers, inclusive do Facebook, geravam cerca de 20 dólares de custo mensal de banda.
    Depois de aplicar o Anubis ao proxy, voltei para a faixa gratuita. Tudo bem se ele puder ser contornado quando necessário; basta bloquear a maior parte do tráfego de coleta em massa de alguns poucos atores maliciosos que ignoram o robots.txt.

  • Em operações de scraping que usam botnets de dispositivos de baixo desempenho, como smart TVs, a prova de trabalho do Anubis parece poder se tornar um obstáculo real. Esse problema também é abordado um pouco em https://lobste.rs/s/kpaxih/update_on_scraper_situation

    • Se eu não estiver enganado, as smart TVs são usadas apenas como proxies e não executam a prova de trabalho em si.

  • O que mais me incomoda no Anubis é o conflito com a web aberta. Meu site é consumido principalmente via feeds RSS; se eu proteger o RSS com Anubis, o feed não funciona, e, se não proteger, todo o conteúdo fica exposto aos scrapers em um formato fácil de ler por máquinas.
    Esse tipo de barreira de prova de trabalho é fundamentalmente difícil de conciliar com a web aberta ou a IndieWeb que buscávamos.

    • No último ano, fiquei preso entre esses compromissos impossíveis, e eu também não encontrei uma boa resposta.

  • Há uma atitude claramente visível de não respeitar as escolhas feitas por outras pessoas.

  • O mais desagradável é que isso parece ser uma conduta que viola claramente leis como a CFAA, mas, ainda assim, esconde a identidade como outros serviços criminosos de DDoS.
    É risível esperar que uma empresa cujo modelo de negócios inteiro depende de roubar o trabalho dos outros e lavar código open source cumpra a lei.

  • O Anubis normalmente não bloqueia o Dillo, mas pode bloqueá-lo dependendo da configuração do site, o que é muito irritante porque incentiva a ideia de que sem JavaScript você nem merece existir: https://paste.rs/jNgwd.png
    Estou pensando se seria possível coletar e manter uma lista de todos os IPs incluídos em proxies residenciais e bloqueá-los por um certo período; talvez o ipset aguente essa escala. Pelos logs, os bots não carregam outros recursos, como CSS ou imagens, mas percorrem todos os arquivos de todos os commits do repositório do Dillo, então são relativamente fáceis de identificar.
    Em cada site, mesmo que apareça apenas uma requisição por IP, é provável que o mesmo IP acesse vários sites, então IPs denunciados várias vezes poderiam ser bloqueados. Em vez de simplesmente derrubar a conexão, seria preciso redirecionar para uma página informativa em uma porta separada, explicando o motivo do bloqueio e como resolvê-lo.
    Isso também reduziria o incentivo para embutir backdoors de proxy reverso em extensões de navegador ou apps de celular, porque os usuários começariam de fato a ser bloqueados.
    É lamentável ter que depender de um sistema de reputação de IP, mas não vejo muitas outras respostas eficazes. Dispositivos vulneráveis, mesmo depois que o servidor de comando e controle da botnet é removido, podem ser comprometidos novamente pelo próximo atacante e incorporados a uma nova botnet.

  • No texto, a pessoa diz: “claro que estou fazendo isso com a ajuda de uma LLM”; então fico curioso para saber por que não recebeu a tag de vibe coding.

    • Pelo mesmo motivo que a pessoa autora não colocaria essa tag só por ter usado um compilador ou editor: o tema do texto não é vibe coding. A tag vibecoding foi removida por pushcx.
    • Quando publiquei, o texto dizia explicitamente que algo para contornar o bloqueio tinha sido feito com vibe coding, então adicionei a tag. Já vi a tag ser aplicada a textos que mencionavam menos programação com IA do que este, então achei surpreendente que ela tenha sido removida, mas acabei aceitando que os critérios de aplicação dessa tag são totalmente inconsistentes.