WebGPU Atomic Fingerprint: como a placa de vídeo se torna uma nova fonte de dados para sistemas antifraude

Até recentemente, a identificação da GPU em navegadores estava principalmente associada ao WebGL: um site forçava o navegador a renderizar uma determinada cena, analisava o resultado e recebia um sinal adicional para identificar o dispositivo. Navegadores com mecanismos anti-detecção já aprenderam há muito tempo a contornar essas verificações alterando parâmetros declarados, interferindo na renderização, adicionando ruído ou simplesmente alterando o resultado. Com o advento do WebGPU, a história se torna muito mais interessante.

A nova API oferece às páginas da web um acesso muito mais direto ao poder de processamento da GPU — o que significa que a GPU deixa de ser um dispositivo para renderizar imagens e se transforma em uma ferramenta que pode receber tarefas e ser monitorada. Para o combate a fraudes, essa é uma diferença fundamental. Uma coisa é perguntar ao navegador: "Qual placa de vídeo você tem?". Outra bem diferente é atribuir uma tarefa a essa placa de vídeo e observar como o hardware a executa. Essa é exatamente a ideia por trás da Impressão Digital Atômica da WebGPU, discutida no webinar Vektor T13.

Para o usuário comum, a tecnologia é quase invisível. No entanto, para desenvolvedores de navegadores anti-detecção, especialistas em múltiplas contas e, cada vez mais, para a infraestrutura de agentes de IA para navegadores, ela é de grande interesse. Quanto mais a automação de navegadores migra para VPS, máquinas virtuais e data centers, maior se torna a discrepância entre o que o navegador alega estar executando e o hardware em que realmente está. O WebGPU oferece aos sistemas antifraude uma nova maneira de detectar essa discrepância.

A abordagem antiga: perguntar ao navegador quem é.

A identificação clássica de navegadores baseia-se principalmente na leitura de características ambientais: qual navegador, qual sistema operacional, qual resolução de tela, quais fontes estão instaladas, como o Canvas se comporta, qual renderizador WebGL está disponível, quais recursos de hardware o sistema reporta. A fragilidade dessa abordagem é óbvia: se os dados chegam por meio de uma API, sempre haverá uma camada de software entre o site e o dispositivo em si — e essa camada pode, teoricamente, ser modificada.

É exatamente isso que os navegadores anti-detecção fazem: tentam mostrar ao site um conjunto consistente de características que difere da configuração real da máquina. O navegador pode estar rodando em um servidor, mas o site vê o perfil de um computador doméstico comum com Windows e uma placa de vídeo NVIDIA GeForce popular. No nível básico da API, isso parece bastante convincente. Mas se você fizer uma pergunta diferente — não "Que tipo de dispositivo é este?", mas "Deixe o dispositivo descobrir algo" — então o jogo muda completamente.

Por que um hash longo ainda não é uma impressão digital?

Uma das informações úteis do webinar diz respeito a um erro comum ao trabalhar com verificadores de impressões digitais. Se um serviço exibe um hash longo e bem definido ao lado do rótulo "WebGPU", é fácil presumir que se trata de uma impressão digital de hardware exclusiva. Na verdade, a mera presença de um hash não prova nada: um hash é simplesmente o resultado da transformação de um conjunto de dados e, se os dados originais forem praticamente idênticos em milhões de dispositivos, uma sequência aparentemente complexa não se torna um identificador mágico.

Portanto, ao analisar qualquer verificador, é muito mais útil observar não a string final, mas os dados a partir dos quais ela foi compilada. Se um serviço usa um conjunto padrão de limites e recursos do WebGPU, a maioria desses parâmetros será idêntica em um grande número de máquinas — esse hash é conveniente para comparar configurações, mas não pode ser considerado automaticamente uma impressão digital única para uma placa gráfica específica. Daí o hábito simples, porém importante: não pergunte "qual hash o verificador mostrou?", mas sim "o que exatamente ele mede?".

Da declaração ao comportamento

