Como Sites Identificam Você: o Guia Completo de Fingerprint do Navegador

O que é fingerprint de navegador, em uma frase

Fingerprint de navegador é a combinação de tudo o que um site consegue medir sobre o seu navegador e o seu dispositivo sem gravar nada na sua máquina e sem pedir permissão. Nenhum valor sozinho te identifica. A combinação, com frequência, identifica.

O jeito clássico de pensar nisso é entropia. Saber que você usa Chrome não estreita quase nada — quase todo mundo usa. Saber o seu fuso estreita um pouco mais. Saber a resolução exata da sua tela, a lista de fontes instaladas, a string do renderizador da sua GPU e o resultado exato de um desenho em canvas estreita enormemente. Cerca de 33 bits de entropia bastam para separar uma pessoa entre todas as vivas, e um fingerprint rico chega desconfortavelmente perto disso sozinho.

Não é teoria. O estudo Panopticlick, da EFF, coletou fingerprints de centenas de milhares de voluntários em 2010 e concluiu que a grande maioria era única dentro da amostra — e isso antes de canvas, WebGL, áudio e Client Hints existirem como sinais. A técnica só ficou mais afiada desde então.

Como sites identificam você sem usar cookie?

Mecanicamente, é sem glamour. Um script roda no carregamento da página, lê uma lista de propriedades, faz um punhado de medições, resume tudo num hash e manda para um servidor. O servidor compara esse hash — ou os componentes individuais — com o que já viu antes. Se bate com um registro existente, você é o mesmo visitante. Se bate em parte, você provavelmente é o mesmo visitante com um detalhe alterado.

A parte interessante acontece do lado do servidor, e é onde a maioria das explicações para cedo demais. Sistemas de detecção sérios não perguntam só "já vi esse fingerprint antes?". Eles fazem mais três perguntas:

• Este fingerprint é coerente por dentro? A plataforma que o user agent declara bate com a plataforma sugerida pela string da GPU, pela lista de fontes e pela pilha de áudio?
• Ele é coerente com a rede? O fuso bate com o país do IP de saída? E o idioma?
• Ele é coerente ao longo do tempo? A assinatura de dispositivo desta conta mudou três vezes esta semana enquanto o login continuou o mesmo?

Essas três perguntas são o motivo de mascaramento grosseiro sair pela culatra. Contradição é um sinal muito mais alto que valor incomum, porque valor incomum acontece naturalmente o tempo todo — gente tem GPU rara e instala fonte esquisita — e contradição, essencialmente, não acontece.

O que vem a seguir é a pilha, camada por camada, do sinal mais barato de ler até o mais difícil de controlar. Cada camada termina com o que olhar no seu próprio resultado.

Camada 1 — cabeçalhos HTTP e user agent

Antes de qualquer script rodar, seu navegador já se apresentou. Toda requisição carrega cabeçalhos: User-Agent, Accept, Accept-Language, Accept-Encoding e, no Chromium moderno, um conjunto de Client Hints como Sec-CH-UA, Sec-CH-UA-Platform e Sec-CH-UA-Mobile.

A string de user agent já foi a história inteira. Não é mais — o Chrome congelou e reduziu essa string de propósito, então ela conta menos do que contava, e o detalhe migrou para os Client Hints. Um site que quiser mais pode pedir os hints de alta entropia (lista completa de versão, arquitetura, versão da plataforma, modelo, arquitetura de bits) e obter um retrato muito mais nítido do que a string congelada oferece.

Duas coisas dessa camada passam batidas com frequência. Primeira: a ordem dos cabeçalhos é um sinal em si — motores diferentes emitem em sequências diferentes, e um cliente HTTP que manda numa ordem incomum se destaca mesmo com todos os valores plausíveis. Segunda: Client Hints e user agent são lidos de lugares diferentes, o que significa que podem discordar — e um Sec-CH-UA declarando Chrome 133 ao lado de um navigator.userAgent declarando Chrome 120 é um sinal de adulteração gratuito e sem ambiguidade.

Camada 2 — canvas e WebGL

É aqui que o fingerprinting para de ler valores declarados e começa a medir o seu hardware.

O fingerprint de canvas funciona pedindo ao navegador que desenhe alguma coisa — normalmente uma linha de texto com uma fonte específica, mais umas formas e gradientes — num canvas fora da tela, e depois lendo os pixels de volta com toDataURL() ou getImageData(). Para um humano, a imagem é idêntica. No nível dos bytes, não: rasterização de fonte, antisserrilhado, arredondamento de subpixel e o próprio caminho de renderização da GPU variam entre máquinas. Resuma esses bytes num hash e você tem um valor estável para uma combinação de hardware e driver, e diferente entre combinações. A técnica foi descrita formalmente em 2012 e está em uso comercial desde então.

