Os Creepy Crawlies do Kernel.org Estão Transformando o Acesso Aberto em um Imposto sobre CPU

Konstantin Ryabitsev afirma que os creepy crawlies agora mantêm de 14 a 16 núcleos de CPU ocupados no git.kernel.org, apesar de defesas projetadas para tornar a coleta automatizada cara. Os crawlers solicitam milhões de páginas individuais de commits em vez de clonar os repositórios Git subjacentes. Essa escolha transforma um arquivo público eficiente em um serviço permanente de renderização de HTML para máquinas não identificadas.

Ryabitsev, administrador de sistemas da Linux Foundation envolvido com a infraestrutura do kernel.org, publicou os números em 29 de agosto de 2026. Simon Willison os destacou em 7 de setembro porque o Datasette apresenta um perfil de risco semelhante. Ele pode expor um banco de dados por meio de uma enorme coleção de páginas úteis e rastreáveis.

A história imediata diz respeito à infraestrutura Linux, mas o conflito vai muito além. Arquivos técnicos abertos foram concebidos para ajudar pessoas a inspecionar, consultar e preservar informações. Clientes em escala de máquina podem transformar essa abertura em uma obrigação computacional sem preço.

A inversão é especialmente acentuada no git.kernel.org. Seus mantenedores já fornecem todo o histórico dos repositórios por meio do Git, um protocolo criado para transferir esse histórico com eficiência. Ainda assim, os scrapers estariam escolhendo a rota computacionalmente cara, solicitando páginas renderizadas separadamente para commits, patches e diffs.

Esse comportamento pressiona os mantenedores a restringir interfaces usadas por desenvolvedores legítimos. Segundo Ryabitsev, o serviço continua responsivo, mas já está desativando recursos e colocando mais ações atrás de controles de acesso. Portanto, o custo do aumento de crawlers é medido tanto em perda de abertura quanto em tempo de CPU.

Creepy Crawlies Geram Seis Milhões de Solicitações Diárias

A escala é grande o bastante para consumir infraestrutura continuamente, mesmo quando o site parece saudável para visitantes humanos.

As medições de crawlers de Ryabitsev descrevem cerca de 6 milhões de solicitações diárias para commits aparentemente aleatórios. O Anubis, um desafio de navegador colocado antes do site principal, rejeita imediatamente cerca de 66% dessas solicitações. Outros 33% resolvem o desafio e seguem para o git.kernel.org.

Os números não provam que todas as solicitações desafiadas venham de uma empresa de IA. Ryabitsev afirma explicitamente que os operadores não conseguem identificar cada cliente com certeza. Uma pessoa pode abrir um commit antigo, enquanto um bot pode imitar um navegador atual.

Os padrões de solicitação fornecem a evidência mais forte. Um cliente que percorre commits não relacionados em forks antigos e inativos não se parece com um desenvolvedor acompanhando uma série de patches. Ryabitsev estima que atividades legítimas representem cerca de 2% do tráfego total, mesmo após usar premissas favoráveis aos usuários.

A carga de trabalho resultante ocupa de 14 a 16 dos 90 núcleos de CPU em cinco nós distribuídos geograficamente. Isso equivale, em média, a cerca de 20% da capacidade total de processamento do serviço. A demanda real chega em ondas, portanto a carga é menos organizada do que uma alocação fixa de 20%.

Esses núcleos executam uma tarefa restrita. Eles transformam objetos Git em páginas HTML para clientes que então analisam a saída renderizada. Ryabitsev afirma que essa atividade consome mais tempo de CPU do que todas as formas de acesso legítimo combinadas, incluindo clones Git.

Essa distinção importa porque um clone transfere um repositório pelo modelo nativo de objetos do Git. O cliente recebe o histórico e pode percorrer os commits localmente. O servidor evita reconstruir uma página de apresentação para cada objeto que o cliente deseja inspecionar.

Solicitações HTML invertem essa eficiência. Cada solicitação pede que o servidor localize dados do repositório, execute o cgit e construa uma resposta legível por humanos. O cliente descarta grande parte da interface ao redor depois de extrair o texto desejado.

Repetida em milhões de URLs, uma página individualmente razoável se torna um endpoint de máquina caro. O planejamento de capacidade tradicional muitas vezes trata visualizações de página como unidades de trabalho comparáveis. O caso do git.kernel.org mostra por que esse modelo falha quando uma URL pode acionar muito mais computação do que outra.

