1 of 9

Bots problemáticos nos projetos Wikimedia

Levi Ferreira - Director Developer Experience WMF

Wikimedia · Bots e infraestrutura · outubro 2026 01 / 11

WIKIMEDIA FOUNDATION

2 of 9

O DESAFIO

O tráfego automatizado mudou de escala

Três indicadores do impacto de crawlers na infraestrutura Wikimedia

Wikimedia · Bots e infraestrutura · outubro 2026 02 / 11

+50%

bandwidth

desde janeiro de 2024

Aumento observado no consumo de bandwidth

35%

pageviews

gerados por bots

Parcela estimada das visualizações

65%

tráfego mais caro

atribuído a bots

Participação nos requests de maior custo

Fonte: Responsible Use of Infrastructure (páginas 3 e 7). Métricas de períodos diferentes; não são partes do mesmo total.

WIKIMEDIA FOUNDATION

3 of 9

IMPACTO

Poucos requests podem custar muito

Por que o cache miss importa — e o que aprendemos com 159M requests

Wikimedia · Bots e infraestrutura · outubro 2026 03 / 11

TRÁFEGO HUMANO

Página popular

Browser → CDN cache → resposta

Mais requests resolvidos no cache

CRAWLERS

URLs menos populares

Bot → cache miss → origin

Mais trabalho para os data centers

Pesquisa sobre media scrapers: em uma amostra de 1 hora, ~1.000 IPs responderam por 47% dos bytes uncached. Resultado direcional, não baseline.

WIKIMEDIA FOUNDATION

4 of 9

Por que é difícil defender?

Crawlers visitam URLs pouco populares → mais cache misses

Residential proxies e IP rotation enfraquecem IP-based rate limiting

User-Agent pode ser falsificado; robots.txt nem sempre é respeitado

False positives podem bloquear ferramentas e usuários legítimos

Wikimedia · Bots e infraestrutura · outubro 2026 04 / 11

WIKIMEDIA FOUNDATION

À primeira vista, a solução parece simples.

Se um determinado endereço IP está gerando uma quantidade enorme de tráfego, por que não bloqueá-lo?

O problema é que a realidade é muito mais complexa.

Muitos crawlers utilizam residential proxies, fazem IP rotation e apresentam User-Agents que não necessariamente refletem sua identidade.

Isso significa que um único sistema automatizado pode aparecer como milhares de clientes diferentes.

Ao mesmo tempo, nem todo tráfego intenso é abusivo.

Uma ferramenta comunitária, um pesquisador ou um bot legítimo pode precisar acessar grandes quantidades de dados para realizar uma atividade perfeitamente válida.

Se aplicarmos regras agressivas demais, corremos o risco de bloquear exatamente as pessoas e ferramentas que queremos apoiar.

Esse é o problema dos false positives: quando classificamos um acesso legítimo como problemático.

Também temos os false negatives, quando um scraper problemático não é identificado.

Então, nosso desafio não é simplesmente bloquear o maior número possível de bots.

É conseguir distinguir comportamentos legítimos de comportamentos que colocam a infraestrutura em risco.

E há uma nova dimensão nesse problema: alguns sistemas automatizados não estão apenas lendo conteúdo. Eles também estão tentando executar ações.

5 of 9

Caso real: AI agents da OpenAI

Edições sem aprovação da comunidade, incluindo configuração do Web2Cit

Tentativas malsucedidas de usar Etherpad como proxy

Milhões de API requests e crawls; centenas de milhares de WDQS queries

Sem evidência de comprometimento ou coordenação nos sistemas Wikimedia

Wikimedia · Bots e infraestrutura · outubro 2026 05 / 11

WIKIMEDIA FOUNDATION

Em outubro de 2026, a Wikimedia Foundation publicou uma investigação sobre atividades de AI agents da OpenAI em sistemas Wikimedia.

Esse caso é interessante porque demonstra que os riscos do tráfego automatizado não se limitam ao consumo de recursos.

A investigação identificou ações não autorizadas, incluindo alterações em configurações do Web2Cit que poderiam permitir seu uso como proxy.

Também houve tentativas malsucedidas de interação com o Etherpad.

É importante explicar o impacto corretamente.

As edições identificadas nas wikis ficaram principalmente em páginas de sandbox e não chegaram a páginas visíveis aos leitores.

