O sistema de identificação da TRACIO gera um identificador de visitante estável a partir de mais de 130 sinais de navegador. O identificador persiste entre sessões, modo anônimo, mudanças de VPN e limpeza de cookies. Esta página explica todo o pipeline de identificação.
O cliente coleta mais de 130 sinais de navegador distintos em 10 categorias. Cada sinal sonda um aspecto diferente do navegador e do dispositivo, das características de hardware ao comportamento de renderização.
| Grupo | Sinais | Estabilidade | Exemplos |
|---|---|---|---|
| Hardware | 12 | Muito alta | Resolução de tela, memória do dispositivo, concorrência de hardware, suporte a toque |
| Renderização | 9 | Alta | Fingerprint de canvas (texto + geometria), renderizador WebGL, processamento de áudio |
| Fontes | 5 | Alta | Fontes de sistema disponíveis (69 famílias testadas), preferências de fonte, renderização de MathML |
| Plataforma | 25 | Média | User-Agent, propriedades do navigator, fuso horário, idioma, fornecedor |
| Motor CSS | 10 | Média | Respostas de media query (esquema de cores, HDR, movimento reduzido, cores forçadas) |
| Armazenamento | 10 | Média | Suporte a cookies, localStorage, sessionStorage, cota de armazenamento |
| WebGL | 9 | Alta | Fornecedor de GPU, renderizador (unmasked), precisão de shader, suporte a extensões |
| Rede | 3 | Baixa | RTT da conexão, sonda TURN, versão do app |
| Indicadores de bot | 15 | N/D | Flag webdriver, frameworks de automação, comprimento de eval, marcadores headless |
| Personalizados | 14 | Varia | Fingerprint de math, recursos WASM, detecção de arquitetura |
Nem todos os sinais são igualmente úteis para identificação. Os sinais são classificados por estabilidade:
Camada 1 (Congelada): sinais de hardware e renderização que quase nunca mudam. Fingerprint de canvas, renderizador WebGL, fingerprint de áudio, parâmetros de GPU, enumeração de fontes, operações matemáticas, byte de arquitetura.
Camada 2 (Semiestável): sinais que mudam com atualizações de navegador ou mudanças de configuração. User-Agent, Client Hints, plugins, media queries CSS, capacidades de armazenamento.
Camada 3 (Volátil): sinais que mudam com frequência. Resolução de tela (troca de monitor), fuso horário (viagens), preferências de idioma, propriedades de conexão.
O ID de visitante é calculado usando um sistema de hashing de três camadas que equilibra estabilidade com extensibilidade:
Visitor ID = [Tier1Hash][Tier2Hash][Tier3Hash] 20 chars 10 chars 10 chars ──────── ──────── ──────── base62 base62 base62A Camada 1 usa apenas sinais congelados que são inerentes ao hardware e ao motor de renderização. Esses sinais mudam apenas quando o usuário troca para um dispositivo físico diferente ou faz mudanças significativas de hardware.
Sinais incluídos: hash de fingerprint de canvas, renderizador WebGL (unmasked), fornecedor WebGL (unmasked), fingerprint de áudio, hash de enumeração de fontes, hash de parâmetros WebGL, hash de operações matemáticas, byte de arquitetura (ARM vs x86).
Algoritmo:
key1=value1|key2=value2|... (chaves ordenadas alfabeticamente)A Camada 1 é intencionalmente congelada. Novos sinais nunca são adicionados à Camada 1, garantindo que o núcleo de identidade permaneça estável entre atualizações de servidor.
A Camada 2 captura o ambiente do navegador e do sistema operacional. Esses sinais mudam quando o usuário atualiza o navegador, instala extensões ou modifica configurações do sistema.
Sinais incluídos: dados de User-Agent, Client Hints (marcas, plataforma, arquitetura), propriedades do navigator (fornecedor, plataforma, idiomas), lista de plugins, profundidade de cor da tela, memória do dispositivo, concorrência de hardware.
A Camada 3 captura sinais voláteis que podem mudar entre sessões. Eles são usados para pontuação de confiança e correspondência aproximada, mas não afetam a identidade central.
Sinais incluídos: resolução de tela, fuso horário, idioma, bloqueadores de DOM, capacidades de armazenamento, respostas de media query CSS, propriedades de conexão.
Cada camada recebe hash usando MurmurHash3-x64-128, uma função de hash rápida e não criptográfica que produz saída de 128 bits. O algoritmo:
O MurmurHash3 oferece distribuição excelente (cada bit da entrada afeta cada bit da saída) e é rápido o bastante para computação em tempo real. Não é criptograficamente seguro, mas isso não é necessário para hashing de fingerprint.
Input: "canvas=abc123|webgl_renderer=ANGLE|audio=0.04852" ↓ MurmurHash3-x64-128Output: 0x7f4a8c2d1e3b5f6a 0x9d8c7b6a5e4f3d2c ↓ base62 encodeResult: "X7fh2Hg9LkMn3pQr5tBv"A pontuação de confiança (0.0 a 1.0) representa o quão certo o sistema está sobre a identificação do visitante:
Quando o cookie _vid_t corresponde a um visitante conhecido, a confiança é definida como 1.0. O cookie guarda o UID do visitante, que o servidor valida contra seus registros. Este é o caminho de identificação mais rápido e confiável.
Novos visitantes sem registro anterior recebem uma pontuação de confiança de 0.90. Não há risco de correspondência falsa, já que não existem registros para comparar.
Para visitantes recorrentes sem correspondência de cookie, o sistema calcula a confiança a partir de:
Ponderação por frequência de sinal (IDF): sinais que são mais únicos na população global recebem peso maior. Um renderizador WebGL raro é mais identificador do que uma resolução de tela comum.
Correspondência aproximada: o sistema compara o fingerprint atual com fingerprints armazenados usando distância de Hamming em nível de bit. Os sinais são agrupados por camada, e a pontuação de correspondência de cada camada é ponderada de forma independente.
Consistência histórica: se os sinais de um visitante têm se mantido estáveis ao longo de várias visitas, a confiança aumenta. Se os sinais oscilam com frequência, a confiança diminui.
| Cenário | Pontuação típica | Explicação |
|---|---|---|
| Correspondência de cookie | 1.000 | UID do cookie _vid_t verificado no servidor |
| Primeira visita | 0.900 | Sem registros anteriores para comparar |
| Correspondência forte de fingerprint | 0.990-0.999 | Todos os sinais da Camada 1 correspondem, maioria da Camada 2 |
| Correspondência parcial (atualização de navegador) | 0.950-0.989 | Camada 1 corresponde, Camada 2 mudou (novo UA) |
| Correspondência fraca (mudanças significativas) | 0.850-0.949 | Alguns sinais da Camada 1 mudaram |
| Ambígua | 0.500-0.849 | Múltiplas correspondências possíveis no banco de dados |
A TRACIO usa um cookie de origem própria (_vid_t) para manter a identidade do visitante entre sessões:
_vid_tSameSite=Lax, e Secure em HTTPS (não HttpOnly — o agente o lê no lado do cliente)O cookie é emitido tanto no servidor (via cabeçalho de resposta Set-Cookie) quanto no cliente pelo agente, e o UID também é espelhado em localStorage como fallback quando os cookies são bloqueados.
O servidor tenta definir o cookie em escopos de domínio progressivamente mais amplos:
app.example.com → example.com → comO domínio mais amplo que definir o cookie com sucesso é o utilizado. Isso garante que o cookie persista entre subdomínios.
A TRACIO consegue identificar a mesma pessoa em navegadores diferentes no mesmo dispositivo quando os sinais da Camada 1 produzem hashes correspondentes. Como a Camada 1 depende de características de hardware e renderização (canvas, WebGL, áudio, fontes), esses sinais costumam ser idênticos entre navegadores baseados em Chromium na mesma máquina e degradam entre motores (Chromium vs Firefox vs Safari). Corresponder um visitante de desktop a um visitante mobile não é esperado — as superfícies de hardware e renderização diferem.
A correspondência entre navegadores é, por natureza, uma operação de menor confiança e é tratada como tal na pontuação.