Browser fin­ger­prin­ting : fon­da­men­taux et pro­tec­tion

Depuis juin 2009, vous avez la pos­si­bi­lité d’inclure votre empreinte digitale sur votre passeport en France. En com­bi­nai­son avec la pho­to­gra­phie, cela apporte une garantie sup­plé­men­taire au détenteur du passeport. En effet, alors que la com­pa­rai­son classique de la photo et de l’apparence réelle comporte théo­ri­que­ment le risque qu’un étranger qui vous ressemble et qui est entré en pos­ses­sion de votre carte d’identité se fasse passer pour vous, le lien vers l’empreinte digitale, qui est toujours unique, exclut un tel scénario dans tous les cas.

Les browser fin­ger­prints (em­preintes digitales des na­vi­ga­teurs) ne se dis­tin­guent pas par leur unicité mais ils offrent un taux de réussite de plus de 80 % lorsqu’il s’agit de re­con­naître les uti­li­sa­teurs du Web, et ce, malgré le fait que la capture de ces em­preintes digitales nu­mé­riques fonc­tionne com­plè­te­ment sans l’uti­li­sa­tion de cookies. C’est la raison pour laquelle les spé­cia­listes du marketing et les ex­ploi­tants de sites Web utilisent de plus en plus souvent l’analyse de suivi des na­vi­ga­teurs pour suivre les uti­li­sa­teurs en ligne et utiliser les résultats pour optimiser le site Web ou pour concevoir des pu­bli­ci­tés ciblées.

Pour récupérer le contenu d’un serveur, vous avez besoin d’un logiciel client. Par exemple, vous pouvez utiliser un client de mes­sa­ge­rie pour récupérer les messages du serveur de mes­sa­ge­rie. Les serveurs Web sont ac­ces­sibles avec les na­vi­ga­teurs les plus connus comme Mozilla Firefox, Safari ou Google Chrome. Grâce au protocole HTTP, ces ap­pli­ca­tions demandent des données aux sites Web et les affichent de manière pratique. Le contenu est transmis via des paquets IP qui, en plus des données uti­li­sa­teurs, con­tien­nent également des in­for­ma­tions sur le client et qui peuvent être utilisées côté serveur pour dé­ter­mi­ner l’empreinte digitale du na­vi­ga­teur.

Il existe es­sen­tiel­le­ment deux types de browser fin­ger­prin­tings :

• Le fin­ger­prin­ting passif : il re­pré­sente la collecte des in­for­ma­tions du na­vi­ga­teur qui se fait sans l’uti­li­sa­tion d’une ap­pli­ca­tion spé­ci­fique. Il s’agit d’in­for­ma­tions contenues par défaut dans les données d’en-tête des paquets IP et qui at­teig­nent donc toujours le serveur Web. Ces in­for­ma­tions com­pren­nent, entre autres, l’adresse IP, le port utilisé et le type de na­vi­ga­teur. Mais aussi des con­fi­gu­ra­tions de base telles que les types de fichiers souhaités (HTML, XHTML, XML), les jeux de ca­rac­tères (par ex. UTF-8) ou les langues (gé­né­ra­le­ment la langue du na­vi­ga­teur ou du système d’ex­ploi­ta­tion) sont inclus. Dans certains cas, l’en-tête HTTP fournit également des in­for­ma­tions sur le système d’ex­ploi­ta­tion utilisé et la page source.
• Le fin­ger­prin­ting actif : dans le cas d’une empreinte digitale active, le na­vi­ga­teur interroge spé­ci­fi­que­ment les in­for­ma­tions qui ne sont pas au­to­ma­ti­que­ment fournies lorsqu’une ressource Web est appelée. Cette requête fonc­tionne avec des ap­pli­ca­tions Ja­vaS­cript ou des plugins qui étendent les fonc­tion­na­li­tés du na­vi­ga­teur (en par­ti­cu­lier Adobe Flash et Microsoft Sil­ver­light). Entre autres, des in­for­ma­tions dé­tail­lées sur le na­vi­ga­teur, mais aussi des in­for­ma­tions dé­tail­lées sur le système d’ex­ploi­ta­tion et l’écran de l’uti­li­sa­teur (largeur, hauteur, ré­so­lu­tion) peuvent être obtenues de cette manière. D’autres données four­nis­sent des in­for­ma­tions sur les polices ins­tal­lées ou le fuseau horaire dans lequel se trouve l’uti­li­sa­teur par exemple.

