Le système d'identification de TRACIO génère un identifiant visiteur stable à partir de plus de 130 signaux du navigateur. L'identifiant persiste à travers les sessions, le mode navigation privée, les changements de VPN et la suppression des cookies. Cette page explique l'intégralité du pipeline d'identification.
Le client collecte plus de 130 signaux distincts du navigateur répartis sur 10 catégories. Chaque signal sonde un aspect différent du navigateur et de l'appareil, des caractéristiques matérielles au comportement de rendu.
| Groupe | Signaux | Stabilité | Exemples |
|---|---|---|---|
| Hardware | 12 | Très haute | Résolution d'écran, mémoire de l'appareil, concurrence matérielle, support tactile |
| Rendering | 9 | Haute | Empreinte canvas (texte + géométrie), renderer WebGL, traitement audio |
| Fonts | 5 | Haute | Polices système disponibles (69 familles testées), préférences de polices, rendu MathML |
| Platform | 25 | Moyenne | User-Agent, propriétés navigator, fuseau horaire, langue, fournisseur |
| CSS Engine | 10 | Moyenne | Réponses aux media queries (schéma de couleurs, HDR, mouvement réduit, couleurs forcées) |
| Storage | 10 | Moyenne | Support des cookies, localStorage, sessionStorage, quota de stockage |
| WebGL | 9 | Haute | Fabricant du GPU, renderer (unmasked), précision des shaders, support des extensions |
| Network | 3 | Basse | RTT de connexion, sonde TURN, version de l'application |
| Bot Indicators | 15 | N/A | Indicateur webdriver, frameworks d'automatisation, longueur d'eval, marqueurs headless |
| Custom | 14 | Variable | Empreinte mathématique, fonctionnalités WASM, détection d'architecture |
Tous les signaux ne sont pas également utiles à l'identification. Les signaux sont classés par stabilité :
Palier 1 (figé) : signaux matériels et de rendu qui ne changent presque jamais. Empreinte canvas, renderer WebGL, empreinte audio, paramètres GPU, énumération des polices, opérations mathématiques, octet d'architecture.
Palier 2 (semi-stable) : signaux qui changent avec les mises à jour du navigateur ou les changements de configuration. User-Agent, Client Hints, plugins, media queries CSS, capacités de stockage.
Palier 3 (volatil) : signaux qui changent fréquemment. Résolution d'écran (changement de moniteur), fuseau horaire (voyage), préférences de langue, propriétés de connexion.
Le visitor ID est calculé à l'aide d'un système de hachage à trois paliers qui équilibre stabilité et extensibilité :
Visitor ID = [Tier1Hash][Tier2Hash][Tier3Hash] 20 chars 10 chars 10 chars ──────── ──────── ──────── base62 base62 base62Le palier 1 n'utilise que des signaux figés, inhérents au matériel et au moteur de rendu. Ces signaux ne changent que lorsque l'utilisateur passe à un autre appareil physique ou effectue des modifications matérielles importantes.
Signaux inclus : hash de l'empreinte canvas, renderer WebGL (unmasked), fabricant WebGL (unmasked), empreinte audio, hash de l'énumération des polices, hash des paramètres WebGL, hash des opérations mathématiques, octet d'architecture (ARM vs x86).
Algorithme :
key1=value1|key2=value2|... (clés triées alphabétiquement)Le palier 1 est intentionnellement figé. Aucun nouveau signal n'y est jamais ajouté, ce qui garantit que le cœur d'identité reste stable à travers les mises à jour serveur.
Le palier 2 capture l'environnement navigateur et OS. Ces signaux changent lorsque l'utilisateur met à jour son navigateur, installe des extensions ou modifie les paramètres système.
Signaux inclus : données User-Agent, Client Hints (marques, plateforme, architecture), propriétés navigator (fournisseur, plateforme, langues), liste des plugins, profondeur de couleur de l'écran, mémoire de l'appareil, concurrence matérielle.
Le palier 3 capture des signaux volatils qui peuvent changer d'une session à l'autre. Ils servent au score de confiance et au fuzzy matching, mais n'affectent pas le cœur d'identité.
Signaux inclus : résolution d'écran, fuseau horaire, langue, bloqueurs DOM, capacités de stockage, réponses aux media queries CSS, propriétés de connexion.
Chaque palier est haché à l'aide de MurmurHash3-x64-128, une fonction de hachage rapide et non cryptographique qui produit une sortie de 128 bits. L'algorithme :
MurmurHash3 offre une excellente distribution (chaque bit d'entrée affecte chaque bit de sortie) et est suffisamment rapide pour un calcul en temps réel. Il n'est pas cryptographiquement sûr, mais cela n'est pas requis pour le hachage d'empreintes.
Input: "canvas=abc123|webgl_renderer=ANGLE|audio=0.04852" ↓ MurmurHash3-x64-128Output: 0x7f4a8c2d1e3b5f6a 0x9d8c7b6a5e4f3d2c ↓ base62 encodeResult: "X7fh2Hg9LkMn3pQr5tBv"Le score de confiance (0.0 à 1.0) représente le degré de certitude du système quant à l'identification du visiteur :
Lorsque le cookie _vid_t correspond à un visiteur connu, la confiance est fixée à 1.0. Le cookie contient l'UID du visiteur, que le serveur valide au regard de ses enregistrements. C'est le chemin d'identification le plus rapide et le plus fiable.
Les nouveaux visiteurs sans enregistrement antérieur reçoivent un score de confiance de 0.90. Il n'y a aucun risque de fausse correspondance puisqu'il n'existe aucun enregistrement à comparer.
Pour les visiteurs récurrents sans correspondance de cookie, le système calcule la confiance à partir de :
Pondération par fréquence des signaux (IDF) : les signaux plus uniques au sein de la population mondiale reçoivent un poids plus élevé. Un renderer WebGL rare est plus identifiant qu'une résolution d'écran courante.
Fuzzy matching : le système compare l'empreinte actuelle aux empreintes stockées à l'aide de la distance de Hamming au niveau du bit. Les signaux sont regroupés par palier, et le score de correspondance de chaque palier est pondéré indépendamment.
Cohérence historique : si les signaux d'un visiteur sont restés stables sur plusieurs visites, la confiance augmente. S'ils fluctuent fréquemment, la confiance diminue.
| Scénario | Score typique | Explication |
|---|---|---|
| Correspondance cookie | 1.000 | UID du cookie _vid_t vérifié côté serveur |
| Première visite | 0.900 | Aucun enregistrement antérieur à comparer |
| Forte correspondance d'empreinte | 0.990-0.999 | Tous les signaux du palier 1 correspondent, la plupart du palier 2 |
| Correspondance partielle (mise à jour du navigateur) | 0.950-0.989 | Le palier 1 correspond, le palier 2 a changé (nouveau UA) |
| Faible correspondance (changements importants) | 0.850-0.949 | Certains signaux du palier 1 ont changé |
| Ambigu | 0.500-0.849 | Plusieurs correspondances possibles en base |
TRACIO utilise un cookie first-party (_vid_t) pour maintenir l'identité du visiteur à travers les sessions :
_vid_tSameSite=Lax, et Secure en HTTPS (pas HttpOnly — l'agent le lit côté client)Le cookie est émis à la fois côté serveur (via l'en-tête de réponse Set-Cookie) et côté client par l'agent, et l'UID est également répliqué dans localStorage comme solution de repli lorsque les cookies sont bloqués.
Le serveur tente de définir le cookie sur des portées de domaine progressivement plus larges :
app.example.com → example.com → comLe domaine le plus large qui parvient à définir le cookie est utilisé. Cela garantit que le cookie persiste à travers les sous-domaines.
TRACIO peut identifier la même personne sur différents navigateurs du même appareil lorsque les signaux du palier 1 produisent des hashs correspondants. Comme le palier 1 repose sur des caractéristiques matérielles et de rendu (canvas, WebGL, audio, polices), ces signaux sont souvent identiques entre navigateurs basés sur Chromium sur la même machine et se dégradent d'un moteur à l'autre (Chromium vs Firefox vs Safari). Faire correspondre un visiteur desktop à un visiteur mobile n'est pas attendu — les surfaces matérielles et de rendu diffèrent.
La correspondance cross-navigateur est par nature une opération à confiance plus faible et elle est traitée comme telle dans le scoring.