Merci d'avoir participé à Google I/O ! Regarder des contenus à la demande

Cette page a été traduite par l'API Cloud Translation.

Fingerprints

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 installation et celle d'un tiers. Par exemple, vous utilisez peut-être un autre type d'appareil. et un navigateur différent, ont une taille d'écran différente et ont des polices différentes installées. 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 pour tenter de le distinguer du plus grand nombre d'utilisateurs possible.

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

Dans certains cas particuliers, le fingerprinting d'un utilisateur est important, 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 cette opération effectuée, ces utilisateurs trouveront souvent inquiétant et se sentent 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 manifestes, comme le stockage d'un cookie avec un identifiant unique et spécifique, peuvent être, dans une certaine mesure, observés par les utilisateurs et contrôlés (Le module précédent vous a présenté 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 l'appelle « empreinte digitale ». 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). Dans cet article, nous examinons l'impact potentiel de ces fonctionnalités sur votre activité exigences et comment continuer à faire ce que vous voulez faire tout en respectant 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 cela vous empêche de commettre le fingerprinting.

En pratique, la plupart des développeurs et la plupart des entreprises n'ont pas besoin d'empreinte digitale des utilisateurs. Si votre appli oblige les utilisateurs à se connecter, vos utilisateurs s'identifient auprès de vous, avec leur consentement et d'une manière qui leur permet de se désinscrire de façon unilatérale à tout moment. Il s'agit d'une méthode de protection de la confidentialité qui permet de savoir quels utilisateurs sont connectés. Il est possible que votre application obliger les utilisateurs à se connecter, ce qui protège encore mieux les utilisateurs la vie privée (et vous collectez ensuite uniquement 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 "correspondance probabiliste", ou dans le cadre d'un ensemble de techniques de correspondance probabiliste. par opposition à la « 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. Le fingerprinting passif est celle qui utilise les informations qui sont fournies par défaut au site web. une technique active de fingerprinting qui 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 du user-agent est un Nous l'étudierons plus en détail plus tard. Il a été considéré comme utile pour fournir beaucoup de des informations sur le navigateur de l'utilisateur, sa version et son système d'exploitation, afin qu'un site Web puisse choisir de présenter différentes les choses en fonction de cela. Cependant, cela augmente également la quantité d'informations distinctives mises à disposition, d'informations qui permet d'identifier un utilisateur d'un autre ; Ces informations ne sont donc 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. Dans ce cas, les tests constituent la meilleure protection ( voir plus loin).

Annexe: mesurer le fingerprinting

La mesure technique de la quantité d'informations fournie par chacun de ces points de données est appelée entropie et est mesurée 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 le fingerprinting existant automatisent ce processus consistant à combiner les réponses de nombreuses API différentes dans un "hachage", qui peut n'identifier qu'un seul un petit groupe d'utilisateurs, peut-être un seul. Maud Nalpas aborde ce sujet en détail dans cette vidéo YouTube, mais en résumé, imaginez que vous voyiez Une liste de vos amis avec leur musique et leurs plats préférés, la langue qu'ils parlent... mais avec leur nom supprimés. Il est très probable que la liste d'une personne l'identifie de manière unique parmi vos amis, ou du moins qu'elle soit restreinte. la liste à quelques personnes seulement. C’est ainsi que fonctionne le fingerprinting ; la liste d'éléments que vous aimez devient le "hachage". Avec ce hachage permet d'identifier plus facilement un utilisateur comme la même personne sur deux sites non connectés. suivi: pour contourner le désir de l'utilisateur concernant la confidentialité.

Que font les navigateurs contre le fingerprinting ?

Il est important de noter que les fournisseurs de navigateurs connaissent très bien les nombreuses façons différentes pour un site Web (ou un tiers inclus dans un site web). pour calculer une empreinte caractéristique pour un utilisateur ou pour que des informations différentes contribuent à 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 délibérément créées pour être accessibles à l'aide d'une empreinte digitale, de toute façon, comme la liste des polices ou les périphériques 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 contribuer à une faire la différence entre vous et moi, et identifier une personne de manière aussi unique que possible sur les sites Web. https://amiunique.org propose une longue liste (mais pas exhaustive) d'utilisateurs susceptibles de contribuer à une empreinte digitale. et la liste s'allonge continuellement (car il existe un fort intérêt financier à pouvoir tracer les empreintes digitales, même si les utilisateurs que vous ne voulez pas ou ne s'y attend peut-être pas).

Non compatible 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 des principaux navigateurs y ont recours pour diverses API matérielles et d'appareils (telles que l'accès NFC et Bluetooth à partir de applications Web côté client), avec des problèmes de fingerprinting et de confidentialité cités comme raisons pour lesquelles elles n'ont pas été implémentées. Ceci, peuvent affecter vos applications et services: vous ne pouvez pas du tout utiliser une API dans un navigateur qui ne l'implémente pas, limiter ou couper complètement certaines approches matérielles.

Passerelle des autorisations utilisateur

Une seconde approche adoptée par les fournisseurs de navigateurs consiste à empêcher l'accès aux API ou aux données sans une 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 en soi, mais elle contribue aussi au caractère unique de l'empreinte digitale. 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’intérêt de le fingerprinting consiste à distinguer dissimuleusement les utilisateurs les uns des autres. Si vous êtes prêt à ce que l’utilisateur sache que vous essayez de les identifier, alors vous n'avez pas besoin de techniques de fingerprinting: demandez à l'utilisateur de créer un compte et de se connecter avec lui.

Ajouter de l'imprévisibilité

Une troisième approche adoptée dans certains cas consiste à "brouiller" les signaux des fournisseurs les réponses des API afin de les rendre moins précises et donc de moins d’identification. Ceci a été décrit dans le cadre du mécanisme de réponse aléatoire du module de données comme quelque chose lorsque vous collectez des données auprès des utilisateurs, afin d'éviter de collecter par inadvertance des données identifiant. Fournisseurs de navigateurs vous pouvez adopter cette approche pour les données d'API mises à la disposition des applications Web et des tiers. Prenons un exemple : API de chronométrage 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. Safari présente une version simplifiée de la configuration système pour cette raison mê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. Elle n'a pas encore été implémentée 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, les réponses et approches sont très variées. sur plusieurs navigateurs et plates-formes dans ce domaine. Cela signifie qu'il est essentiel de tester votre travail dans plusieurs environnements différents. Bien entendu, cela est toujours important, mais il peut être raisonnable de supposer que le rendu HTML ou CSS sera constant pour une moteur de rendu donné, peu importe le navigateur ou la plate-forme sur lequel se trouve le moteur. Il peut donc être tentant de tester par exemple). Ce n'est pas du tout le cas pour l'utilisation des API, car les navigateurs qui partagent un le moteur de rendu peut considérablement renforcer sa surface d'API contre le fingerprinting.