Comme mentionné pré­cé­dem­ment, l’empreinte digitale du na­vi­ga­teur sert à iden­ti­fier un uti­li­sa­teur afin de pouvoir le re­con­naître plus tard. Il est de cette façon possible d’observer leur com­por­te­ment de na­vi­ga­tion afin d’acquérir des con­nais­sances sur la fonc­tion­na­lité et l’uti­li­sa­tion du projet Web ou d’afficher un contenu per­son­na­lisé à cet uti­li­sa­teur. Evi­dem­ment, le visiteur du site ne devrait pas remarquer le browser fin­ger­prin­ting autant que cela est possible, ce qui n’est pas un problème avec la variante passive, puisque les données sont de toute façon trans­fé­rées à chaque demande et ne doivent être sau­ve­gar­dées que du côté du serveur.

Cependant, cette in­for­ma­tion transmise au­to­ma­ti­que­ment manque souvent d’ex­pres­si­vité. En par­ti­cu­lier l’adresse IP, dont le stockage est également pro­blé­ma­tique pour des raisons ju­ri­diques, et les ports TCP utilisés ne peuvent pas remplir leur rôle de ca­rac­té­ris­tiques décisives de l’empreinte digitale numérique pour deux raisons :

1. At­tri­bu­tion dynamique d’adresses : si vous vous connectez à Internet, vous ne recevrez pas d’adresse IP fixe et per­ma­nente de votre four­nis­seur d‘accès. Vous obtenez à chaque fois une nouvelle IP dynamique à partir du vivier d’adresses dis­po­nibles. Une adresse IP spé­ci­fique ne peut donc être attribuée qu’à un seul appareil pour une période de temps donnée. Seul l’uti­li­sa­teur et son four­nis­seur savent exac­te­ment quand un appareil obtient une nouvelle adresse Internet.
2. Tra­duc­tion d’adresses réseau (Network Adress Trans­la­tion NAT) : encore plus pro­blé­ma­tique lorsque NAT est utilisée. La procédure connecte plusieurs appareils à Internet sous une adresse IP publique commune, les uti­li­sa­teurs partagent donc cette adresse IP. Elle est utilisée, par exemple, par les routeurs qui unissent les ménages privés dans un réseau local, mais aussi par les four­nis­seurs qui utilisent la tech­no­lo­gie pour contrôler le secteur des com­mu­ni­ca­tions mobiles en par­ti­cu­lier. De cette façon, il arrive que les appareils mobiles partagent la même adresse IP avec deux uti­li­sa­teurs dif­fé­rents.

Les deux tech­niques d’at­tri­bu­tion d’adresses résultent prin­ci­pa­le­ment de la pénurie d’adresses IPv4 dis­po­nibles. Etant donné que le protocole suc­ces­seur IPv6 résoudra ce problème dans les années à venir, il reste à voir dans quelle mesure les adresses dy­na­miques et le NAT seront utilisés à l’avenir.

Les ports TCP utilisés par un client pour com­mu­ni­quer avec le serveur ne con­vien­nent pas non plus comme fonction de re­con­nais­sance de pé­ri­phé­rique. Alors que le numéro de port source est généré au hasard pour chaque requête, des numéros de port par défaut fixes sont toujours fournis pour les services du réseau, ce qui explique pourquoi tous les clients utilisent le même port de des­ti­na­tion. Par exemple, pour les requêtes HTTP vers un serveur Web, il s’agit du port TCP80.

