User-Agent explicado: De UA strings e impressões digitais do navegador até Client Hints

Abra o painel de Rede nas ferramentas de desenvolvimento do seu navegador e quase sempre você encontrará um cabeçalho User-Agent. Parece uma breve introdução: qual navegador está fazendo a solicitação, em qual sistema operacional ele roda e qual versão afirma ser.

Isso torna tentador tratar o cabeçalho como um ID de dispositivo — ou assumir que mudar uma linha pode transformar um navegador em outro dispositivo. Ambas as ideias estão apenas parcialmente corretas.

Uma cadeia de User-Agent, ou UA, é uma informação de compatibilidade declarada pelo cliente. Não é uma credencial de identidade confiável, e um cliente pode modificá-la. No entanto, não existe isoladamente. Um site pode comparar a UA com Client Hints, APIs JavaScript, propriedades da tela, fontes, Canvas, WebGL, contexto da rede e comportamento. A questão útil, portanto, não é apenas se um UA pode ser alterado, mas qual papel ele desempenha na superfície observável completa do navegador.

Este artigo utiliza padrões de HTTP e pesquisas de fingerprinting no navegador para responder quatro perguntas:

1. Por que uma UA string parece um pedaço de arqueologia de navegador?
2. Quanta informação identificativa UA pode contribuir e como devemos interpretar a pesquisa?
3. Por que mudar apenas a UA pode criar uma inconsistência mais óbvia?
4. O que UA Reduction e User-Agent Client Hints realmente mudaram?

Neste artigo, UA significa principalmente o cabeçalho da solicitação HTTP User-Agent. Também discutimos navigator.userAgent e navigator.userAgentData em JavaScript. Essas interfaces são relacionadas, mas não permanentemente idênticas em todos os navegadores e contextos.

1. O que é um User-Agent?

Seção 10.1.5 do RFC 9110 define User-Agent como um campo contendo informações sobre o agente de usuário que originou a solicitação. Sua gramática simplificada é:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

Em linguagem simples, a string começa com um nome de produto e pode incluir uma versão. Mais produtos ou comentários podem vir a seguir. O padrão reconhece usos como soluções alternativas de interoperabilidade, diagnósticos e análises, mas também aconselha as implementações a não revelarem detalhes desnecessários: um UA mais longo e específico aumenta tanto o tamanho da requisição quanto o risco de impressão digital.

Um UA moderno Chromium desktop pode se parecer assim:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

Dividir a sequência por espaços revela vários nomes que parecem não ter relação com Chrome:

Token	O que isso geralmente significa hoje	Uma leitura errada comum
Mozilla/5.0	Um token histórico de compatibilidade	O navegador deve ser Firefox ou um produto Mozilla
Windows NT 10.0	Uma categoria Windows plataforma; um UA reduzido não pode distinguir de forma confiável Windows 10 de 11	O computador deve rodar Windows 10
Win64; x64	Uma pista de que isso é Windows de 64 bits em uma arquitetura x86-64	Ele comprova o modelo físico exato da CPU
AppleWebKit/537.36	Uma linhagem de motor e token de compatibilidade	Chrome ainda usa a implementação completa do Safari
KHTML, like Gecko	Linguagem de compatibilidade histórica	Tanto KHTML quanto Gecko estão rodando
Chrome/145.0.0.0	A família Chrome/Chromium e a versão principal; Componentes de versões inferiores podem ser reduzidos	Ele revela a versão precisa do patch
Safari/537.36	Um token mantido para compatibilidade com sites antigos	O navegador deve ser Safari

O UA ficou prolixo porque os primeiros sites frequentemente se ramificavam com nomes de navegadores. Navegadores novos precisavam alegar compatibilidade com produtos antigos para receber a página correta. Essas declarações se acumularam ao longo do tempo, criando um registro histórico que não pode ser lido literalmente.

A primeira regra da análise sintática UA é, portanto, simples: é um protocolo de compatibilidade, não uma descrição rígida do dispositivo.

2. Por que os sites ainda utilizam UA?

UA não é usado apenas para rastreamento. Usos legítimos incluem:

• servindo como recurso para um navegador mais antigo com um problema de compatibilidade conhecido;
• selecionar um instalador ou formato de download apropriado;
• encontrar falhas específicas de versão nos logs de diagnóstico;
• medindo distribuições amplas de famílias de navegadores, plataformas e versões principais;
• identificando combinações impossíveis em tráfego automatizado ou malicioso.