O serviço não entrou em colapso sob a carga atual de fundo. Ryabitsev diz que sistemas de integração contínua mal projetados ainda podem causar interrupções mais agudas, especialmente quando muitos nós realizam clones superficiais simultâneos. O tráfego de crawlers cria um problema diferente porque remove permanentemente a margem operacional.

Essa margem perdida reduz a tolerância a picos de tráfego, eventos de manutenção e automação legítima. Também obriga operadores a gastar tempo estudando comportamentos adversariais em vez de melhorar os serviços para desenvolvedores do kernel. Assim, um site aparentemente estável pode carregar um custo oculto substancial.

A mudança crucial não é que o código-fonte público possa ser baixado. O Kernel.org apoia intencionalmente esse uso. A mudança é que clientes não identificados estão escolhendo uma representação custosa e exigindo-a em escala industrial.

O Git Torna os Dados Baratos, mas o HTML os Torna Caros

O conflito central não é acesso versus sigilo. É acesso em massa eficiente versus extração página por página desperdiçadora.

O desenvolvimento do Linux sempre se beneficiou da replicação. Repositórios Git podem ser clonados, arquivos de listas de discussão podem ser copiados e espelhos podem preservar material além da vida útil de qualquer servidor individual. O Kernel.org incentiva essa redundância em vez de tratar cada download como uma ameaça.

O Git torna esse modelo econômico ao transferir objetos de acordo com seus relacionamentos. Um repositório armazena commits, árvores e conteúdos de arquivos como objetos endereçáveis. Cliente e servidor negociam quais objetos faltam ao cliente e então movem os dados necessários sem recriar uma página web em torno de cada commit.

A interface web atende a outro propósito. Ela ajuda um desenvolvedor a inspecionar uma mudança, compartilhar um link estável, comparar revisões ou baixar um patch sem clonar um grande repositório. O cgit, a interface usada pelo git.kernel.org, oferece várias visualizações porque cada uma apoia um fluxo de trabalho humano legítimo.

Essas opções também multiplicam a superfície rastreável. O repositório principal do Linux contém cerca de 1,48 milhão de commits, segundo o relato de Ryabitsev. O Git.kernel.org hospeda cerca de 922 forks que, em grande parte, compartilham os mesmos objetos subjacentes.

Assim, um crawler pode descobrir muitas URLs que levam a conteúdo duplicado de commits. Ele também pode solicitar visualizações de patches, renderizações em texto simples, árvores de repositórios e comparações arbitrárias. O conteúdo é finito, mas o espaço de URLs possível se torna muito maior.

Esse é um modo de falha conhecido em sites baseados em bancos de dados. Um banco de dados pode conter um número administrável de registros enquanto sua interface permite incontáveis combinações de filtros, ordenação, paginação e comparação. Cada rota gerada parece outro documento para um crawler indiscriminado.

Willison conectou esse padrão ao Datasette, sua ferramenta open source para publicar bancos de dados pesquisáveis na web. Uma instância do Datasette pode transformar informações estruturadas em páginas navegáveis e resultados de consultas. Essa acessibilidade é valiosa para pessoas, mecanismos de busca, pesquisadores e ferramentas assistivas.

Ela também pode expor combinações caras de parâmetros. Um bot não precisa de código malicioso para criar uma carga prejudicial. Basta enumerar links ou construir URLs válidas mais rápido do que a aplicação consegue atendê-las a baixo custo.

O mesmo risco se aplica a sistemas de documentação, rastreadores de problemas, navegadores de código, portais de registros públicos e arquivos pessoais. Sites que transformam dados estruturados sob demanda são mais vulneráveis do que páginas estáticas porque cada acesso pode acionar trabalho de banco de dados ou renderização no servidor.

O cache ajuda quando muitos clientes solicitam o mesmo recurso. Ele ajuda menos quando crawlers espalham deliberada ou acidentalmente solicitações entre URLs únicas. Parâmetros de consulta, diffs arbitrários e forks antigos podem impedir a reutilização que torna um cache valioso.

Operadores podem pré-renderizar páginas populares, mas é impossível pré-renderizar todas as comparações possíveis. Eles também podem fornecer exportações em massa, mas um crawler projetado em torno de links web pode nunca descobrir ou selecionar a rota eficiente. Disponibilidade técnica não garante um comportamento sensato do cliente.

Para desenvolvedores que criam arquivos pesquisáveis, este é um alerta arquitetural. O acesso por máquina deve usar APIs limitadas, feeds, exportações ou protocolos de repositório sempre que possível. Interfaces humanas precisam de limites que reflitam o custo de gerar cada resposta.

