Ce qu'envoient les User-Agent Client Hints, et ce que l'analytics voit encore

Que sont les User-Agent Client Hints ?

Les navigateurs Chromium envoient les User-Agent Client Hints sous la forme d'un ensemble d'en-têtes de requête Sec-CH-UA qui transportent les détails du navigateur et de la plateforme dans des champs séparés, et ils n'envoient les champs détaillés que lorsqu'un serveur les demande. La documentation développeur de Chrome décrit ce modèle comme un modèle "where the server must ask the browser for a set of data about the client (the hints) and the browser applies its own policies or user configuration to determine what data is returned." Les hints sont activés par défaut depuis Chrome 89.

L'ancien en-tête User-Agent regroupait tout dans une seule chaîne à chaque requête : navigateur, version complète, système d'exploitation et sa version, et sur Android le modèle de l'appareil. L'article de Google sur ce changement indique que cette combinaison "could contain enough information to allow individual users to be uniquely identified." Les client hints la découpent pour que la requête par défaut en transporte moins, et tout supplément doit être demandé d'une manière que le navigateur peut voir.

Si vous gérez l'analytics d'un site web, cela compte pour deux rapports : la répartition par navigateur et par OS, et le type d'appareil. Les deux fonctionnent toujours dans Chrome, mais certains détails qui arrivaient autrefois gratuitement nécessitent désormais une demande explicite.

Une requête, avant et après

Ancien en-tête User-Agent

• Navigateur et version complète
• Système d'exploitation et version
• Modèle de l'appareil sur Android
• Tout cela à chaque requête

Requête Chrome par défaut

• Marque du navigateur et version majeure
• Indicateur mobile
• Nom de l'OS
• Le reste attend que le serveur le demande

Quels en-têtes Sec-CH-UA Chrome envoie-t-il ?

Chrome envoie trois en-têtes Sec-CH-UA à chaque requête HTTPS et retient les autres jusqu'à ce que le serveur les demande. La spécification du WICG définit onze en-têtes. Ceux qui comptent pour l'analytics :

En-tête	Exemple de valeur	Entropie	Envoyé par défaut ?
Sec-CH-UA	"Chromium";v="93", "Google Chrome";v="93"	Faible	Oui
Sec-CH-UA-Mobile	?0 pour ordinateur, ?1 pour mobile	Faible	Oui
Sec-CH-UA-Platform	"macOS"	Faible	Oui
Sec-CH-UA-Platform-Version	"10.0.0"	Élevée	Non, nécessite Accept-CH
Sec-CH-UA-Full-Version-List	"Google Chrome";v="98.0.4738.0"	Élevée	Non, nécessite Accept-CH
Sec-CH-UA-Model	"Pixel 3"	Élevée	Non, nécessite Accept-CH
Sec-CH-UA-Arch	"arm"	Élevée	Non, nécessite Accept-CH
Sec-CH-UA-Bitness	"64"	Élevée	Non, nécessite Accept-CH

La spécification définit aussi Sec-CH-UA-WoW64, Sec-CH-UA-Form-Factors et l'en-tête obsolète Sec-CH-UA-Full-Version. Les client hints ne circulent que sur des connexions sécurisées, donc une page servie en HTTP simple n'en reçoit aucun.

La liste des marques contient une bizarrerie volontaire. Elle inclut une fausse marque comme " Not;A Brand";v="99", que la documentation de Chrome appelle GREASE et qui peut apparaître à n'importe quelle position avec n'importe quel nom. MDN explique qu'elle sert à empêcher les serveurs de "rejecting unknown user agents outright." Tout parseur que vous écrivez doit ignorer les marques qu'il ne reconnaît pas au lieu de se fier à leur position.

Quelle est la différence entre les hints à faible et à forte entropie ?

Les hints à faible entropie sont les champs qu'un navigateur envoie à tous les sites parce qu'ils révèlent peu de choses au-delà de ce que montrent déjà les autres en-têtes, et les hints à forte entropie sont les champs qui restreignent assez un navigateur pour aider à l'identifier. La spécification du WICG indique que les hints par défaut n'exposent "only the user agent's branding information, and the significant version number," deux éléments "fairly clearly sniffable" à partir d'autres en-têtes et des fonctionnalités que le navigateur prend en charge.