A vantagem do WebGPU é que ele permite transferir parte da coleta de dados de impressão digital do domínio da declaração para o domínio do comportamento. Em vez de ler mais um parâmetro, é possível executar uma tarefa computacional. O teste em questão utiliza shaders de computação e operações atômicas: múltiplas threads paralelas trabalham com um contador compartilhado por meio de Adição Atômica. Para o desenvolvedor médio, isso é simplesmente um mecanismo para sincronizar computações paralelas. Para pesquisadores de coleta de dados de impressão digital, há outro interesse: como exatamente a GPU organiza e agenda esse trabalho paralelo.

Uma placa gráfica moderna não é apenas um conjunto de unidades de computação idênticas: a distribuição de tarefas baseia-se numa arquitetura complexa de hardware e software, e o comportamento resultante é influenciado pela geração da GPU, pelos drivers, pelo agendador de carga, pelas configurações de desempenho e por fatores ambientais. É uma espécie de experimento. O site não pergunta: "Você tem uma RTX 2080?" – ele diz: "Aqui está a tarefa, execute-a", e então analisa o perfil de execução. Essa é a questão: uma declaração pode ser substituída por uma string, mas o comportamento do hardware real é muito mais difícil de simular.

O que isso muda para navegadores com recursos anti-detecção?

Vamos considerar uma configuração típica. O perfil informa ao site que o usuário está trabalhando em um computador doméstico comum com uma placa de vídeo dedicada NVIDIA, o User Agent corresponde ao navegador Chrome padrão do Windows e os demais parâmetros também são cuidadosamente selecionados. No entanto, o navegador está sendo executado em um VPS, que não possui a placa de vídeo especificada. Até certo ponto, essa discrepância pode ser ocultada no nível da API: consultar o modelo da GPU retorna o valor desejado, verificar o renderizador WebGL retorna o resultado correto.

Um teste computacional levanta uma questão diferente: se o hardware alegado realmente existe, por que o comportamento computacional real se assemelha tanto a ele? Isso não significa que um único teste WebGPU possa declarar definitivamente "temos um sistema anti-detecção" — softwares antifraude quase nunca funcionam de forma tão rudimentar. Mas outro sinal forte emerge, e esses são precisamente os sinais necessários para os modernos sistemas de avaliação de risco. O mais interessante aqui não é identificar o modelo da placa gráfica, mas encontrar uma contradição: o navegador alega uma coisa, mas o comportamento do hardware diz outra. São precisamente essas inconsistências internas na identidade digital que interessam cada vez mais aos softwares antifraude.

Por que 70% de precisão é muita coisa?

O webinar cita uma taxa de precisão de identificação de aproximadamente 70% para essa abordagem. Sem uma descrição da metodologia, isso não deve ser considerado uma característica universal de qualquer Impressão Digital Atômica WebGPU, mas a própria formulação da pergunta ilustra claramente a lógica antifraude. Um observador externo poderia pensar: "Apenas 70%? Isso significa que o teste não é confiável." Para fins antifraude, essa lógica é falha — não é necessário um único sinal perfeito com 100% de precisão.

Imagine um sistema que monitora simultaneamente características do navegador, User-Agent, tipo e reputação do IP, ASN, localização geográfica, parâmetros comportamentais, Canvas, WebGL, WebGPU, desempenho da CPU e da GPU, sinais de virtualização e histórico da conta. Cada indicador isoladamente pode estar errado, mas a combinação deles produz um resultado completamente diferente. É como uma investigação: uma única evidência raramente resolve o caso, mas uma dúzia de fatos independentes apontando na mesma direção têm um peso completamente diferente. Portanto, mesmo um sinal de hardware moderadamente preciso se mostra verdadeiramente útil.

Um verificador não é uma ferramenta antifraude.

Este é um ponto crítico para o mercado de navegadores anti-detecção. Um usuário abre um verificador público, vê valores verdes e conclui que o navegador passou no teste. Mas um verificador e um sistema antifraude real resolvem problemas diferentes. Um verificador público precisa fornecer um resultado amigável ao usuário; um sistema real pode nem mesmo divulgar quais sinais coleta e qual peso atribui a cada um. Além disso, não precisa necessariamente comparar sua impressão digital com algum padrão "correto" — basta notar uma combinação estatisticamente incomum de características.

