Fingerprinting

Le fingerprinting consiste à tenter d'identifier un utilisateur lorsqu'il revient sur votre site Web ou à identifier le même utilisateur sur différents sites Web. De nombreuses caractéristiques peuvent différer entre votre configuration et celle d'un autre utilisateur. Par exemple, vous utilisez peut-être un type d'appareil et un navigateur différents, et vous avez une taille d'écran et des polices différentes. Si j'ai la police "Dejavu Sans" installé et que vous ne le faites pas, alors n’importe quel site web peut faire la différence entre vous et moi en vérifiant cette police. Voici comment le fingerprinting fonctionne ; vous constituez une collection de ces points de données, et chacun offre davantage de moyens de distinguer les utilisateurs.

Une définition plus formelle pourrait ressembler à ceci: le fingerprinting est l'action qui consiste à utiliser des éléments de longue durée de la configuration d'un utilisateur afin d'essayer de le distinguer du plus grand nombre d'utilisateurs possible.

Pourquoi le fingerprinting porte-t-il atteinte à la confidentialité des utilisateurs ?

Il existe des cas particuliers où l'empreinte d'un utilisateur est importante, par exemple pour la détection des fraudes. Mais le fingerprinting peut aussi être utilisé pour suivre les utilisateurs sur différents sites. Le suivi s'effectue souvent sans que les utilisateurs ne donnent leur consentement, ou, dans certains cas, sur la base d'un consentement non valide qui n'informe pas correctement l'utilisateur. Une fois cela fait, ces utilisateurs trouveront souvent cela quelque peu inquiétant et se sentiront plutôt trahis.

Le fingerprinting consiste à trouver des moyens de distinguer discrètement un utilisateur d'un autre. Le fingerprinting permet de reconnaître s'il s'agit toujours du même utilisateur sur le même site Web, ou de reconnaître le même utilisateur dans deux profils de navigateur différents en même temps. Cela signifie que le fingerprinting peut être utilisé pour suivre les utilisateurs sur plusieurs sites. Les méthodes de suivi déterministes et explicites, telles que le stockage d'un cookie avec un ID utilisateur unique, peuvent être observées et contrôlées dans une certaine mesure par les utilisateurs (le module précédent a expliqué certaines de ces approches). Mais le fingerprinting est plus difficile à éviter exactement parce que c'est caché ; elle repose sur des caractéristiques immuables et se produit très probablement de manière invisible. C'est pourquoi on parle d'empreinte. Dans le meilleur des cas, il est difficile de changer votre empreinte digitale, qu'il s'agisse de votre empreinte numérique ou de celle qui se trouve à l'extrémité. de vos doigts.

Les fournisseurs de navigateurs savent que les utilisateurs n'aiment pas être suivis et implémentent continuellement des fonctionnalités pour limiter le fingerprinting (que nous avons vus dans le module précédent). Nous allons voir comment ces fonctionnalités peuvent affecter vos exigences commerciales et comment continuer à faire ce que vous voulez tout en protégeant la confidentialité. Il s'agit davantage de la façon dont la protection du navigateur contre le fingerprinting influence ce que vous faites et comment, plutôt que sur la façon dont il vous empêchera de le faire.

En pratique, la plupart des développeurs et la plupart des entreprises n'ont pas besoin d'empreinte digitale des utilisateurs. Si votre application nécessite que les utilisateurs se connectent, ils s'identifient à vous, avec leur consentement, et de manière à pouvoir désactiver unilatéralement cette fonctionnalité à tout moment. Il s'agit d'une méthode de protection de la confidentialité qui permet de savoir quels utilisateurs sont connectés. Votre application peut ne pas exiger que les utilisateurs se connectent, ce qui protège encore plus leur confidentialité (et vous ne collectez alors que les données dont vous avez besoin).

À faire

