Seu navegador está seguro? Um guia dos testes de vazamento e fingerprint

Você configurou a VPN, desativou o GPS, ativou o kill switch e se sente o Edward Snowden da sua sala. Aí entra num site aleatório e ele te cumprimenta em português, sugere a loja da sua cidade e já assume seu fuso horário. Estranho, né? Não é. Seu navegador entregou tudo e nem precisou do IP pra isso.

A verdade é que IP é só um dos vetores. Idioma, WebRTC, IPv6, fuso horário, canvas, fontes, resolução de tela: cada um desses é uma migalha que, somada, forma uma impressão digital única. VPN só esconde o IP, não esconde o resto.

Se você ainda acha que a barra “conectado” resolve tudo, releia VPN não é o suficiente e lembre que seu provedor te vê mais do que você imagina.

Este post é um checklist. Primeiro, onde testar o quanto você está vazando. Depois, como fechar as torneiras no Brave e no Mullvad no desktop Linux, o papel do Tor Browser, e o que usar no Android: Brave como principal, e a briga Fennec vs Cromite pra secundário.

Antes de tudo: vazamento e fingerprint não são a mesma coisa

“Vazamento” virou palavra guarda-chuva e isso atrapalha na hora de ler os resultados. Vale separar em duas famílias, porque a defesa de cada uma é completamente diferente.

Vazamento de rede. Algum dado sai por um caminho que contorna a camada que você configurou. A VPN está ativa mas o DNS ainda vai pro provedor. O túnel encapsula IPv4 e o IPv6 escapa pela interface nativa. O WebRTC abre UDP direto e entrega seu IP real. Aqui existe certo e errado objetivos: ou vazou, ou não vazou.

Fingerprinting. Nada “vaza” no sentido literal. O site apenas combina dezenas de características legítimas do navegador (fontes instaladas, resolução, renderização de canvas, versão do WebGL, fuso) até montar um identificador estável que dispensa cookie. Aqui não existe aprovado ou reprovado, existe grau de raridade e consistência.

Confundir as duas leva a conclusão errada. “Seu navegador é único entre 300 mil” não significa que a VPN falhou. E DNS vazando não se resolve instalando extensão anti-fingerprint.

Parte 1: onde testar (o arsenal de dedo-duro)

Regra antes de sair clicando: teste com a VPN ligada e desligada, compare, e use sempre o teste estendido quando disponível. Um resultado “verde” com VPN não significa nada se você não sabe qual era o “vermelho” sem ela.

Mais alguns cuidados que mudam o resultado:

• Teste no perfil que você usa de verdade. Janela anônima limpa mede um navegador que você não usa. Faça as duas medições se quiser comparar, mas a que importa é a do dia a dia.
• Um navegador por vez. Resultado de Brave, Mullvad e Fennec não é intercambiável, nem entre perfis do mesmo navegador.
• Feche o resto. Extensão sincronizando, cliente de e-mail, torrent: tudo isso polui o teste de DNS.
• Repita depois de cada atualização grande. Navegador que atualiza reseta flag, cliente de VPN que atualiza muda regra de rota. Já vi as duas coisas acontecerem.

IP, DNS, WebRTC e IPv6 (os vazamentos clássicos)

IPv6: o que mais quebra em silêncio

Boa parte das VPNs encapsula IPv4 e, no melhor caso, bloqueia IPv6; no pior, deixa o tráfego v6 sair pela interface nativa. Como praticamente toda operadora residencial brasileira já entrega IPv6, o site pode simplesmente preferir o v6 e enxergar seu endereço real enquanto o painel da VPN mostra “conectado”.

Se o ipleak.net ou o test-ipv6.com mostrarem um IPv6 com o prefixo da sua operadora, é vazamento, ponto final. Ou a VPN suporta IPv6 de verdade, ou ela bloqueia v6 por completo. Meio termo aqui é o pior dos mundos.

DNS: tudo funciona, e é por isso que ninguém percebe

O resultado esperado depende do seu desenho de rede. Se você usa o resolver da VPN, deve aparecer só o ASN dela. Se usa NextDNS ou DNSCrypt local, deve aparecer o provedor escolhido e o perfil certo.

O test.nextdns.io é o mais direto de todos, porque devolve JSON:

{
	"status": "ok",
	"protocol": "DOH",
	"profile": "fp3c610bc5d9319252",
	"client": "2804:7f0:6941:756b::1002",
	"clientName": "nextdns-cli"
}

"status": "unconfigured" significa que suas consultas não estão passando pelo perfil que você acha que configurou.

