User-Agent expliqué : des chaînes de UA et des empreintes digitales du navigateur à Client Hints

Ouvrez le panneau Réseau dans les outils développeurs de votre navigateur et vous trouverez presque toujours un en-tête User-Agent. Cela ressemble à une brève introduction : quel navigateur fait la requête, sur quel système d’exploitation il s’exécute, et quelle version il prétend être.

Cela rend tentant de traiter l’en-tête comme un identifiant de périphérique — ou de supposer que changer une ligne peut transformer un navigateur en un autre appareil. Les deux idées ne sont que partiellement correctes.

Une chaîne de User-Agent, ou UA, est une information de compatibilité déclarée par le client. Ce n’est pas une attestation d’identité fiable, et un client peut la modifier. Pourtant, il n’existe pas isolément. Un site peut comparer le UA avec Client Hints, JavaScript APIs, propriétés d’écran, polices, Canvas, WebGL, contexte réseau et comportement. La question utile n’est donc pas simplement de savoir si un UA peut être modifié, mais quel rôle il joue dans la surface observable complète du navigateur.

Cet article utilise les normes HTTP et la recherche sur l’empreinte digitale dans les navigateurs pour répondre à quatre questions :

1. Pourquoi une chaîne de UA ressemble-t-elle à un ouvrage d’archéologie de navigateur ?
2. Quelle quantité d’informations identifiantes UA peuvent-elles apporter, et comment devons-nous interpréter la recherche ?
3. Pourquoi changer uniquement le UA peut-il créer une incohérence plus évidente ?
4. Qu’est-ce que UA Reduction et User-Agent Client Hints ont réellement changé ?

Dans cet article, UA fait principalement référence à l’en-tête de la requête HTTP User-Agent. Nous discutons aussi de navigator.userAgent et de navigator.userAgentData en JavaScript. Ces interfaces sont liées mais pas identiques de façon permanente à tous les navigateurs et contextes.

1. Qu’est-ce qu’un User-Agent ?

Section 10.1.5 de RFC 9110 définit User-Agent comme un champ contenant des informations sur l’agent utilisateur qui a initié la requête. Sa grammaire simplifiée est la suivante :

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

En termes simples, la chaîne commence par un nom de produit et peut inclure une version. Plus de produits ou commentaires pourront suivre. La norme reconnaît des usages tels que les solutions d’interopérabilité, les diagnostics et les analyses, mais elle conseille aussi aux implémentations de ne pas révéler de détails inutiles : une UA plus longue et plus spécifique augmente à la fois la taille des requêtes et le risque d’empreintes digitales.

Un UA de bureau Chromium moderne pourrait ressembler à ceci :

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

Diviser la chaîne par des espaces révèle plusieurs noms qui semblent sans rapport avec Chrome :

Token	Ce que cela signifie généralement aujourd’hui	Une mauvaise lecture courante
Mozilla/5.0	Un jeton de compatibilité historique	Le navigateur doit être Firefox ou un produit Mozilla
Windows NT 10.0	Une catégorie Windows de plateforme ; un UA réduit ne peut pas distinguer de manière fiable Windows 10 de 11	L’ordinateur doit fonctionner Windows 10
Win64; x64	Un indice que c’est un Windows 64 bits sur une architecture x86-64	Cela prouve le modèle physique exact du processeur
AppleWebKit/537.36	Une lignée moteur et un jeton de compatibilité	Chrome utilise toujours l’implémentation complète de Safari
KHTML, like Gecko	Langage de compatibilité historique	KHTML et Gecko sont tous les deux en cours
Chrome/145.0.0.0	La famille Chrome/Chromium et la version principale ; Les composants des versions inférieures peuvent être réduits	Il révèle la version précise du patch
Safari/537.36	Un jeton conservé pour la compatibilité avec les anciens sites	Le navigateur doit être Safari