Vérifiez si les services tiers font appel au fingerprinting. Dans le module relatif aux tiers, vous peut déjà disposer d'une liste des services tiers que vous incluez et des requêtes Web qu'ils effectuent. Cela peut être possible pour inspecter ces requêtes afin de voir quelles données sont renvoyées à l'émetteur, le cas échéant. Mais c'est souvent difficile : Le fingerprinting est, par nature, un processus dissimulé qui implique de demander des données qui ne sont pas soumises à l'approbation de l'utilisateur.

Nous vous conseillons également de lire les règles de confidentialité de vos dépendances et services tiers afin de rechercher d'éventuels signes de fingerprinting. en cours d'utilisation. On parle parfois de "mise en correspondance probabiliste" ou de "suite de techniques de mise en correspondance probabiliste", par opposition à la "mise en correspondance déterministe".

Fonctionnement du fingerprinting

Bien souvent, votre combinaison personnelle de tous ces attributs vous est propre, à un petit groupe de personnes similaires ; cela peut être utilisé pour vous suivre de manière cachée.

À part: le fingerprinting passif et actif

Il existe à ce stade une distinction utile entre les techniques de fingerprinting passif et active. Une technique d'empreinte digitale passive utilise les informations fournies au site Web par défaut. Une technique d'empreinte digitale active interroge explicitement le navigateur pour obtenir des informations supplémentaires. Cette distinction est importante, car les navigateurs peut tenter de détecter, d’intercepter ou d’atténuer les techniques actives. Les API peuvent être restreintes ou accessibles via une boîte de dialogue demander l'autorisation à l'utilisateur (et donc avertir l'utilisateur qu'ils sont utilisés ou lui permettre de les refuser) par défaut). Une technique passive est une technique qui utilise des données déjà fournies au site Web, souvent parce que, historiquement, au tout début de l'autoroute de l'information, cette information était transmise à tous les sites. La chaîne user-agent en est un exemple, et nous y reviendrons plus en détail plus tard. Il était considéré comme utile pour fournir de nombreuses informations sur le navigateur, la version et le système d'exploitation de l'utilisateur, afin qu'un site Web puisse choisir de présenter différentes choses en fonction de ces informations. Cependant, cela augmente également la quantité d'informations distinctives mises à disposition, d'informations qui permet d'identifier un utilisateur d'un autre ; C'est pourquoi ces informations ne sont plus disponibles, ou du moins plus figées. afin qu'il ne se distingue plus. Si votre activité repose sur ces informations, par exemple, si vous prenez différentes branches de code en fonction du user-agent. Ce code risque de ne plus fonctionner, car les navigateurs figent ou arrêtent de plus en plus cette information. Les tests constituent la meilleure protection dans ce cas ( voir plus loin).

Aparté : Mesurer la capacité d'empreinte

La mesure technique de la quantité d'informations fournie par chacun de ces points de données s'appelle l'entropie et se mesure en bits. Une caractéristique où il existe de nombreuses valeurs possibles différentes (comme la liste des polices installées) peut contribuer à beaucoup de bits au total, où un élément peu puissant (comme le système d'exploitation que vous utilisez) ne peut qu'ajouter quelques-unes. L'Almanach HTTP décrit comment les bibliothèques d'empreinte digitale existantes automatisent ce processus de combinaison des réponses de nombreuses API différentes en un "hachage", qui ne peut identifier qu'un petit groupe d'utilisateurs, voire un seul. Maud Nalpas en parle en détail dans cette vidéo YouTube, mais en résumé, imaginez que vous voyiez une liste de vos amis avec leur musique préférée, leur nourriture préférée et les langues qu'ils parlent, mais sans leur nom. Il est fort probable que la liste d'une personne l'identifie de manière unique parmi vos amis, ou du moins réduise la liste à quelques personnes. C’est ainsi que fonctionne le fingerprinting ; la liste d'éléments que vous aimez devient le "hachage". Avec ce hachage, il est plus facile d'identifier un utilisateur comme étant la même personne sur deux sites différents et non connectés, ce qui est l'objectif du suivi : contourner le désir de confidentialité de l'utilisateur.