Portanto, ao testar um ambiente anti-detecção, a pergunta correta não é "Passei no verificador?", mas sim "O comportamento real do dispositivo corresponde ao perfil que o site vê?". A diferença entre essas perguntas é enorme.

A aleatorização também deixa uma marca.

Quando surge uma nova impressão digital, a reação inicial do mercado é previsível: ela precisa ser aleatorizada. Isso funciona para alguns tipos de impressões digitais, mas, com características computacionais, surge um problema fundamental. Se a mudança não ocorre naturalmente, no nível do hardware e do driver, mas artificialmente — dentro do navegador —, uma nova camada de comportamento é introduzida. E essa camada também pode ser explorada.

Em vez de perguntar "a impressão digital é idêntica?", o sistema antifraude começa a fazer outras perguntas: quão estável é o resultado, se é consistente com outras características do hardware, se muda plausivelmente entre execuções, se o modelo de GPU declarado é capaz de demonstrar tal comportamento. É uma corrida sem fim: ocultamos um sinal e o sistema começa a analisar o próprio mecanismo pelo qual ele é falsificado. É precisamente por isso que a aleatorização primitiva gradualmente chega a um beco sem saída: para um perfil estável, a consistência interna do ambiente é mais importante do que um resultado aleatório.

O teste não necessariamente utiliza 100% da placa de vídeo.

Há outro detalhe importante. Quando se trata de identificação de GPU por meio de computação, é fácil imaginar um benchmark pesado: as ventoinhas aceleram, a carga da placa gráfica sobe para 100% e o usuário imediatamente percebe que algo está errado. Mas o teste não precisa necessariamente ser pesado. Na demonstração do webinar, o Atomic Fingerprint é executado rapidamente e não causa um pico de carga perceptível — e esse é o ponto crucial.

A identificação por impressão digital não exige uma medição completa do desempenho da GPU; uma pequena tarefa computacional personalizada pode ser suficiente para a identificação. Isso é conveniente para o site: o teste é integrado ao carregamento normal da página, evitando que uma visita à loja online se transforme em uma execução do FurMark, e o usuário pode nem perceber nada. É exatamente por isso que o WebGPU é tão atraente para softwares antifraude: ele permite o acesso a computações de nível relativamente baixo diretamente da página da web, sem a necessidade de instalar um aplicativo separado.

Da gestão de múltiplas contas aos agentes de IA

Há alguns anos, o público principal desse tipo de pesquisa eram desenvolvedores de navegadores anti-detecção, profissionais de marketing de afiliados e especialistas em gestão de múltiplas contas. Agora, uma nova categoria enorme se juntou a eles: os agentes de IA para navegadores. Esses agentes interagem constantemente com sites comuns: buscam informações, preenchem formulários, utilizam SaaS, gerenciam painéis de controle e testam interfaces — geralmente usando Playwright, Chromium e outras estruturas de automação. E tudo isso, na maioria das vezes, não é executado no computador do usuário, mas na nuvem.

Um único servidor pode hospedar dezenas de navegadores: o orquestrador cria e destrói contêineres, as sessões migram entre nós, cada navegador recebe seu próprio perfil e, externamente, todos aparecem como dispositivos separados. Isso geralmente é suficiente para a automação clássica, mas não para a identificação precisa de dispositivos. A identidade lógica do agente começa a divergir da identidade física da máquina: o agente se considera um dispositivo, o perfil do navegador descreve outro, a GPU pertence a uma terceira infraestrutura, o IP vem de uma quarta rede — e tudo isso está simultaneamente disponível para o sistema de avaliação de riscos.

Isso dá origem a uma nova classe de sinais de correlação. Imagine uma plataforma que executa centenas de agentes de navegador em paralelo: cada um com seu próprio perfil, cookies, armazenamento local e resolução de tela; portanto, no nível da aplicação, são 100 usuários independentes. Mas, fisicamente, todos eles podem estar rodando em vários servidores idênticos. E se dezenas de dispositivos supostamente independentes exibirem comportamentos computacionais de baixo nível muito semelhantes, o sistema tem motivos para suspeitar de uma fonte comum de infraestrutura. Para a multi-conta, este é um problema antigo em uma nova forma; para a indústria de agentes de IA, é um problema cuja escala está apenas começando a emergir. E afeta até mesmo aqueles que executam agentes de forma completamente legal: mais cedo ou mais tarde, teremos que entender por que os sites percebem essa infraestrutura como automação suspeita.