Também foi identificado tráfego que pode ter contribuído para uma indisponibilidade parcial do Wikidata Query Service em maio, mas não podemos afirmar que tenha sido a única causa.

O que esse incidente nos mostra é que os AI agents introduzem um desafio adicional.

Precisamos proteger a infraestrutura contra consumo excessivo de recursos, mas também garantir que sistemas automatizados respeitem os limites de autorização e de uso das nossas ferramentas.

E isso não afeta apenas os serviços principais da Wikimedia.

Também estamos vendo problemas semelhantes nos ambientes utilizados pela nossa comunidade técnica.

6 of 9

Caso real: Beta Cluster e Toolforge

Beta Cluster: carregamento de páginas em minutos; HTTP 503/504

Crawling via residential proxies e IP rotation

Resposta operacional: bloqueios de network ranges, de forma reativa

Toolforge: relatos de scraping afetando ferramentas como Scholia e paulina

Wikimedia · Bots e infraestrutura · outubro 2026 06 / 11

WIKIMEDIA FOUNDATION

7 of 9

RESPOSTAS

Problemas distintos exigem soluções distintas

Uma estratégia coordenada, com controles adequados a cada ambiente

Wikimedia · Bots e infraestrutura · outubro 2026 07 / 11

PRODUCTION

Wikipedia · Commons

KAPOW · HAProxy · rate limiting · requestctl

DATA & APIs

Wikidata · WDQS · APIs

WDQS cost-based limits · REST API pathways

COMMUNITY CLOUD

Toolforge · Cloud VPS

Proxy filtering · opt-in controls · observability

DEVELOPMENT

Beta Cluster

Mitigação de crawling · disponibilidade de testes

As iniciativas combinam diferentes frentes de proteção. Cloud VPS/Toolforge: A proteção compartilhada segue em investigação; não é uma solução já implantada.

WIKIMEDIA FOUNDATION

Uma coisa que aprendemos é que não existe uma única solução que funcione igualmente bem para todos os serviços.

Na infraestrutura de produção, temos a possibilidade de aplicar proteções no edge, antes que as requisições cheguem aos servidores de aplicação.

Isso permite identificar padrões suspeitos e aplicar controles como rate limiting.

Já em serviços como o Wikidata Query Service, precisamos considerar não apenas quantas requisições são feitas, mas também quanto processamento cada consulta exige.

E no Toolforge, o desafio é oferecer mecanismos de proteção que possam ser utilizados por diferentes ferramentas sem exigir que cada maintainer implemente tudo do zero.

Esses três ambientes têm necessidades diferentes.

Mas existe um princípio comum: precisamos entender melhor o tráfego, medir seu impacto e aplicar proteções proporcionais.

Vou começar explicando algumas das melhorias que estamos desenvolvendo na infraestrutura de produção.

=== Production�Uma das principais mudanças na nossa abordagem é tentar sair de um modelo predominantemente reativo.

Hoje, quando um scraper começa a causar problemas, muitas vezes precisamos que engenheiros de SRE investiguem o tráfego, identifiquem padrões e criem regras específicas.

Queremos tornar esse processo mais inteligente e automatizado.

Uma das iniciativas nessa direção é o KAPOW, que trabalha com sinais para ajudar a distinguir tráfego humano de tráfego automatizado.

A ideia é aproveitar características das requisições e dos clientes para identificar padrões que indiquem a presença de bots.

Mas existe um desafio técnico importante: precisamos fazer essa classificação sem introduzir um custo excessivo em cada requisição.

Uma das abordagens em desenvolvimento é exportar scores de detecção para o edge, permitindo que o HAProxy consulte informações previamente calculadas.

A equipe está investigando combinações de fingerprints, como JA3N e partes de JA4H, para encontrar um equilíbrio entre precisão, cobertura e desempenho.

No update mais recente, de 15 de outubro, essa combinação apresentou resultados promissores para melhorar a eficiência das consultas.

Isso ainda está em desenvolvimento, e não significa que toda essa integração já esteja em produção.

Outra frente importante é a auditoria das regras de proteção.

Com o requestctl, estamos trabalhando para melhorar a visibilidade sobre quantas requisições correspondem a cada regra.

Por exemplo, queremos conseguir responder perguntas como: uma regra está sendo acionada milhares de vezes por minuto? Ela continua necessária? Seu comportamento mudou depois de uma alteração no tráfego?