L’en-tête du protocole HTTP qui est utilisée pour la trans­mis­sion de contenu Web n’a pas, con­trai­re­ment au TCP et donnés d’en-tête, de taille fixe. En plus de la capacité de contenir des entrées définies par l’uti­li­sa­teur, divers champs nor­ma­li­sés sont requis, dont certains sont d’une im­por­tance élé­men­taire pour la création de l’empreinte digitale du na­vi­ga­teur. Il s’agit notamment des données d’en-tête suivantes :

• « Referer » (page d‘origine) : lorsqu’un uti­li­sa­teur passe de la page A à la page B, l’URL de la page A est trans­fé­rée, en tant que Referer, au serveur de la page B. Dans certaines cir­cons­tances, certains uti­li­sa­teurs at­teig­nent toujours la page cible à partir d’une certaine page source, ce qui est tout aussi utile pour créer l’empreinte digitale que les pa­ra­mètres GET contenus dans l’URL.
• « User-Agent » (des­crip­tion du client) : pour chaque requête HTTP, le client fournit gé­né­ra­le­ment une des­crip­tion de lui-même dans le champ « User Agent ». En plus du nom et du numéro de version, l’en-tête HTTP fournit également un espace pour un com­men­taire dans lequel de nombreux na­vi­ga­teurs listent la pla­te­forme ou le système d’ex­ploi­ta­tion sous-jacent.
• « Accept » (formats de sortie autorisés) : le na­vi­ga­teur utilise le champ d’ac­cep­ta­tion pour informer le serveur des types de contenu qu’il peut traiter et souhaite donc utiliser comme formats de sortie possibles. Outre HTML, XHTML (Ex­ten­sible Hypertext Markup Language) et XML (Ex­ten­sible Markup Language) sont par­ti­cu­liè­re­ment demandés. Si le champ est manquant, le client prend en charge tous les types de contenu.
• « Accept-Charset » (polices au­to­ri­sées) : en plus du format de sortie, le client peut également définir le jeu de ca­rac­tères souhaité que le serveur doit utiliser dans sa réponse. Il s’agit prin­ci­pa­le­ment de l’UFT -8 et de la norme ISO/IEC 8859-1.
• « Accept-Encoding » (formats de com­pres­sion acceptés) : afin d’optimiser le temps de char­ge­ment du projet Web, il est courant de com­pres­ser le contenu Web avant l’envoi. Le na­vi­ga­teur doit extraire les données com­pres­sées avant de pouvoir les afficher. Dans le champ « Accepter l’encodage », il informe le serveur contacté des formats de com­pres­sion qu’il prend en charge. La liste des pro­cé­dures possibles main­te­nues par l’ IANA comprend gzip, deflate, exi et br, entre autres.

La prise d’empreinte digitale active exige, comme son nom l’indique, que l‘opérateur d’un projet Web demande ac­ti­ve­ment des in­for­ma­tions sur le client. Les pro­prié­tés et les données demandées sont donc des ca­rac­té­ris­tiques qui n’ap­pa­rais­sent pas dans les données d’en-tête des packages clients. Comme cela exige que les ap­pli­ca­tions soient exécutées du côté du na­vi­ga­teur, l’uti­li­sa­teur peut théo­ri­que­ment prouver l’empreinte digitale de l’appareil à tout moment en analysant les paquets de données sortants ou le code source HTML ou Ja­vaS­cript. Dans la grande majorité des cas, cependant, le processus restera caché aux visiteurs, tout comme avec des pro­cé­dures de suivi com­pa­rables.

Pour un échange de données trans­pa­rent et rapide entre le client et le serveur, il est courant d’im­plé­men­ter l’empreinte active du na­vi­ga­teur via des éléments AJAX (Asyn­chro­nous JavaScript and XML). Cette tech­no­lo­gie permet aux visiteurs d’interagir avec une page sans avoir à la recharger com­plè­te­ment à chaque requête HTTP. Pour cela, seules les res­sources demandées sont chargées en arrière-plan, alors que l’uti­li­sa­teur peut encore voir et utiliser tous les autres éléments. L’in­for­ma­tion qui peut être obtenue à l’aide des scripts ap­pro­priés peut-être divisée en deux ca­té­go­ries : l’in­for­ma­tion sur le na­vi­ga­teur et l’in­for­ma­tion à l’écran. De plus, l’empreinte digitale de l’appareil peut également être étendue avec des in­for­ma­tions sur le fuseau horaire et les couleurs du système en utilisant Ja­vaS­cript.

