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 130 sinais passivos coletados durante um único carregamento de página, sem depender de cookies, localStorage ou qualquer 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. Todo o processo de coleta é concluído em menos de 50 milissegundos em hardware moderno.

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.

Sem armazenamento, sem cookies

Um princípio de design crítico do nosso sistema é que a identificação não depende de nenhuma forma de armazenamento no lado do cliente. Não definimos cookies, não escrevemos no localStorage nem usamos IndexedDB para fins de rastreamento. O visitor ID é derivado inteiramente das características inerentes do dispositivo — o hardware, a pilha de software, a configuração de rede. Isso significa que a identificação sobrevive à limpeza de cookies, ao modo anônimo e até à reinstalação do navegador.

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. Com a implantação hospedada em nuvem, todo o processamento acontece na sua infraestrutura. Nenhum dado de visitante jamais chega aos nossos servidores. Essa arquitetura torna simples a conformidade com o GDPR, a CCPA e outras regulamentações de privacidade.