Métodos experimentais para detectar navegadores de impressão digital: da versão declarada à validação de comportamento

Há muitas afirmações sobre a possibilidade de detectar impressões digitais de navegador, e a maioria fica apenas na conclusão. Em vez de discutir quem ganha ou perde, é mais útil observar como pesquisadores transformaram a questão em um experimento reproduzível e quais métricas usaram para chegar a um julgamento.

Um estudo publicado na ACM Internet Measurement Conference (IMC) 2024, intitulado Browser Polygraph, foi realizado por pesquisadores da Arizona State University, da Boston University e da Amazon; o DOI é 10.1145/3646547.3688455. Em vez de usar dados simulados em laboratório, o sistema foi implantado durante 4,5 meses no ambiente real de produção de uma grande empresa financeira e cobriu 205.000 sessões de usuários reais. Dez soluções comuns de mascaramento de ambiente foram testadas, enquanto o tráfego normal de usuários serviu como controle.

Como o experimento foi montado

Três decisões de projeto permitiram aplicar a detecção a todo o tráfego sem prejudicar a operação do negócio.

Os atributos precisavam ter baixo custo. A detecção lê apenas um conjunto fixo de propriedades, com sobrecarga por execução na ordem de milissegundos e KB. Assim, ela pode ser aplicada a todo o tráfego sem amostragem e sem efeito perceptível para o usuário.

Os atributos precisavam ser estáveis. Em vez de parâmetros que o usuário pode alterar, foram escolhidas estruturas internas definidas pelo próprio navegador. Cada versão traz um mecanismo JavaScript diferente, e há pequenas diferenças entre versões na quantidade de APIs e no número de propriedades anexadas a cada objeto. O estudo usou como referência o intervalo entre Chrome 110 e Chrome 114: o sistema contou as propriedades de 28 objetos-chave e comparou o resultado com a versão que o navegador declarava. Se não houver correspondência, a declaração e o comportamento real não vêm da mesma base.

Os rótulos precisavam ser confiáveis. Cada ambiente testado foi conectado ao mesmo tráfego de produção e avaliado pelas mesmas regras, enquanto o grupo de controle era formado pelo comportamento normal de usuários reais. Portanto, o resultado não mede subjetivamente se algo “parece real”, mas se aquele tráfego pode ser diferenciado segundo as mesmas regras.

Métricas para avaliar se a simulação é real

As medidas usadas no estudo podem ser agrupadas em quatro categorias.

• Consistência: a versão declarada pelo navegador corresponde à estrutura de seus objetos internos? Essa é a métrica central e a mais difícil de falsificar, porque alterar uma string não muda ao mesmo tempo o número de objetos e propriedades do mecanismo.
• Taxa de detecção: o estudo realizou testes detalhados com quatro das soluções, obtendo taxas entre 67% e 84%.
• Desvio em relação a dispositivos reais: sob as mesmas regras, navegadores normais receberam pontuação de risco 0, enquanto as soluções testadas ficaram, em média, entre 8,85 e 11,66. A pontuação representa a distância da distribuição real, e não uma impressão subjetiva de semelhança.
• Distinguibilidade: o tráfego testado pode ser separado do tráfego normal? Uma categoria que não pode ser separada indica que, com esse método, não há lacuna comportamental em relação a navegadores reais.

Das quatro métricas, a primeira é a causa; as outras três são consequências dela.

Onde cada uma das quatro categorias apresenta diferença

O estudo dividiu as soluções testadas em quatro categorias conforme a implementação subjacente.

Na primeira categoria, as características de baixo nível não correspondem a nenhuma versão conhecida de navegador real, ou seja, não existe um mecanismo correspondente. Uma verificação simples expõe a inconsistência.

Na segunda, o ambiente contém características reais de impressão digital, mas ao trocar a identidade apenas a declaração superficial muda; o mecanismo subjacente permanece o mesmo. Esse foi o padrão mais comum no estudo. Como analogia, o cartão de visita mostra uma versão nova, mas o sotaque continua antigo. O problema não é o ajuste de cada parâmetro, e sim a lacuna entre declaração e comportamento; é daí que vem grande parte das detecções.

Na terceira categoria, o mecanismo subjacente muda junto com a identidade. Se o ambiente declara uma versão específica, ele executa o mecanismo correspondente a essa versão, mantendo a consistência; por isso, esse detector não conseguiu diferenciar o tráfego. O artigo também observa que identificar essa categoria exige métodos de detecção mais complexos.

A quarta categoria não altera o navegador. Ela executa um navegador real dentro de uma máquina virtual e depois carrega a configuração desejada. Como o navegador é genuinamente real, o detector não consegue diferenciá-lo, mas o custo operacional é alto e difícil de escalar.

A diferença entre as quatro categorias não está na quantidade de parâmetros, mas em saber se a declaração e o comportamento vêm da mesma base.

Orientações práticas para escolher uma solução de ambiente

O foco da detecção mudou da leitura de declarações para a validação de comportamento, de modo que parâmetros superficiais editáveis oferecem cada vez menos vantagem. Para uma avaliação prática:

• Pergunte sobre a camada interna, não sobre a lista de parâmetros. Quando a versão declarada muda, a camada subjacente também muda? As impressões digitais são geradas automaticamente como combinações reais ou montadas manualmente como um conjunto de valores?
• Compare os ambientes entre si. Se vários ambientes retornam características internas muito parecidas, o isolamento não é completo.
• Primeiro consistência, depois diferenciação. Quanto mais características internamente contraditórias forem ajustadas, maior será a superfície de exposição.
• Passar em uma página genérica de detecção não significa que uma plataforma aceitará o ambiente. A validação final ainda deve usar uma pequena quantidade de tráfego real para testes próprios.

O problema central da camada de isolamento é fazer com que cada ambiente seja independente e internamente consistente. É isso que a PurpleMark busca resolver. Detecção e antidetecção devem ser usadas dentro dos limites de conformidade aplicáveis; o verdadeiro valor do estudo é fornecer uma base verificável para avaliação, e não uma classificação de quais produtos são bons ou ruins.