La plupart des pro­prié­tés qui peuvent être in­ter­ro­gées via le na­vi­ga­teur de l’uti­li­sa­teur sont les mêmes que celles obtenues avec l’empreinte digitale passive. Le suivi est possible à l’aide de l’objet Navigator, qui est une fonction possible pour les objets Windows, c’est-à-dire les fenêtres qui s’ouvrent dans le na­vi­ga­teur. Même si aucune norme générale n’est définie pour l’objet Navigator, il est toujours supporté par tous les na­vi­ga­teurs courants. Entre autres choses, il transmet les in­for­ma­tions suivantes au serveur Web :

• navigator.appName : transmet le nom du na­vi­ga­teur, par exemple « Opera » ou « Netscape ».
• navigator.app­Ver­sion : informe le serveur de la version du na­vi­ga­teur et, dans quelques cas, du système d’ex­ploi­ta­tion et même du type de pro­ces­seur. Une entrée possible est par exemple « 5 :0 (Windows) ».
• navigator.coo­kieE­na­bled : à l’aide de la fonction coo­kieE­na­bled, il est possible de vérifier si les cookies sont supportés par le na­vi­ga­teur (« true ») ou si l’uti­li­sa­teur les a dé­sac­ti­vés (« false »).
• navigator.language : cette propriété vous permet de trouver la langue du na­vi­ga­teur. Elle est supportée par tous les na­vi­ga­teurs courants (Internet Explorer à partir de la version 11.0, Firefox à partir de la version 1.0) et cor­res­pond ap­proxi­ma­ti­ve­ment à l’entrée HTTP « Accept Language ». Des exemples de codes de langue valides sont « en », « en-US » ou « de ».
• navigator.platform : spécifie la pla­te­forme utilisée par l’uti­li­sa­teur. Les valeurs possibles incluent Win32, MacIntel, Linux i686, iPhone, Android et SunOS.
• navigator.userAgent : même si l’empreinte digitale du na­vi­ga­teur est active, il est possible d’afficher un ID na­vi­ga­teur détaillé. La propriété userAgent ne diffère pas des in­for­ma­tions d’en-tête HTTP du même nom et renvoie des valeurs telles que le nom, la version et la pla­te­forme du na­vi­ga­teur dans le résumé. L’exemple suivant montre un extrait possible : « Mozilla*5.0 (Windows NT 6.1 ; WOW64 ; rv :53.0) Gecko/20100101 Firefox/53.0 ».

Les in­for­ma­tions sur l‘écran du visiteur du site Web peuvent également être connues via une fenêtre de na­vi­ga­teur Ja­vaS­cript. Comme l’objet Na­vi­ga­teur, il n’est pas spécifié dans une norme, mais est supporté par tous les na­vi­ga­teurs courants. Jusqu’à cinq fonctions d’af­fi­chages sont trans­mises au serveur avec un script approprié :

• screen.width : cette valeur indique la largeur totale (en pixels) de l‘écran uti­li­sa­teur.
• screen.height : la propriété height indique au serveur la hauteur totale (en pixels) de l’affichage uti­li­sa­teur.
• screen.avail­Width : spécifie la largeur d’affichage réelle (en pixels) dis­po­nible pour l’uti­li­sa­teur. Pour ce faire, la largeur des fonctions de l’interface, comme la barre des tâches de Windows, est sous­traite de la valeur totale.
• screen.avail­Height : spécifie la hauteur d’affichage réelle (en pixels) dis­po­nible pour l’uti­li­sa­teur. Comme pour la largeur dis­po­nible, les di­men­sions des ca­rac­té­ris­tiques de l’interface sont sous­traites de la valeur totale.
• screen.co­lor­Depth : la fonction co­lor­Depth indique au serveur Web la pro­fon­deur de couleur (bits par pixel) dis­po­nible à l’uti­li­sa­teur pour l’affichage des images. co­lor­Depth est équi­valent à la fonction pixel­Depth qui renvoie également la valeur de pro­fon­deur de couleur mais n’est pas prise en charge par tous les na­vi­ga­teurs.