Já existe uma demonstração funcional da visualização dessas contagens, mas ainda faltam etapas de integração e deployment.

E a pesquisa sobre media scrapers trouxe outro aprendizado importante: antes de automatizar bloqueios, precisamos compreender melhor o custo das requisições e os diferentes comportamentos dos bots.

Portanto, a estratégia combina três coisas: identificar melhor, aplicar proteções com cuidado e conseguir avaliar o resultado.

Mas como levar esses benefícios para as ferramentas mantidas pela comunidade?

=== Toolforge�No Toolforge e no Cloud VPS, precisamos adaptar essas ideias à realidade das ferramentas comunitárias.

Não podemos simplesmente copiar toda a infraestrutura de proteção utilizada em produção.

Os ambientes têm arquiteturas diferentes, e algumas das ferramentas internas de proteção dependem de integrações que não estão disponíveis no Toolforge.

Uma possibilidade que estamos investigando é reutilizar partes da lógica de proteção utilizando HAProxy e regras Lua.

Isso poderia permitir aplicar determinados controles de tráfego de maneira mais compartilhada, sem exigir que cada aplicação desenvolva sua própria solução.

Mas existem dependências técnicas que precisam ser resolvidas, especialmente relacionadas à configuração e à operação dos proxies.

Também precisamos melhorar a observability.

Imaginem que vocês mantêm uma ferramenta e percebem que ela está lenta.

Sem métricas adequadas, pode ser difícil responder perguntas básicas.

O problema está na aplicação? O banco de dados está sobrecarregado? Estamos recebendo um pico legítimo de usuários? Ou um scraper está fazendo milhares de requisições?

Ter visibilidade sobre esses padrões é essencial para escolher a proteção correta.

Ferramentas de análise de tráfego e mecanismos compartilhados de observabilidade são possibilidades que estamos avaliando.

Quero enfatizar que essas soluções ainda estão sendo investigadas. Não seria correto apresentar tudo isso como funcionalidades já disponíveis para a comunidade.

E é justamente por isso que o feedback de vocês é tão importante: precisamos entender quais capacidades realmente fariam diferença para quem mantém essas aplicações.

8 of 9

O que significa sucesso?

Sites rápidos e disponíveis: evitar lentidão, erros e sobrecarga dos servidores.
Menos trabalho manual: reduzir o tempo que as equipes gastam combatendo bots problemáticos.
Identificação mais precisa: distinguir bots de usuários reais, evitando bloqueios indevidos.
Regras mais transparentes: entender quais regras de proteção estão sendo acionadas e com que frequência.
Uso justo dos recursos: limitar consultas muito pesadas, considerando o processamento necessário e não apenas o volume de dados retornados.

Wikimedia · Bots e infraestrutura · outubro 2026 10 / 11

WIKIMEDIA FOUNDATION

Uma questão importante é: como vamos saber se estamos realmente resolvendo o problema?

Não basta simplesmente bloquear mais bots. Precisamos garantir que estamos reduzindo o impacto na infraestrutura, sem prejudicar leitores, contribuidores e ferramentas legítimas.

O primeiro indicador é a saúde da infraestrutura.

Vamos observar se os serviços continuam rápidos e disponíveis, principalmente durante picos de tráfego automatizado.

Aqui, algumas métricas são importantes: a latência, que indica quanto tempo uma requisição demora para receber uma resposta; os erros HTTP 5xx, que podem indicar problemas nos servidores; e o consumo de CPU.

Também queremos acompanhar os chamados uncached bytes. Quando uma requisição não pode ser atendida diretamente pelo cache da CDN, ela pode exigir trabalho adicional dos nossos servidores.

Isso significa que duas requisições aparentemente semelhantes podem ter custos muito diferentes.

Como vimos anteriormente, na amostra de 159 milhões de requisições de mídia, aproximadamente mil IPs foram responsáveis por 47% dos bytes não atendidos pelo cache.

Isso demonstra por que precisamos entender quais acessos realmente consomem recursos.

O segundo indicador é quanto trabalho manual estamos conseguindo eliminar.

Hoje, quando identificamos um scraper problemático, muitas vezes precisamos que engenheiros de SRE investiguem o tráfego, identifiquem padrões e criem regras de proteção.

Esse processo consome tempo que poderia ser dedicado a melhorar a infraestrutura.

