Como funciona, nos bastidores, o rastreamento de pegada digital

Todo dispositivo que se conecta à internet deixa um rastro de artefatos técnicos — uma pegada digital. Na tracio.ai, reconstruímos essa pegada a partir de mais de 300 sinais passivos coletados durante um único carregamento de página, sem que a identificação dependa de cookies ou de qualquer outra forma de armazenamento persistente no lado do cliente. Este artigo explica exatamente como esse processo funciona.

A camada de coleta de sinais

Quando nosso agente JavaScript carrega no navegador de um visitante, ele começa a coletar sinais de várias categorias simultaneamente. Renderização de canvas, consultas de parâmetros de WebGL, processamento de AudioContext, enumeração de fontes e leituras de propriedades do navigator rodam todos em paralelo, cada um limitado pelo próprio timeout, de modo que uma sonda lenta não segure as demais. Quanto tempo a passagem inteira leva depende do dispositivo do visitante, e os números a seguir são os que medimos nos nossos.

A percepção-chave é que cada sinal captura um aspecto diferente da pilha de hardware e software do dispositivo. A renderização de canvas reflete a GPU, o driver e o motor de renderização de fontes. Os parâmetros de WebGL expõem o modelo da placa gráfica e suas capacidades. O AudioContext revela diferenças na forma como o DSP de áudio processa operações de ponto flutuante. As propriedades do navigator reportam núcleos de CPU, memória, plataforma e configurações de idioma.

Nossa equipe mediu isso em 2 bilhões de eventos no mês passado: o tempo mediano de coleta foi de 38ms, e o 99º percentil foi de 52ms. Na verdade, primeiro tentamos a abordagem ingênua — coletar sinais sequencialmente. Era 40x mais lenta. A coleta em paralelo com barreira de timeout foi uma das primeiras decisões arquiteturais que acertamos.

Impressão digital TLS: a primeira camada

Antes mesmo de nosso JavaScript ser executado, o navegador já revelou informações significativas por meio do handshake TLS. A mensagem Client Hello contém as suítes de cifras que o navegador suporta, as extensões TLS que ele usa, as curvas elípticas que ele prefere e os algoritmos de assinatura que ele aceita. Essas informações são determinadas pela biblioteca TLS do navegador e variam significativamente entre famílias de navegadores, versões e sistemas operacionais.

Capturamos essa impressão digital TLS usando o hashing JA4 — um substituto moderno do JA3 que oferece melhor granularidade e estabilidade entre versões. O hash JA4 sozinho consegue distinguir Chrome de Firefox e de Safari, e muitas vezes reduz a identificação a uma faixa de versão específica do navegador. Combinado com nossos sinais do lado do cliente, ele fornece uma camada de validação cruzada extremamente difícil de falsificar.

Impressão digital de canvas e GPU

A impressão digital de canvas explora o fato de que GPUs diferentes renderizam as mesmas instruções de desenho com sutis diferenças no nível de pixel. A Canvas API nos permite desenhar uma cena cuidadosamente projetada — strings de texto específicas em várias fontes, formas geométricas com coordenadas específicas e gradientes com paradas de cor precisas — e depois calcular um hash dos dados de pixel resultantes.

As diferenças de renderização vêm de variações nos algoritmos de anti-aliasing, na renderização subpixel, na mistura de cores e no hinting de fontes entre modelos de GPU e versões de driver. Mesmo dois dispositivos com o mesmo modelo de GPU podem produzir saídas de canvas diferentes se rodarem versões de driver ou sistemas operacionais diferentes. Isso torna o hash de canvas um dos nossos sinais mais distintivos.

Perfilamento de hardware por WebGL

A WebGL API expõe informações detalhadas sobre o subsistema gráfico que vão muito além das strings de renderizador e fabricante. Consultamos tamanhos máximos de textura, formatos de precisão de shader, extensões suportadas, dimensões de viewport e dezenas de outros parâmetros que variam entre modelos de GPU e configurações de driver.