O fingerprint de WebGL tem duas formas. A direta pergunta ao WebGL quem ele é: pela extensão WEBGL_debug_renderer_info, a página lê as strings de fabricante e renderizador sem máscara, que numa máquina Windows parecem uma descrição ANGLE nomeando a placa de vídeo real e o backend Direct3D. Os navegadores vêm restringindo progressivamente essa extensão, mas no Chromium desktop ela continua comumente legível. A forma indireta renderiza uma cena 3D e resume o resultado, exatamente como o canvas, mas com mais superfície — somada à lista de extensões suportadas e a valores como o tamanho máximo de textura.

Para uma ferramenta de isolamento de perfil, essa é a camada mais difícil de falsificar de forma convincente, porque o valor precisa ser diferente por perfil e plausível como hardware real e estável entre sessões do mesmo perfil. Erre um desses três e o mascaramento fica pior que não fazer nada. Aprofundamos aqui por que ruído aleatório sai pela culatra.

Camada 3 — áudio e fontes instaladas

Dois sinais mais discretos, que se comportam como o canvas com outra física.

O fingerprint de áudio usa a Web Audio API. Um script monta um grafo curto de processamento — tipicamente um oscilador alimentando um compressor de dinâmica —, renderiza offline sem nunca tocar som e lê de volta as amostras em ponto flutuante. Pilhas de áudio diferentes, comportamento de ponto flutuante diferente e builds de navegador diferentes produzem números microscopicamente diferentes. Some ou resuma tudo e você tem outro identificador estável, que o usuário nunca ouve nem vê.

A enumeração de fontes é mais antiga e continua eficaz, porque o conjunto de tipografias instaladas num computador é surpreendentemente pessoal. Ele reflete a versão do sistema, o pacote de idioma, o pacote de escritório que você instalou, as ferramentas de design que usa, o driver de impressora que veio com fontes junto. Historicamente um script renderizava uma frase de teste numa fonte candidata com uma fonte de fallback conhecida e comparava largura e altura; hoje ele também pode usar document.fonts.check() para chegar à mesma conclusão com menos código. Rode isso contra algumas centenas de nomes candidatos e você tem uma lista quase sempre perto de única.

A armadilha de coerência aqui é específica e comum: um perfil que se declara macOS enquanto informa uma lista de fontes cheia de famílias exclusivas de Windows, ou que declara português do Brasil sem nenhuma cobertura latina estendida. Fontes também são onde uma máquina Linux costuma se entregar, já que o conjunto de fontes do Linux não se parece com o do Windows nem com o do macOS.

Camada 4 — WebRTC e o vazamento de IP

O WebRTC existe para navegadores fazerem voz e vídeo em tempo real sem plugin. Para conectar dois pares atrás de roteadores domésticos, ele usa ICE, que reúne endereços candidatos: interfaces de rede local e um endereço público descoberto perguntando a um servidor STUN "de que IP você me vê chegando?".

Essa última parte é o problema. A troca com o STUN acontece por UDP, direto do navegador — ela não necessariamente segue o proxy HTTP que você configurou. Então uma página pode abrir um RTCPeerConnection, gerar uma oferta, ler os candidatos ICE e descobrir um IP público que o seu proxy deveria estar escondendo. Sem aviso de permissão, sem indicador visível.

O quadro melhorou, e vale ser preciso em vez de alarmista. O Chromium moderno substitui endereços de rede local por nomes .localmDNS aleatorizados por padrão, o que fechou em boa medida o buraco do "seu IP da LAN está exposto" que artigos antigos ainda alardeiam. O que não fechou foi o caminho do endereço público: se o UDP consegue sair direto da sua máquina, o candidato srflx ainda pode revelar um endereço diferente da saída do seu proxy.

Por isso anti-detects tratam WebRTC como configuração por perfil, e não como interruptor de liga e desliga. O AlterAntiX expõe cinco modos — bloquear de vez, informar um endereço falso, informar o real, encaminhar pelo proxy do perfil ou desabilitar UDP — porque a resposta certa depende genuinamente do site. Uma plataforma que espera chamada de vídeo funcionando vai notar o WebRTC ausente; uma que nunca usa não vai se importar. O detalhamento dos cinco modos está aqui.

Camada 5 — TLS e JA3/JA4, a camada que o JavaScript não alcança

Tudo acima acontece depois que a conexão foi estabelecida. Esta camada acontece antes.

O primeiro pacote de qualquer conexão HTTPS é o ClientHello. Ele anuncia as versões de TLS que o seu cliente suporta, a lista ordenada de suítes de cifra, as extensões, as curvas elípticas aceitas e os protocolos de aplicação preferidos via ALPN. Essas escolhas são feitas pela biblioteca TLS compilada dentro do seu navegador, e diferem de forma significativa entre Chrome, Firefox, Safari, curl, requests do Python e o Chromium empacotado dentro de um framework de aplicativo.