As equipes que documentam essas decisões também devem preservar decisões operacionais junto ao código. Uma base de conhecimento de engenharia pesquisável pode conectar políticas de crawlers, rotas custosas e evidências de incidentes antes da chegada de outra onda de tráfego.

O incidente no kernel.org demonstra que a largura de banda é apenas parte da conta. Tempo de CPU, rotatividade de cache, custos de observabilidade e atenção dos operadores podem predominar quando clientes automatizados solicitam repetidamente representações dinâmicas.

O Anubis Elevou o Preço Até que os Crawlers o Pagassem

A prova de trabalho reduziu temporariamente o tráfego abusivo, mas crawlers persistentes se adaptaram porque os dados subjacentes continuavam valiosos.

O Kernel.org começou com defesas conhecidas. Operadores identificaram strings suspeitas de user-agent, inspecionaram logs e bloquearam endereços associados à coleta automatizada evidente. Essa abordagem funcionou enquanto os crawlers se identificavam ou se originavam de um conjunto administrável de redes.

Depois, o tráfego ficou mais difícil de classificar. Ryabitsev descreve clientes que alegavam ser navegadores comuns e distribuíam solicitações por sub-redes de nuvem. Bloquear uma rede inteira poderia deter abusos, mas também poderia negar verificações automatizadas legítimas hospedadas pelo mesmo provedor.

A mudança seguinte enfraqueceu ainda mais os controles baseados em endereços. As solicitações começaram a chegar de um grande número de endereços residenciais e móveis. Segundo Ryabitsev, cada endereço gerava apenas quatro ou cinco solicitações antes de desaparecer dos logs.

Esse padrão se assemelha a redes de proxy que roteiam tráfego por dispositivos de consumidores. Um site vê o que parece ser uma ampla população de usuários não relacionados em vez de uma operação concentrada de scraping. Quando um endereço parece suspeito, aquela fonte específica talvez nunca retorne.

O Kernel.org respondeu com o Anubis, um firewall web open source que desafia clientes antes de permitir que alcancem um serviço upstream. Seu mecanismo central é a prova de trabalho, uma pequena tarefa matemática relativamente cara para o cliente, mas barata para o servidor verificar.

O projeto Anubis descreve o software como uma defesa para serviços menores da internet que enfrentam tráfego sustentado de crawlers de IA. Seus mantenedores também o chamam de uma resposta severa porque os desafios podem bloquear pequenos scrapers e bots legítimos de arquivamento.

No git.kernel.org, o desafio inicialmente mudou a economia. Clientes automatizados pararam de tentar acessar o serviço, enquanto visitantes humanos aceitaram um atraso modesto. Esse período durou vários meses.

Mais tarde, os bots começaram a resolver o nível de dificuldade quatro. Os operadores elevaram o desafio para o nível cinco, que exigia mais computação do cliente. Ryabitsev afirma que essa configuração pode levar vários segundos em um dispositivo móvel e deixar o telefone visivelmente quente.

A dificuldade maior voltou a garantir vários meses. Ela também impôs um custo maior a cada visitante legítimo que recebia o desafio. A acessibilidade sofre quando hardware antigo, navegadores focados em privacidade, JavaScript desativado ou conexões instáveis não conseguem concluir o fluxo esperado.

Os rastreadores acabaram resolvendo o nível cinco também. Na época do relatório de Ryabitsev, aproximadamente um terço dos 6 milhões de solicitações diárias de commits superava o desafio. A prova de trabalho não se tornou inútil, pois ainda bloqueava os outros dois terços, mas já não restabelecia o equilíbrio anterior.

Esse resultado expõe a fraqueza central da dissuasão econômica. Um desafio funciona apenas enquanto o custo supera o valor esperado pelo rastreador. Um histórico técnico valioso e limpo dá aos coletores um motivo para gastar mais recursos.

Ryabitsev argumenta que o histórico de commits do Linux é particularmente atraente porque grande parte dele antecede a proliferação de texto gerado. Pesquisadores temem que o treinamento repetido com material sintético possa degradar a qualidade dos modelos ou amplificar artefatos. Isso torna registros técnicos bem estruturados e produzidos por humanos um material de treinamento desejável.

As identidades e os objetivos exatos dos clientes continuam sem verificação. Alguns podem apoiar o treinamento de modelos, enquanto outros podem criar índices de busca, conjuntos de dados de código, produtos de segurança ou arquivos comerciais. Operacionalmente, seu comportamento compartilhado importa mais do que o rótulo.