A combinação desses parâmetros cria um perfil de hardware detalhado. Um dispositivo com uma NVIDIA RTX 4070, por exemplo, reportará tamanhos máximos de textura diferentes, precisão de shader diferente e suporte a extensões diferente de um dispositivo com uma AMD RX 7800 XT. Esse perfil de hardware é inerentemente estável — não muda com atualizações de navegador, apenas com mudanças de hardware ou driver.

Impressão digital de processamento de áudio

A Web Audio API fornece outra fonte de sinal dependente de hardware. Criamos um nó oscilador, conectamo-lo a um compressor de dinâmica e medimos o buffer de saída. Diferenças na precisão de ponto flutuante, na implementação do DSP e nos algoritmos de reamostragem entre hardwares de áudio e sistemas operacionais produzem variações mensuráveis na saída.

As impressões digitais de áudio têm unicidade moderada, mas estabilidade excepcional. O pipeline de processamento de áudio raramente muda, a menos que o usuário troque de hardware de áudio ou reinstale o sistema operacional. Isso torna os sinais de áudio âncoras valiosas no nosso sistema de identificação em múltiplas camadas.

Fusão de sinais e resolução de identidade

Os sinais brutos são criptografados e transmitidos ao nosso servidor, onde o motor de identificação de dispositivos os processa por meio de um sistema de hashing de três camadas. Os sinais de nível de hardware (canvas, WebGL, áudio) formam a Camada 1 — o núcleo estável da identidade. Os sinais de nível de navegador (detecção de recursos, propriedades CSS, capacidades de mídia) formam a Camada 2, processada por correspondência entre sessões para lidar com a variação esperada das atualizações de navegador. Os sinais voláteis (user agent, fuso horário, idioma) formam a Camada 3, contribuindo para a pontuação de confiança sem determinar as decisões de identidade.

O algoritmo de fusão pondera cada sinal por sua unicidade e estabilidade. Uma correspondência em um hash de canvas raro tem muito mais peso do que uma correspondência em uma resolução de tela comum. Essa abordagem ponderada garante que a identificação permaneça precisa mesmo quando um subconjunto dos sinais muda.

O que armazenamos e por que a identificação não depende disso

Um princípio de design crítico do nosso sistema é que a identificação não depende de armazenamento no lado do cliente. O visitor ID é derivado das características inerentes do dispositivo — o hardware, a pilha de software, a configuração de rede — e é por isso que a identificação sobrevive à limpeza de cookies, ao modo anônimo e até à reinstalação do navegador.

Essa é uma afirmação sobre dependência, não sobre abstinência, e vale dizer a diferença com todas as letras. Nós definimos, sim, um cookie próprio, _vid_t, que guarda um identificador opaco com expiração de 365 dias, e espelhamos o mesmo valor no localStorage. O que não fazemos é definir cookies de terceiros, gravar qualquer coisa que funcione entre sites ou ler histórico de navegação, dados de formulário ou IndexedDB. O cookie existe porque é a resposta mais barata possível para "já vimos este navegador antes?" — quando ele sobrevive, a correspondência é imediata e certa. Quando não sobrevive, nada quebra: os sinais do dispositivo reconstroem o identificador sozinhos, com confiança um pouco menor. Um visitante que apaga tudo continua sendo reconhecido; um sistema construído só sobre armazenamento o teria perdido.

Privacidade por arquitetura

Como coletamos apenas atributos técnicos do navegador — sem histórico de navegação, sem dados de formulário, sem conteúdo pessoal —, o impacto na privacidade é mínimo. A Orientação do W3C sobre Fingerprinting descreve as melhores práticas para o uso responsável de sinais de navegador, e nossa arquitetura se alinha a esses princípios. O processamento acontece em nossa nuvem gerenciada, com residência de dados na UE ou nos EUA, conforme a região que você escolher. Essa arquitetura torna simples a conformidade com o GDPR, a CCPA e outras regulamentações de privacidade.