Que font les navigateurs pour lutter contre l'empreinte digitale ?

Il est important de noter que les fournisseurs de navigateurs sont très conscients des nombreuses façons dont un site Web (ou un tiers inclus sur un site Web) peut calculer une empreinte distinctive pour un utilisateur, ou comment différents éléments d'informations peuvent contribuer à l'unicité de cette empreinte. Certaines de ces méthodes sont explicites et délibérées, comme la chaîne user-agent du navigateur, qui indique souvent identifie le navigateur, le système d'exploitation et la version utilisée (ce qui contribue à vous distinguer de moi, si vous et J'utilise des navigateurs différents). Certaines méthodes ne sont pas créées délibérément pour être exploitables par une empreinte digitale, mais le sont quand même, comme la liste des polices ou les appareils vidéo et audio disponibles pour le navigateur. (Le navigateur n'a pas besoin d'utiliser de ces appareils, obtenez simplement une liste d'entre eux par nom.) Certains ont été reconnus pour contribuer à l'identification des empreintes digitales, comme le rendu exact en pixels de l'anticrénelage des polices sur un élément de canevas. Il y en a beaucoup d'autres, et chaque différence entre votre navigateur et le mien ajoute de l'entropie, ce qui peut potentiellement permettre de faire la différence entre vous et moi, et d'identifier une personne de manière aussi unique que possible sur les sites Web. https://amiunique.org propose une longue liste (mais certainement pas exhaustive) de fonctionnalités pouvant contribuer à l'empreinte, et cette liste ne cesse de croître (car il est très intéressant d'être en mesure d'identifier les utilisateurs, même s'ils ne le souhaitent pas ou ne s'y attendent pas).

Incompatible avec certaines API puissantes

La réponse des fournisseurs de navigateurs à toutes ces approches pour calculer l'empreinte digitale d'un utilisateur est de trouver des moyens de réduire la quantité d'entropie disponible via ces API. L'option la plus restrictive consiste à ne pas les implémenter. Certains grands navigateurs l'ont fait pour diverses API matérielles et d'appareil (telles que l'accès NFC et Bluetooth à partir d'applications Web côté client), en raison de problèmes d'empreinte digitale et de confidentialité. Cela peut évidemment affecter vos applications et services : vous ne pouvez pas utiliser une API dans un navigateur qui ne l'implémente pas, ce qui peut limiter ou exclure complètement certaines approches matérielles.

Passerelle des autorisations utilisateur

Les fournisseurs de navigateurs ont également adopté une deuxième approche consistant à empêcher les accès aux API ou aux données sans autorisation explicite de l'utilisateur. Cette approche est également souvent adoptée pour des raisons de sécurité : un site Web ne doit pas pouvoir prendre de photos avec votre webcam. sans votre autorisation ! Mais dans le cas présent, la confidentialité et la sécurité peuvent avoir des intérêts similaires. Identifier la position d'une personne constitue bien sûr une violation de la confidentialité, mais cela contribue également à l'unicité de l'empreinte. Autorisation requise de voir la géolocalisation ne réduit pas l'entropie supplémentaire qu'un lieu ajoute à l'unicité de cette empreinte. élimine l'utilisation de la géolocalisation pour le fingerprinting, car celle-ci ne s'effectue plus de manière invisible. L'objectif de l'empreinte digitale est de distinguer les utilisateurs les uns des autres de manière subtile. Si vous êtes prêt à ce que l'utilisateur sache que vous essayez de l'identifier, vous n'avez pas besoin de techniques d'empreinte digitale : demandez à l'utilisateur de créer un compte et de s'y connecter.

Ajouter de l'imprévisibilité

Une troisième approche adoptée dans certains cas consiste à "brouiller" les requêtes les réponses des API afin de les rendre moins précises et donc de moins d’identification. Dans le module de données, nous avons décrit cette pratique comme une option à envisager lorsque vous collectez des données auprès des utilisateurs afin d'éviter de collecter par inadvertance des données permettant de les identifier. Les fournisseurs de navigateurs peuvent également adopter cette approche pour les données API mises à la disposition des applications Web et des tiers. C'est le cas des API de synchronisation très précises utilisées pour mesurer les performances des pages de window.performance.now(). Le navigateur connaît ces valeurs à une précision de l'ordre de la microseconde, mais les valeurs renvoyées sont délibérément réduites en étant arrondies à la 20e microseconde la plus proche limite pour éviter leur utilisation dans le fingerprinting (et pour la sécurité, pour éviter les attaques temporelles). L’objectif ici est pour s'assurer que les API restent utiles, mais pour rendre les réponses moins identifiantes: en substance, pour fournir une "immunité collective" en créant votre appareil ressemble davantage à celui de tout le monde plutôt que de vous sembler particulier. C'est pour cette raison que Safari présente une version simplifiée de la configuration système.

Appliquer un budget dédié à la confidentialité

Le Privacy Budget suggère que les navigateurs estiment les informations révélées par chaque surface de fingerprinting. Il n'a pas encore été implémenté dans les navigateurs. L'objectif est d'autoriser des API puissantes tout en préservant la confidentialité des utilisateurs. En savoir plus sur la proposition de budget pour la confidentialité

Utiliser un environnement de test étendu

Tous ces éléments auront une incidence sur la façon dont vous créez des applications et des services. En particulier, il existe une grande diversité de réponses et d'approches entre les navigateurs et les plates-formes dans ce domaine. Cela signifie qu'il est essentiel de tester votre travail dans plusieurs environnements différents. Bien sûr, cela est toujours important, mais il peut être raisonnable de supposer que le rendu HTML ou CSS sera constant pour un moteur de rendu donné, quel que soit le navigateur ou la plate-forme sur laquelle il se trouve (il peut donc être tentant de ne tester que dans un seul navigateur basé sur Blink, par exemple). Ce n'est absolument pas le cas pour l'utilisation des API, précisément parce que les navigateurs qui partagent un moteur de rendu peuvent différer considérablement dans la façon dont ils renforcent leur surface d'API contre l'empreinte digitale.

À faire

  • Vérifiez vos propres données analytiques et votre audience pour déterminer les navigateurs à privilégier lors des tests.
  • Firefox, Chrome, Edge et Safari sur ordinateur, Chrome et Samsung Internet sur Android, et Safari sur iOS sont de bons navigateurs à tester. Vous pouvez ainsi tester sur les trois principaux moteurs de rendu (Gecko dans Firefox, diverses branches de Blink dans Chrome, Edge et Samsung Internet, et Webkit dans Safari), ainsi que sur les plates-formes mobiles et de bureau.
  • Si votre site peut également être utilisé sur des appareils moins courants, tels que des tablettes, des montres connectées ou des consoles de jeu, faites-y également un test. Certaines plates-formes matérielles peuvent être en retard par rapport aux mobiles et aux ordinateurs de bureau en ce qui concerne les mises à jour des navigateurs, ce qui signifie que certaines API peuvent ne pas être implémentées ou n'est pas disponible dans les navigateurs de ces plates-formes.
  • Testez avec un ou plusieurs navigateurs qui mettent en avant la confidentialité des utilisateurs comme motivation. Incluez les versions bêta et les versions de prévisualisation à venir de vos navigateurs les plus courants, le cas échéant et si elles sont disponibles : la version preview de la technologie de Safari, Canary de Chrome et le canal bêta de Firefox. Vous avez ainsi plus de chances d'identifier les erreurs d'API et les modifications qui affectent vos sites avant qu'elles n'affectent vos utilisateurs. De même, prenez en compte les besoins en tenant compte de toute analyse existante. Si votre base d'utilisateurs compte un grand nombre de téléphones Android plus anciens, veillez à les inclure dans vos tests. La plupart des gens n'ont pas du matériel rapide et des dernières versions qu’une équipe de développement.
  • Effectuez des tests à la fois avec un profil propre et en mode navigation privée. Il est probable que vous ayez déjà accordé les autorisations requises dans votre profil personnel. Testez ce qui se passe si vous refusez l'autorisation au site pour une question.
  • Testez explicitement vos pages dans la protection contre les empreintes digitales de Firefox. . Cela permet d'afficher des boîtes de dialogue d'autorisation si votre page tente de créer une empreinte numérique ou de renvoyer des données erronées pour certaines API. Cela vous permet de vérifier si les tiers inclus dans votre service utilisent des données accessibles à l'aide d'une empreinte digitale, ou si votre propre service dépend à ce sujet. Vous pouvez ensuite déterminer si le fuzzing délibéré vous empêche de faire ce dont vous avez besoin. Envisagez d'apporter des corrections en conséquence pour obtenir ces données à partir d'une autre source, vous en passer ou utiliser des données moins précises.
  • Comme indiqué précédemment dans le module sur les tiers, il est également important d'auditer vos dépendances tierces pour voir si elles utilisent des techniques d'empreinte digitale. Le fingerprinting passif est difficile à détecter (et impossible si un tiers le fait sur son serveur), mais le mode de fingerprinting peut signaler certaines techniques de fingerprinting, et rechercher des utilisations de navigator.userAgent ou de création inattendue d'objets <canvas> peuvent aussi révéler certaines approches qui méritent un examen approfondi. Il est également utile de rechercher l'utilisation du terme "mise en correspondance probabiliste" dans les documents marketing ou techniques décrivant un tiers. Cela peut parfois indiquer l'utilisation de techniques d'empreinte digitale.

Outils de test multinavigateurs

Il est difficile d'automatiser le test de votre code à des fins de confidentialité. Les éléments à rechercher lors des tests manuels sont décrits plus haut. Que se passe-t-il lorsque vous refusez l'autorisation au site pour les API auxquelles il tente d'accéder, par exemple, et comment cela est-il présenté à l'utilisateur ? Un test automatisé ne peut pas déterminer si le site agit de manière à inciter l'utilisateur à lui faire confiance ou, au contraire, à se méfier de celui-ci. ou pensent que quelque chose est caché.

Cependant, une fois le site audité, le test des API permet de confirmer que rien n'est défectueux dans les nouvelles versions "bêta" à venir et "preview" versions) peuvent être automatisées et doivent donc être en grande partie intégrées à votre suite de tests existante. Lorsque vous travaillez avec la couverture de la surface de l'API, n'oubliez pas que la plupart des navigateurs permettent de contrôler les API et les fonctionnalités disponibles. Chrome le fait via des options de ligne de commande, tout comme Firefox. Avoir accès à ces options dans la configuration de l'outil de test vous permettra d'exécuter certains tests avec les API activées ou désactivées. (Voir, par exemple, plug-in de lancement du navigateur et le paramètre "launch.args" de Puppeteer pour connaître les différentes façons pour ajouter des indicateurs de navigateur lors du lancement.)

Ne compter que sur la chaîne du user-agent pour obtenir des informations générales

Prenons un autre exemple : les navigateurs envoient depuis le début du Web une description d'eux-mêmes avec chaque requête du En-tête User-Agent HTTP. Depuis presque longtemps, les utilisateurs exhortent les développeurs Web à ne pas utiliser le contenu de l'en-tête user-agent. pour diffuser un contenu différent selon les navigateurs. Pendant tout ce temps, les développeurs Web l'ont fait malgré tout, avec une certaine quantité de justification dans certains cas (mais pas tous). Étant donné que les navigateurs ne souhaitent pas être désignés comme responsables d'une expérience non optimale par les sites Web, chaque navigateur se fait passer pour un autre navigateur, et la chaîne user-agent se présente comme suit :

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36

Il prétend, entre autres, être Mozilla/5.0, un navigateur qui a été publié en même temps que les premiers astronautes ont embarqué à bord de la Station spatiale internationale il y a plus de deux décennies. La chaîne user-agent est bien entendu une source d'entropie riche pour l'empreinte digitale. Pour atténuer cette empreinte, les fabricants de navigateurs ont déjà gelé l'en-tête user-agent ou s'y emploient. Il s'agit d'un autre exemple de modification des données fournies par une API sans nécessairement la supprimer entièrement. L'envoi d'un en-tête user-agent vide endommagerait d'innombrables sites Web qui supposent sa présence. En général, ce que font les navigateurs consiste à supprimer certains détails, puis à les garder pour la plupart inchangés à partir de ce moment. (Vous pouvez le voir dans Safari, Chrome, et Firefox.) Cette protection contre le fingerprinting détaillé signifie essentiellement que vous ne pouvez plus compter sur la précision de l'en-tête user-agent, il est important de trouver d'autres sources de données.

Pour être clair, les données de l'user-agent ne disparaissent pas complètement, mais elles sont disponibles avec une granularité plus faible ou sont parfois inexactes, car un nombre plus ancien, mais inchangé, peut être signalé. Par exemple, Firefox, Safari et Chrome limitent tous le numéro de version macOS à 10 (pour en savoir plus, consultez Informations sur la réduction de la chaîne user-agent). Pour en savoir plus sur la façon dont Chrome prévoit de réduire les données dans la chaîne user-agent, consultez la page Réduction de l'user-agent. En résumé, vous pouvez vous attendre à ce que le numéro de version du navigateur indiqué ne contienne qu'une version majeure (le numéro de version ressemblera donc à 123.0.0.0, même si le navigateur est en version 123.10.45.108). La version de l'OS ne comportera aucun détail et sera figée sur l'un des quelques choix inchangés. Ainsi, une version imaginaire de Chrome 123.45.67.89 exécutée sur un "Windows 20" imaginaire indiquerait son numéro de version comme suit :

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Les informations de base dont vous avez besoin (la version du navigateur) sont toujours disponibles : il s'agit de Chrome 123, sous Windows. Mais la filiale d'informations (architecture de la puce, version de Windows, version de Safari qu'il imite, version mineure du navigateur) ne seront plus disponibles après cette date.

Comparez-le à un user-agent Chrome "actuel" sur une autre plate-forme :

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

On peut voir que la seule chose qui diffère est le numéro de version de Chrome (104) et l'identifiant de la plate-forme.

De même, la chaîne user-agent de Safari affiche une plate-forme et un numéro de version de Safari, et indique également une version d'OS sur iOS, mais tout le reste est figé. Ainsi, une version imaginaire de Safari 1234.5.67 exécutée sur un macOS 20 imaginaire peut indiquer l'user-agent suivant :

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

Sur un appareil iOS 20 imaginaire, cela peut se présenter comme suit:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**

Encore une fois, les informations de base (il s'agit de Safari, il est sur iOS ou macOS) sont disponibles, et Safari sur iOS fournit toujours un numéro de version iOS. Cependant, la plupart des informations secondaires qui étaient disponibles auparavant ont été gelées depuis. Plus important encore, cela inclut le numéro de version de Safari, qui n'est pas nécessairement disponible.

Les modifications apportées au user-agent signalé ont fait l'objet d'un débat houleux. Résumés à l'adresse https://github.com/WICG/ua-client-hints#use-cases summarises certains arguments et les raisons du changement, et Rowan Merewood propose une présentation avec quelques stratégies visant à ne plus utiliser le user-agent à des fins de différenciation, dans le contexte de la proposition UA Client Hints expliquée plus loin.

Fuzzing

Le "fuzzing" est un terme issu des pratiques de sécurité, où les API sont appelées avec des valeurs inattendues dans l'espoir qu'elles gèrent ces des valeurs inattendues de manière incorrecte et exposent un problème de sécurité. Les développeurs Web doivent connaître le script intersites (XSS), qui consiste à ajouter un script malveillant à une page, souvent parce que la page n'échappe pas correctement le code HTML injecté (vous effectuez donc une requête de recherche contenant le texte <script>). Les développeurs backend connaissent l'injection SQL, qui se produit lorsque les requêtes de base de données qui ne valident pas correctement les entrées utilisateur présentent des problèmes de sécurité (comme illustré par xkcd avec Little Bobby Tables). Le fuzzing, ou test fuzz, est plus approprié pour les tentatives automatisées de fournir de nombreuses entrées invalides ou inattendues à une API, et pour vérifier les résultats en cas de fuites de sécurité, de plantages ou d'autres mauvaises manipulations. Toutes ces informations illustrent délibérément des informations inexactes. Ici, cependant, les navigateurs le font de manière préventive (en rendant l'user-agent délibérément incorrect) pour encourager les développeurs à ne plus s'appuyer sur ces données.

À faire

  • Vérifiez si votre codebase dépend de la chaîne user-agent (une recherche de navigator.userAgent est susceptible de trouver la plupart des occurrences dans votre code côté client, et votre code backend recherche probablement User-Agent en tant qu'en-tête), y compris vos dépendances.
  • Si vous trouvez des utilisations dans votre propre code, déterminez ce que le code vérifie et trouvez un autre moyen de faire cette différenciation (ou trouvez une dépendance de remplacement, ou travaillez avec la dépendance en amont en signalant des problèmes ou en les interrogeant sur les mises à jour). Parfois la différenciation des navigateurs est nécessaire pour contourner les bugs, mais le user-agent devient de moins en moins le moyen de le faire une fois celui-ci bloqué.
  • Vous êtes peut-être en sécurité. Si vous n'utilisez que les valeurs principales de la marque, de la version majeure et de la plate-forme, elles seront presque certainement toujours disponibles et correctes dans la chaîne user-agent.
  • MDN décrit de bonnes façons d'éviter de s'appuyer sur la chaîne user-agent ("reniflage du navigateur"), dont la principale est la détection de fonctionnalités.
  • Si vous dépendez d'une manière ou d'une autre de la chaîne user-agent (même en utilisant les quelques valeurs fondamentales qui restent utiles), c'est une bonne l'idée de tester avec les futurs user-agents présents dans les nouvelles versions des navigateurs. Il est possible de tester ces versions de navigateur à venir à l'aide de versions bêta ou d'aperçus technologiques, mais vous pouvez également définir une chaîne user-agent personnalisée pour les tests. Vous pouvez remplacer la chaîne du user-agent dans Chrome, Edge, Firefox et Safari lors du développement local, afin de vérifier comment votre code gère les différentes valeurs de user-agents que vous pourriez recevoir de la part des utilisateurs.

Client Hints

Une proposition majeure pour fournir ces informations est les indications client User-Agent, bien que cette fonctionnalité ne soit pas disponible dans tous les navigateurs. Les navigateurs compatibles transmettront trois en-têtes: Sec-CH-UA, qui donne la marque et le numéro de version du navigateur ; Sec-CH-UA-Mobile, qui indique si la requête provient d'un appareil mobile ; et Sec-CH-UA-Platform, qui nomme le système d’exploitation. (Il est moins facile d'analyser ces en-têtes, car ils ne sont des en-têtes structurés plutôt que de simples chaînes, et cela est contrôlé par les navigateurs qui envoient des erreurs qui seront traitées de manière incorrecte si elles ne sont pas correctement analysées. Comme précédemment, il s'agit d'un exemple de "fuzz testing" effectué de manière préventive par le navigateur. Un développeur utilisant ces données doit traiter car les données sont conçues de sorte qu'une analyse incorrecte ou différée pourrait donner de mauvais résultats, par exemple pour montrer des marques qui ne ou des chaînes qui ne se ferment pas correctement.) Heureusement, ces données sont également mises à la disposition de JavaScript directement par le navigateur en tant que navigator.userAgentData, qui, dans un navigateur compatible, peut ressembler à cet objet :

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}