navigator.cpuPerformance no Chrome 152: novo sinal de detecção para anti-detect e scraping

25 de agosto de 2026, o Chrome 152 chegou ao canal estável no Windows, Mac, Linux, ChromeOS e Android — e trouxe a propriedade navigator.cpuPerformance. Um número de 0 a 4 que o site lê de forma síncrona, sem permissões e sem um único ciclo de computação. Foi pensado como uma dica para chamadas de vídeo e streams: um dispositivo fraco recebe 240p sem desfoque de fundo, um poderoso — 1080p com efeitos. Duas semanas após o lançamento, a indústria de scraping discute outra coisa: os sistemas anti-bot agora têm um sinal barato e estável sobre o hardware em que seu navegador está rodando.

O que exatamente o navegador entrega

A propriedade não retorna gigahertz nem o modelo do processador, mas sim uma "categoria" de desempenho. De acordo com a nota explicativa do WICG, os níveis vão de quatro a zero:

• 0 — não foi possível classificar o dispositivo;
• 1 — praticamente inadequado para tarefas pesadas;
• 2 — fraco, mas funcional;
• 3 — confortável para cenários comuns;
• 4 — potente, com folga para multitarefa.

A especificação proíbe explicitamente a divulgação do fornecedor, nome do modelo e número de núcleos, exige HTTPS e estabelece um objetivo de privacidade: cada categoria deve cobrir uma parte significativa dos dispositivos na internet — cerca de centenas de modelos diferentes de CPU, para que o valor não restrinja a audiência a poucos.

A implementação real no Chromium acabou sendo mais simples do que a especificação. Na análise da Zyte, foi mostrado que a classificação se baseia principalmente no número de núcleos lógicos e em uma tabela embutida de aumentos e diminuições: a frequência não é considerada de forma alguma, embora a especificação permita. Aumentos são dados a AMD Ryzen, núcleos Intel Gracemont, Apple silicon e Intel Core Ultra; diminuições — a Intel Atom e processadores da era Core 2. A vinculação grosseira é a seguinte: máquinas de um único núcleo e muito fracas caem na primeira categoria, dois a quatro núcleos dão a segunda, quatro a dez núcleos ou chips modernos de eficiência energética — a terceira, e oito ou mais núcleos em Core Ultra, Apple M-series e tudo que tiver dez núcleos ou mais — a quarta.

Por que isso é um sinal de detecção, e não apenas mais um byte de entropia

O valor em si é fraco: cinco opções — isso dá cerca de 2,3 bits de entropia, menos do que a interface de linguagem. O perigo está em três outras propriedades.

É gratuito. Para medir a verdadeira velocidade de execução do JS, o script de detecção precisa ocupar o processador por dezenas de milissegundos, e isso é notável no profiler. Aqui — a leitura síncrona da propriedade, zero custos, zero rastros.

É estável. O valor não depende da carga da máquina no momento da verificação: é uma classe de hardware, e não a utilização atual. Entre sessões, reinicializações e mudanças de IP, ele permanece o mesmo — ou seja, é adequado como parte de um identificador de perfil de longa duração.

É verificado quanto à consistência. Este é o principal. Motores anti-bot modernos raramente banem com base em um único campo — eles buscam contradições internas no conjunto. Um dispositivo que declara a quarta categoria deve confirmá-la com um navigator.hardwareConcurrency plausível, um navigator.deviceMemory razoável, uma linha moderna de renderizador GPU e uma velocidade de execução de JS correspondente. Um perfil que entrega a categoria 4 e, ao mesmo tempo, executa um benchmark como uma máquina virtual de dois núcleos, é capturado por uma verificação cruzada trivial.

Separadamente, surge quase uma linha divisória pronta entre "data center contra usuário real": uma instância típica de nuvem com dois vCPUs relata honestamente a primeira categoria, enquanto laptops e telefones de consumo vivem na terceira a quarta. Para um scraper que roda em uma VPS barata em modo headless e se passa por um Chrome comum no Windows, essa é uma combinação desconfortável.

Como isso difere do hardwareConcurrency, que sempre existiu

Uma pergunta razoável: o número de núcleos que o site lia antes através de navigator.hardwareConcurrency, e a quantidade de memória — através de navigator.deviceMemory. O que mudou?

A conectividade mudou. hardwareConcurrency é um número bruto, e sua substituição já é feita há muito tempo: você coloca oito em vez de trinta e dois, e a questão está resolvida. cpuPerformance é uma quantidade derivada, calculada pelo próprio navegador a partir de uma tabela embutida. Assim que dois campos aparecem no conjunto, um dos quais é calculado a partir do outro, qualquer modificação unilateral rompe a conexão entre eles. Se você definiu quatro núcleos, mas a categoria permaneceu a quarta — pela lógica da implementação, essa combinação requer ou Apple silicon, ou Core Ultra, ou dez núcleos; portanto, ou o número de núcleos está mentindo, ou a linha GPU está mentindo, e o detector só precisa notar o fato da discrepância, sem precisar descobrir onde exatamente está a mentira.

É exatamente por isso que as antigas listas de verificação "quais campos substituir no perfil" se tornam obsoletas não por um único item, mas por blocos inteiros: a pergunta correta agora não é "o que substituir", mas "qual configuração de hardware consistente temos no total".

Quem é mais afetado por isso

Somente Chromium — e isso não é uma atenuante. O WebKit adotou uma posição "contra" em relação a essa API, a Mozilla não declarou uma posição pública, então no Safari e no Firefox a propriedade provavelmente não existirá. Mas a esmagadora maioria da automação de produção — Playwright, Puppeteer, nodriver, Patchright, navegadores de agentes — é construída exatamente sobre o Chromium. Ou seja, o sinal chega exatamente ao nicho onde menos se espera.

