Após o congelamento do User-Agent, por que Client Hints é o novo sinal de fingerprint? A evolução de UA para CH

Nos últimos anos, os principais navegadores vêm reforçando suas políticas de privacidade: o Safari lançou o ITP, o Firefox introduziu o Total Cookie Protection e o Chrome avançou oficialmente com o congelamento do User-Agent (UA Reduction). Muita gente ainda acredita que “mudar o UA” basta para fazer um dispositivo parecer outro, sem perceber que o UA já foi bastante simplificado e está perdendo detalhes. O sinal que assume um papel cada vez mais importante na identificação de dispositivos é Client Hints (CH).

Este artigo não ensina nenhum método para “burlar detecção”. Ele parte apenas dos princípios técnicos para esclarecer três pontos: por que o UA está sendo congelado? O que exatamente é Client Hints e por que ele é considerado um sinal de fingerprint de alta entropia? Por que a chamada “consistência do fingerprint” é o que realmente importa? Isso ajuda a entender por que a gestão moderna de ambientes de navegador, especialmente no isolamento de múltiplas contas, precisa tratar todos os parâmetros como um conjunto coerente e não como campos independentes.

1. Por que a string de UA deixou de ser suficiente?

Por muito tempo, User-Agent foi a principal informação usada pelos sites para identificar navegadores e dispositivos. Ele expõe dados como marca e versão do navegador, sistema operacional e arquitetura do dispositivo. Porém, como as strings de UA eram longas e estáveis, elas podiam ser usadas com facilidade para fingerprinting. Por isso, o Chrome anunciou explicitamente a redução gradual do UA: manter apenas informações básicas, como a versão principal, e transferir mais detalhes para um novo mecanismo, o Client Hints.

A consequência direta do congelamento do UA é que falsificar apenas o UA já não convence. Os sistemas não confiam somente nele; também verificam se outros campos estão alinhados com o UA. Os sinais mais óbvios de inconsistência são parâmetros contraditórios, por exemplo:

• O UA informa macOS 14, mas o campo de versão da plataforma informa macOS 13;
• O UA declara um dispositivo móvel, mas o indicador móvel continua como ?0;
• A arquitetura de hardware aparece como arm64, enquanto valores como navigator.hardwareConcurrency parecem mais compatíveis com x86.

Em sistemas de identificação de dispositivos, contradições como essas podem indicar rapidamente que o perfil não corresponde a um dispositivo real. É por isso que “mudar apenas o UA” já não funciona na era do User-Agent congelado.

2. O que é Client Hints e por que ele é um fingerprint de alta entropia?

Client Hints (CH) é um conjunto de informações sobre capacidades do dispositivo que o navegador pode revelar ao servidor sob demanda por meio de requisições HTTP ou do ambiente JavaScript. Há duas diferenças principais em relação ao UA:

1. Ele inclui campos de alta entropia (High Entropy Values). Alta entropia significa que a combinação dessas informações pode ser bastante distintiva e difícil de adivinhar, como a versão exata da plataforma, uma lista completa de marcas e versões e a arquitetura do dispositivo. Navegadores reais retornam esses valores conforme a necessidade, em vez de expor tudo de uma só vez.

2. CH não é analisado isoladamente; ele é conferido em conjunto com outros fingerprints. Sistemas reais de identificação normalmente verificam se CH combina com o UA, se CH e fingerprints da camada de transporte, como TLS JA3/JA4, correspondem ao mesmo tipo de navegador, se CH é coerente com propriedades JavaScript como navigator.platform, concorrência e proporção de pixels do dispositivo (DPR), e se combina com as características da plataforma do sistema operacional.

Isso leva a um conceito essencial: o difícil não é alterar um campo isolado, mas fazer todos os campos parecerem originados do mesmo dispositivo real. Quase qualquer campo pode ser modificado individualmente. O verdadeiro desafio é fazer marca, versão da plataforma, UA, DPR, memória, arquitetura, fingerprint TLS e outros sinais formarem um perfil de dispositivo coerente. É por isso que muitas configurações que parecem “preencher todos os campos” ainda podem ser facilmente percebidas como inconsistentes.

3. Quais são os erros mais comuns de consistência do fingerprint?

Quando entendemos que a consistência é o ponto central, fica fácil enxergar por que muitas configurações de parâmetros dão errado. Erros comuns incluem:

• CH não combina com o UA (o caso mais comum): o UA informa macOS 14.1, mas CH retorna uma versão de plataforma que na prática nem existe;
• UA móvel com indicador móvel ?0: em um dispositivo móvel real, o normal seria ?1;
• Derivação incorreta da lista de versões completas: por exemplo, a versão principal do navegador é 120, mas as características da versão completa parecem as de uma versão antiga 115;
• DPR, memória e outros valores entram em conflito com o tipo real de dispositivo: por exemplo, um dispositivo Apple mostra uma proporção de pixels anormalmente baixa ou um computador Windows comum informa apenas 1 GB de memória;
• As diferenças entre navegadores são ignoradas: por exemplo, forçar um campo em um navegador que não o suporta ou retornar em determinado motor um campo que ele nunca exporia.

