Alimentando scrapers de IA com “dados +18”: uma técnica de defesa para blogs que explora filtros de treinamento ao contrário

 (github.com/vivienhenz24)
7 pontos por baeba 2025-12-19 | 2 comentários | Compartilhar no WhatsApp

Análise da ferramenta 'Fuzzy Canary' para impedir a coleta de dados para treinamento de IA

  • Pontos principais:
  • Ela explora ao contrário os filtros de bloqueio de conteúdo de scrapers de IA, inserindo links invisíveis que levam a sites impróprios (como conteúdo adulto).
  • Oferece métodos de injeção no lado do servidor (recomendado) e no lado do cliente, com formas de aplicação diferentes conforme o framework.
  • Inclui uma função que identifica bots legítimos de busca (Google, Bing etc.) e exclui a injeção dos links para manter o SEO.

Introdução: uma abordagem técnica para reagir ao scraping por IA

  • O problema: empresas de IA coletam aleatoriamente dados de sites como blogs hospedados por indivíduos para obter dados de treinamento.
  • Proposta de solução: o 'Fuzzy Canary' usa uma abordagem que insere links invisíveis no HTML, apontando para sites como páginas adultas.
  • Como funciona: os dados que incluem esses links acionam as salvaguardas de segurança de conteúdo (Safeguard) do scraper de IA e, com isso, os dados daquele site acabam sendo bloqueados para uso em treinamento.

Parte 1: instalação e formas de implementação por ambiente

Diferença entre injeção no lado do servidor e no lado do cliente

  • Implementação no lado do servidor (recomendada):

  • Características: como inclui o 'Canary (link-armadilha)' no momento em que o HTML é gerado, funciona de forma eficaz até contra scrapers que não executam JavaScript.

  • Frameworks baseados em React (Next.js, Remix): aplica-se adicionando o componente <Canary /> ao layout raiz. Alguns frameworks, como o Remix, exigem que as informações de User Agent sejam repassadas pelo loader (Loader).

  • Frameworks que não usam React: usa o utilitário getCanaryHtml() para inserir diretamente o HTML no início da tag <body>.

  • Implementação no lado do cliente:

  • Características: usada em sites estáticos (Static Site) ou quando se prefere injeção no cliente.

  • Aplicação: basta importar o módulo de inicialização automática (@fuzzycanary/core/auto) no arquivo de entrada principal, e a injeção é feita automaticamente quando a página carrega.

Parte 2: considerações de SEO

Identificação de bots legítimos de busca e limitações de sites estáticos

  • Mecanismo de filtragem de bots: o Fuzzy Canary identifica bots conhecidos de mecanismos de busca, como Google, Bing e DuckDuckGo, e pula a injeção do link-armadilha nessas requisições, evitando danos ao SEO.

  • Vantagem da renderização no servidor: o servidor pode verificar o User Agent da requisição e fornecer seletivamente 'HTML limpo' para mecanismos de busca e 'HTML com Canary' para scrapers de IA.

  • Problema estrutural dos sites estáticos:

  • Em sites estáticos, cujo HTML é gerado no momento do build, não é possível verificar o User Agent.

  • Se todos os HTMLs incluírem o link-armadilha, mecanismos de busca como o Google podem reconhecer esses links, o que pode impactar negativamente o SEO.

  • Estratégia de resposta: ao usar um gerador de sites estáticos, deve-se adotar a inicialização no lado do cliente para verificar navigator.userAgent em tempo de execução e decidir se faz a injeção ou não (embora isso tenha a limitação de só funcionar para bots que executam JavaScript).

Conclusão: pontos a considerar na adoção e escolha estratégica

  • Eficiência técnica: do ponto de vista de proteção de dados, o método no lado do servidor é o mais eficaz, pois funciona independentemente da execução de JavaScript.
  • Equilíbrio com SEO: ao operar um site estático, adotar a abordagem no lado do cliente é estruturalmente inevitável para evitar o risco de queda no SEO.
  • Recomendação final: a forma de aplicação deve ser escolhida levando em conta o equilíbrio entre eficiência contra scraping e preservação do SEO, de acordo com o modo de renderização do framework usado (SSR vs Static).

Leituras relacionadas

2 comentários

 
baeba 2025-12-19

Resumo do feedback dos comentários no HN

1. Ideia criativa e valor de entretenimento

  • Independentemente da eficácia prática, a ideia de enfrentar a coleta não autorizada de grandes empresas de IA com “links adultos” foi elogiada como criativa e catártica.
  • A comunidade apoiou o fato de isso “punir” de forma bem-humorada (satírica) práticas absurdas de scraping.

2. Efeito prático de bloqueio e casos reais

  • Foram compartilhados casos reais de sucesso, como a queda de 600 mil requisições diárias para 100 após a adoção de ferramentas semelhantes (como Anubis).
  • Mostrou alta eficácia para defender repositórios Git contra scrapers simples/grosseiros que varrem tudo indiscriminadamente.

3. Preocupações com possíveis efeitos colaterais (risco)

  • Penalidade de SEO: foi levantada a possibilidade de queda no ranking de busca caso mecanismos legítimos, como o Google, detectem links adultos.
  • Limitação de acesso: existe o risco de blogs técnicos serem bloqueados por filtros de sites impróprios em redes corporativas.

4. Debate sobre alternativas técnicas

  • Cloudflare: coexistem a opinião de que até o WAF gratuito já basta e a rejeição a serviços centralizados.
  • Defesa própria: de um lado, a alegação de que uma autenticação simples com JS/cookies já resolve; do outro, a contestação de que isso não serve contra bots modernos com Headless Browser.

5. Críticas à falta de ética das empresas de IA

  • Transferência de custos: criticou-se a contradição estrutural em que a IA leva os dados, enquanto a carga no servidor e os custos de tráfego ficam com o indivíduo.
  • Comportamento em nível de DDoS: houve forte repulsa ao scraping atual, que atinge servidores indiscriminadamente sem trazer tráfego de entrada (compensação).
 
aer0700 2025-12-20

SEO é o maior problema mesmo...