À faire

Vérifiez vos propres données analytiques et votre audience pour déterminer les navigateurs à privilégier lors des tests.
Voici quelques navigateurs à tester : Firefox, Chrome, Edge, Safari sur ordinateur, Chrome et Samsung Internet sur Android. et Safari sur iOS. Vous pouvez ainsi tester les trois principaux moteurs de rendu (Gecko dans Firefox, 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.
Effectuez le test avec un ou plusieurs navigateurs qui affirment que la confidentialité des données des utilisateurs est un facteur de motivation. Inclure les versions préliminaires et de test à venir navigateurs courants et s'ils sont disponibles: la version preview de la technologie Safari, Canary de Chrome, version bêta de Firefox Vous aurez ainsi plus de chances d'identifier les défaillances et les modifications de l'API qui affectent vos sites avant que ces modifications n'affectent vos utilisateurs. De même, prenez en compte les besoins en tenant compte de toute analyse existante. Si votre comprend un grand nombre d'anciens téléphones Android. Assurez-vous de 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 un test à l'aide d'un profil non infecté 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 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 de créer corrections en conséquence pour obtenir ces données à partir d'une autre source, s'en passer ou utiliser des données moins précises.
Comme nous l'avons vu précédemment dans le module relatif aux tiers, il est également important d'auditer vos les dépendances pour voir si elles utilisent des techniques de fingerprinting. 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 peut également être utile de rechercher des utilisations du terme "correspondance probabiliste". en marketing ou des documents techniques décrivant un tiers ; cela peut parfois indiquer l'utilisation de techniques de fingerprinting.

Outils de test multinavigateurs

Tester votre code à des fins de confidentialité est difficile à automatiser, et les éléments à prendre en compte lors des tests manuels sont décrits plus haut. Par exemple, que se passe-t-il lorsque vous refusez l'autorisation d'accès au site pour les API auxquelles il tente d'accéder ? Comment cela se présente-t-il à 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. Quelque chose Lorsque vous utilisez la couverture de la surface de l'API, prenez en compte le fait que la plupart des navigateurs autorisent un certain niveau pour contrôler quelles API et fonctionnalités sont disponibles. Pour cela, Chrome utilise des commutateurs de ligne de commande. tout comme Firefox, et y accéder dans 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 veulent pas être identifiés par des sites Web pour une expérience non optimale, Ainsi, chaque navigateur se fait passer pour un autre navigateur, et la chaîne du user-agent ressemble à ceci:

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 s'agit, entre autres, de Mozilla/5.0, un navigateur sorti en même temps que les premiers astronautes à bord de la Station spatiale internationale il y a plus de vingt ans. La chaîne user-agent est une source d'entropie pour le fingerprinting, Bien sûr, et pour limiter cette possibilité, les fabricants de navigateurs ont soit déjà figé l'en-tête du user-agent, soit pour y parvenir. Il s'agit d'un autre exemple de modification des données fournies par une API sans nécessairement supprimer complètement l'API. L'envoi d'un en-tête user-agent vide empêcherait d'innombrables sites Web qui le supposent. En général, ce que font les navigateurs consiste à en supprimer certains détails, puis à les garder globalement 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 du user-agent, il est important de trouver d'autres sources de données.

Précisons que les données dans le user-agent ne disparaîtront pas complètement, mais elles sont disponibles à un niveau de précision inférieur ou parfois inexactes, car un chiffre plus ancien, mais immuable, peut être indiqué. Par exemple, Firefox, Safari et Chrome, avec une majuscule au début de chaque mot. le numéro de version macOS indiqué sur 10 (voir Mise à jour concernant la réduction des chaînes user-agent). pour en savoir plus). Pour découvrir en détail comment Chrome prévoit de réduire les données dans la chaîne user-agent, consultez Réduction user-agent. En bref, 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 à 123.0.0.0, même si le navigateur est la version 123.10.45.108), et la version du système d'exploitation sera sans détail et vous figez sur l'un des quelques choix immuables. Une version fictive de Chrome (123.45.67.89) s'exécutant "Windows 20" indiquerait son numéro de version comme:

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 essentielles dont vous avez besoin (la version du navigateur) restent 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 ceci avec une User-agent Chrome 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 constate que la seule différence réside dans le numéro de version de Chrome (104) et l'identifiant de la plate-forme.

