← Voltar ao blog

Como o BrowserLeaks detecta? 11 testes e a ordem completa de verificação

Ao abrir a página inicial do BrowserLeaks, você vê uma longa fila de testes: IP, Canvas, WebGL, fontes, TLS. Há quem clique do primeiro ao último item, gaste mais de uma hora e feche a página sem lembrar o que cada um apontou. Há também quem teste só a página de IP e encerre por ali. Os parâmetros coletados pelos scripts da página ficam intocados.

Nenhum dos dois jeitos produz uma conclusão estável. O problema está na ordem: as leituras não se cruzam e, mesmo depois de testar tudo, continua difícil dizer se o ambiente tem alguma falha.

Este artigo organiza os 11 testes principais do BrowserLeaks em três grupos (saída de rede, leitura da página e declarações de conexão): primeiro o que cada grupo mede, depois uma ordem completa que vai da saída até o handshake. Todas as páginas abrem e rodam direto no navegador.

Estrutura do site: um teste por página, divididos em três grupos

A proposta do BrowserLeaks é dedicar uma página a cada dimensão de teste, com a home como entrada. Para quem usa navegador antifingerprint, a rotina diária passa pelos 11 testes principais; itens extras como detecção de filtragem de conteúdo, media queries CSS e detecção de extensões entram conforme a necessidade. Os testes de plugins antigos como Flash e Java foram descontinuados e podem ser ignorados.

Os 11 itens se dividem em três grupos pela origem da leitura: o primeiro verifica por onde a requisição sai, o segundo o que os scripts da página leem, e o terceiro as declarações do handshake da conexão. Antes de tudo, uma tabela geral:

Item de testeO que medeO que conferir em várias contas
IP Address (/ip)IP de saída e localizaçãoSe confere com a configuração do proxy
DNS Leak Test (/dns)Caminho da resolução de domíniosSe a resolução contornou o proxy
WebRTC Leak Test (/webrtc)Endereços expostos via WebRTCSe o IP real vazou
Geolocation API (/geo)Leitura de geolocalização do navegadorCompatível com a região do IP
JavaScript (/javascript)Motor de script e informações básicasLeitura condizente com versões atuais
Canvas Fingerprint (/canvas)Hash da imagem CanvasEstável em testes repetidos
WebGL Report (/webgl)Fabricante e modelo da GPUAlinhado ao perfil do dispositivo
Font Fingerprinting (/fonts)Lista de fontes e tamanhos renderizadosQuantidades e idiomas sem contradição
ClientRects (/rects)Precisão das posições dos elementosLeituras consistentes no mesmo ambiente
Client-Hints Test (/client-hints)Marca e plataforma nos cabeçalhosBate com a leitura dos scripts
TLS Client Test (/tls)Criptografia no handshakeCompatível com o kernel declarado

O que observar em cada grupo

O primeiro grupo é o da saída, com quatro itens que respondem à mesma pergunta: a requisição realmente sai pelo proxy? O /ip mostra o IP e a localização, o /dns revela se a resolução de domínios contornou o proxy, o /webrtc verifica se o navegador vazou o endereço real pelo canal WebRTC e o /geo mostra a leitura de geolocalização. Se o grupo da saída apontar vazamento, pause os demais testes e volte para corrigir o proxy e as configurações do ambiente.

Na dúvida sobre qual nível de WebRTC escolher, o artigo configurações de WebRTC em navegadores antifingerprint detalha os cenários de cada um dos três níveis. Para os critérios de julgamento do caminho de resolução, o guia de detecção de vazamento de DNS traz o fluxo completo.

O segundo grupo é o de leitura, com cinco itens ligados aos parâmetros de ambiente que os scripts da página obtêm. O /javascript informa o motor de script e as leituras básicas. /canvas, /webgl, /fonts e /rects são, respectivamente, as fontes de fingerprint da renderização de imagem, da placa de vídeo, das fontes e da posição dos elementos. Neste grupo confira duas coisas: se as leituras condizem com o perfil do dispositivo e se permanecem estáveis em testes repetidos no mesmo ambiente.

Sobre a lógica de renderização e a interpretação do hash, o guia de Canvas fingerprint aprofunda o tema.

O terceiro grupo é o de declarações, com dois itens para verificação cruzada. A página client-hints mostra a marca e a plataforma declaradas nos cabeçalhos, para conferir se formam o mesmo conjunto das leituras dos scripts. O /tls mostra as características de criptografia do handshake, para confrontar com a versão de kernel declarada. Esses dois itens precisam das leituras dos dois primeiros grupos como referência; isolados, não revelam problemas. Por isso ficam por último.

Diagrama da distribuição dos 11 testes do BrowserLeaks em três grupos

Como ordenar: três rodadas

A ordem segue as dependências: saída primeiro, leitura no meio, declarações no fim.

1. Primeira rodada: verificação da saída: rode /ip, /dns, /webrtc, /geo. Se o proxy não estiver ativo ou houver vazamento, pare e corrija a rede antes de seguir. Testar os itens de fingerprint sem isso não serve para nada.