O desenvolvedor do Anubis, Xe Iaso, também reconheceu que a prova de trabalho não é uma resposta completa. Em uma discussão técnica, Iaso explicou que o mecanismo mira a economia da raspagem em massa, mas expressou ceticismo sobre seus benefícios contra clientes distribuídos e capazes.

Um cliente com automação de navegador pode executar JavaScript, armazenar cookies e resolver o mesmo desafio público que uma pessoa. Clientes distribuídos podem dividir o trabalho entre muitos dispositivos. Aumentar a dificuldade, então, corre o risco de punir visitantes legítimos mais rapidamente do que dissuade coletores bem financiados.

A experiência do Kernel.org confirma essa troca com dados de produção. A defesa teve sucesso, os clientes adversariais se adaptaram e os operadores elevaram o custo. A disputa não terminou porque atacante e defensor ainda tinham outro ajuste a fazer.

Arquivos Abertos Estão Sendo Forçados a Remover Recursos Úteis

O resultado mais prejudicial não é uma conta de servidor mais alta. É o recuo gradual do acesso anônimo e amigável para humanos.

O Kernel.org planeja reduzir o número de URLs rastreáveis e restringir operações cujo processamento é caro. Ryabitsev alerta que usuários anônimos devem esperar que algumas funcionalidades desapareçam. Os dados subjacentes continuarão disponíveis para download, mas obtê-los poderá exigir etapas adicionais.

Essa resposta é racional para um operador de infraestrutura. Se uma interface gera uma carga desproporcional, restringi-la protege o restante do serviço. Clones Git e fluxos de trabalho de desenvolvedores são mais importantes do que a renderização anônima e ilimitada de comparações arbitrárias.

Ainda assim, cada restrição muda quem pode usar o arquivo. Um desenvolvedor com Git instalado pode clonar um repositório e inspecioná-lo localmente. Um estudante seguindo um link, um jornalista verificando um commit ou alguém usando um dispositivo limitado pode depender da interface no navegador.

Ferramentas automatizadas de pesquisa também podem ter finalidades legítimas. A indexação para busca ajuda usuários a encontrar correções antigas. Sistemas de arquivamento preservam evidências. Serviços de segurança correlacionam commits com vulnerabilidades. Ferramentas de acessibilidade podem buscar páginas de formas que não se parecem com a navegação convencional.

Restrições amplas não conseguem separar claramente esses clientes de coletores abusivos. A autenticação cria responsabilização, mas adiciona trabalho administrativo. Limites de taxa reduzem picos, mas podem falhar quando as solicitações chegam de endereços distribuídos.

Bloquear redes residenciais excluiria domicílios reais. Bloquear provedores de nuvem interferiria na automação de desenvolvedores. Exigir prova de trabalho faz cada visitante gastar eletricidade e tempo antes que o servidor saiba se a solicitação é útil.

Robots.txt fornece um sinal de política, mas não é um mecanismo de controle de acesso. O padrão oficial de robots afirma que suas regras não constituem autorização. Rastreadores cooperativos seguem as preferências declaradas, enquanto um cliente não identificado pode ignorá-las ou se passar por um navegador.

O resultado é uma assimetria. Organizações responsáveis identificam seus rastreadores, publicam documentação, obedecem às exclusões e se tornam fáceis de bloquear. Coletores menos responsáveis ocultam sua identidade e distribuem o tráfego, tornando-se mais difíceis de deter.

Isso pode produzir um resultado perverso, no qual rastreadores compatíveis perdem acesso enquanto os evasivos continuam. Também torna a atribuição de tráfego pouco confiável. Operadores podem descrever razoavelmente uma classe comportamental como raspagem por IA sem conseguir conectar as solicitações a um desenvolvedor de modelos específico.

Essa incerteza é a principal questão cética desta história. As medições de tráfego de Ryabitsev são evidência operacional direta, mas a finalidade por trás de cada solicitação não foi estabelecida de forma independente. A estimativa de 98% diz respeito ao aparente comportamento de raspagem, não a uma lista verificada de empresas de IA.

A distinção deve orientar tanto a política quanto a cobertura jornalística. Seria impreciso atribuir toda a carga a um fornecedor específico sem evidências de rede. Seria igualmente impreciso descartar o problema porque todos os clientes não têm uma identidade pública.

