Une étude publiée à l’IMC 2024 a transformé la détection en expérience en ligne reproductible : au lieu de croire la version annoncée par le navigateur, elle a compté les propriétés d’objets internes et les a comparées à cette version. La méthode est plus instructive que la conclusion.
Les affirmations sur la possibilité de détecter les empreintes de navigateur sont nombreuses, et la plupart s’arrêtent à une conclusion. Plutôt que de débattre de qui gagne ou perd, il est plus utile d’examiner comment des chercheurs ont transformé la question en expérience reproductible et quels indicateurs ils ont utilisés pour trancher.
Une étude publiée à l’ACM Internet Measurement Conference (IMC) 2024, intitulée Browser Polygraph, a été menée par des chercheurs de l’Arizona State University, de la Boston University et d’Amazon ; son DOI est 10.1145/3646547.3688455. Au lieu d’utiliser des données simulées en laboratoire, le système a été déployé pendant 4,5 mois dans l’environnement de production réel d’une grande entreprise financière et a couvert 205 000 sessions d’utilisateurs réels. Dix solutions courantes de camouflage d’environnement ont été testées, avec le trafic normal d’utilisateurs comme groupe témoin.
Comment l’expérience a été mise en place
Trois choix de conception ont permis de déployer la détection sur l’ensemble du trafic sans perturber l’activité.
Les caractéristiques devaient être peu coûteuses à mesurer. La détection ne lit qu’un ensemble fixe de propriétés, avec un coût de l’ordre de quelques millisecondes et de quelques KB par exécution. Elle peut donc s’appliquer à tout le trafic sans échantillonnage et sans effet perceptible pour l’utilisateur.
Les caractéristiques devaient être stables. Les chercheurs n’ont pas choisi des paramètres que l’utilisateur peut modifier, mais des structures internes fixées par le navigateur lui-même. Chaque version embarque un moteur JavaScript différent, avec de petites variations du nombre d’API disponibles et du nombre de propriétés attachées à chaque objet. L’étude a pris comme référence la plage allant de Chrome 110 à Chrome 114 : le système a compté les propriétés de 28 objets clés, puis a comparé le résultat à la version déclarée par le navigateur. Une incohérence indique que la déclaration et le comportement réel ne proviennent pas de la même base technique.
Les étiquettes devaient être fiables. Chaque environnement testé a été connecté au même trafic de production et évalué avec les mêmes règles, tandis que le groupe témoin correspondait au comportement normal de vrais utilisateurs. Le résultat ne mesure donc pas subjectivement si quelque chose « paraît réel », mais si ce trafic peut être distingué avec ces règles.
Indicateurs pour évaluer si la simulation est réelle
Les mesures utilisées dans l’étude peuvent être regroupées en quatre catégories.
- Cohérence : la version déclarée par le navigateur correspond-elle à la structure de ses objets internes ? C’est l’indicateur central et le plus difficile à falsifier, car modifier une chaîne de caractères ne change pas en même temps le nombre d’objets et de propriétés dans le moteur.
- Taux de détection : l’étude a mené des essais détaillés sur quatre solutions, avec des taux compris entre 67 % et 84 %.
- Écart par rapport aux appareils réels : avec les mêmes règles de décision, les navigateurs normaux obtenaient un score de risque de 0, tandis que les solutions testées affichaient une moyenne comprise entre 8,85 et 11,66. Ce score mesure la distance par rapport à la distribution réelle, et non une impression subjective de ressemblance.
- Distinguabilité : le trafic testé peut-il être séparé du trafic normal ? Une catégorie impossible à séparer indique qu’avec cette méthode, aucun écart comportemental n’apparaît par rapport aux vrais navigateurs.
Parmi ces quatre indicateurs, le premier est la cause ; les trois autres en sont les conséquences.
Là où les quatre catégories de résultats se différencient
L’étude a réparti les solutions testées en quatre catégories selon leur implémentation sous-jacente.
Dans la première catégorie, les caractéristiques de bas niveau ne correspondent à aucune version connue d’un vrai navigateur : aucun moteur ne peut donc leur être associé. Une simple vérification révèle l’écart.
Dans la deuxième, l’environnement contient de vraies caractéristiques d’empreinte, mais lors d’un changement d’identité, seule la déclaration de surface change tandis que le moteur sous-jacent reste identique. C’était le cas le plus fréquent dans l’étude. Par analogie, la carte de visite affiche une nouvelle version, mais l’accent reste ancien. Le problème n’est pas la qualité du réglage de chaque paramètre, mais l’écart entre déclaration et comportement ; l’essentiel des détections vient de là.
Dans la troisième catégorie, le moteur sous-jacent change en même temps que l’identité. Si l’environnement déclare une version donnée, il exécute le moteur correspondant, la cohérence est donc préservée et ce détecteur n’a pas distingué le trafic. L’article précise également que des méthodes de détection plus complexes seraient nécessaires pour identifier cette catégorie.
La quatrième catégorie ne modifie pas le navigateur : elle exécute un vrai navigateur dans une machine virtuelle, puis charge la configuration cible. Comme le navigateur est réellement authentique, le détecteur ne peut pas le distinguer, mais le coût opérationnel est élevé et difficile à mettre à l’échelle.
La différence entre les quatre catégories ne tient pas au nombre de paramètres, mais au fait que la déclaration et le comportement proviennent ou non de la même base.
Conseils pratiques pour choisir une solution d’environnement
La détection s’est déplacée de la lecture des déclarations vers la validation du comportement ; les paramètres de surface modifiables procurent donc de moins en moins d’avantage. Pour une évaluation concrète :
- Interrogez la couche sous-jacente, pas la liste des paramètres. Quand la version déclarée change, la couche interne change-t-elle aussi ? Les empreintes sont-elles générées automatiquement sous forme de combinaisons réelles, ou assemblées manuellement comme un jeu de valeurs ?
- Comparez les environnements entre eux. Si plusieurs environnements renvoient des caractéristiques internes très similaires, l’isolation n’est pas complète.
- La cohérence d’abord, la différenciation ensuite. Plus on ajuste de caractéristiques contradictoires entre elles, plus la surface d’exposition augmente.
- Réussir une page de détection générique ne signifie pas qu’une plateforme acceptera l’environnement. La validation finale doit encore s’appuyer sur une petite quantité de trafic réel pour vos propres essais.
Le problème essentiel de l’isolation d’environnement consiste à rendre chaque environnement autonome et cohérent en interne. C’est précisément ce que PurpleMark cherche à faire. La détection comme l’antidétection doivent rester dans les limites de conformité applicables ; la véritable valeur de cette étude est de fournir une base factuelle pour l’évaluation, et non un classement des bons et des mauvais produits.