2. Segunda rodada: verificação da leitura: rode /javascript, /canvas, /webgl, /fonts, /rects. Confira item por item a consistência com o perfil e a estabilidade no mesmo ambiente, anotando as anomalias.

3. Terceira rodada: verificação das declarações: rode /client-hints, /tls. Use as leituras das duas rodadas anteriores como referência e confirme que declarações, scripts e handshake estão alinhados.

O nível de detalhe das três rodadas acompanha o peso do ambiente. No dia a dia, um ambiente novo conclui a primeira rodada mais /canvas e /webgl em poucos minutos; para contas críticas antes de entrar em operação, rode as 11 verificações completas e registre as leituras com a data no arquivo do ambiente, de modo que futuras mudanças de configuração tenham histórico para consultar.

Os três sites de detecção podem dividir o trabalho com a mesma lógica: o Whoer entrega uma pontuação geral, ideal para a checagem rápida diária; o Browserscan fornece um retrato dos parâmetros, útil para conferir em inspeções; o BrowserLeaks trata um item por página, ideal para investigar problemas específicos. Quando a pontuação parecer estranha, percorra a sequência das três rodadas para localizar a página com problema. Se a pontuação estiver baixa mas não ficar claro onde os pontos foram perdidos, consulte primeiro a composição da nota no guia de detecção do Whoer. Depois volte e refaça as rodadas correspondentes, o que economiza tempo em comparação com retestar às cegas.

Onde isso entra na configuração de ambientes do MostMate

As leituras de detecção acabam se convertendo em configuração do ambiente. O MostMate é um navegador antifingerprint em que os ambientes são criados um a um por conta, com dados isolados entre si; a maioria das 11 leituras encontra sua origem no formulário de criação.

Os quatro itens do grupo de saída correspondem às configurações de proxy e ao nível de WebRTC. O proxy é gerenciado em uma lista própria e depois distribuído aos ambientes. O WebRTC pode ficar real, bloqueado ou personalizado.

Configuração do WebRTC no MostMate

Os cinco itens do grupo de leitura correspondem aos parâmetros das configurações de fingerprint. Idioma, fuso horário e geolocalização são gerados por padrão no modo "baseado no IP". Tela, núcleos e memória assumem valores reais ou níveis especificados. As entradas do grupo de declarações são a escolha do sistema operacional e da versão do navegador. O UA é gerado conforme a seleção e pode ser editado depois. Para conferir se as duas declarações vêm da mesma fonte, basta voltar à página client-hints.

Fingerprint baseado no IP no MostMate

O painel de pré-visualização do fingerprint já lista os valores de cada parâmetro na criação do ambiente, e contradições evidentes são corrigidas na hora, sem esperar que a página de detecção as descubra. Para ver o fluxo completo de criação, consulte antes a página de apresentação do MostMate. A detecção e a configuração alinham os sinais da camada de ambiente; se as contas serão correlacionadas pela plataforma depende também das regras da plataforma e do comportamento de uso.

Diagrama das três rodadas de verificação, da saída às declarações

Perguntas frequentes

O BrowserLeaks exige cadastro? É pago?

Não é preciso cadastro: as páginas de teste rodam automaticamente ao abrir e os testes principais são gratuitos. A receita vem da oferta de APIs de dados a terceiros; o usuário comum pode simplesmente entrar e testar.

É preciso rodar os 11 itens todas as vezes?

No dia a dia, não. A primeira rodada do grupo de saída mais dois ou três itens de leitura cobre a maior parte dos riscos em poucos minutos. Antes de colocar ambientes críticos em operação, ou quando as leituras não baterem entre si, rode as 11 verificações completas.

O mesmo ambiente deu resultados diferentes em dois testes. É normal?

Avalie item por item. O hash do Canvas, a lista de fontes e o IP de saída devem ser estáveis; leituras diferentes em testes repetidos indicam um problema de configuração. Pequenas oscilações em itens de exibição dinâmica não configuram anomalia.

BrowserLeaks ou Whoer, qual usar?

Eles não competem. O Whoer entrega uma pontuação geral, boa para a checagem rápida diária; o BrowserLeaks trata um item por página, bom para localizar problemas específicos. Quanto à interpretação combinada das leituras, o guia de detecção do Whoer traz as comparações.

Considerações finais

Os 11 testes principais do BrowserLeaks são, na essência, uma verificação do ambiente em camadas. O grupo de saída confirma por onde a requisição sai, o de leitura confirma o que os scripts enxergam, e o de declarações confirma que handshake e leituras vêm da mesma fonte; cada rodada tem um objeto de conferência claro.

Percorra as três rodadas antes de colocar um ambiente novo em operação. Registre as leituras no arquivo. Para incorporar essas conferências à rotina, baixe o MostMate, crie o ambiente, confira primeiro a pré-visualização do fingerprint e depois passe página por página nos testes.

MOSTMATE

Gestão segura de múltiplas contas, sem complicação

Comece com sua primeira conta e use MostMate para construir operações multicontas mais seguras, inteligentes e eficientes.

  • Perfis independentes. Identidades consistentes.
  • Automação com IA · Saúde das contas · Operações em equipe
Baixar MostMate