A contradição atinge mais fortemente a emulação de perfis móveis. Se um perfil anti-detecto se passa por um smartphone Android, e cpuPerformance sob ele responde "4", porque o navegador está fisicamente rodando em um desktop com Ryzen, isso não é uma pequena imprecisão, mas um par de sinais mutuamente exclusivos. O mesmo vale para cenários de fazenda, onde dezenas de perfis com diferentes "dispositivos" vivem em uma única máquina host e, portanto, dão a mesma categoria.

O que isso muda para a pilha de parsing

Algumas consequências práticas para aqueles que executam navegadores headless em massa.

• Contêineres herdam do host. O navegador no Docker vê os núcleos da máquina host, e não os limites do cgroup — isso significa que dez contêineres em um único servidor robusto darão dez categorias máximas idênticas. A diversidade de perfis que você cuidadosamente desenhou no user-agent não existe no nível de hardware.
• VPS barata agora é mais perceptível. Dois vCPUs — isso é a primeira categoria, e a primeira categoria no Chrome desktop sob Windows raramente é encontrada em pessoas reais. Antes, um servidor fraco era apenas lento; agora ele também está marcado.
• O sinal é gratuito para o site. Verificações pesadas como benchmarks de tempo são incluídas seletivamente pelos sites, porque custam tempo ao usuário. A leitura da propriedade não custa nada, então será adicionada ao conjunto básico até mesmo por aqueles sites que antes se limitavam à reputação de IP e cabeçalhos.
• Ele se juntará ao Compute Pressure. Nas notas de lançamento do Chrome, é sugerido combinar a nova API com a API de Compute Pressure — ou seja, a combinação "classe de hardware mais carga observada" foi inicialmente pensada como um cenário padrão, e os anti-bots não precisarão inventar nada.

Separadamente, vale a pena revisar a suposição de que é suficiente coletar uma vez um perfil "bom" e reutilizá-lo por anos. Os navegadores adicionam essas propriedades sem anúncios para os usuários finais: entre o lançamento do Chrome 152 e as primeiras análises públicas, passaram-se semanas em que os perfis entregavam tranquilamente um novo campo, sem suspeitar de nada. Verificar o conjunto de campos faz sentido a cada ciclo de lançamentos, e não uma vez por ano.

O que fazer na prática

1. Capture o valor atual. No console do perfil: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory e a linha do renderizador WebGL. Registre em quartetos, e não um campo por vez — você será verificado exatamente pela combinação.
2. Verifique a categoria com a legenda do perfil. A legenda móvel — primeira a terceira categoria, laptop de baixo custo — segunda a terceira, desktop topo de linha — quarta. Categoria 4 sob a aparência de um antigo Android ou categoria 1 sob a aparência de um MacBook na série M são igualmente suspeitos.
3. Não altere a propriedade diretamente. A substituição através de Object.defineProperty é detectada por rastros de redefinição do getter e pela discrepância com a verdadeira velocidade de execução. Se for para mudar, que seja no nível de construção do navegador ou através de mecanismos embutidos.
4. Lembre-se do override legal. O Chrome dá ao usuário uma opção nas configurações (Performance → Speed → Override CPU performance tier), e aos administradores — uma política corporativa. Isso é útil saber de ambos os lados: o valor pode ser não apenas "real", mas também definido manualmente, e um override massivamente idêntico em um pool de perfis se torna uma marca.
5. Distribua os perfis em diferentes hardwares. Se todos os seus perfis estão em um único servidor, eles terão a mesma categoria — independentemente de quais dispositivos estão representando. Este é o caso em que um parque de várias máquinas de configurações diferentes resolve o problema honestamente, enquanto um patch não.

Mais detalhes sobre um sinal adjacente da mesma família — na análise da impressão digital pelo volume de memória do dispositivo, e sobre navegadores stealth que trabalham com essas propriedades de forma nativa, há benchmark do nodriver, Camoufox e Patchright.

Onde estão os proxies aqui

Para ser direto: proxies não consertam a impressão digital do navegador. cpuPerformance é calculado do lado do cliente, e nenhum IP o mudará. Mas o anti-bot toma decisões com base na soma dos camadas, e é exatamente na interseção das camadas que geralmente ocorre a falha.

A cadeia típica pela qual setups baratos falham é assim: IP de uma rede de hospedagem conhecida, primeira categoria de processador, sinais headless em JS — três sinais independentes, cada um dos quais é tolerável separadamente, mas juntos eles se somam a um veredicto inequívoco. Remover a camada de rede dessa soma é mais barato e confiável do que lutar contra os campos do navegador: com um IP residencial, a solicitação parece tráfego de um provedor doméstico comum, e a hipótese "data center" cai por si só para o detector. Para lendas móveis, a lógica é a mesma — um proxy móvel deve apoiar o perfil móvel, caso contrário, a contradição simplesmente se transfere do processador para a rede.

Resumindo

O Chrome 152 adicionou não tanto uma nova impressão digital, mas uma nova linha na tabela de verificações cruzadas. Dois bits e pouco por si só não revelam ninguém — o que revela é a inconsistência: o dispositivo declarado deve coincidir com a classe do processador, a quantidade de memória, a placa de vídeo, a velocidade de execução e a rede pela qual a solicitação chegou. A auditoria de perfis nesta semana deve começar com uma linha no console e a pergunta "esse hardware realmente existe para quem estamos nos passando?".