O problema começa quando UA sniffing passa de um recurso de compatibilidade restrita para capacidade de adivinhação pelo nome do produto. O código pode ver Chrome e assumir que existe uma API específica. Essa suposição pode falhar em um WebView incorporado, um navegador derivado de Chromium, um navegador com política empresarial, um UA congelado ou um cliente que mudou seu cabeçalho.

Uma ordem de operações mais robusta é:

1. Teste diretamente a API ou comportamento necessário sempre que for possível detectar capacidades.
2. Quando a identificação do navegador é inevitável, use um parser mantido em vez de uma expressão regular ad hoc.
3. Armazene apenas as categorias grosseiras que o produto realmente precisa.
4. Forneça um plano B para marcas desconhecidas, versões desconhecidas e campos ausentes.

3. UA é uma impressão digital do navegador?

Mais precisamente, UA é uma entrada para uma impressão digital do navegador, geralmente não a impressão digital completa.

A impressão digital do navegador não requer um número de série secreto. Ele mede uma coleção de atributos relativamente estáveis e distintivos expostos pelo navegador. UA contribui com pistas sobre a família, versão e plataforma dos navegadores. Dimensões da tela, fontes, fuso horário, Canvas, WebGL, AudioContext e outras interfaces adicionam mais informações.

A pesquisa realizada por Laperdrix e colegas, Browser Fingerprinting: A Survey, discute essas técnicas como uma forma de reconhecimento apátrida. Um site não precisa necessariamente escrever um Cookie primeiro; Ele pode tentar associar visitas aos atributos que um navegador expõe. "Sem estado" não significa que o servidor não armazene nada. Isso significa que o material de reconhecimento não depende de um identificador persistente do lado do cliente.

1. O que significa o resultado de 10 bits do artigo?

No estudo de 2010 Panopticlick How Unique Is Your Web Browser?, Peter Eckersley analisou cerca de 470.000 impressões digitais de navegadores. O jornal informou que:

• a impressão digital completa carregava em média cerca de 18,1 bits de informações identificativas nessa amostra;
• Colocando intuitivamente, uma impressão digital média ocorreu aproximadamente uma vez em 286.777 navegadores;
• a tabela reportava cerca de 10,0 bits de informação média apenas para a cadeia de UA;
• entre navegadores com Flash ou Java ativado, 94,2% das impressões digitais completas eram únicas.

Autoinformação é comumente escrita como:

I(x) = -log₂ P(x)

Se um determinado UA ocorre com probabilidade 1/1024 em uma população, observá-lo fornece 10 bits de informação. Isso não significa que UA tenha exatamente 1.024 valores possíveis ou que identifique uma pessoa de forma única. Ele descreve quanto de incerteza essa observação elimina, em média.

2. Por que o resultado de 2010 não é constante na web atual?

O resultado continua importante, mas precisa de pelo menos três qualificações:

• Visitantes de uma página de teste de privacidade não eram uma amostra aleatória de todos os usuários da internet;
• A diversidade de navegadores, plugins e versões UA em 2010 diferia muito do ecossistema atual;
• UA Reduction, a redução das superfícies dos plugins e as proteções anti-impressão digital mudaram a distribuição dos atributos observáveis.

O estudo apoia a afirmação de que UA e outros atributos podem contribuir com informações distintivas mensuráveis. Isso não apoia dizer que um UA sempre tem exatamente 10 bits de entropia hoje. A potência de impressão digital depende da população, janela de tempo, políticas do navegador e da combinação dos sinais.

4. Por que mudar só UA pode sair pela culatra?

UA é uma declaração do cliente sem prova criptográfica. Um servidor não pode ler a veracidade de fábrica de um dispositivo a partir desse cabeçalho. No entanto, pode verificar se diferentes observações são razoavelmente compatíveis.

Suponha que um UA afirme ser um navegador móvel, mas a página não observe pontos de contato, uma janela que consistentemente se assemelha a uma tela de desktop e Client Hints que reportem uma plataforma desktop. Qualquer observação pode ter uma exceção legítima. Várias contradições estáveis juntas ainda podem formar um padrão classificável.