Um detalhe que confunde muita gente: o navegador pode ter DNS próprio. Firefox e Chromium implementam DoH internamente e ignoram a configuração do sistema quando isso está ativo. Você pode ter DNSCrypt impecável no Linux e o navegador resolvendo tudo pela Cloudflare sem te avisar. Teste o navegador, não só o sistema. A parte de sistema eu cobri na série de DNS criptografado.

WebRTC: o vazamento que sobrevive à VPN

WebRTC é a API de comunicação em tempo real do navegador (videochamada, áudio, transferência peer to peer). Pra funcionar atrás de NAT, ela precisa descobrir todos os endereços da sua máquina e, pra isso, consulta servidores STUN por UDP. Esse tráfego pode sair fora do túnel.

Teste em browserleaks.com/webrtc e leia assim:

• Public IP address. Se aparecer seu IP residencial com a VPN ligada, é vazamento crítico. Só deveria aparecer o IP da VPN, ou nada.
• Local IP address. Endereços privados (192.168.x.x, 10.x.x.x) expõem a topologia da sua rede interna. Navegador moderno substitui isso por um identificador mDNS terminado em .local, que é o comportamento correto.
• IPv6 candidates. Mesma armadilha da seção anterior, agora por outro caminho.

A correção fica na Parte 2, por navegador.

TLS, ECH e criptografia de transporte

ECH (Encrypted Client Hello). Sem ele, mesmo com HTTPS e DNS criptografado, seu provedor vê o SNI, ou seja, qual site você acessa. Já disseco isso em SNI Leak: o calcanhar de Aquiles do DNS seguro.

Lembre que o ECH depende de DNS criptografado pra funcionar: o navegador precisa buscar a chave pública no registro DNS do tipo HTTPS. Sem DoH ativo, o Firefox nem tenta. Dá pra conferir se um site publica a chave:

dig +short HTTPS esli.blog

1 . alpn="h3,h2" ipv4hint=104.21.15.52,172.67.161.182 ech=AEX+DQBB0AAg... ipv6hint=2606:4700:3036::ac43:a1b6

O campo ech= presente significa que o servidor suporta. Ausente significa que, pra aquele domínio, seu SNI continua em texto claro por mais bem configurado que esteja o seu lado.

O fingerprint que quase ninguém testa: JA3 e JA4

Antes de qualquer HTTP, seu cliente TLS anuncia a lista de cipher suites que suporta, as extensões, a ordem delas, os grupos de curvas. Essa combinação é estável o suficiente pra identificar o software, e às vezes a versão exata. É o JA3 (formato antigo) e o JA4 (o atual):

{
  "user_agent": "curl/8.18.0",
  "ja4": "t13d3513h2_bfa337485184_8d7351bd871b"
}

Por que importa na prática: o JA4 desmente o User-Agent. Se você usa uma extensão que finge ser Chrome no Windows enquanto o seu JA4 é o do Firefox no Linux, você não ficou anônimo, ficou raro. A inconsistência é mais identificável que a verdade.

Não existe correção simples aqui, e é justamente esse o recado. Fingerprint de TLS é propriedade da implementação, não configuração. O caminho é usar um navegador comum, com a stack TLS padrão dele, sem mascarar User-Agent na mão.

Fingerprint e rastreamento

O BrowserLeaks continua sendo o mais útil da lista justamente porque não te dá um número: ele mostra o hash de canvas, o renderer do WebGL (que costuma entregar o modelo exato da sua GPU), a lista de fontes detectadas, o fingerprint de áudio e as APIs de mídia. Vale percorrer a barra lateral inteira uma vez na vida.

O CreepJS merece destaque separado: em vez de medir raridade, ele procura contradição. Cruza o que o navegador declara com o que o comportamento revela e aponta onde você está mentindo. Se você usa privacy.resistFingerprinting ou o escudo do Brave, é o teste que mostra se o disfarce está consistente.

(O deviceinfo.me, que já foi padrão nessa lista, está fora do ar. O domínio ainda resolve, mas o servidor não responde.)

O vetor esquecido: relógio

Fuso horário é fingerprint, e a hora do sistema é atacável na rede. Se o Intl.DateTimeFormat do seu browser entrega America/Sao_Paulo, adivinha de onde você é. Padronizar isso também é parte do jogo (juntamente com autenticar a própria sincronização), assunto que cobri em NTS: por que você precisa autenticar a hora do seu Linux.

Pra medir fuso, locale e formatação de data isoladamente: arkenfox.github.io/TZP.

Android: camada de apps (aqui o bicho pega)

No celular o vazamento raramente é só o navegador. São os apps despejando telemetria por baixo do pano.