Está cada vez mais difícil fazer passar um VPS por um PC comum.

Um servidor virtual é conveniente para quase todos: é barato, está disponível 24 horas por dia, 7 dias por semana, é fácil de clonar e ideal para automação. Mas ele não precisa ter a mesma aparência de um computador de usuário comum — e quanto mais as especificações de hardware se tornam acessíveis por meio de um navegador, mais difícil é ignorar essa diferença. Antes, você tinha que trabalhar principalmente com o que o sistema informava; agora você pode testar como ele realmente se comporta.

O WebGPU Performance mostra um lado da questão — a velocidade de execução de determinadas operações da GPU. O Atomic Fingerprint adiciona outro — o comportamento da execução paralela. E esses testes provavelmente se tornarão mais comuns com o tempo, e não apenas para a placa gráfica: CPU, memória, temporizadores, recursos de agendamento, virtualização, a pilha gráfica — um navegador moderno apresenta uma vasta área para medição.

WebGL veio para ficar.

O webinar original descreve a coleta de dados via WebGL como uma tecnologia que deveria ceder lugar ao WebGPU, e vale a pena esclarecer isso aqui. O surgimento de um sinal mais forte geralmente não significa que o sinal antigo deixe de ser coletado imediatamente: um recurso antifraude adicional e de baixo custo é quase sempre útil. Portanto, é mais correto considerar o WebGPU não como um botão que "substituirá o WebGL", mas como a próxima camada de coleta de dados via hardware. O WebGL oferece um conjunto de recursos, o WebGPU outro, os testes de desempenho um terceiro e o User-Agent e as dicas do cliente um quarto. O sistema antifraude não precisa escolher apenas um; a força do sistema reside na combinação.

Pelo mesmo motivo, a abordagem oposta — desativar completamente o WebGPU — também é ineficaz. Isso é útil como técnica de diagnóstico: você pode comparar o comportamento de um site com e sem a API e determinar se algo depende da sua disponibilidade. Mas, como estratégia permanente, desativá-la é menos eficaz, já que a ausência da tecnologia também é uma característica. Se o WebGPU se tornar um recurso padrão dos navegadores modernos, um perfil com a API completamente desativada poderá se destacar. Além disso, o WebGPU é cada vez mais necessário não para identificação de usuários, mas para gráficos, computação e um número crescente de aplicativos web, incluindo algumas cargas de trabalho de IA diretamente no navegador. Isso leva a uma armadilha conhecida: aumentar indefinidamente a privacidade simplesmente desativando a API não funcionará — em algum momento, o próprio conjunto de recursos desativados se torna uma identificação de usuário.

O combate à fraude não busca o "ruim", mas sim o estranho.

Talvez esta seja a principal conclusão de toda a história do WebGPU. O combate à fraude é frequentemente apresentado como um conjunto de detectores: VPN é ruim, proxy é ruim, incompatibilidade com WebGPU é ruim, automação é ruim. Sistemas reais são mais complexos. Um usuário de rede corporativa está perfeitamente conectado a uma VPN dentro da lei; um desenvolvedor está trabalhando em uma máquina virtual; um serviço de jogos em nuvem fornece uma GPU remota; um agente de IA é, por definição, automação. Portanto, um único fato não é suficiente — o sistema tenta entender o contexto e avaliar a plausibilidade de toda a combinação. E é aqui que ambientes mal configurados começam a apresentar problemas: o navegador afirma uma coisa, a GPU mostra outra, o desempenho uma terceira, o IP conta uma quarta história e o comportamento do usuário uma quinta. Cada característica é aceitável individualmente, mas juntas criam um dispositivo difícil de encontrar no mundo real.