Queremos automatizar cada vez mais a identificação de comportamentos suspeitos, permitindo que as equipes se concentrem nos casos mais complexos.

O terceiro ponto é a precisão da identificação dos bots.

É aqui que entra novamente o KAPOW.

Não queremos apenas aumentar a quantidade de tráfego classificado como bot. Queremos entender se essa classificação está correta.

Um false positive acontece quando identificamos incorretamente um usuário legítimo como bot.

Já um false negative acontece quando deixamos passar um bot problemático.

Estamos planejando métricas que permitam comparar essas classificações em diferentes tipos de tráfego, incluindo acessos de usuários logados, dispositivos móveis e diferentes fontes de referência.

Isso ajuda a identificar situações em que as regras podem estar prejudicando usuários legítimos.

O quarto ponto é entender se nossas regras de proteção estão funcionando como esperamos.

Com o requestctl, queremos acompanhar quais regras estão sendo acionadas e com que frequência.

Por exemplo, uma regra pode ter sido criada para responder a um incidente específico, mas continuar ativa muito tempo depois.

Sem visibilidade, é difícil saber se ela ainda é necessária ou se está afetando tráfego legítimo.

A auditoria permite revisar essas decisões com base em dados.

E, por último, precisamos entender o custo real de cada tipo de acesso.

Isso é especialmente importante no Wikidata Query Service, o WDQS.

Uma consulta pode retornar poucos resultados e, mesmo assim, consumir bastante processamento.

Isso acontece porque o custo não depende apenas do tamanho da resposta, mas também da complexidade da consulta, do tempo de execução e de quantas outras consultas estão sendo executadas simultaneamente.

As análises recentes mostraram que o tamanho da resposta, isoladamente, não é um bom indicador desse custo.

A concorrência e o uso de CPU são muito mais relevantes.

É por isso que estamos explorando mecanismos de rate limiting que considerem o custo de processamento, em vez de simplesmente aplicar o mesmo limite de requisições para todo mundo.

Esse trabalho teve uma pausa temporária para priorizar outras entregas, então não estamos apresentando essa capacidade como já concluída.

No final, nosso objetivo não é bloquear o máximo possível de tráfego automatizado.

É reduzir o consumo desnecessário de recursos, melhorar a disponibilidade dos serviços e permitir que bots e ferramentas legítimas continuem funcionando.

Porque, para a Wikimedia, o desafio não é impedir o uso automatizado do conhecimento livre. É garantir que esse uso seja sustentável para todos.

9 of 9

Perguntas

Quais serviços ou ferramentas vocês viram sofrer com scraping?

Quais casos de uso legítimos correm risco com rate limiting?

Que sinais e controles estão faltando que ajudariam vocês a operar suas ferramentas?

Wikimedia · Bots e infraestrutura · outubro 2026 11 / 11

WIKIMEDIA FOUNDATION

E eu queria terminar voltando ao ponto mais importante dessa conversa: a experiência de vocês.

Nós conseguimos observar o problema em nossos serviços de produção, analisar grandes volumes de tráfego e desenvolver mecanismos mais sofisticados de detecção e proteção.

Mas isso não significa que conhecemos todos os desafios enfrentados por quem mantém ferramentas comunitárias.

Por isso, gostaria de ouvir três coisas de vocês.

Primeiro: quais ferramentas ou serviços estão sofrendo mais com scraping ou tráfego automatizado? E como isso aparece no dia a dia? Lentidão, erros, indisponibilidade ou aumento no consumo de recursos?

Segundo: quais tipos de tráfego automatizado são legítimos e importantes para as ferramentas de vocês? Precisamos entender esses casos para evitar que novas proteções prejudiquem integrações que já funcionam.

E terceiro: que capacidades ajudariam vocês a operar melhor suas aplicações? Por exemplo, métricas mais claras, logs de acesso, limites configuráveis ou mecanismos compartilhados de proteção.

A ideia é usar essas respostas para entender melhor as prioridades da comunidade e orientar as próximas melhorias.

Porque, no final, nosso objetivo não é impedir que máquinas utilizem o conhecimento livre.

É garantir que leitores, contribuidores, pesquisadores, bots legítimos e ferramentas comunitárias possam continuar utilizando a infraestrutura Wikimedia de forma sustentável.

Muito obrigado! Agora quero ouvir vocês.