O PCAPdroid é o que fecha a discussão: se você acha que algo vaza, capture e olhe os pacotes. Chutômetro não é diagnóstico.

Checklist rápido

Como ler os resultados sem se enganar

“Único entre 250 mil” não é sentença de morte. No Tor Browser e no Mullvad Browser a estratégia é uniformizar: todo mundo parece igual, então a métrica de raridade fica boa. No Brave a estratégia é randomizar: o fingerprint muda a cada sessão e por site, então o teste pode acusar unicidade justamente porque a defesa está funcionando. Rode duas vezes em abas diferentes; se o hash mudou, a randomização está ativa.

Consistência importa mais que raridade. Fingerprint comum e coerente esconde melhor que fingerprint raro e contraditório. É por isso que empilhar extensão “anti-detect” costuma piorar o resultado.

Nenhum teste mede o que você faz logado. Dá pra zerar todos os vazamentos técnicos e continuar identificado porque você entrou na sua conta.

O painel da VPN não é evidência. “Conectado” quer dizer que o túnel subiu, não que todo o tráfego passa por ele.

Parte 2: refinando o Brave e o Mullvad no desktop (Linux)

Por que esses dois? Porque, segundo a grade do PrivacyTests.org, são os que passam mais testes de proteção prontos pra uso, como já argumentei em Qual o melhor navegador. O site não publica score agregado, mas a contagem reportada pelo PCMag (run #95) coloca o Brave em ~143/156 e o Mullvad em ~141/156, empatados no topo, à frente até do Tor Browser em bloqueio puro (o Tor ganha em anonimato de rede, que é outra briga). Ou seja: o melhor dos dois mundos é usar cada um pro que ele serve.

Brave: o daily driver blindado

brave://settings/shields

• Trackers & ads: Aggressive
• Fingerprinting: Block (Strict/aggressive)
• Upgrade connections to HTTPS: Strict

brave://settings/privacy

• WebRTC IP Handling Policy: Disable Non-Proxied UDP, que fecha o vazamento de IP via STUN
• Bloqueie cookies de terceiros
• Desative P3A, “diagnostic reports” e o Web Discovery Project (telemetria, mesmo que “anônima”)
• “Forget me when I close this site”: ligado nos domínios que importam

brave://settings/security

• Secure DNS: aponte pro seu resolver (NextDNS/Quad9 via DoH). No desktop faz sentido; no mobile, se a VPN já cuida do DNS, é escolha sua

Tem muito mais escondido nas brave:// internas, já mapeei o que vale em Explorando funções avançadas no Brave Browser. E antes que você perca tudo num reinstall: Sync não é backup.

Opcional mas recomendado: uBlock Origin por cima do escudo nativo, pra ter controle fino de filtros. E a janela Tor (New private window with Tor) pra quando precisar de .onion sem sair do Brave.

Depois de mexer, volte no browserleaks.com/webrtc e confirme. A configuração só vale se aparecer na medição.

Mullvad Browser: o anti-fingerprint de fábrica

Aqui a regra é o oposto do Brave: não mexa. O Mullvad entrega um fingerprint padronizado de propósito pra todo mundo parecer igual. Cada “melhoria” ou alteração sua te torna único, que é exatamente o que você não quer. (Se quiser o contexto da empresa por trás, escrevi Mullvad: privacidade sem marketing, sem conta e sem desculpas.)

• Não instale extensões. Cada uma é um bit de entropia
• Não maximize nem redimensione a janela. O letterboxing existe pra padronizar a resolução reportada, e quebrar isso te denuncia
• Não instale fontes nem faça login em contas
• Não fuce no about:config. O resistFingerprinting já vem afinado; você só vai desregular
• Ajuste o nível de segurança pelo escudo (Standard/Safer/Safest) conforme o site
• Pareie com VPN. O Mullvad Browser não tem anonimato de rede: sem VPN, seu provedor vê os destinos igual a qualquer outro navegador. Ele cuida do browser, a VPN cuida da rede

Resumindo a divisão de trabalho: Brave pra vida diária (compatibilidade + bloqueio agressivo), Mullvad pra quando fingerprint importa mais que conveniência.

E os outros?

• Firefox comum, Tor Browser e Mullvad Browser: pra matar o WebRTC de vez, em about:config defina media.peerconnection.enabled como false. Chamada de vídeo no navegador para de funcionar, é o preço. No Mullvad e no Tor, isso é dos poucos ajustes que valem a pena, porque não altera fingerprint visível.
• Chrome e Chromium puros: não existe controle nativo equivalente ao do Brave. A extensão oficial que fazia isso foi descontinuada. Se WebRTC te preocupa e você usa Chrome, o caminho realista é trocar de navegador ou bloquear UDP no firewall.

Parte 3: Tor Browser, quando privacidade não basta e você quer anonimato

Brave e Mullvad te dão privacidade. O Tor Browser te dá anonimato de rede, coisa que nenhuma VPN entrega, porque numa VPN você só troca o observador (o provedor) por outro (o provedor da VPN). O Tor roteia por três saltos, cada um cego pro anterior, e ninguém no caminho vê origem e destino ao mesmo tempo.

O que ele faz que os outros não fazem:

• Fingerprint uniforme por design. É a mesma base do Mullvad Browser, só que com a rede Tor acoplada. Timezone em UTC, locale en-US, tela padronizada. Aquele redirect regional automático simplesmente não acontece
• Sem correlação de IP. O site vê o IP do exit node, que muda e não é seu
• Acesso a .onion. Serviços que nem existem na web comum. Aliás, na minha opinião, todo site deveria ter um endereço na rede Tor

Os contras:

• É lento. Três saltos custam latência. Não é daily driver
• Muito site bloqueia exit nodes. CAPTCHA infinito, 403, o pacote completo
• Não mexa nele. Maximizar janela, instalar extensão, mudar about:config: cada ajuste quebra a uniformidade e te torna rastreável. A regra do Mullvad vale em dobro aqui
• Não te salva de você mesmo. Logar na sua conta pessoal dentro do Tor mata o anonimato na hora. E o Tor protege o tráfego do browser, não do resto do device

Em rede hostil ou sob censura, o Tor tem pontes e transportes plugáveis. O mais prático pra emprestar sua banda a quem precisa é o Snowflake, cobri o funcionamento em Snowflake: proxy temporário para contornar a censura.

No Android: existe Tor Browser for Android (oficial, via F-Droid ou Play). Pra rotear o sistema inteiro pela rede Tor, o Orbot funciona como VPN local. Ambos já fazem parte do meu kit no celular.

Regra prática de quando puxar cada um:

Parte 4: Android, Brave como principal, Fennec vs Cromite

O Mullvad Browser não existe pra Android (sim, uma tristeza). O Brave segue como principal, com o mesmo endurecimento do desktop e mais dois detalhes que só existem no mobile:

• Idioma: coloque en-US no topo. Isso muda o header Accept-Language e mata aquele redirect automático pro .com.br mesmo com VPN em outro país
• Trave o vazamento no nível do SO: Configurações do Android → VPN → (seu provedor) → VPN sempre ativa + Bloquear conexões sem VPN. É isso que impede IPv6 nativo de escapar do túnel
• WebRTC: Disable non-proxied UDP; Secure DNS desligado se a VPN cuida do DNS (ou aponte pro NextDNS). Pra DNS criptografado no Android sem depender do navegador, tem o InviZible Pro e alternativas

Mas todo mundo devia ter um secundário: pra compartimentar identidades, pra abrir o que quebra no principal, e pra não colocar todos os ovos num engine só. E é aqui que entram Fennec e Cromite.

Os dois candidatos

Cromite, sucessor espiritual do Bromite. Chromium sem telemetria, com adblock nativo e mitigações de fingerprint ligadas por padrão. Leve, rápido, “Chromium limpo” sem o circo de rewards/cripto do Brave.

Fennec, o Firefox do F-Droid, degoogled, sem os binários proprietários da Mozilla. Aceita about:config completo e add-ons (leia-se uBlock Origin). Engine Gecko, não Chromium.

Ajustes que importam no Fennec (about:config):

• privacy.resistFingerprinting → true (padroniza timezone pra UTC e locale pra en-US, de novo, mata o redirect regional na raiz)
• media.peerconnection.enabled → false (desliga WebRTC de vez)
• webgl.disabled → true se você tolera perder alguns sites
• geo.enabled → false

Qual escolher como secundário?

Fennec. E o motivo é puramente estratégico: meu principal (Brave) é Chromium/Blink, e um bom secundário não deve repetir o mesmo engine. O Fennec é Gecko, e isso me dá duas coisas que o Cromite não dá:

1. Diversidade de engine. Fingerprint diferente por construção, e um fallback de renderização real pra quando um site quebra no Chromium (acontece mais do que deveria)
2. resistFingerprinting de verdade. A mesma linhagem de defesa do Tor/Mullvad, algo que nenhum Chromium mobile replica com a mesma profundidade

O Cromite é ótimo, mas como secundário ele é redundante no eixo que importa: continua sendo Chromium, igual ao Brave. Ele brilha noutro papel: quando você precisa de um segundo Chromium especificamente (algum site que só vai bem em Blink) e não quer o peso nem os extras do Brave. Aí sim, Cromite entra como “Chromium limpo de plantão”.

Detalhe: resistFingerprinting pode brigar com layout e quebrar alguns sites. É o mesmo problema do Mullvad no desktop, padronização custa conveniência. Se isso te incomoda mais do que o ganho de privacidade compensa, aí o Cromite vira secundário aceitável. Mas pro objetivo de secundário de verdade, Fennec ganha.

Uma nota: escolher Firefox em 2026 exige olhar pra Mozilla com ceticismo, o que motivou Mozilla sob ataque: o que aconteceu com o Firefox. A graça do Fennec é justamente pegar o engine do Firefox sem a bagagem corporativa da Mozilla.

Bônus: testando pela linha de comando

Pra checar o host rapidamente, sem abrir navegador:

#!/usr/bin/env bash
# leak-check.sh - auditoria rapida de saida da maquina

echo "== IPv4 =="
curl -s -4 https://ip.me

echo "== IPv6 =="
curl -s -6 https://ip.me || echo "sem saida IPv6"

echo "== Cloudflare trace =="
curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc|tls|sni|warp)='