O JA3, publicado pela Salesforce, foi a primeira forma amplamente adotada de resumir esse pacote: concatenar versão de TLS, cifras, extensões, curvas e formatos de ponto e resumir a string num hash. O JA4, da FoxIO, é o sucessor moderno e foi desenhado para corrigir a fraqueza do JA3 — o Chrome passou a aleatorizar a ordem das próprias extensões TLS, o que mudava o hash JA3 a cada conexão e o tornava inútil para identificar Chrome. O JA4 ordena as listas antes de resumir, então ordem aleatória não quebra mais, e produz uma string em parte legível por humano em vez de um hash opaco: protocolo e versão de TLS, se o SNI é domínio ou IP, contagem de cifras e de extensões, ALPN e depois hashes truncados das listas ordenadas de cifras e extensões.

A consequência para quem mascara navegador é seca. JavaScript não reescreve o ClientHello. Nenhuma quantidade de ruído em canvas ou de edição de user agent toca nele. Se a assinatura TLS do seu navegador não corresponde a nenhuma build real de Chrome, o detector já sabe que tem algo incomum antes de a sua página pintar um pixel — e quem olha essa camada (Akamai, Cloudflare, DataDome) é exatamente quem está na frente das plataformas que importam para você.

Como esses sinais se somam num placar de risco

Nenhuma plataforma publica o próprio modelo de pontuação, e quem te disser os pesos exatos está chutando. O que dá para observar é o formato do modelo, e ele é consistente entre fornecedores.

Leia a tabela inteira e o padrão fica óbvio: a coluna que decide resultado não é "o quanto cada valor está escondido", e sim "os valores concordam entre si". Quatro das seis falhas típicas são contradições, não exposições.

Existe uma segunda dimensão que vale nomear: estabilidade. Um fingerprint que nunca muda identifica uma máquina. Um fingerprint que muda a cada sessão identifica uma ferramenta. O que passa por normal é um fingerprint que fica igual por semanas e muda um pouco quando o navegador atualiza — o que, aliás, é o motivo de um perfil regerado do zero toda vez que você abre não se parecer nada com o computador de uma pessoa real.

E existe uma terceira, que quase ninguém contabiliza: contexto. O mesmo fingerprint pesa de forma completamente diferente dependendo do que a conta está fazendo. Um perfil recém-criado com um sinal incomum que já sai gastando dinheiro é tratado de um jeito muito diferente de uma conta de dois anos com o mesmo sinal que nunca fez nada surpreendente. É por isso que a resposta honesta para "esse fingerprint é seguro?" é sempre "seguro para quê, em qual conta, com que histórico?" — e por isso ninguém consegue te entregar um limite numérico.

Ou seja: o modelo mental útil não é uma fechadura, é uma balança. Você não está tentando ser indetectável, porque não dá. Está tentando manter o lado técnico da balança quieto o suficiente para que ele nunca seja o que decide a questão.

O que fazer com esse resultado

Rodar o verificador uma vez te dá uma foto. Rodar de propósito te dá um diagnóstico. A sequência abaixo leva uns dez minutos e cada passo é reproduzível — dá para comparar os seus números com o que este artigo afirma.

• Faça a linha de base do seu navegador normal. Abra o verificador de fingerprintno seu Chrome do dia a dia, sem proxy. Guarde hash de canvas, renderizador WebGL, contagem de fontes, fuso e IP. É assim que "você" se parece.
• Recarregue duas vezes. Todos os valores têm que ser idênticos entre recarregamentos. O que mudar sozinho ou está sendo aleatorizado por uma extensão que você esqueceu, ou é genuinamente instável — vale saber nos dois casos.
• Ligue seu proxy ou VPN e recarregue. Agora só o IP e possivelmente o país informado deveriam ter mudado. Se o fuso continua dizendo o seu país enquanto o IP diz outro, você achou na sua própria configuração a contradição da seção anterior.
• Rode o teste de WebRTC com o proxy ligado. Aqui. Se ele informar um endereço que não é a saída do proxy, o vazamento é real e é agora.
• Compare dois perfis isolados. Se você usa alguma ferramenta de perfis, abra o mesmo verificador em dois perfis ao mesmo tempo e compare os resultados. Canvas, WebGL, fontes, tela, fuso e IP têm que ser todos diferentes. O que for idêntico entre os dois é um vínculo entre eles.

Esse último passo é o que separa isolamento real de isolamento cosmético, e é o único teste que responde de fato à pergunta que te interessa: um site concluiria que estes dois perfis são a mesma máquina?

Onde o AlterAntiX entra

O AlterAntiX gera um fingerprint coerente por perfil — navigator, tela, ruído de canvas e de áudio com seed estável por perfil, fabricante e renderizador do WebGL, geolocalização derivada do fuso, Client Hints mantidos em sintonia com o user agent e WebRTC como escolha explícita de cinco modos. Todo perfil abre no próprio Painel de Fingerprint, que lê as APIs do navegador ao vivo e informa o que aquele perfil está emitindo de verdade, apontando divergências como fuso que não bate com o país do IP.

E ele cobre a camada em que este guia termina: um proxy TLS por perfil reemite o ClientHello com presets de Chrome real, com user agents fixados de propósito nas versões que esses presets cobrem, para os dois nunca se contradizerem. As builds de Windows e Linux são gratuitas — baixe aqui. Ainda não existe build para macOS.