Le fuseau horaire dans lequel se trouve un uti­li­sa­teur peut être déterminé à l’aide de la méthode Ja­vaS­cript get­Ti­me­zo­neOff­set(). Stric­te­ment parlant, cela re­pré­sente la dif­fé­rence de temps entre l’UTC (Universal Coor­di­na­ted Time) et l’heure locale en minutes. Les réglages du système d’ex­ploi­ta­tion sont utilisés comme valeurs de référence. Une simple boîte de dialogue Ja­vaS­cript qui im­plé­mente la méthode et présente la dif­fé­rence ressemble à ceci :

Lo­gi­que­ment, le système de couleur doit aussi être ac­ces­sible depuis les pa­ra­mètres du système d’ex­ploi­ta­tion pour le traçage. Afin que la fonction utile ici Ja­vaS­cript get­Com­pu­ted­Style() puisse être choisie par l’uti­li­sa­teur dans l’optique d’un cadre de fenêtre, de zone de et compagnie, elle est soumise au support d’un CSS (Cascading Style Sheets). La langue de feuille de style vous permet de créer des éléments de site Web qui adoptent au­to­ma­ti­que­ment les pa­ra­mètres de couleur du système du visiteur. En détail, il s’agit de la sélection des couleurs pour ces éléments du système :

• Cadres de la fenêtre active (Ac­ti­ve­Bor­der)
• Texte du titre de la fenêtre active (Ac­ti­ve­Cap­tion)
• Arrière-plan du bureau (Back­ground)
• Texte sur les boutons (But­ton­Text)
• Bordure d’éléments 3D (ThreeD­High­light)

Le serveur Web reçoit alors les valeurs de couleur cor­res­pon­dantes ou les des­crip­tions des couleurs du système et peut les inclure dans la création de l’empreinte digitale.

Les na­vi­ga­teurs Internet ont été conçus à l’origine pour afficher des documents HTML simples, y compris des images in­di­vi­duelles. Au fil du temps, cependant, les exigences imposées aux pro­grammes clients ont con­si­dé­ra­ble­ment augmenté en raison de projets Web de plus en plus complexes, et les éléments in­te­rac­tifs se sont ra­pi­de­ment imposés, en plus des formats de médias tels que les fichiers audio et vidéo. Pour que les na­vi­ga­teurs puissent lire ces dif­fé­rents contenus, les dé­ve­lop­peurs ont dû étendre la gamme de fonctions des ap­pli­ca­tions. Ceci a été fait par le biais des plugins qui sont encore utilisés à cette fin aujourd’hui. A l’aide de Ja­vaS­cript, les plugins installés peuvent être vérifiés et utilisés pour dé­ter­mi­ner l’empreinte digitale du na­vi­ga­teur.

Le plugin le plus populaire au monde est Adobe Scho­ck­wave Flash qui est né­ces­saire pour lire les ani­ma­tions Flash. En outre, Flash a été le format pré­do­mi­nant pour les vidéos sur le Word Wide Web pendant des années, ce qui fait de l’extension, qui inclut Flash Player notamment, un must. Bien que HTML5 soit devenu une al­ter­na­tive plus sérieuse et plus sûre pour la diffusion et la lecture de contenu vidéo, le plugin est toujours installé dans plusieurs na­vi­ga­teurs. La plupart des na­vi­ga­teurs standards des appareils mobiles, qui n’offrent pas d’extension cor­res­pon­dante, sont une exception.