echo "== DNS (NextDNS) =="
curl -s https://test.nextdns.io

echo "== JA4 do curl =="
curl -s https://tls.browserleaks.com/json | grep '"ja4"'

Uma ressalva importante: esse script mede o host, não o navegador. O JA4 retornado é o do curl e o DNS é o do sistema. Serve pra validar VPN, rota e resolver do sistema operacional, que é onde a maioria dos problemas de rede realmente está. Pro navegador, não tem jeito, é preciso abrir as páginas de teste nele.

O que nenhum desses testes pega

Vale delimitar o escopo, porque teste passado gera confiança, e confiança mal calibrada é pior que nenhuma.

Análise de tráfego. Volume, tempo e padrão de acesso continuam visíveis mesmo com ECH e DNS cifrados. Existe pesquisa madura de website fingerprinting em cima só disso.

Tudo que não é navegador. Aplicativo de celular, cliente de e-mail, atualizador do sistema, telemetria de IDE. No Android o PCAPdroid cobre esse buraco; no desktop, é wireshark e paciência.

Correlação por conta. Login é identificação voluntária. Nenhum teste técnico protege contra isso.

Extensões. Uma extensão maliciosa lê a página depois que o TLS terminou. Todos os testes vão passar.

O que muda amanhã. Atualização de navegador reseta preferência, atualização de cliente de VPN muda regra de rota. Por isso teste é rotina, não evento único.