É exatamente por isso que a era das impressões digitais estáticas está gradualmente chegando ao fim. O mercado conviveu por muito tempo com a ideia de que uma impressão digital é um conjunto de valores: hash do Canvas, hash do WebGL, AudioContext, fontes, resolução da tela, concorrência de hardware. Colete esses valores, junte-os e você terá um identificador. Uma tendência mais interessante hoje em dia é a impressão digital ativa, em que um site não apenas pergunta a um dispositivo sobre suas características, mas atribui a ele uma tarefa e monitora sua resposta. Isso se aproxima muito mais da biometria comportamental, exceto que o objeto é um computador em vez de uma pessoa: a velocidade com que uma operação é executada, como a carga paralela é distribuída, a estabilidade do resultado, como o sistema se comporta sob condições variáveis ​​e se tudo isso corresponde ao hardware declarado. Forjar as respostas para essas perguntas é relativamente fácil. Forjar toda a física do comportamento de um sistema é muito mais difícil.

O que isso significa para o mercado?

Para os desenvolvedores de navegadores anti-detecção, a conclusão é bastante desagradável: a coleta de impressões digitais está se tornando cada vez mais próxima da camada de processamento. Simplesmente alterar a API JavaScript não é mais suficiente — quanto mais próxima a medição estiver do comportamento real do hardware, mais difícil será construir uma abstração plausível. Para especialistas em múltiplas contas, isso significa que a qualidade da infraestrutura está se tornando mais importante do que o número de opções na interface anti-detecção: um indicador verde por si só não garante nada. As equipes de arbitragem devem avaliar o risco da infraestrutura separadamente da qualidade do IP e do perfil do navegador — um proxy residencial caro não resolve inconsistências no nível do dispositivo.

Para os desenvolvedores de agentes de IA, o problema é ainda mais amplo: eles precisam projetar não apenas a inteligência do agente, mas também sua interação com o ambiente digital externo. Se milhares de navegadores autônomos operarem na nuvem, os sites inevitavelmente aprenderão a distinguir essa infraestrutura dos dispositivos de usuários comuns. Isso não significa necessariamente bloqueio — com o tempo, mecanismos adequados para identificar agentes legítimos podem surgir. Mas, até que isso aconteça, a automação do navegador existirá dentro de uma infraestrutura historicamente projetada para humanos — e o software antifraude percebe essa contradição.

WebGPU é apenas o começo.

A própria Impressão Digital Atômica não deve ser vista como uma tecnologia nova e universal que eliminará os navegadores antifraude amanhã. A tecnologia antifraude evolui de forma diferente: um novo sinal surge, é analisado, então surgem métodos de normalização e proteção, a tecnologia antifraude aprende a analisar esses métodos e, então, outra fonte de informação é descoberta. O WebGPU é mais importante como um indicador direcional. O navegador está se tornando uma plataforma computacional cada vez mais poderosa, o que significa que um site pode não apenas ler informações sobre um dispositivo, mas também experimentar com ele.

Para especialistas, isso muda completamente a abordagem da identificação de dispositivos. A questão principal não é mais "O que o navegador reporta sobre o computador?", mas sim "O comportamento do computador corresponde ao que o navegador reporta?" — e a diferença entre os dois é enorme. No mundo das impressões digitais estáticas, era possível focar nos valores corretos; no mundo da identificação ativa, é preciso pensar no comportamento correto de todo o ambiente. Portanto, o WebGPU Atomic Fingerprint interessa até mesmo àqueles que nunca planejaram escrever seu próprio verificador de GPU: ele demonstra claramente para onde o antifraude moderno está caminhando — da verificação de parâmetros individuais à verificação da consistência interna do dispositivo. Para um profissional de marketing de afiliados, isso significa que analisar apenas endereços IP e indicadores verdes não é mais suficiente; para um desenvolvedor de sistemas antifraude, significa que a fronteira entre o navegador e o hardware está se tornando cada vez mais importante; para um engenheiro de agentes de IA, significa que a própria infraestrutura de execução está se tornando parte da identidade do agente. E para o antifraude, é mais uma maneira de fazer ao dispositivo uma pergunta simples: "Você é realmente o computador que afirma ser?"