Essas contradições são bastante visíveis nos sistemas de identificação de dispositivos. No fundo, todas resultam de não tratar o ambiente como um conjunto coerente.

4. Então, o que significa uma “configuração correta”?

Em vez de pensar em “preencher campos”, é melhor pensar em manter um perfil de ambiente coerente. Isso normalmente exige alguns cuidados:

• Vincular CH ao UA: derivar o conjunto correspondente de CH — marca, plataforma e versão — seguindo as regras reais do motor e da versão do navegador, e não combinando valores aleatórios;
• Respeitar a estratégia de retorno dos campos de alta entropia: fornecer por padrão informações de baixa entropia, retornar valores de alta entropia sob demanda como faria um navegador real e não retornar campos que o navegador atual não suporta;
• Manter propriedades JS, cabeçalhos HTTP e características do sistema coerentes entre si: DPR deve fazer sentido com a resolução da tela, memória com o tipo de plataforma, indicador móvel com o UA e arquitetura com todo o restante do perfil do sistema;
• Coordenar também o fingerprint da camada de transporte: características como TLS/JA3/JA4 devem ser compatíveis com a versão de navegador declarada.

Em uma frase: a verdadeira dificuldade é fazer CH, UA, ambiente JavaScript e características do sistema formarem um perfil coerente de comportamento do navegador, não simplesmente aumentar o número de campos preenchidos.

5. O que isso tem a ver com gestão de ambientes para múltiplas contas?

Quem trabalha com e-commerce internacional, publicidade em redes sociais ou lojas independentes pode se perguntar qual é a relação entre esses princípios técnicos e “criar ambientes de navegador separados para diferentes contas comerciais”. A relação é direta: a gestão de ambientes só faz sentido quando cada ambiente é internamente coerente.

• Quando existem muitas contas e regiões, em vez de montar manualmente UA, sistema operacional, resolução e outros parâmetros em cada ambiente, é melhor deixar a ferramenta gerar automaticamente um conjunto de parâmetros alinhados com o sistema e a versão do motor escolhidos, reduzindo retrabalho causado por alterações isoladas que entram em conflito.
• Contas comerciais de regiões e plataformas diferentes devem ter ambientes independentes e com parâmetros internamente coerentes, em vez de todas compartilharem os mesmos “parâmetros de modelo” e acabarem parecendo anormalmente semelhantes no nível do dispositivo.
• Ao trocar o proxy para outra região, manter versão do sistema, modelo do dispositivo e outras características como uma configuração coerente do próprio ambiente se aproxima mais do comportamento de um dispositivo real do que “mudar apenas o IP e deixar todos os outros parâmetros exatamente iguais”.

Esses são justamente os problemas de consistência que ferramentas de gestão de ambientes de navegador para múltiplas contas procuram resolver. Ao criar um ambiente, o PurpleMark oferece um ponto único de configuração para sistema operacional, versão do motor Chromium, User-Agent, resolução, fuso horário, idioma, CPU/memória, Canvas, WebGL, TLS e outros parâmetros de dispositivo e fingerprint. Depois de escolher uma região e a finalidade da conta, é possível gerar o ambiente segundo um esquema coerente, em vez de improvisar parâmetros a cada login. O que ele realmente administra é a consistência geral e a reutilização da conta, do ambiente de navegador e da configuração de rede em um único espaço de trabalho, e não formas de enganar um mecanismo específico de detecção.

6. Resumo

O congelamento do UA marca uma nova fase do fingerprinting de navegadores: o que importa não é mais apenas quais campos existem, mas se eles são coerentes entre si. À medida que Client Hints assume o papel de sinal de alta entropia, entender a relação entre CH, UA, características do sistema e fingerprints de transporte é mais importante do que memorizar uma grande lista de nomes de campos.

Se você mantém apenas algumas contas comerciais reais e em conformidade com as regras, não há necessidade de concentrar esforços em combater sistemas de detecção. Uma abordagem mais prática é usar uma ferramenta de gestão de ambientes como o PurpleMark para manter região, sistema e parâmetros de navegador de cada conta claros, coerentes e reutilizáveis, reduzindo na origem os problemas causados por configurações contraditórias.

(Observação: este artigo tem finalidade exclusivamente educativa sobre os princípios técnicos do fingerprinting de navegadores. Sempre opere em conformidade com os termos de serviço de cada plataforma e utilize contas legítimas.)