Le UA est devenu verbeux car les premiers sites web s’inspiraient souvent de noms de navigateurs. Les nouveaux navigateurs devaient prétendre être compatibles avec les anciens produits pour recevoir la bonne page. Ces déclarations se sont accumulées au fil du temps, créant un registre historique qui ne peut être lu au pied de la lettre.

La première règle de l’analyse UA est donc simple : il s’agit d’un protocole de compatibilité, pas d’une description stricte du périphérique.

2. Pourquoi les sites web utilisent-ils encore UA ?

UA n’est pas utilisé uniquement pour le suivi. Les usages légitimes incluent :

• servant de plan B à un navigateur plus ancien avec un problème de compatibilité connu ;
• choisir un installateur ou un format de téléchargement approprié ;
• trouver des défaillances spécifiques à une version dans les journaux de diagnostic ;
• mesurant les distributions larges de familles de navigateurs, de plateformes et de versions majeures ;
• identifier des combinaisons impossibles dans le trafic automatisé ou malveillant.

Le problème commence lorsque UA détection passe d’un simple repli de compatibilité à la devinette par nom de produit. Le code peut voir Chrome et supposer qu’une API particulière existe. Cette hypothèse peut échouer dans un WebView intégré, un navigateur dérivé de Chromium, un navigateur avec une politique d’entreprise, un UA gelé, ou un client qui a changé d’en-tête.

Un ordre d’opérations plus robuste est :

1. Testez directement l’API ou le comportement requis chaque fois que la détection de capacités est possible.
2. Lorsque l’identification par navigateur est inévitable, utilisez un analyseur maintenu plutôt qu’une expression régulière ad hoc.
3. Stockez uniquement les catégories grossières dont le produit a réellement besoin.
4. Fournir un plan B pour les marques inconnues, les versions inconnues et les champs manquants.

3. Est-ce UA une empreinte digitale de navigateur ?

Plus précisément, UA est une entrée pour une empreinte digitale de navigateur, pas généralement l’empreinte complète.

L’empreinte digitale par navigateur ne nécessite pas de numéro de série secret. Il mesure un ensemble d’attributs relativement stables et distinctifs exposés par le navigateur. UA fournit des indices sur la famille, la version et la plateforme des navigateurs. Les dimensions de l’écran, les polices, le fuseau horaire, le Canvas, le WebGL, le AudioContext et d’autres interfaces ajoutent des informations supplémentaires.

L’enquête menée par Laperdrix et ses collègues, Browser Fingerprinting: A Survey, aborde ces techniques comme une forme de reconnaissance sans état. Un site n’a pas nécessairement besoin d’écrire un Cookie d’abord ; Il peut tenter d’associer les visites aux attributs exposés par un navigateur. « Sans État » ne signifie pas que le serveur ne stocke rien. Cela signifie que le matériel de reconnaissance ne dépend pas d’un identifiant client persistant.

1. Que signifie le résultat 10 bits de l’article ?

Dans l’étude Panopticlick de 2010 How Unique Is Your Web Browser?, Peter Eckersley a analysé environ 470 000 empreintes digitales de navigateurs. Le journal rapportait que :

• L’empreinte complète contenait en moyenne environ 18,1 bits d’informations d’identification dans cet échantillon ;
• En termes intuitifs, une empreinte en moyenne se produit environ une fois dans 286 777 navigateurs ;
• Le tableau indiquait environ 10,0 bits d’informations moyennes pour la seule chaîne UA ;
• parmi les navigateurs équipés de Flash ou Java activé, 94,2 % des empreintes complètes étaient uniques.

L’auto-information s’écrit couramment comme suit :

I(x) = -log₂ P(x)

Si un UA particulier se produit avec une probabilité 1/1024 dans une population, son observation fournit 10 bits d’information. Cela ne signifie pas que UA possède exactement 1 024 valeurs possibles ou qu’il identifie une personne de manière unique. Il décrit en moyenne l’incertitude que cette observation élimine.

2. Pourquoi le résultat de 2010 n’est-il pas une constante pour le web actuel ?