"Entropie élevée" vient de la théorie de l'information. La documentation de Chrome présente le terme comme une référence à "the amount of information that these values reveal about the user's browser." Un nom de modèle comme Pixel 3 ou un build exact comme 98.0.4738.0 divise la population des utilisateurs de Chrome en groupes bien plus petits que "Chrome 98 sur Android". Le guide du browser fingerprinting explique comment ces champs s'additionnent une fois combinés.

Comment un site demande-t-il des hints à forte entropie avec Accept-CH ?

Un site demande des hints à forte entropie en renvoyant un en-tête de réponse Accept-CH qui nomme les hints souhaités, après quoi le navigateur décide s'il les envoie lors des requêtes suivantes vers cette origine. L'échange se déroule en quatre étapes :

1. Le navigateur demande une page et n'envoie que Sec-CH-UA, Sec-CH-UA-Mobile et Sec-CH-UA-Platform.
2. Le serveur répond avec un en-tête comme Accept-CH: Sec-CH-UA-Full-Version-List, Sec-CH-UA-Model, ou la page inclut la même liste dans une balise <meta http-equiv="Accept-CH">.
3. Les requêtes suivantes vers cette origine transportent les hints demandés, si la politique du navigateur le permet.
4. Un nouvel en-tête Accept-CH remplace entièrement l'ensemble précédent, et un en-tête vide l'efface.

Trois règles de la documentation de Chrome piègent souvent. Les hints demandés via Accept-CH durent "for the duration of the browser session or until a different set of hints are specified." Ils ne sont envoyés que sur les requêtes same-origin, donc une requête vers cdn.example.net ne reçoit rien sauf si la page délègue chaque hint avec un en-tête Permissions-Policy. Et une première visite ne transporte que les hints par défaut, puisque le serveur ne les a pas encore demandés. Chromium documente un mécanisme distinct pour les hints dont un site a besoin dès la première requête.

Les scripts disposent d'une seconde voie. navigator.userAgentData expose les valeurs à faible entropie sous la forme de brands, mobile et platform, et navigator.userAgentData.getHighEntropyValues() renvoie une promesse avec des champs comme model, platformVersion et fullVersionList. Comme pour les en-têtes, Chrome précise que "it's down to the browser what values, if any, are returned."

Qu'a changé la réduction du User-Agent dans Chrome ?

La réduction du User-Agent a figé l'essentiel de la chaîne User-Agent de Chrome sur des valeurs fixes, donc l'ancien en-tête ne transporte plus que la version majeure du navigateur, une chaîne de plateforme fixe et un marqueur mobile. Le projet Chromium l'a déployée par phases :

Version de Chrome	Sortie	Changement dans la chaîne UA
Chrome 101	26 avril 2022	Numéros mineur, de build et de patch figés à 0.0.0
Chrome 107	25 octobre 2022	Plateforme et version de l'OS sur ordinateur remplacées par des valeurs fixes
Chrome 110	7 février 2023	Version d'Android figée à 10 et modèle de l'appareil remplacé par K
Chrome 113	2023	Fin de la reverse origin trial, donc tous les chargements de page reçoivent la chaîne réduite

Les valeurs de plateforme fixes sur ordinateur sont des chaînes littérales. Chromium les liste comme Windows NT 10.0; Win64; x64, Macintosh; Intel Mac OS X 10_15_7, X11; Linux x86_64 et X11; CrOS x86_64 14541.0.0, et chaque téléphone Android indique Linux; Android 10; K. Chromium précise que ces valeurs "will not update even if a user is on an updated operating system or device." La réduction s'applique à Windows, macOS, Linux, ChromeOS et Chrome sur Android. Chromium n'a aucun projet actuel pour iOS ni pour Android WebView.

La page de Chromium est explicite sur l'endroit où sont passés les anciens détails : "All of the information that was contained in the User-Agent string prior to reduction is available through the high entropy client hints."

Quels navigateurs prennent en charge les User-Agent Client Hints ?

