Pular para o conteúdo
Voltar ao teste de fingerprintMetodologia · pontuação · limitações

Como funcionam os testes de fingerprint de navegador

Como a auditoria do Clearcote compara sinais do navegador, calcula a pontuação, trata as evidências de rede e evita transformar dados ausentes ou contextuais em uma falsa aprovação.

O que o teste de fingerprint do navegador mede

A auditoria mede a coerência: se subsistemas independentes do navegador dão respostas compatíveis sobre a mesma máquina. Ela pode comparar JavaScript com CSS, a página principal com um worker ou iframe, uma família de navegador declarada com APIs que só existem em um motor específico, e uma GPU informada com o pipeline de renderização que de fato produziu uma imagem.

Isso é diferente de medir raridade. Um dispositivo incomum, mas internamente consistente, pode passar. Uma identidade de aparência comum pode falhar quando duas superfícies se contradizem. Por isso, a maioria das verificações não precisa de uma linha de base populacional: o próprio navegador fornece os dois lados da comparação.

Como a pontuação de coerência é calculada

A pontuação é a proporção das verificações aplicáveis e pontuadas que concordam. Ela não é a probabilidade de um visitante ser humano, não é uma taxa de detecção e não é uma garantia de que uma sessão de automação seja invisível. Uma pontuação de 92 significa que 92 por cento das comparações pontuadas que se aplicavam eram coerentes.

Achados contextuais ficam de fora porque ambientes comuns podem produzi-los: ferramentas de acessibilidade, extensões, desktops remotos, navegadores gerenciados por políticas, proteções de privacidade e hardware ausente, tudo isso altera superfícies observáveis. Verificações que não conseguem rodar aparecem como não medidas e nunca contam como aprovadas.

Por que algumas medições exigem uma sonda de rede

O JavaScript não consegue ler o TLS ClientHello, a ordem dos frames HTTP/2, os parâmetros de transporte do QUIC nem o endereço público usado pelo WebRTC. Esses dados existem abaixo do runtime da página. Para medi-los, é preciso que um servidor informe o que de fato chegou pela rede.

A auditoria abre duas conexões com tls.clearcotelabs.com para comparar handshakes TLS independentes. O teste de vazamento de WebRTC contata stun.l.google.com — o que significa que o Google vê o IP de origem da conexão — e compara esse endereço com aquele pelo qual a auditoria está sendo servida. Se algum dos dois serviços estiver inacessível, o resultado correspondente fica como não medido, e não como limpo.

Coleta de dados e o corpus de pesquisa

Executar a auditoria envia um perfil do navegador ao Clearcote para análise interna. O aviso de consentimento da ferramenta lista os campos antes de a execução começar. O corpus de pesquisa, que é separado, armazena um registro de configuração menos detalhado, usado para estudar cobertura e falsos positivos; ele não é um banco de dados de fraude nem de reputação de contas.

As regras completas de retenção e exclusão, e a descrição campo a campo do que é coletado, estão na política de privacidade da auditoria. Manter essa política à parte permite que o teste continue conciso sem esconder o que sai do navegador.

O que um teste público de navegador não consegue determinar

Uma página pública não enxerga a idade global do perfil, o histórico de navegação entre sites, a reputação da conta, cookies privados de outras origens nem os modelos de risco do lado do servidor usados por sistemas antibot comerciais. O input comportamental pode revelar timing mecânico ou interpolação perfeita, mas uma interação curta não é um classificador comportamental treinado.

Por isso, uma pontuação alta deve ser lida de forma restrita: as medições que rodaram não revelaram muitas contradições internas. Ela não diz nada definitivo sobre reputação, intenção, histórico da conta ou todos os sinais que um detector em produção pode combinar.

Um caso merece ser dito com todas as letras, porque é o mais mal interpretado. Todas as verificações do grupo de automação podem passar e, mesmo assim, uma sessão pode ser classificada como automatizada. Em um teardown publicado de um agente comercial em produção, um payload capturado de um navegador controlado pelo protocolo DevTools voltou rotulado como bot de webdriver com ferramentas de desenvolvedor detectadas — enquanto esse mesmo payload informava todas as flags de automação como falsas e só diferia de uma janela comum em identificadores de sessão, leituras de relógio e um campo de timing de rede. Não há como saber, a partir do cliente, em que o servidor se baseou, e esta página deliberadamente não inclui uma linha para algo que não consegue medir. A conclusão honesta é que a presença de um protocolo de depuração é decidida fora dos valores que uma página consegue ler; portanto, uma seção de automação limpa significa que essas superfícies específicas estão limpas, e não que a conexão passa despercebida.

Esse mesmo teardown é o motivo de esta página informar várias leituras em vez de pontuá-las. Payloads capturados idênticos, reenviados ao mesmo fornecedor com uma semana de intervalo, voltaram com veredictos de tampering e de antidetect substancialmente diferentes — drift do modelo, histórico de replay ou ambos, sem que os dois efeitos tenham sido separados. Pontuações absolutas de um detector ativo mudam com o tempo; só as diferenças medidas contra um controle na mesma sessão significam alguma coisa. Isso vale também para o número desta própria página, e é por isso que a execução informa o quão estáveis foram as respostas do seu navegador, em vez de tratar uma única rodada como verdade absoluta.