De même, la chaîne de user-agent de Safari affiche une plate-forme et un numéro de version de Safari, et donne également une version d'OS sur iOS, mais tout le reste est figé. Ainsi, une version 1234.5.67 imaginaire de Safari exécutée sur un macOS 20 imaginaire pourrait donner à son user-agent comme suit:

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**.

Là encore, les informations de base (Safari, sous iOS ou macOS) sont disponibles, et iOS Safari fournit toujours un numéro de version pour iOS. mais une grande partie des informations auxiliaires qui étaient disponibles dans le passé ont depuis été gelées. Il est important de noter que le numéro de version, 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 être familiarisés avec les scripts intersites (XSS), ce qui implique l'ajout d'un script malveillant à une page, souvent parce que celle-ci n'échappe pas correctement au code HTML injecté (donc vous lancez une requête de recherche). contenant le texte <script>). Les développeurs back-end connaissent l'injection SQL, où les requêtes de base de données qui ne valident pas correctement les entrées utilisateur exposent des problèmes de sécurité (comme l'illustre l'exemple de xkcd avec Little Bobby Tables). Les tests à données aléatoires sont plus adaptés utilisé pour les tentatives automatisées de fournir de nombreuses entrées non valides ou inattendues à une API et pour vérifier les résultats de fuites de sécurité, des plantages ou d'autres problèmes de gestion. Toutes ces informations illustrent délibérément des informations inexactes. Ici, cependant, c'est en cours de manière préventive par les navigateurs (en rendant le user-agent délibérément incorrect) afin d'encourager les développeurs à cesser de s'appuyer sur ces données.

À faire

Vérifiez que votre codebase ne dépend pas de la chaîne du user-agent (une recherche sur navigator.userAgent est susceptible de trouver la plupart des occurrences). dans votre code côté client, et votre code backend recherchera probablement User-Agent comme en-tête), y compris votre les dépendances.
Si vous trouvez des utilisations dans votre propre code, déterminez ce qu'il vérifie et trouvez une autre façon de faire cette différenciation (ou trouvez une dépendance de remplacement, ou travaillez avec la dépendance en amont en signalant les problèmes ou en consultant 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 fondamentales de la marque, de la version majeure et de la plate-forme, ces valeurs resteront très certainement disponibles et qu'elles soient correctes dans la chaîne du user-agent.
MDN décrit de bonnes façons d'éviter de se fier à la chaîne user-agent ("sniffing du navigateur"), dont la principale est la détection de caractéristiques.
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 d'effectuer des tests avec ces navigateurs versions elles-mêmes par le biais de versions bêta ou d'aperçu de la technologie, mais il est également possible de définir une chaîne user-agent personnalisée pour 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.

Indicateurs client

L'une des principales propositions pour fournir ces informations concerne les indicateurs client user-agent, bien que cela ne soit pas compatible avec 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. En d'autres termes, comme précédemment, un exemple de "test à données aléatoires" 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 rendues disponibles par le navigateur directement en JavaScript navigator.userAgentData, qui, dans un navigateur compatible, pourrait ressembler à l'objet suivant:

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