O dano mensurável existe na camada de aplicação. Milhões de solicitações selecionam commits antigos, bifurcações duplicadas e renderizações caras. Um desafio defensivo bloqueia muitas solicitações, mas volumes substanciais pagam o custo computacional e continuam.

A Cloudflare abordou o problema mais amplo ao dar aos proprietários de sites controles mais granulares para rastreadores de busca, agentes e treinamento. Seus controles de tráfego de IA refletem uma distinção importante, porque um rastreador de treinamento de modelos e um assistente solicitado por um usuário não têm a mesma finalidade.

Grandes redes de borda podem combinar inteligência sobre endereços, sinais de navegador, histórico de tráfego e observações em toda a sua base de clientes. Pequenos serviços de código aberto raramente têm essa visibilidade. Eles precisam tomar decisões com logs locais e identificadores imperfeitos.

Essa lacuna concentra os danos nas organizações menos capazes de absorvê-los. Uma grande plataforma comercial pode comprar mais capacidade e implantar gerenciamento especializado de bots. Um projeto voluntário, arquivo acadêmico ou editor independente pode simplesmente fechar rotas caras.

A web aberta então perde mais do que alguns recursos de interface. Ela perde a premissa de que publicar informações úteis e vinculáveis é economicamente seguro. As páginas permanecem tecnicamente públicas, mas o acesso se torna condicionado, desafiado ou disponível apenas por fluxos de trabalho de dados em massa.

O Conflito Real É Entre Abertura e Computação Sem Preço

Dados abertos não exigem que toda representação possível permaneça gratuita, anônima e ilimitada.

O argumento ético em torno do rastreamento frequentemente se concentra na permissão para copiar conteúdo. O Kernel.org acrescenta uma segunda questão: quem deve pagar para transformar esse conteúdo no formato que um coletor prefere?

Os repositórios Linux já estão disponíveis por meio de um mecanismo eficiente de transferência. Os operadores não estão ocultando o histórico nem exigindo controle exclusivo sobre ele. Eles se opõem a clientes que fazem o serviço público calcular repetidamente uma representação mais cara.

Essa diferença separa o caso de um simples debate sobre restringir conhecimento. Um clone eficiente permite que um coletor assuma grande parte do custo de processamento após a transferência. A raspagem de HTML commit por commit transfere trabalho repetido para a fonte.

Um coletor responsável deve primeiro procurar exportações em massa, acesso ao repositório, feeds, sitemaps ou APIs documentadas. Deve armazenar em cache o material obtido, eliminar bifurcações duplicadas e evitar combinações arbitrárias de parâmetros. Também deve se identificar e oferecer um canal de contato funcional.

A negociação de taxas também importa. Um rastreador que precisa de um volume incomum pode pedir a um operador um espelho ou uma exportação programada. O Kernel.org afirma que pretende continuar fornecendo dados às pessoas que os solicitarem, mesmo à medida que as interfaces anônimas se tornem mais restritivas.

Essas práticas parecem elementares porque os mecanismos de busca maduros as desenvolveram ao longo de décadas. A demanda por IA ampliou o número de organizações que coletam conjuntos de dados em escala web. Nem todas as equipes parecem ter herdado as mesmas normas operacionais.

Os incentivos também diferem. Um coletor correndo para adquirir material escasso anterior à IA se beneficia de agir rapidamente. O custo da coleta ineficiente recai sobre milhares de operadores de sites não relacionados. Sem contratos, fiscalização ou identidade confiável, o rastreador não paga automaticamente esse custo externo.

A prova de trabalho tenta transferir parte da despesa de volta para o solicitante. Os resultados do git.kernel.org mostram tanto a atração quanto o limite desse modelo. Ela aumenta o custo marginal, mas não consegue distinguir uma solicitação humana valiosa de uma solicitação automatizada valiosa.

Cobrar por rastreamento cria outra rota possível, mas o pagamento por si só não resolve o desenho do sistema. Um rastreador ainda pode sobrecarregar um endpoint dinâmico se preços, cotas e controles de capacidade estiverem mal alinhados. Sites pequenos também não dispõem dos sistemas de faturamento necessários para negociar acesso de máquinas.

Uma melhor descoberta de protocolos ajudaria. Uma página legível por máquinas poderia direcionar coletores para um clone de repositório, arquivo compactado ou exportação de dados limitada. Os rastreadores ainda precisariam de incentivos ou exigências para respeitar essa orientação.