O artigo Panopticlick já documentou casos comparáveis: alguns navegadores afirmavam ser um iPhone enquanto suportavam Flash, e alguns Firefox UAs apareceram junto com recursos de armazenamento disponíveis apenas no Internet Explorer. O [estudo FP-Scanner] de 2018(https://www.usenix.org/conference/usenixsecurity18/presentation/vastel) examinou esse problema de forma sistemática. Algumas extensões anti-impressão digital e ferramentas de falsificação introduziram inconsistências entre interfaces, permitindo que um detector identificasse atributos modificados e, em alguns casos, inferisse o navegador original ou a família de sistemas operacionais.

Nem toda inconsistência é maliciosa. Áreas de trabalho remotas, ferramentas de acessibilidade, políticas empresariais, camadas de compatibilidade e hardware incomum podem criar combinações incomuns. Um sistema de risco cuidadoso deve tratar uma inconsistência como evidência probabilística, não como uma razão automática para bloquear um usuário.

Para gerenciamento de perfis de navegador, três propriedades importam:

• Consistência interna: UA, Client Hints, plataforma, arquitetura, toque e sinais de tela não devem se contradizer diretamente.
• Estabilidade ao longo do tempo: Um perfil duradouro não deve mudar drasticamente em todo lançamento sem um motivo.
• Diversidade plausível: perfis podem diferir, mas combinações raras geradas mecanicamente não são necessariamente mais seguras.

O estudo FP-STALKER também mostrou que alterar atributos não impede automaticamente a ligação. Um modelo pode usar atributos estáveis e mudanças plausíveis de versão para conectar impressões digitais anteriores e posteriores.

5. Qual problema UA Reduction resolve?

Uma UA tradicional é enviada com quase todos os pedidos. Qualquer endpoint de primeira ou terceira parte que receba a solicitação pode lê-la passivamente. Quanto mais precisa a sequência, mais informações distintivas cada destinatário obtém por padrão.

O plano User-Agent Reduction da Chromium reduz essa granularidade padrão:

• A partir do Chrome 101, as versões menores, de build e patch para desktop foram reduzidas a 0.0.0;
• fases posteriores versões unificadas do sistema operacional de desktop, detalhes da CPU e informações Android dispositivos;
• um Android UA reduzido usa valores fixos de plataforma e modelo, como Android 10; K;
• Sites que realmente exigem mais detalhes podem solicitar User-Agent Client Hints.

O formato reduzido pode ser resumido como:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

A redução diminui a superfície passiva de impressão digital do UA legado. Isso não elimina a impressão digital do navegador. A versão principal, a plataforma ampla e o estado móvel podem permanecer visíveis, enquanto outras APIs, propriedades de rede e comportamento ainda podem fornecer informações.

6. Como User-Agent Client Hints funcionam?

O mecanismo geral é definido em RFC 8942, enquanto o WICG User-Agent Client Hints rascunho descreve campos específicos de UA. A abordagem divide informações que antes existiam em uma cadeia não estruturada em campos estruturados, distinguindo pistas de baixa entropia que podem ser enviadas por padrão das dicas de alta entropia que um site normalmente solicita explicitamente.

Um pedido inicial simplificado pode ser assim:

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

Se o servidor realmente precisar de arquitetura e bitness para selecionar um instalador, ele pode responder com:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

Quando o navegador suporta o mecanismo e os requisitos de segurança e políticas forem atendidos, uma solicitação posterior pode incluir:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

Os UA Client Hints comuns incluem:

Campo	Propósito típico	Nível de informação
Sec-CH-UA	Lista de marcas e principais versões	Geralmente baixa entropia
Sec-CH-UA-Mobile	Se o cliente prefere uma experiência móvel	Geralmente baixa entropia
Sec-CH-UA-Platform	Categoria ampla de plataforma	Geralmente baixa entropia
Sec-CH-UA-Arch	Arquitetura da CPU	Alta entropia; solicitação quando necessário
Sec-CH-UA-Bitness	Bitness da arquitetura	Alta entropia; solicitação quando necessário
Sec-CH-UA-Platform-Version	Versão da plataforma	Alta entropia; solicitação quando necessário
Sec-CH-UA-Full-Version-List	Versões completas para marcas reportadas	Alta entropia; solicitação quando necessário
Sec-CH-UA-Model	Modelo do dispositivo	Alta entropia; solicitação quando necessário

Três detalhes de engenharia são fáceis de ignorar.

1. Client Hints nem todos são enviados automaticamente

Pistas de baixa entropia podem aparecer por padrão. Pistas de alta entropia geralmente exigem uma resposta Accept-CH. Navegação inicial, subrecursos, política de permissões, transporte seguro e suporte ao navegador podem afetar o que chega. Um servidor deve permitir que todos os campos opcionais estejam ausentes.

2. A lista de marcas testa deliberadamente a robustez do parser

Sec-CH-UA pode conter várias marcas e uma marca sintética usada para testar a compatibilidade. O código não deve assumir que a primeira entrada é sempre o nome do produto, e não deve falhar quando uma marca desconhecida aparece. Analise o campo estruturado, ignore as entradas que você não reconhece e deixe espaço para futuras marcas.

3. Respostas que variam em dicas precisam de tratamento correto do cache

Se arquitetura, plataforma ou outra dica mudar a resposta, configure corretamente Vary ou uma estratégia de chave de cache equivalente. Caso contrário, um cache compartilhado pode servir conteúdo gerado para uma classe de dispositivo para outra.

7. Os Client Hints são mais privados do que os UA tradicionais?

Eles melhoram a forma como as informações são expostas, mas não garantem imunidade contra impressão digital.

A UA tradicional revela um grande feixe não estruturado de forma passiva e por padrão. Client Hints dividir esse pacote em campos, tornar os pedidos de informações com maior entropia mais explícitos e dar ao navegador a oportunidade de aplicar controles de política, permissão ou orçamento de privacidade.

No entanto, arquitetura, versões completas, versões de plataforma e modelos de dispositivos ainda podem aumentar a distinção. RFC 8942 trata explicitamente privacidade e desempenho como restrições de projeto. Os desenvolvedores devem perguntar:

• Esse recurso realmente exige a área?
• A detecção de capacidades ou uma escolha do usuário pode substituí-la?
• O aplicativo pode armazenar apenas uma categoria grosseira?
• Por quanto tempo os valores brutos são mantidos e quem pode acessá-los?
• Recursos terceirizados receberão as mesmas dicas?

8. Orientação de engenharia para manuseio de UA do lado do servidor

1. Nunca use UA como prova de identidade ou autoridade

UA podem suportar opções de apresentação e opções de compatibilidade. Não deve determinar identidade, autorização, trust de pagamento ou um limite de segurança. Um valor controlado pelo cliente não pode servir como credencial de controle de acesso.

2. Preferência detecção de capacidades às listas de navegador

Quando uma interface precisa de uma API, teste essa capacidade diretamente:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

A detecção de capacidades lida melhor com navegadores derivados, recursos experimentais, políticas empresariais e lançamentos futuros do que uma regra como "habilitar isso para Chrome 145."

3. Aceitar UA, Client Hints e estados desconhecidos legados

Durante a migração, um servidor pode receber apenas a UA legada, tanto UA quanto Client Hints, ou formas altamente reduzidas de ambas. O modelo de dados deveria permitir unknown, em vez de adivinhar, um modelo exato de sistema operacional ou dispositivo para preencher todos os campos.

4. Reduzir a granularitária logarítmica

Se analytics precisar apenas de desktop versus mobile, família de navegador e versão principal, não mantenha cadeias brutas de UA e todas as dicas de alta entropia indefinidamente. A minimização de dados reduz o risco de privacidade e impede que um pipeline de análise trate variações menores como uma dimensão significativa.

5. Tratar anomalias como evidência, não veredictos

Um UA que afirma Windows enquanto uma API se comporta diferente é, no máximo, um único sinal de risco. Ambientes empresariais, virtualização, sessões remotas, camadas de compatibilidade e tecnologias assistivas podem gerar anomalias legítimas. Transformar um descompasso em uma decisão automática de fraude gera falsos positivos.

9. Como UA devem ser configurados em ambientes de múltiplos perfis?

Para testes interregionais, prévias de publicidade, operações de contas e isolamento de privacidade, o objetivo não deve ser criar a UA mais incomum. Um perfil deve ser explicável, estável e compatível com o ambiente ao seu redor.

Revise o seguinte em ordem:

1. Versão do navegador: A versão UA principal deve ser plausível para o motor real e suas capacidades.
2. Sistema operacional: A UA plataforma, a Client Hints plataforma e a categoria JavaScript-visível da plataforma devem ser compatíveis.
3. Arquitetura e bitness: UA, Client Hints e o ambiente executável não devem fazer afirmações diretamente conflitantes.
4. Formato do dispositivo: Uma declaração móvel deve fazer sentido junto com suporte ao toque, viewport, proporção de pixels e padrões de interação.
5. Contexto regional: idioma, fuso horário, geolocalização e saída do proxy não precisam coincidir mecanicamente, mas devem fazer sentido para o fluxo real de trabalho.
6. Estabilidade do perfil: Quando uma conta ou identidade de teste reutiliza um perfil de longa duração, evite trocar de plataforma e de versão principal sem motivo.

A conversão atual de perfil da PurpleMark mapeia o sistema operacional selecionado para uma plataforma UA e primeiro tenta extrair a versão do navegador de um token Chrome/ ou CriOS/ configurado. Quando não existe uma versão utilizável, ela deriva um recurso razoável em relação à versão principal do motor atual. O objetivo não é falsificar uma string isolada, mas sim colocar UA configuração dentro de um modelo consistente de perfil de navegador.

O isolamento de perfis e a consistência dos parâmetros podem reduzir correlação técnica e viés de teste. Eles não podem garantir que as contas nunca serão vinculadas, e não substituem regras da plataforma, dados de conta, informações de pagamento ou práticas operacionais responsáveis. Use essas capacidades apenas para proteção legal de privacidade, testes legais e atividades empresariais em conformidade.

10. Perguntas frequentes

P1: Mudar UA transforma o navegador em outro navegador?

Não. Isso altera parte do que o cliente declara. Ele não substitui o motor JavaScript, pipeline de renderização, pilha de rede ou APIs Web suportadas.

P2: Um site pode ler a "verdadeira UA"?

Não existe uma "UA real universal em nível de hardware" que todo site possa ignorar o navegador para ler. Um site, no entanto, pode comparar Client Hints, testes de capacidade e outros sinais de impressão digital, encontrar afirmações incompatíveis e fazer uma inferência probabilística.

P3: Um UA reduzido pode distinguir Windows 10 de Windows 11?

A redução do UA legado normalmente não pode fazer isso de forma confiável porque ambos podem relatar Windows NT 10.0. Um navegador que suporta UA Client Hints pode fornecer informações mais detalhadas sobre a versão da plataforma após o site solicitá-las. Os servidores ainda precisam lidar com campos ausentes e diferenças de mapeamento.

P4: Desabilitar JavaScript para UA exposição?

Não completamente. O HTTP User-Agent é um cabeçalho de solicitação e pode ser enviado junto com a solicitação de página antes da rodagem da página JavaScript. Desativar JavaScript remove algumas superfícies de coleta, mas também quebra partes substanciais da web moderna.

P5: Client Hints substituirá completamente User-Agent?

Não presuma isso no curto prazo. Muitos clientes e servidores ainda dependem do UA legado, enquanto UA Client Hints suporte varia. Trate Client Hints como aprimoramento progressivo: prefira informações estruturadas quando disponíveis, mas mantenha reservas para UA antigos e estados desconhecidos.

P6: Um UA gerado aleatoriamente melhora o anonimato?

Não necessariamente. Randomizar um campo pode criar contradições com versão, plataforma, toque e sinais de renderização. Para um perfil de longa duração, uma configuração comum, estável e internamente compatível geralmente é mais defensável do que mudanças aleatórias frequentes.

11. Conclusão

User-Agent não é uma credencial de identidade confiável nem uma cadeia irrelevante. Ela está situada na interseção entre compatibilidade web, privacidade e análise de riscos. Para os desenvolvedores, é uma entrada de compatibilidade sobrecarregada pela história. Para pesquisadores em impressão digital, é um atributo com informações estatísticas mensuráveis. Para os fornecedores de navegadores, é uma superfície de exposição padrão que precisa ser reduzida.

As ideias-chave se encaixam em três afirmações:

• Não leia um UA literalmente; Ele contém muitos tokens históricos de compatibilidade.
• Não avalie UA isoladamente; O reconhecimento prático vem das combinações de sinais e sua evolução ao longo do tempo.
• Não pense Client Hints apenas como "mais UA campos"; seu valor reside na divulgação estruturada, orientada por requisições e governável.

Quando um sistema passa de identificar o nome de um navegador para testar a capacidade necessária — e de coletar todos os detalhes disponíveis para solicitar apenas o necessário — UA retorna ao seu papel correto: uma pista de compatibilidade, não uma verdade de identidade.

Referências e padrões

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.