Como verificar a consistência do UserAgent? As quatro falhas que um UA incompatível expõe

No site de verificação, o campo do UA aparece normal, mas poucos dias depois do login a conta já recebe um desafio de verificação. A primeira reação de muita gente é trocar o UA de novo ou instalar mais um plugin de troca de UA. O resultado: as anomalias aparecem com ainda mais frequência.

Na maior parte das vezes, esse tipo de problema está na consistência. O UA é um único campo, mas a plataforma o lê em mais de um lugar. Se você altera só um deles, os demais continuam com o valor original, e a comparação entre eles revela a contradição.

O primeiro passo da verificação do UA é conferir se esse campo diz a mesma coisa em todas as superfícies de exposição; só depois vem a etapa de compará-lo com dispositivo, região e outros parâmetros. Este artigo primeiro destrincha os três canais pelos quais a plataforma lê o UA, depois lista os quatro tipos de sinais que um UA incompatível expõe e, por fim, traz uma lista de cinco pontos de conferência, com o método de configuração no navegador antifingerprint.

Os três canais pelos quais a plataforma lê o UA

O mesmo valor de UA é lido pela plataforma em três lugares: cabeçalhos HTTP, cabeçalhos Client Hints e scripts da página. Os três canais são independentes entre si e podem ser conferidos separadamente.

Quando a requisição é enviada, a string de UA no cabeçalho é o canal mais antigo: o site lê esse valor antes mesmo de entregar a página. A partir da versão 89, o Chrome passou a enviar as informações do dispositivo separadamente na série de cabeçalhos Sec-CH-UA. Marca do navegador, plataforma e versão da plataforma ocupam um cabeçalho cada, consultados pelo site sob demanda. A documentação de Client Hints da MDN descreve com clareza a estrutura desses cabeçalhos.

O terceiro canal fica nos scripts da página. navigator.userAgent e navigator.userAgentData reportam novamente, de dentro da página, as informações de navegador e plataforma. Em tese, as três leituras são idênticas palavra por palavra. Se qualquer uma delas for alterada isoladamente, as outras duas não mudam junto.

É exatamente aqui que os plugins de troca de UA tropeçam. A maioria deles substitui apenas a string de UA do cabeçalho; quando o script da página lê o valor, encontra o original, e os dois canais entram em contradição na hora. Detectar esse tipo de discrepância não exige tecnologia sofisticada: basta o script de análise de risco pegar as duas leituras e compará-las.

Falta um contexto importante. O Chrome vem congelando gradualmente as informações da string de UA antiga: a parte final do número da versão já está fixa e mais detalhes migraram para os Client Hints. O espaço para mexer apenas na string de UA está encolhendo, e o alinhamento entre os canais se torna cada vez mais decisivo.

O que um UA incompatível expõe: quatro tipos de sinais

Visto isoladamente, o UA não é verdadeiro nem falso; é dentro do conjunto de sinais que as falhas aparecem. A maior parte das incompatibilidades causadas por problemas de ambiente se encaixa em um dos quatro tipos abaixo.

Primeiro tipo: canais em contradição. O cabeçalho informa Chrome 126, enquanto a leitura do script da página ainda mostra Chrome 118; ou a marca declarada no Sec-CH-UA não corresponde ao que o navigator.userAgentData retorna. Esse tipo de leitura praticamente só tem uma explicação: o UA foi alterado isoladamente, e a mudança não cobriu todos os canais.

Segundo tipo: declaração em contradição com parâmetros de hardware. O UA diz iPhone, mas a tela tem uma resolução de desktop de 1920×1080 e zero pontos de toque; o UA declara Windows, e o renderizador de GPU reporta um chip da Apple. Os parâmetros de hardware são medições lidas do ambiente real, enquanto o UA é um valor declarado que pode ser preenchido à vontade. Quando os dois são colocados lado a lado, a falha salta muito mais aos olhos do que o próprio UA. As causas desse tipo de contradição são detalhadas parâmetro por parâmetro em por que a randomização de fingerprints não é segura.

Terceiro tipo: contradição com a combinação de ambiente. O IP de saída está nos Estados Unidos, mas o UA é de um navegador em chinês, e a lista de idiomas e o fuso horário apontam para outra região. UA, sistema, idioma, fuso horário e IP deveriam compor um mesmo perfil regional. Basta um desses itens desviar para o perfil inteiro ficar suspeito. Esse tipo de contradição não se resolve trocando o UA; o que precisa mudar é a configuração do ambiente.

Quarto tipo: incompatibilidade com as características da camada de transporte. As características deixadas pelo handshake TLS parecem de uma ferramenta automatizada ou de uma versão de navegador muito antiga, enquanto os cabeçalhos informam um Chrome recente. As características da camada de transporte são mais difíceis de disfarçar do que o UA, e para a plataforma conferir se os dois lados são coerentes o custo é baixo.

Dos quatro tipos de sinais, os três primeiros podem ser evitados ainda na fase de configuração do ambiente; o quarto depende da própria forma de acesso. Na checagem do dia a dia, fique de olho nos três primeiros: ao encontrar leituras contraditórias, volte e revise a configuração.

Como fazer a verificação de consistência: cinco pontos de conferência

Não depende de um único site de teste: siga cinco pontos de conferência.

1. Conferência dos canais: abra o ambiente e acesse a página de teste; no painel Network das ferramentas de desenvolvedor, veja o UA e o Sec-CH-UA nos cabeçalhos e compare com a leitura de navigator.userAgent no console. Os três valores precisam ser idênticos.