Les navigateurs Chromium prennent en charge les User-Agent Client Hints, Firefox et Safari non. Les données de compatibilité de MDN indiquent Sec-CH-UA comme pris en charge dans Chrome et Edge depuis la version 89 et dans Opera depuis la version 75, et indiquent Sec-CH-UA comme Accept-CH non pris en charge dans Firefox et Safari. navigator.userAgentData suit la même répartition.

L'analytics se retrouve donc avec deux chemins d'analyse. Dans Chrome et Edge, la chaîne UA réduite plus les hints à faible entropie donnent le navigateur, la version majeure, le nom de l'OS et un indicateur mobile. Dans Firefox et Safari, l'en-tête User-Agent reste la seule source, et WebKit a lui aussi figé sa propre chaîne. Sa page sur la prévention du suivi indique, parmi ses changements contre le fingerprinting, que WebKit a "altered the user agent string to not change with minor software updates."

Que peut encore lire un outil d'analytics pour les rapports navigateur, OS et appareil ?

Un outil d'analytics lit encore le nom du navigateur, la version majeure, la famille d'OS et la distinction mobile ou ordinateur à chaque visite Chrome sans rien demander, mais la version de l'OS et le modèle de l'appareil nécessitent des hints à forte entropie. La répartition concrète pour un visiteur Chrome :

Champ du rapport	Depuis la chaîne UA réduite	Depuis les hints par défaut à faible entropie	Nécessite un hint à forte entropie
Nom du navigateur	Oui	Oui, Sec-CH-UA	Non
Version majeure du navigateur	Oui	Oui, Sec-CH-UA	Non
Version complète du navigateur	Non, affiche .0.0.0	Non	Sec-CH-UA-Full-Version-List
Nom de l'OS	Oui	Oui, Sec-CH-UA-Platform	Non
Version de l'OS	Non, valeur fixe	Non	Sec-CH-UA-Platform-Version
Mobile ou ordinateur	Oui, jeton Mobile	Oui, Sec-CH-UA-Mobile	Non
Modèle de téléphone	Non, affiche K	Non	Sec-CH-UA-Model

Chaque visiteur Windows 11 dans Chrome indique Windows NT 10.0 dans la chaîne UA, donc une répartition Windows 10 contre Windows 11 fondée sur la chaîne UA est fausse. Toutes les visites Chrome sur Android déclarent la version 10. Si un graphique des versions d'OS dans votre analytics montre une seule version qui prend le dessus entre fin 2022 et mi-2023, c'est la réduction, pas votre audience. La détection des bots devient elle aussi plus difficile, puisqu'un client automatisé copie une chaîne Chrome actuelle en une ligne de code ; le guide sur le filtrage du trafic de bots présente des vérifications qui ne reposent pas sur le seul UA.

Les User-Agent Client Hints réduisent-ils le fingerprinting ?

Les User-Agent Client Hints réduisent le fingerprinting passif, parce qu'un site ne reçoit plus la version complète, la version de l'OS et le modèle de l'appareil à chaque requête, mais ils n'arrêtent pas un script qui demande volontairement des valeurs à forte entropie. La spécification du WICG énonce les deux moitiés : le but est de "reduce the amount of default entropy exposed to the web at large," mais "it will still be possible for some, or all, hints to be requested and used for active fingerprinting purposes."

La différence tient à la visibilité. Une demande de Sec-CH-UA-Model apparaît dans l'en-tête Accept-CH du site ou dans un appel à getHighEntropyValues(), que les outils de confidentialité et les auditeurs peuvent détecter. L'ancienne chaîne livrait les mêmes données en silence. Pour un propriétaire de site, la règle est simple : ne demandez un hint à forte entropie que lorsqu'une fonctionnalité en a besoin, par exemple pour proposer le bon téléchargement selon l'architecture du processeur, et pas pour enrichir des profils d'analytics.

Que rapporte Flowsery sur les navigateurs et les appareils ?

