Comment fonctionne le suivi de l'empreinte numérique en coulisses
Des handshakes TLS au rendu canvas — comment nous reconstituons l'empreinte numérique d'un appareil à partir de plus de 130 signaux passifs, sans cookies ni stockage.
Chaque appareil qui se connecte à Internet laisse une traînée d'artefacts techniques — une empreinte numérique. Chez tracio.ai, nous reconstituons cette empreinte à partir de plus de 130 signaux passifs collectés pendant un seul chargement de page, sans nous appuyer sur les cookies, le localStorage ou toute forme de stockage persistant côté client. Cet article explique précisément comment ce processus fonctionne.
La couche de collecte des signaux
Lorsque notre agent JavaScript se charge dans le navigateur d'un visiteur, il commence à collecter simultanément des signaux à travers plusieurs catégories. Le rendu canvas, les requêtes de paramètres WebGL, le traitement AudioContext, l'énumération des polices et la lecture des propriétés navigator s'exécutent tous en parallèle. L'ensemble du processus de collecte s'achève en moins de 50 millisecondes sur du matériel moderne.
L'idée clé est que chaque signal capture un aspect différent de la pile matérielle et logicielle de l'appareil. Le rendu canvas reflète le GPU, le pilote et le moteur de rendu des polices. Les paramètres WebGL exposent le modèle et les capacités de la carte graphique. L'AudioContext révèle des différences dans la manière dont le DSP audio traite les opérations en virgule flottante. Les propriétés navigator rapportent les cœurs CPU, la mémoire, la plateforme et les réglages de langue.
Notre équipe a mesuré cela sur 2 milliards d'événements le mois dernier : le temps de collecte médian était de 38ms, et le 99e centile de 52ms. Nous avons d'abord essayé l'approche naïve — collecter les signaux séquentiellement. Elle était 40x plus lente. La collecte parallèle avec un garde-fou de timeout a été l'une des premières décisions d'architecture que nous avons réussies d'emblée.
Empreinte TLS : la première couche
Avant même que notre JavaScript ne s'exécute, le navigateur a déjà révélé des informations importantes via le handshake TLS. Le message Client Hello contient les suites de chiffrement que le navigateur prend en charge, les extensions TLS qu'il utilise, les courbes elliptiques qu'il privilégie et les algorithmes de signature qu'il accepte. Ces informations sont déterminées par la bibliothèque TLS du navigateur et varient considérablement selon les familles de navigateurs, les versions et les systèmes d'exploitation.
Nous capturons cette empreinte TLS à l'aide du hachage JA4 — un remplacement moderne de JA3 offrant une meilleure granularité et une stabilité entre versions accrue. Le hachage JA4 seul peut distinguer Chrome de Firefox et de Safari, et resserre souvent l'identification à une plage de versions de navigateur précise. Combiné à nos signaux côté client, il fournit une couche de recoupement extrêmement difficile à falsifier.
Empreinte canvas et GPU
L'empreinte canvas exploite le fait que différents GPU rendent les mêmes instructions de dessin avec de subtiles différences au niveau des pixels. La Canvas API nous permet de dessiner une scène soigneusement conçue — des chaînes de texte précises dans plusieurs polices, des formes géométriques à des coordonnées particulières et des dégradés avec des arrêts de couleur exacts — puis de calculer un hachage des données de pixels résultantes.
Les différences de rendu proviennent des variations dans les algorithmes d'anticrénelage, le rendu sous-pixel, le mélange des couleurs et le hinting des polices selon les modèles de GPU et les versions de pilotes. Même deux appareils dotés du même modèle de GPU peuvent produire des sorties canvas différentes s'ils exécutent des versions de pilotes ou des systèmes d'exploitation différents. Cela fait du hachage canvas l'un de nos signaux les plus distinctifs.
Profilage matériel WebGL
La WebGL API expose des informations détaillées sur le sous-système graphique qui vont bien au-delà des chaînes de renderer et de vendor. Nous interrogeons les tailles de texture maximales, les formats de précision des shaders, les extensions prises en charge, les dimensions du viewport et des dizaines d'autres paramètres qui varient selon les modèles de GPU et les configurations de pilotes.
La combinaison de ces paramètres crée un profil matériel détaillé. Un appareil équipé d'une NVIDIA RTX 4070, par exemple, rapportera des tailles de texture maximales, une précision de shaders et une prise en charge d'extensions différentes de celles d'un appareil équipé d'une AMD RX 7800 XT. Ce profil matériel est intrinsèquement stable — il ne change pas avec les mises à jour de navigateur, uniquement avec les changements de matériel ou de pilotes.
Empreinte du traitement audio
La Web Audio API fournit une autre source de signal dépendante du matériel. Nous créons un nœud oscillateur, le connectons à un compresseur dynamique et mesurons le tampon de sortie. Les différences de précision en virgule flottante, d'implémentation du DSP et d'algorithmes de rééchantillonnage selon le matériel audio et les systèmes d'exploitation produisent des variations mesurables dans la sortie.
Les empreintes audio ont une unicité modérée mais une stabilité exceptionnelle. Le pipeline de traitement audio change rarement, à moins que l'utilisateur ne change de matériel audio ou ne réinstalle le système d'exploitation. Cela fait des signaux audio des ancres précieuses dans notre système d'identification multi-niveaux.
Fusion des signaux et résolution d'identité
Les signaux bruts sont chiffrés et transmis à notre serveur, où le moteur d'identification d'appareil les traite via un système de hachage à trois niveaux. Les signaux matériels (canvas, WebGL, audio) forment le Niveau 1 — le cœur d'identité stable. Les signaux de navigateur (détection de fonctionnalités, propriétés CSS, capacités média) forment le Niveau 2, traités par un appariement inter-sessions pour gérer la dérive attendue due aux mises à jour de navigateur. Les signaux volatils (user agent, fuseau horaire, langue) forment le Niveau 3, contribuant au score de confiance sans piloter les décisions d'identité.
L'algorithme de fusion pondère chaque signal selon son unicité et sa stabilité. Une correspondance sur un hachage canvas rare pèse bien plus lourd qu'une correspondance sur une résolution d'écran courante. Cette approche pondérée garantit que l'identification reste précise même lorsqu'un sous-ensemble de signaux change.
Ni stockage, ni cookies
Un principe de conception essentiel de notre système est que l'identification ne dépend d'aucune forme de stockage côté client. Nous ne posons pas de cookies, n'écrivons pas dans le localStorage et n'utilisons pas IndexedDB à des fins de suivi. L'identifiant visiteur dérive entièrement des caractéristiques intrinsèques de l'appareil — le matériel, la pile logicielle, la configuration réseau. Cela signifie que l'identification survit à l'effacement des cookies, au mode navigation privée et même à la réinstallation du navigateur.
Confidentialité par l'architecture
Parce que nous ne collectons que des attributs techniques du navigateur — aucun historique de navigation, aucune donnée de formulaire, aucun contenu personnel —, l'impact sur la confidentialité est minime. Le W3C Fingerprinting Guidance décrit les bonnes pratiques pour un usage responsable des signaux du navigateur, et notre architecture s'aligne sur ces principes. Avec un déploiement hébergé dans le cloud, tout le traitement se déroule sur votre infrastructure. Aucune donnée de visiteur n'atteint jamais nos serveurs. Cette architecture rend simple la conformité au GDPR, au CCPA et aux autres réglementations sur la vie privée.