Le résultat reste important, mais il nécessite au moins trois qualifications :

• Les visiteurs d’une page de test de confidentialité n’étaient pas un échantillon aléatoire de tous les utilisateurs d’Internet ;
• La diversité des navigateurs, plugins et versions UA en 2010 différait grandement de l’écosystème actuel ;
• UA Reduction, la réduction des surfaces des plugins et les protections anti-empreintes digitales ont modifié la répartition des attributs observables.

L’étude soutient l’affirmation selon laquelle UA et d’autres attributs peuvent apporter des informations distinctives mesurables. Cela ne soutient pas le fait qu’un UA ait toujours exactement 10 bits d’entropie aujourd’hui. La puissance d’empreintes digitales dépend de la population, de la fenêtre temporelle, des politiques du navigateur et de la combinaison des signaux.

4. Pourquoi changer uniquement UA ne pourrait-il se retourner contre lui ?

UA est une déclaration client sans preuve cryptographique. Un serveur ne peut pas lire la vérité d’usine d’un appareil à partir de cet en-tête. Il peut cependant vérifier si différentes observations sont raisonnablement compatibles.

Supposons qu’un UA prétend être un navigateur mobile, mais que la page ne détecte aucun point de contact, une fenêtre qui ressemble constamment à un écran de bureau, et des Client Hints qui indiquent une plateforme de bureau. Toute observation peut faire l’objet d’une exception légitime. Plusieurs contradictions stables ensemble peuvent encore former un schéma classifiable.