Néanmoins, un scan pour Adobe Flash, y compris le numéro de version, reste un élément important pour spécifier l’empreinte digitale numérique d’un na­vi­ga­teur. Un script possible qui utilise une ins­truc­tion « try…catch » à cette fin et qui peut être im­plé­menté n’importe où dans le projet Web ressemble à ceci :

Dans un premier temps, l’ap­pli­ca­tion Ja­vaS­cript tente de créer un nouvel objet ActiveX (ne fonc­tionne que dans Internet Explorer), qui détermine et transmet le numéro de version dans les cas réussis. Si ce processus échoue, le script accède à l’objet mime Types, qui est su­bor­donné à l’objet Navigator déjà ré­per­to­rié. Le même est capable de détecter tous les formats de fichiers et les plugins de lecture (navigator.plugins) supportés par le na­vi­ga­teur. Dans le contexte du script utilisé ici, il y a ré­troac­tion s’il rencontre Scho­ck­wave Flash ou Scho­ck­wave Flash 2.0.

Des fonc­tion­na­li­tés si­mi­laires comme Scho­ck­wave Flash sont également ajoutées au na­vi­ga­teur par l’extension Sil­ver­light de Microsoft. Le plugin pour la prise en charge des éléments in­te­rac­tifs est gé­né­ra­le­ment beaucoup moins courant qu’Adobe Flash, par exemple, et n’est plus pris en charge par de nom­breuses versions de na­vi­ga­teurs po­pu­laires. Cependant, cela peut s’avérer précieux pour le browser fin­ger­prin­ting, car un na­vi­ga­teur qui a ce plugin installé peut, à l’inverse, se dis­tin­guer clai­re­ment de beaucoup d’autres na­vi­ga­teurs. Dans ce contexte, vous pouvez à nouveau utiliser un script en deux parties pour le test fin­ger­print qui, dans ce cas, essaie d’abord de con­fi­gu­rer un objet ActiveX et inspecte l’objet navigator.plugins s’il échoue :

Comme mentionné pré­cé­dem­ment, la première partie du script tente d’utiliser un objet ActiveX, afin de détecter Microsoft Sil­ver­light. Dans ce but, les trois versions actuelles (à partir de mai 2017) des plugins sont listées dans le tableau « v ». La liste est le fondement de la fonction « is­Ver­sion­Sup­por­ted » qui édite la valeur « true » (s’applique) ou « false » (ne s’applique pas) pour la version res­pec­tive, selon que le client contrôlé le supporte ou non. Si les éléments ActiveX ne sont pas supportés, le script examine l’objet navigator.plugins à la place.

Les deux scripts déjà in­tro­duits con­vien­nent pour capturer les deux plugins les plus im­por­tants et le seul moyen de dé­ter­mi­ner ces ex­ten­sions pour un uti­li­sa­teur d’Internet Explorer. Pour tous les na­vi­ga­teurs qui prennent en charge l’objet navigator.plugins, il existe cependant une autre option qui ajoute des in­for­ma­tions sur Shockwave Flash et Microsoft Sil­ver­light à l’empreinte du na­vi­ga­teur, mais aussi sur tous les plugins de na­vi­ga­teur installés, encore une fois en utilisant l’ins­truc­tion « Try…catch » :

Le sous-objet « plugins » du na­vi­ga­teur est recherché avec ce script pour les plugins installés, y compris le nom (« name »), la des­crip­tion (« des­crip­tion ») et le nom du fichier (« filename »).

De la même manière, tous les formats supportés par le client respectif peuvent également être analysés pour l’empreinte digitale du na­vi­ga­teur. Il y a des dif­fé­rences à cet égard, par exemple sur dif­fé­rents appareils, c’est pourquoi les valeurs obtenues peuvent con­tri­buer à la spé­ci­fi­ca­tion de l’empreinte digitale dans de nombreux cas. Cependant, au lieu de l’objet « plugins », le script doit accéder à l’objet « mimeTypes » déjà mentionné :