O desenho da aplicação pode reduzir a exposição antes que o tráfego chegue. Desenvolvedores podem limitar tamanhos de resultado, rejeitar comparações irrazoáveis, canonizar URLs equivalentes e atribuir limites separados a rotas caras. Eles podem pré-calcular visualizações comuns e exigir autenticação para consultas incomuns.

A observabilidade precisa medir o trabalho, e não apenas as solicitações. Um milhão de respostas estáticas em cache pode custar menos do que alguns milhares de consultas não armazenadas em cache a bancos de dados. Os operadores precisam de tempo de CPU por rota, eficácia do cache, taxas de conclusão de desafios e comportamento de clientes agrupado entre endereços.

A questão de política mais profunda diz respeito à identidade verificável. Um rastreador que declara seu operador e sua finalidade pode receber acesso sob medida. Um cliente distribuído que finge ser milhões de navegadores impede a negociação e transforma cada solicitação em uma decisão de confiança.

Até que a identidade melhore, sistemas defensivos dependerão de inferência comportamental. Isso significa que falsos positivos continuarão inevitáveis. O custo humano deve ser acompanhado tão seriamente quanto o tráfego bloqueado, porque uma proteção que exclui usuários reais pode prejudicar o serviço que preserva.

As criaturas rastejantes, portanto, representam uma falha de governança tanto quanto um problema de tráfego. A web tem normas para o comportamento voluntário de rastreadores, mas não possui uma estrutura confiável para clientes em escala de máquina que ignoram essas normas.

Três Sinais Mostrarão se a Pressão Está Diminuindo

A próxima fase será medida pelo comportamento do tráfego, pela funcionalidade perdida e por uma melhor responsabilização dos rastreadores.

O primeiro sinal é a taxa de aprovação do desafio no git.kernel.org. Cerca de 33% das solicitações aleatórias de commits superavam o Anubis quando Ryabitsev publicou seus números. Uma queda sustentada sugeriria que novos controles restauraram a pressão econômica ou melhoraram a classificação dos clientes.

Uma taxa de aprovação estável ou crescente apontaria na direção oposta. Isso mostraria que os coletores continuam valorizando os dados o suficiente para absorver cada aumento defensivo. Outro aumento na dificuldade do desafio também revelaria que a disputa permanece focada em custo, e não em identidade.

O segundo sinal é a quantidade de funcionalidades anônimas que o kernel.org remove. Restrições limitadas a comparações excepcionalmente caras apoiariam uma resposta direcionada. Perdas mais amplas nas visualizações comuns de commits, patches ou navegação mostrariam que a pressão dos rastreadores está mudando a experiência pública.

Os operadores devem documentar o que desaparece e por quê. Esse registro ajudaria outros projetos a identificar padrões de URL perigosos antes que chegassem ao mesmo ponto. Também revelaria se as defesas preservam os fluxos de trabalho humanos comuns que deveriam proteger.

O terceiro sinal é se os principais operadores de crawlers adotam identidades verificáveis e rotas eficientes de aquisição. Faixas de endereços publicadas, user agents específicos para cada finalidade, informações de contato e políticas de taxa aplicáveis permitiriam que os sites distinguissem automação cooperativa de scraping evasivo.

Sem essa responsabilização, o mercado de defesa continuará avançando em direção a fingerprinting de navegador, controles de borda gerenciados, autenticação e acesso pago. Essas ferramentas podem proteger a capacidade, mas também tornam a publicação independente mais complicada.

Para desenvolvedores, a ação imediata é examinar quais rotas públicas consomem mais CPU e quantas URLs distintas expõem o mesmo registro subjacente. Teste se um cliente em massa consegue recuperar as mesmas informações por meio de uma interface mais barata.

Publique essa rota de forma clara e, em seguida, imponha limites rígidos à geração dinâmica de HTML. Monitore separadamente as taxas de conclusão de proof-of-work e as falhas de usuários legítimos. Uma defesa deve reduzir a computação abusiva sem transformar cada leitor em dano colateral.

Para quem desenvolve IA, a escolha responsável é mais simples. Use a representação autorizada de menor custo, identifique o crawler, respeite a política do site e entre em contato com os operadores antes de escalar. O acesso aberto é um convite para usar conhecimento compartilhado, não uma reivindicação ilimitada sobre os processadores de outra pessoa.

Os creepy crawlies em git.kernel.org tornaram esse limite visível. A web aberta pode sustentar leitores de máquina, mas apenas se essas máquinas deixarem de tratar cada URL pública como capacidade computacional gratuita.