2. Conferência de hardware: compare item por item o tipo de dispositivo declarado no UA com a resolução de tela, a capacidade de toque, o renderizador de GPU, o número de núcleos e a memória. Se a declaração diz um tipo de dispositivo, as medições precisam corresponder a ele.

3. Conferência regional: verifique se o idioma do UA, a lista de idiomas do navegador, o fuso horário e o IP de saída pertencem a um mesmo perfil regional; em declarações móveis, tudo ainda precisa combinar com as características da rede móvel.

4. Conferência de versão: a versão do navegador no UA deve estar na faixa predominante do mercado-alvo; versão demais atualizada ou presa a uma antiga de vários anos são sinais anormais, e ela também precisa ser coerente com o comportamento do motor.

5. Registro de reavaliação: depois de ajustar a configuração, passe novamente pela página de teste e arquive as leituras de cada rodada. Quando o ambiente apresentar anomalias no futuro, esses registros serão o ponto de partida da investigação.

Quanto às ferramentas, o CreepJS coleta justamente as contradições entre as leituras dos scripts da página e os valores que o navegador declara; teste com ele um ambiente de UA alterado e as contradições entre canais serão apontadas diretamente. Sites de teste abrangentes, como o Browserscan, servem para obter a leitura geral dos cinco parâmetros. Use os dois tipos de ferramenta em conjunto. O UA é apenas um dos sinais de consistência do ambiente; a ordem de checagem do ambiente inteiro tem uma tabela de seis itens no artigo sobre a verificação de consistência antivinculação, que pode ser usada junto com os cinco pontos de conferência daqui.

Emparelhando o UA no navegador antifingerprint

Ao ajustar os cinco pontos de conferência, o caminho mais eficiente é gerar o UA junto com os parâmetros que o acompanham, em vez de preencher cada campo à mão. O MostMate é um navegador antifingerprint com IA, amigável para iniciantes, que prepara um ambiente de navegador independente para cada conta; a consistência do UA cai exatamente dentro do fluxo de configuração de ambiente dele. Antes de começar, vale conhecer o fluxo completo de criação na página de apresentação do MostMate.

Ao criar um ambiente, escolha primeiro o sistema operacional e a versão do navegador, e o User-Agent é gerado em sequência, com opção de edição quando necessário. Idioma, fuso horário e geolocalização vêm, por padrão, no modo “configurado pelo IP”. Escolhido o proxy de saída, esses itens e a combinação regional do UA se alinham automaticamente. O painel de pré-visualização da fingerprint lista em tempo real o User-Agent e os valores atuais dos demais parâmetros: já na criação do ambiente dá para ver se a configuração como um todo se sustenta, sem precisar rodar o ambiente e voltar para corrigir depois.

O nível de granularidade da configuração também fica a seu critério. Nas configurações manuais de fingerprint, onze itens como UA, tela, fuso horário e idioma precisam ser escolhidos um a um; já as configurações recomendadas na página inicial do site geram diretamente um conjunto de ambiente coerente, segundo a lógica do dispositivo. Cada caminho tem seus cenários adequados.

Vale deixar claro o limite. A consistência entre o UA e a configuração do ambiente reduz apenas um tipo de sinal de exposição. Se uma conta será ou não vinculada pela plataforma também depende das regras da plataforma, das relações entre contas e do comportamento de uso; a configuração do ambiente resolve apenas a camada do ambiente.

Perguntas frequentes

Instalei um plugin de troca de UA; por que fico mais fácil de identificar?

O plugin costuma alterar apenas o canal do cabeçalho; o que os scripts da página e os Client Hints leem continua sendo o valor original. Quando surge uma contradição entre os canais, é como se “UA alterado” estivesse escrito nas próprias leituras. A contradição em si é um sinal anormal, mais visível do que não alterar nada.

O número de versão do UA é quanto mais novo, melhor?

Basta que a versão esteja na faixa predominante do mercado-alvo. Uma versão mais nova que a última lançada, ou presa a uma antiga de vários anos, são sinais anormais. A versão também precisa ser coerente com o comportamento do motor; correr atrás da novidade isoladamente não faz sentido.

Um ambiente de desktop pode usar um UA móvel?

Pode, desde que a resolução de tela, a capacidade de toque, a memória do dispositivo e os demais parâmetros sejam configurados em conjunto como os de um dispositivo móvel. Para ver como esses parâmetros se interligam, fingerprint de resolução de tela e tamanho de janela traz uma comparação detalhada.

O site de teste mostra o UA consistente; quer dizer que não há problema?

As leituras dos sites de teste cobrem sobretudo os parâmetros legíveis pelos scripts da página; características da camada de transporte e parte dos detalhes dos Client Hints nem sempre aparecem nelas. É mais seguro concluir depois de percorrer os cinco pontos de conferência.

Considerações finais

O objetivo da verificação do UA é que os três canais e o ambiente como um todo se sustentem mutuamente: canais sem contradição, declaração coerente com as medições de hardware, combinação regional que faça sentido, faixa de versão dentro do razoável. Percorra os cinco pontos de conferência em ordem e a maior parte das falhas na camada do UA poderá ser eliminada antes de o ambiente entrar em operação. Fazer a checagem antes de subir o ambiente é o que custa menos.

Ao criar um ambiente novo, rode essa verificação antes de colocar a conta em operação: economiza muito mais trabalho do que trocar o UA depois que o desafio aparece. Se quiser gerenciar seus ambientes seguindo esse fluxo, baixe o MostMate e, do sistema operacional ao proxy e à conferência da pré-visualização da fingerprint, deixe o UA e o ambiente inteiro configurados de uma vez.