Comme mentionné pré­cé­dem­ment, CSS et Ja­vaS­cript peuvent être utilisés pour vérifier si certaines polices sont ins­tal­lées sur le système d’ex­ploi­ta­tion du client sous enquête. La con­nais­sance des polices exis­tantes est in­té­res­sante pour plusieurs raisons, dont certaines vont même au-delà de la simple dé­ter­mi­na­tion de l’empreinte digitale. Entre autres choses, un coup d’œil aux polices de ca­rac­tères peut fournir les in­for­ma­tions suivantes :

• Identifié le logiciel qui a installé la ou les polices, comme Microsoft Office ou Adobe Creative Cloud
• Dé­ter­mi­ner le logiciel utilisé pour créer votre propre police (par exemple, votre écriture per­son­nelle)
• Con­clu­sions sur les pré­fé­rences et les intérêts de l’uti­li­sa­teur client, par exemple sur la base de polices de ca­rac­tères, de logos ou de jeux de ca­rac­tères spé­ci­fiques à un sujet.

La liste succincte montre que de telles enquêtes sur les polices de ca­rac­tères non seulement aident à préciser l’empreinte digitale, mais peuvent également être utiles pour créer des campagnes pu­bli­ci­taires ciblées. Bien sûr, plus il y a de polices ins­tal­lées, meilleurs sont les résultats de l’analyse. Alors qu’avec les CSS, seules les polices in­di­vi­duelles peuvent être dé­ter­mi­nées, avec une ap­pli­ca­tion Flash (.swf) et la fonction Ja­vaS­cript re­cei­ve­Fonts(), il est possible de récupérer et de lister l’arsenal complet des polices. Le code né­ces­saire de l’objet Flash (Ac­tionS­cript) ressemble à ceci:

L’in­té­gra­tion dans le document HTML succède à ce code, qui doit être inséré dans la zone de corps :

Les services Web comme les pla­te­formes de médias sociaux exigent gé­né­ra­le­ment que l’uti­li­sa­teur accédant dispose d’un compte uti­li­sa­teur spé­ci­fique et soit connecté avec celui-ci. Autrement, la majorité des res­sources que le service respectif fournit reste cachée, une cir­cons­tance qui peut être utilisée lors de la création de l’empreinte digitale du na­vi­ga­teur. Pour cela, une seule ressource au service, à laquelle seuls les uti­li­sa­teurs en­re­gis­trés peuvent accéder, doit être connue et intégrée dans le projet Web pour être vérifiée dans le cadre d’un élément DOM.

Le type d’éléments est se­con­daire, car les com­po­sants décisifs, les évé­ne­ments onload() et onerror(), peuvent être utilisés dans de nombreux com­po­sants HTML tels que <img />,<frame /> ou <script />. Ils y sont dé­clen­chés si la ressource liée a été chargée ou n’a pas pu être chargée. Après quoi le serveur Web reçoit une no­ti­fi­ca­tion cor­res­pon­dante. Un exemple <img> élément qui vérifie l’état de connexion sur Twitter est créé à l’aide des lignes de code suivantes, notez que l’URL peut changer à tout moment :

Le guide montre quelles sont les options de suivi de grande portée qu’offre une empreinte digitale de na­vi­ga­teur bien conçue, et donc aussi la rapidité avec laquelle un uti­li­sa­teur peut être reconnu et tracé même sans cookies. Très peu de gens savent si l’empreinte digitale de leur propre na­vi­ga­teur est unique ou non. Il existe dif­fé­rents outils Web tels que AmlUnique ou Pa­nop­ti­click avec lesquels vous pouvez tester l’unicité de votre propre browser fin­ger­prin­ting en un seul clic.

Ainsi, si vous souhaitez obtenir de la clarté et tester votre na­vi­ga­teur, par exemple avec premier AmlUnique, appelez sim­ple­ment le service via l’adresse Web amiunique.org et cliquez sur le bouton « Voir mon empreinte digitale de na­vi­ga­teur ». Voici un bref aperçu de votre na­vi­ga­teur Web, le comparant à plus de 370 000 autres na­vi­ga­teurs (en date de mai 2017).

