Test d'Empreinte du Navigateur : Analyse Canvas, WebGL et Unicité

Modifier uniquement la chaîne User-Agent ne protège en rien votre anonymat et engendre au contraire des "contradictions entre couches" flagrantes : Premièrement, la discordance entre couche application et couche transport : si vous configurez sous Windows un UA d'iPhone Safari, l'en-tête HTTP revendique Apple, mais le paquet TCP SYN porte la signature indélébile du noyau Windows (absence d'option TS et séquence MSS, NOP, WS, NOP, NOP, SACK_PERM), contredisant directement la suite d'options à 8 éléments d'Apple. Deuxièmement, les invariants d'implémentation en HTTP/3 et HTTP/2 : les moteurs Chromium, WebKit et Gecko se distinguent par des structures impossibles à falsifier, telles que le mappage des flux unidirectionnels HTTP/3 (Chromium: 2:control,10:encoder vs WebKit: 2:control,6:encoder) et l'ordre des pseudo-en-têtes HTTP/2 (Chromium: m,a,s,p vs non-Chromium: m,s,a,p). Changer un en-tête superficiel sans modifier les couches réseau sous-jacentes révèle immédiatement la supercherie.

💡 Découvrez tous les détails sur les signatures de transport dans notre Analyse d'anonymat de proxy.

Les navigateurs anti-détection modifient Chromium ou injectent des scripts JavaScript pour intercepter les propriétés de navigator, ajouter du bruit aux rendus Canvas/WebGL et émuler des résolutions d'écran ou contextes audio. Cependant, les systèmes de détection avancés repèrent facilement ces anomalies : Premièrement, l'altération des prototypes et des fonctions natives : les hooks JS dégradent souvent Function.prototype.toString, les descripteurs de propriétés et la chaîne d'héritage. Deuxièmement, les invariants de rendu GPU et de shaders : bien que le bruit injecté modifie le hash de l'image, la précision arithmétique en virgule flottante et la logique de rastérisation du pilote graphique physique restent fixes, formant un schéma de bruit artificiel distinctif. Troisièmement, les piles réseau non modifiées : la plupart de ces navigateurs n'opèrent qu'au niveau JS et n'ajustent pas les caractéristiques TCP/TLS du système d'exploitation hôte.

Non. Le mode navigation privée est exclusivement conçu pour empêcher "l'enregistrement des traces locales sur votre propre appareil", et non pour empêcher "l'identification à distance par les serveurs web". À la fermeture de la fenêtre privée, les cookies, le stockage local et l'historique sont effacés. En revanche, l'empreinte de navigateur s'appuie sur la mesure de propriétés matérielles et logicielles via JavaScript (modèle de carte graphique, rastérisation Canvas, shaders WebGL, polices installées, réponse des oscillateurs audio, cœurs CPU et profondeur des couleurs). Comme le matériel physique, les pilotes graphiques et le moteur de rendu sont rigoureusement identiques en mode privé, les serveurs distants calculent exactement le même hash d'empreinte qu'en navigation normale.

Il ne s'agit aucunement d'un faux positif, mais de l'architecture technique obligatoire sur iOS : Premièrement, les règles de l'App Store d'Apple : Apple exige de manière stricte que tous les navigateurs web sur iOS/iPadOS (y compris Chrome, Edge, Firefox et Opera) utilisent le moteur de rendu WebKit / WKWebView fourni par le système, interdisant tout recours aux moteurs Chromium Blink ou Gecko. Deuxièmement, la preuve par le protocole : sous iOS, Chrome (CriOS) transmet sur les connexions HTTP/3 le mappage de flux unidirectionnels exclusif à WebKit (2:control,6:encoder), totalement distinct de Chromium sous Windows ou Android (2:control,10:encoder). Chrome sous iOS est fondamentalement un navigateur WebKit doté d'une interface Google, et son identification en tant que WebKit est techniquement exacte.

Oui, mais selon des conditions strictes et des limites précises, et cela n'a strictement rien à voir avec une « authentification de l'utilisateur ». Notre système de récupération d'identité repose sur une pondération à quatre niveaux : 1) Niveau d'ancrage matériel (chaîne du modèle de GPU, latence de base audio, nombre de périphériques multimédias) ; 2) Niveau de haute entropie système (liste des polices installées, voix de synthèse vocale) ; 3) Niveau variable du navigateur (hachage de rendu Canvas, hachage de calcul AudioContext) ; 4) Niveau d'environnement d'affichage (résolution d'écran, fuseau horaire). Après agrégation des quatre couches, les deux conditions suivantes doivent être simultanément remplies pour valider une identité existante : un score total supérieur au seuil, et la correspondance d'au moins une caractéristique centrale à haute entropie (polices, voix de synthèse, Canvas ou Audio). Cette seconde condition est délibérée : les attributs publics à faible entropie comme le modèle de GPU, le fuseau horaire et la résolution se répètent massivement sur les appareils de même série, et aucune combinaison de ces données ne peut suffire à constituer une identité. Sans cette règle, des versions antérieures risquaient d'assimiler à tort deux inconnus. De plus, la couche d'ancrage matériel applique un droit de veto absolu : nombre de cœurs CPU différent, écart de mémoire vive supérieur à 4GB, divergence de latence de base audio de plus de 0.005 seconde ou différence de points tactiles maximaux disqualifient immédiatement l'appareil sans procéder au calcul du score.

⚠ L'objectif de ce dispositif est d'aligner de manière stable les observations répétées d'un même appareil, non d'établir votre identité civile : il ne constitue aucunement une authentification d'identité et ne doit jamais être employé comme telle.

Toutes deux appartiennent aux « caractéristiques système à haute entropie », ne requièrent aucune permission et s'exécutent de façon totalement imperceptible sans le moindre son audible. Empreinte AudioContext : elle injecte un oscillateur (Oscillator) dans un compresseur dynamique (DynamicsCompressor) au sein d'un OfflineAudioContext pour effectuer un rendu hors ligne, puis extrait les valeurs flottantes pour en calculer l'empreinte. Le même graphe audio produit d'infimes variations sur le bit de poids faible selon les moteurs de navigateur, bibliothèques mathématiques et unités flottantes, sans émettre de son. Tout à fait distincte et indépendante se trouve AudioContext.baseLatency : cette valeur reflète la taille du tampon de sortie déterminée par la carte son et ses pilotes ; nous l'utilisons comme ancrage matériel (un écart supérieur à 0.005 seconde disqualifie la correspondance) et non comme hachage d'identité. Empreinte d'énumération de polices : elle mesure successivement la largeur et la hauteur d'une chaîne textuelle rendue avec chaque police candidate par rapport aux polices de secours ; une différence prouve la présence de la police. Les polices dépendent directement des logiciels installés sur votre machine (Office, suite Adobe, outils de développement, méthodes de saisie), faisant de la liste des polices l'élément individuel le plus discriminant de tout le jeu de données.

💡 La différence de stabilité découle de l'origine des changements : les hachages Canvas et Audio évoluent à chaque mise à jour de version du navigateur (les moteurs de rendu et bibliothèques mathématiques changeant constamment), tandis que la liste des polices ne change que lors de l'installation ou la désinstallation de logiciels — raison pour laquelle son poids est le plus élevé.

Le MSS (Maximum Segment Size) représente la charge utile maximale par paquet TCP annoncée lors de l'établissement de la connexion. Notre serveur le lit directement dans votre paquet SYN sans exiger d'installation ni de configuration. L'ajout des en-têtes IP et TCP reconstitue le MTU du lien réseau : ajouter 40 octets pour IPv4, ajouter 60 octets pour IPv6. Les valeurs usuelles ont une signification technique précise : 1500 désigne un réseau Ethernet standard ou une liaison brute de serveur dédié ; 1492 correspond au PPPoE (connexions résidentielles DSL / FTTH), où l'en-tête PPPoE de 8 octets réduit la capacité utile ; inférieur ou égal à 1420 révèle une encapsulation supplémentaire, typique d'un tunnel VPN tel que WireGuard / Tailscale ou d'un relais CDN.

⚠ L'élément capital est le suivant : le MSS décrit la liaison réseau, pas l'appareil. Il signale uniquement la présence d'une encapsulation sur le trajet et ne prouve pas à lui seul l'usage d'un proxy (une connexion résidentielle PPPoE n'est pas non plus à 1500). La véritable valeur diagnostique réside dans la contradiction : lorsqu'une localisation déclarée au niveau applicatif s'oppose durablement aux propriétés de la liaison de transport (par exemple prétendre à une connexion locale directe alors que le MSS se situe de façon stable dans la plage d'un tunnel). Consultez notre Analyse d'anonymat de proxy pour plus de détails.

C'est l'erreur que nous redoutons le plus (fusion erronée), et nous y opposons trois lignes de défense successives — le déclenchement de l'une quelconque d'entre elles empêche la fusion. Premièrement, l'isolation stricte par compartiments : les profils candidats sont d'abord séparés selon la plateforme d'OS et le moteur de navigateur, sans comparaison inter-compartiments. Deux navigateurs à moteurs différents sur une même machine ne seront donc jamais associés en une identité unique. Deuxièmement, le veto d'ancrage matériel : nombre de cœurs logiques CPU, mémoire vive (tolérance de 4GB), latence audio de base (tolérance de 0.005 seconde) et points tactiles maximaux entraînent une exclusion directe sans calcul de score en cas de conflit avéré. Troisièmement, la porte d'admission des caractéristiques centrales : même avec un score très élevé, l'absence de correspondance sur les caractéristiques centrales à haute entropie (polices, voix, Canvas, Audio) bloque la réclamation — cette barrière empêche un agrégat de données publiques à faible entropie d'atteindre un faux score élevé.

⚠ Mention de transparence : nous ne disposons d'aucune valeur mesurée du taux de fausse fusion sur trafic réel à publier actuellement. Cette métrique exige un volume important d'accès réels sur la durée ; afficher un chiffre avant d'avoir réuni un échantillon suffisant serait trompeur.