L’article Panopticlick documentait déjà des cas comparables : certains navigateurs affirmaient être un iPhone tout en prenant en charge Flash, et d’autres Firefox UA apparaissaient avec des fonctionnalités de stockage disponibles uniquement dans Internet Explorer. L’étude [FP-Scanner] de 2018(https://www.usenix.org/conference/usenixsecurity18/presentation/vastel) a examiné ce problème de manière systématique. Certaines extensions anti-empreintes digitales et outils d’usurpation introduisaient des incohérences entre interfaces, permettant à un détecteur d’identifier des attributs modifiés et, dans certains cas, d’inférer le navigateur ou la famille de systèmes d’exploitation d’origine.

Toutes les incohérences ne sont pas malveillantes. Les bureaux à distance, les outils d’accessibilité, les politiques d’entreprise, les couches de compatibilité et le matériel peu commun peuvent tous créer des combinaisons inhabituelles. Un système de risque rigoureux doit traiter une incohérence comme une preuve probabiliste, et non comme une raison automatique de bloquer un utilisateur.

Pour la gestion des profils de navigateur, trois propriétés comptent :

• Cohérence interne : UA, Client Hints, plateforme, architecture, tactile et signaux d’écran ne doivent pas se contredire directement.
• Stabilité dans le temps : Un profil durable ne devrait pas changer radicalement à chaque lancement sans raison.
• Diversité plausible : Les profils peuvent différer, mais les rares combinaisons générées mécaniquement ne sont pas nécessairement plus sûres.

L’étude FP-STALKER a également montré que changer d’attributs n’empêche pas automatiquement le lien. Un modèle peut utiliser des attributs stables et des changements de version plausibles pour connecter des empreintes digitales antérieures et ultérieures.

5. Quel problème UA Reduction traite-t-il ?

Un UA traditionnel est envoyé avec presque toutes les demandes. Tout point de terminaison propriétaire ou tiers recevant la requête peut la lire passivement. Plus la chaîne est précise, plus chaque destinataire obtient par défaut d’informations distinctives.

Le plan User-Agent Reduction de Chromium réduit cette granularité par défaut :

• À partir de Chrome 101, les versions mineure, compilation et patch pour bureau ont été réduites à 0.0.0 ;
• les phases ultérieures des versions unifiées du système d’exploitation de bureau, les détails du processeur et les informations Android périphériques ;
• Un Android UA réduit utilise des valeurs fixes de plateforme et de modèle telles que Android 10; K ;
• Les sites qui exigent vraiment plus de détails peuvent demander User-Agent Client Hints.

Le format réduit peut se résumer ainsi :

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

La réduction diminue la surface passive d’empreintes digitales de la UA héritée. Cela n’élimine pas l’empreinte digitale par navigateur. La version principale, l’état large de la plateforme et mobile peuvent rester visibles, tandis que d’autres API, propriétés réseau et comportements peuvent encore fournir des informations.

6. Comment User-Agent Client Hints fonctionnent ?

Le mécanisme général est défini dans RFC 8942, tandis que le WICG User-Agent Client Hints brouillon décrit des champs spécifiques à UA. L’approche divise l’information qui vivait autrefois dans une chaîne non structurée en champs structurés, distinguant les indices à faible entropie qui peuvent être envoyés par défaut des indices à forte entropie qu’un site demande normalement explicitement.

Une demande initiale simplifiée peut ressembler à ceci :

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

Si le serveur a réellement besoin d’architecture et de bitness pour sélectionner un installateur, il peut répondre par :

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

Lorsque le navigateur prend en charge le mécanisme et que les exigences de sécurité et de politique sont respectées, une requête ultérieure peut inclure :

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

Les UA Client Hints courantes incluent :

Champ	Objectif typique	Niveau d’information
Sec-CH-UA	Liste des marques et des principales versions	Généralement faible entropie
Sec-CH-UA-Mobile	Le client préfère-t-il une expérience mobile	Généralement faible entropie
Sec-CH-UA-Platform	Catégorie large de plateformes	Généralement faible entropie
Sec-CH-UA-Arch	Architecture CPU	Entropie élevée ; demande quand nécessaire
Sec-CH-UA-Bitness	Bitness d’architecture	Entropie élevée ; demande quand nécessaire
Sec-CH-UA-Platform-Version	Version de la plateforme	Entropie élevée ; demande quand nécessaire
Sec-CH-UA-Full-Version-List	Versions complètes pour les marques signalées	Entropie élevée ; demande quand nécessaire
Sec-CH-UA-Model	Modèle de dispositif	Entropie élevée ; demande quand nécessaire

Trois détails techniques sont faciles à manquer.

1. Client Hints ne sont pas tous envoyés automatiquement

Des indices à faible entropie peuvent apparaître par défaut. Les indices à forte entropie nécessitent généralement une réponse Accept-CH. La navigation initiale, les sous-ressources, la politique d’autorisation, le transport sécurisé et le support du navigateur peuvent tous influencer ce qui arrive. Un serveur doit permettre l’absence de chaque champ optionnel.

2. La liste des marques teste délibérément la robustesse des parseurs

Sec-CH-UA peut contenir plusieurs marques et une marque synthétique utilisée pour tester la compatibilité. Le code ne doit pas supposer que la première entrée est toujours le nom du produit, et il ne doit pas échouer lorsqu’une marque inconnue apparaît. Analysez le champ structuré, ignorez les entrées que vous ne reconnaissez pas, et laissez de la place aux futures marques.

3. Les réponses qui varient sur les indices nécessitent une gestion correcte du cache

Si l’architecture, la plateforme ou un autre indice modifie la réponse, configurez correctement Vary ou une stratégie de clé de cache équivalente. Sinon, un cache partagé peut servir du contenu généré pour une classe de dispositif à une autre.

7. Est-Client Hints plus privés que les UA traditionnelles ?

Ils améliorent la manière dont les informations sont exposées, mais ne garantissent pas une immunité contre les empreintes digitales.

Le UA traditionnel révèle un grand paquet non structuré de manière passive et par défaut. Client Hints diviser ce paquet en champs, rendre les demandes d’informations à plus forte entropie plus explicites, et donner au navigateur la possibilité d’appliquer des contrôles politiques, d’autorisations ou de budget de confidentialité.

Cependant, l’architecture, les versions complètes, les versions de plateforme et les modèles d’appareils peuvent encore augmenter la distinction. RFC 8942 considère explicitement la confidentialité et la performance comme des contraintes de conception. Les développeurs devraient se demander :

• Cette fonctionnalité nécessite-t-elle vraiment ce champ ?
• La détection de capacités ou un choix de l’utilisateur peut-elle la remplacer ?
• L’application peut-elle stocker uniquement une catégorie grossière ?
• Combien de temps les valeurs brutes sont-elles conservées, et qui peut y accéder ?
• Les ressources tierces recevront-elles les mêmes indices ?

8. Conseils d’ingénierie pour la gestion UA côté serveur

1. Ne jamais utiliser UA comme preuve d’identité ou d’autorité

UA peut prendre en charge les choix de présentation et les solutions de compatibilité. Elle ne doit pas déterminer l’identité, l’autorisation, la fiducie de paiement ou une limite de sécurité. Une valeur contrôlée par le client ne peut pas servir de certification de contrôle d’accès.

2. Préfère la détection de capacités aux listes de navigateurs

Lorsqu’une interface a besoin d’une API, testez directement cette capacité :

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

La détection de capacités gère mieux les navigateurs dérivés, les fonctionnalités expérimentales, les politiques d’entreprise et les futures versions qu’une règle telle qu'« activer cela pour Chrome 145 ».

3. Accepter les UA, Client Hints et les États inconnus

Lors de la migration, un serveur peut ne recevoir que les UA hérités, à la fois UA et Client Hints, ou des formes fortement réduites des deux. Le modèle de données devrait permettre unknown plutôt que de deviner un système d’exploitation ou un modèle de périphérique exact pour remplir chaque champ.

4. Réduire la granularité logarithmique

Si l’analytique ne nécessite que le bureau versus mobile, la famille de navigateurs et la version principale, ne conservez pas indéfiniment les chaînes de UA brutes ni tous les indices à forte entropie. La minimisation des données réduit les risques pour la vie privée et empêche un pipeline d’analyse de considérer les variations mineures comme une dimension significative.

5. Considérer les anomalies comme des preuves, pas comme des verdicts

Un UA qui affirme Windows alors qu’une API se comporte différemment est, au mieux, un signal de risque. Les environnements d’entreprise, la virtualisation, les sessions à distance, les couches de compatibilité et les technologies d’assistance peuvent produire de véritables anomalies. Transformer un décalage en une décision automatique de fraude crée des faux positifs.

9. Comment UA doit-il être configuré dans des environnements multi-profils ?

Pour les tests interrégionaux, les aperçus publicitaires, les opérations de compte et l’isolation de la confidentialité, l’objectif ne doit pas être de créer les UA les plus inhabituelles. Un profil doit être explicable, stable et compatible avec son environnement environnant.

Examinez les éléments suivants dans l’ordre :

1. Version navigateur : la UA version majeure devrait être plausible pour le moteur réel et ses capacités.
2. Système d’exploitation : la UA plateforme, la Client Hints plateforme et la catégorie JavaScript-visible doivent être compatibles.
3. Architecture et bitness : UA, Client Hints et l’environnement exécutable ne doivent pas faire de revendications directement contradictoires.
4. Format de l’appareil : Une déclaration mobile devrait avoir du sens avec le support tactile, la fenêtre de vue, le ratio de pixels et les motifs d’interaction.
5. Contexte régional : langue, fuseau horaire, géolocalisation et sortie proxy n’ont pas besoin de correspondre mécaniquement, mais ils devraient avoir du sens pour le flux de travail réel.
6. Stabilité du profil : Lorsque un compte ou une identité de test réutilise un profil de longue durée, évitez de changer de plateforme et de version principale sans raison précise.

La conversion de profil actuelle de PurpleMark associe le système d’exploitation sélectionné à une plateforme UA et tente d’abord d’extraire la version navigateur d’un jeton Chrome/ ou CriOS/ configuré. Lorsqu’aucune version utilisable n’existe, elle découle d’un plan de repli raisonnable par rapport à la version principale du moteur actuel. Le but n’est pas de falsifier une chaîne isolée, mais de placer UA configuration dans un modèle cohérent de profil de navigateur.

L’isolation des profils et la cohérence des paramètres peuvent réduire la corrélation technique et le biais de test. Ils ne peuvent garantir que les comptes ne seront jamais liés, et ils ne remplacent pas les règles de la plateforme, les données de compte, les informations de paiement ou les pratiques opérationnelles responsables. Utilisez ces fonctionnalités uniquement pour la protection légale de la vie privée, les tests autorisés et les activités professionnelles conformes.

10. Foire aux questions

Q1 : Changer UA transforme le navigateur en un autre ?

Non. Cela modifie une partie de ce que le client déclare. Il ne remplace pas le moteur JavaScript, le pipeline de rendu, la pile réseau ou les API Web prises en charge.

Q2 : Un site web peut-il lire la « vraie UA » ?

Il n’existe pas de « vrai UA » universel au niveau matériel que chaque site web peut contourner le navigateur pour lire. Un site peut néanmoins comparer Client Hints, des tests de capacité et d’autres signaux d’empreintes digitales, trouver des affirmations incompatibles et faire une inférence probabiliste.

Q3 : Un UA réduit peut-il distinguer Windows 10 de Windows 11 ?

La réduction de UA héritée ne peut normalement pas le faire de manière fiable car les deux peuvent Windows NT 10.0 signaler. Un navigateur qui prend en charge UA Client Hints peut fournir des informations plus détaillées sur la version de la plateforme après qu’un site les ait demandées. Les serveurs doivent toujours gérer les champs manquants et les différences de mapping.

Q4 : Désactiver JavaScript arrête-t-il UA exposition ?

Pas complètement. Le HTTP User-Agent est un en-tête de requête et peut être envoyé avec la requête de page avant que la page JavaScript ne s’exécute. Désactiver JavaScript supprime certaines surfaces de collecte mais casse aussi d’importantes parties du web moderne.

Q5 : Va-t Client Hints remplacer complètement User-Agent ?

Ne supposez pas cela à court terme. De nombreux clients et serveurs dépendent encore de la UA héritée, tandis que UA Client Hints support varie. Considérez Client Hints comme une amélioration progressive : préférez l’information structurée quand elle est disponible, mais conservez des solutions de secours pour les UA hérités et les états inconnus.

Q6 : Un UA généré aléatoirement améliore-t-il l’anonymat ?

Pas forcément. La randomisation d’un champ peut créer des contradictions avec la version, la plateforme, le tactile et les signaux de rendu. Pour un profil à longue durée, une configuration commune, stable et compatible en interne est généralement plus défendable que des changements aléatoires fréquents.

11. Conclusion

User-Agent n’est ni une attestation d’identité fiable ni une filière sans importance. Il se situe à l’intersection de la compatibilité web, de la confidentialité et de l’analyse des risques. Pour les développeurs, c’est une entrée de compatibilité alourdie par l’histoire. Pour les chercheurs en empreintes digitales, il s’agit d’un attribut avec des informations statistiques mesurables. Pour les fabricants de navigateurs, il s’agit d’une surface d’exposition par défaut qui doit être réduite.

Les idées clés s’inscrivent en trois affirmations :

• Ne lisez pas un UA littéralement ; Il contient de nombreux jetons de compatibilité historiques.
• N’évaluez pas UA isolement ; La reconnaissance pratique provient de la combinaison de signaux et de leur évolution au fil du temps.
• Ne considérez pas Client Hints simplement comme des « domaines plus UA » ; leur valeur réside dans une divulgation structurée, guidée par la demande et gouvernable.

Lorsqu’un système passe de l’identification d’un nom de navigateur à la validation de la capacité nécessaire — et de la collecte de tous les détails disponibles à la demande uniquement nécessaire — UA revient à son rôle approprié : un indice de compatibilité, pas une vérité identitaire.

Références et normes

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.