Les valeurs ini­tia­le­ment présentes ne sont pas les seules données que l’outil Web vérifie et incorpore dans l’empreinte du na­vi­ga­teur. Les boutons « cliquez ici » ou « voir plus de détails » vous donnent un aperçu détaillé de toutes les in­for­ma­tions qui ont contribué à la dé­ter­mi­na­tion de l’unicité. Entre autres, vous trouverez également les valeurs ex­pli­quées dans le guide, comme les types de contenu acceptés, les méthodes de com­pres­sion possibles, la ré­so­lu­tion de l’écran ou l’ac­cep­ta­tion des cookies.

Il n’est pas possible d’empêcher com­plè­te­ment que l’empreinte digitale numérique de votre na­vi­ga­teur Internet soit dé­ter­mi­née, les ca­rac­té­ris­tiques trans­fé­rées au­to­ma­ti­que­ment dans l’en-tête HTTP lors de l’empreinte digitale passive sont toujours reçues par l’opérateur du serveur Web. Cependant, vous pouvez essayer de maintenir la valeur de re­con­nais­sance de votre client aussi bas que possible afin que l’empreinte digitale ne soit pas unique et donc inu­ti­li­sable pour le suivi. La solution la plus simple est d’utiliser une extension de na­vi­ga­teur qui bloque au­to­ma­ti­que­ment les contenus actifs tels que Ja­vaS­cript, Flash ou Sil­ver­light, ce qui les empêche lo­gi­que­ment de trans­mettre des in­for­ma­tions au serveur.

Ces plugins, qui incluent NoScript pour Firefox ou Script­Block pour Chrome, cons­ti­tuent aussi la pro­tec­tion optimale contre le Canvas-Fin­ger­prin­ting. Ce sous-type d’em­preintes digitales de na­vi­ga­teur tente de suivre le client spé­ci­fi­que­ment en utilisant des éléments de Canvas. Le fait que le rendu du texte dans ces éléments varie gran­de­ment selon le système d’ex­ploi­ta­tion, le na­vi­ga­teur, la carte graphique, les pilotes et les polices est utilisé.

Toutefois, lorsque vous activez de tels plugins, vous devez con­si­dé­rer le fait que des services Web spé­ci­fiques ou du moins certains contenus in­di­vi­duels ne fonc­tion­ne­ront peut-être plus. Bien que les ex­ten­sions, les contenus ou les sites Web vous per­met­tent de définir des listes de filtres spé­ci­fiques pour suspendre le blocage des scripts, cela n’est pas très utile si vous n’êtes pas sûr si le four­nis­seur est digne de confiance ou non. Il convient également de noter que l’uti­li­sa­tion d’un tel bloqueur est également une fonction qui peut être utilisée di­rec­te­ment pour spécifier l’empreinte digitale numérique.

Outre les solutions de blocage de script, tout ce qu’il vous reste à faire est de ne pas in­di­vi­dua­li­ser le système et le na­vi­ga­teur. Choi­sis­sez un na­vi­ga­teur fré­quem­ment utilisé (Firefox par exemple en France) et utilisez les pa­ra­mètres par défaut si possible. Il en va de même pour le système d’ex­ploi­ta­tion utilisé. Si vous ne disposez pas d’ex­ten­sions sup­plé­men­taires pour votre client, vous avez de bonnes chances de ne pas créer une empreinte digitale unique et d’être bien préparé contre les pro­cé­dures de suivi. En attendant, en tant qu’uti­li­sa­teur de smart­phone, en par­ti­cu­lier avec les anciens modèles, vous êtes encore largement en sécurité, grâce au fait que les smart­phones n’offrent ac­tuel­le­ment que peu d’options de per­son­na­li­sa­tion pour le na­vi­ga­teur et le système.