Flowsery rapporte les données d'appareil, de navigateur et d'OS dans son analytics, sans browser fingerprinting, sans cookies dans son mode sans cookies et sans stocker de données personnelles. L'API de Flowsery renvoie des répartitions par navigateur avec le nombre de visiteurs et les revenus par navigateur, filtre par nom de navigateur comme Chrome, Safari, Firefox et Edge, avec "Safari includes Mobile Safari automatically," et regroupe les visiteurs selon des dimensions qui incluent browser_version et os_version. L'endpoint visiteur renvoie le type d'appareil, le navigateur, l'OS et les dimensions du viewport de la page vue la plus récente. En mode sans cookies, Flowsery utilise un hash de visiteur renouvelé chaque jour, donc ces champs décrivent des sessions sur votre site sans construire de profil d'un appareil sur plusieurs jours, l'une des raisons pour lesquelles les visiteurs uniques ne signifient pas la même chose d'un outil à l'autre. La page sur l'analytics respectueux de la vie privée liste ce que collecte le traqueur.

Questions fréquentes

Les User-Agent Client Hints remplacent-ils l'en-tête User-Agent ?

Non, Chrome envoie toujours l'en-tête User-Agent, mais sous une forme réduite, avec une version mineure figée et des valeurs de plateforme fixes. Les détails qui en ont été retirés sont disponibles via les client hints à forte entropie, qu'un site doit demander.

Firefox envoie-t-il les en-têtes Sec-CH-UA ?

Non. Les données de compatibilité de MDN indiquent Sec-CH-UA et Accept-CH comme non pris en charge dans Firefox et Safari. Ces navigateurs ne se décrivent toujours que via l'en-tête User-Agent.

Pourquoi mon analytics affiche-t-il tous les utilisateurs Android sous Android 10 ?

Chrome 110 a figé la version d'Android à 10 dans la chaîne UA et remplacé le modèle de l'appareil par K. Tout outil qui n'analyse que la chaîne UA indique Android 10 pour chaque visite de Chrome sur Android. La vraie version nécessite le hint Sec-CH-UA-Platform-Version.

L'analytics peut-il distinguer Windows 11 de Windows 10 dans Chrome ?

Pas à partir de la chaîne UA, qui indique Windows NT 10.0 pour les deux. Un site qui demande Sec-CH-UA-Platform-Version via Accept-CH, ou qui appelle getHighEntropyValues(), reçoit la version de plateforme que Chrome choisit de partager.

Faut-il HTTPS pour les client hints ?

Oui. Chrome n'envoie les client hints que sur des connexions sécurisées, donc un site en HTTP simple ne reçoit aucun en-tête Sec-CH-UA.

Les client hints à forte entropie sont-ils des données personnelles ?

Pris isolément, un modèle d'appareil ou un numéro de build d'OS ne désigne pas une personne. Combinés à d'autres signaux en un identifiant stable, ils entrent dans une empreinte, et une empreinte qui isole un appareil constitue une donnée personnelle au sens du RGPD, ce qui explique pourquoi l'analytics respectueux de la vie privée évite d'en construire une.

Quelle est la fausse marque de l'en-tête Sec-CH-UA ?

C'est une entrée GREASE comme " Not;A Brand";v="99", qui peut apparaître à n'importe quelle position avec n'importe quel nom. Elle sert à empêcher les serveurs de rejeter d'emblée les user agents inconnus. Un parser doit ignorer les marques qu'il ne reconnaît pas plutôt que de se fier à la position.

Comment obtenir la version complète de Chrome ou le modèle de l'appareil dans l'analytics ?

Renvoyez un en-tête Accept-CH qui nomme les hints voulus, comme Sec-CH-UA-Full-Version-List et Sec-CH-UA-Model. Un script peut aussi appeler navigator.userAgentData.getHighEntropyValues(). Dans les deux cas, le navigateur décide de ce qu'il renvoie, si tant est qu'il renvoie quelque chose.

Les client hints atteignent-ils les requêtes vers d'autres domaines ?

Les hints demandés via Accept-CH ne sont envoyés que sur les requêtes de même origine. Une requête vers cdn.example.net ne reçoit rien, sauf si la page délègue chaque hint avec un en-tête Permissions-Policy.

Chrome envoie-t-il des hints à forte entropie dès la première visite ?

Une première visite ne transporte que les trois hints par défaut, car le serveur n'a encore rien demandé. Une fois que le serveur envoie Accept-CH, les requêtes suivantes incluent les hints demandés pour la durée de la session du navigateur ou jusqu'à ce qu'un autre ensemble soit défini. Chromium documente un mécanisme distinct pour les hints dont un site a besoin dès la première requête.