Fechando as torneiras

Não existe navegador perfeitamente privado, existe o navegador certo pro seu modelo de ameaça:

• Brave endurecido, o dia a dia
• Fennec, secundário, engine diferente, compartimentação
• Mullvad Browser (desktop), quando fingerprint importa mais que conveniência
• Tor Browser + Orbot, quando você precisa de anonimato, não só privacidade

E o hábito importa: existe uma diferença enorme entre “configurei DNS criptografado” e “verifiquei que as consultas saem cifradas pelo resolver certo”. A primeira frase é intenção e a segunda é engenharia. Reserve vinte minutos, rode a bateria uma vez, anote os resultados em algum lugar e repita a cada dois ou três meses, ou depois de qualquer mudança grande de navegador, VPN ou rede. Vazamento é quase sempre regressão: algo que já funcionou e parou, e você só descobre comparando com a medição anterior.

Teste, compare, ajuste, teste de novo. E pare de confiar cegamente na barra “conectado” da VPN: ela esconde o IP, não o resto do seu device gritando quem você é. O IP era só o começo, agora você tem o encanamento inteiro mapeado.

Leitura relacionada aqui no blog

Fundamentos

• Não confie no seu provedor de internet
• VPN não é o suficiente
• Qual a melhor VPN · Qual o melhor navegador
• Guias de privacidade e segurança online · Privacidade e segurança em 2025

DNS, SNI e a hora

• Série DNS criptografado: parte 1, DNSCrypt e DNS Stamps · parte 2, dnscrypt-proxy no Linux · parte 3, Android e InviZible Pro
• SNI Leak: o calcanhar de Aquiles do DNS seguro
• NTS: por que você precisa autenticar a hora do seu Linux

Navegadores e Tor

• Explorando funções avançadas no Brave · Sync não é backup no Brave
• Mullvad: privacidade sem marketing
• Mozilla sob ataque: o que aconteceu com o Firefox
• Snowflake: contornar a censura · Todo site deve ter um endereço na rede Tor
• Como fugir das propagandas na internet

Contexto

• Vigilância governamental: Five Eyes, MLAT e outros