Qu'est-ce que la réduction user-agent ?

La réduction de la chaîne User-Agent (UA) permet de réduire la quantité d'informations permettant l'identification personnelle partagées dans la chaîne, qui peuvent être utilisées pour le fingerprinting passif. Maintenant que ces modifications sont disponibles pour tous les utilisateurs, toutes les requêtes de ressources ont un en-tête User-Agent réduit. Par conséquent, les valeurs renvoyées par certaines interfaces Navigator sont réduites, y compris navigator.userAgent, navigator.appVersion et navigator.platform.

Les développeurs Web doivent vérifier si le code de leur site utilise la chaîne User-Agent. Si votre site s'appuie sur l'analyse de la chaîne User-Agent pour lire le modèle de l'appareil, la version de la plate-forme ou la version complète du navigateur, vous devrez implémenter l'API User-Agent Client Hints.

User-Agent Client Hints (UA-CH)

Les indices client User-Agent permettent d'accéder à l'ensemble complet des données User-Agent, mais uniquement lorsque les serveurs déclarent activement un besoin explicite de données spécifiques.

En supprimant les données utilisateur exposées passivement, nous mesurons et réduisons mieux la quantité d'informations exposées intentionnellement par les en-têtes de requête, les API JavaScript et d'autres mécanismes.

Pourquoi devons-nous réduire UA et UA-CH ?

Historiquement, la chaîne User-Agent diffusait une longue chaîne de données sur le navigateur, le système d'exploitation et la version d'un utilisateur avec chaque requête HTTP. Cela posait problème pour deux raisons:

  • La précision et l'abondance de détails peuvent permettre d'identifier l'utilisateur.
  • La disponibilité par défaut de ces informations peut entraîner un suivi masqué.

UA et UA-CH réduits améliorent la confidentialité des utilisateurs en ne partageant que des informations de base par défaut.

L'User-Agent réduit inclut la marque du navigateur et une version importante, l'origine de la requête (ordinateur ou mobile) et la plate-forme. Pour accéder à plus de données, les indices client User-Agent vous permettent de demander des informations spécifiques sur l'appareil ou les conditions de l'utilisateur.

De plus, au fil du temps, la chaîne User-Agent est devenue plus longue et plus complexe, ce qui a entraîné une analyse de chaîne sujette aux erreurs. UA-CH fournit des données structurées et fiables, plus faciles à interpréter. Le code existant qui analyse la chaîne UA ne devrait pas se briser (bien qu'il renvoie moins de données). Vous devrez migrer vers UA-CH si votre site a besoin d'informations client spécifiques.

Comment fonctionne la réduction de UA et UA-CH ?

Voici un bref exemple illustrant le fonctionnement de la chaîne user-agent réduite et de UA-CH. Pour un exemple plus détaillé, consultez Améliorer la confidentialité des utilisateurs et l'expérience des développeurs avec les hints client user-agent.

Un utilisateur ouvre le navigateur et saisit example.com dans la barre d'adresse:

  1. Le navigateur envoie une requête pour charger la page Web.

    1. Le navigateur inclut l'en-tête User-Agent avec la chaîne User-Agent réduite. Exemple : User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36.

    2. Le navigateur inclut les mêmes informations dans les en-têtes d'indice client User-Agent par défaut. Exemple :

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. Le serveur peut demander au navigateur d'envoyer des indices client supplémentaires, tels que le modèle de l'appareil, avec l'en-tête de réponse Accept-CH. Exemple : Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model.

  3. Le navigateur applique les règles et la configuration utilisateur pour déterminer quelles données sont autorisées à être renvoyées au serveur dans les en-têtes de requête suivants. Exemple :

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

Conseils client critiques

Si vous avez besoin d'un ensemble spécifique de Client Hints dans votre requête initiale, vous pouvez utiliser l'en-tête de réponse Critical-CH. Les valeurs Critical-CH doivent être un sous-ensemble des valeurs demandées par Accept-CH.

Par exemple, la requête initiale peut inclure une requête pour Device-Memory et Viewport-Width, où Device-Memory est considéré comme critique.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

Si le navigateur a besoin d'un indice critique (Critical-CH) pour afficher correctement la page Web, le serveur peut demander ces informations supplémentaires avec l'en-tête Accept-CH. Le navigateur peut ensuite envoyer une nouvelle requête pour la page, y compris l'indice critique.

En résumé, Accept-CH demande toutes les valeurs que vous souhaitez pour la page, tandis que Critical-CH ne demande que le sous-ensemble de valeurs que vous devez avoir au chargement pour charger correctement la page. Pour en savoir plus, consultez la spécification de fiabilité des indices client.

Détecter les appareils de type tablette avec l'API UA-CH

À mesure que la distinction entre les appareils mobiles, les tablettes et les ordinateurs de bureau devient moins nette et que les facteurs de forme dynamiques sont plus courants (écrans pliables, basculement entre le mode ordinateur portable et le mode tablette), il est conseillé d'utiliser la conception responsive et la détection de fonctionnalités pour présenter une interface utilisateur appropriée.

Toutefois, les informations fournies par le navigateur pour la chaîne User-Agent et les indices client User-Agent proviennent de la même source. Les mêmes formes de logique devraient donc fonctionner.

Par exemple, si ce format est vérifié sur la chaîne UA:

  • Format du téléphone: 'Android' + 'Chrome/[.0-9]* Mobile'
  • Format de la tablette: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

L'interface des en-têtes UA-CH par défaut correspondants peut être vérifiée:

  • Format de téléphone: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • Motif pour tablette: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

Ou l'interface JavaScript équivalente:

  • Format du téléphone: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • Format de la tablette: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

Pour les cas d'utilisation spécifiques au matériel, le nom du modèle de l'appareil peut être demandé via l'indice Sec-CH-UA-Model à haute entropie.

Comment utiliser et tester la UA réduite ?

Pour commencer, examinez le code de votre site pour identifier les instances et les utilisations de la chaîne User-Agent. Si votre site s'appuie sur l'analyse de la chaîne User-Agent pour lire le modèle de l'appareil, la version de la plate-forme ou la version complète du navigateur, vous devez implémenter l'API UA-CH.

Une fois que vous êtes passé à l'API UA-CH, vous devez effectuer des tests pour vous assurer d'obtenir les données attendues de l'User-Agent. Il existe trois façons de tester, chacune augmentant en complexité.

La disponibilité à grande échelle de la réduction de l'user-agent signifie que la chaîne UA entièrement réduite est fournie sur tous les appareils Chrome. La réduction a commencé avec une version mineure de Chrome au 2e trimestre 2022.

Tester des chaînes personnalisées en local

Si vous souhaitez tester votre site à l'aide de chaînes User-Agent personnalisées pour simuler différents appareils, lancez Chrome avec l'indicateur de ligne de commande --user-agent="Custom string here". Pour en savoir plus sur les options de ligne de commande, consultez cette page.

Vous pouvez également utiliser l'émulateur d'appareil dans les outils pour les développeurs Chrome.

Transformer la chaîne dans le code de votre site

Si vous traitez la chaîne user-agent Chrome existante dans votre code côté client ou côté serveur, vous pouvez la transformer en nouveau format pour tester la compatibilité. Vous pouvez effectuer un test en ignorant et en remplaçant la chaîne, ou en générant la nouvelle version et en la testant côte à côte.

Prise en charge des indices client et des indices critiques

Trois indices client par défaut sont renvoyés au serveur, y compris le nom et la version majeure du navigateur, une valeur booléenne indiquant si le navigateur se trouve sur un appareil mobile et le nom du système d'exploitation. Ils sont envoyés après le handshake du protocole TLS (Transport Layer Security). Elles sont déjà disponibles et compatibles avec votre navigateur.

Toutefois, il peut arriver que vous deviez récupérer des informations essentielles pour que votre site s'affiche.

Optimiser les suggestions critiques

Un handshake TLS est la première étape pour créer une connexion sécurisée entre le navigateur et le serveur Web. Sans intervention, l'en-tête de réponse Critical-CH était conçu pour indiquer au navigateur de relancer immédiatement la requête si la première a été envoyée sans indice critique.

Schéma séquentiel des hints client avec des hints critiques.
Lorsqu'un indice critique est demandé par le serveur, le client réessaie d'envoyer la première requête pour la page Web avec l'indice critique. Dans cet exemple, l'indice pour Sec-CH-UA-Model est demandé deux fois: une fois en tant qu'indice client avec Accept-CH et une fois en tant qu'indice critique avec Critical-CH.

Pour optimiser les indications critiques (en-tête Critical-CH), vous devez intercepter cet échange et fournir un modèle pour les indications client. Ces étapes peuvent être complexes et nécessiter des connaissances avancées.

Les frames HTTP/2 et HTTP/3 ACCEPT_CH, combinés à l'extension TLS ALPS, constituent une optimisation au niveau de la connexion pour transmettre les préférences d'indice client du serveur à temps pour la première requête HTTP. Ils nécessitent une configuration complexe, et nous vous recommandons de ne les utiliser que pour les informations vraiment critiques.

BoringSSL (une fourchette d'OpenSSL) vous aide à utiliser les fonctionnalités expérimentales de Google dans Chromium. Pour le moment, ALPS n'est implémenté que dans BoringSSL.

Si vous devez utiliser des indices critiques, consultez notre guide sur la fiabilité et l'optimisation des indices critiques.

Questions fréquentes

Combien de temps les indices spécifiés via l'en-tête Accept-CH seront-ils envoyés ?

Les indices spécifiés via l'en-tête Accept-CH sont envoyés pendant toute la durée de la session du navigateur ou jusqu'à ce qu'un autre ensemble d'indices soit spécifié.

UA-CH est-il compatible avec HTTP/2 et HTTP/3 ?

UA-CH fonctionne avec les connexions HTTP/2 et HTTP/3.

Les sous-domaines (et les CNAME) nécessitent-ils une page racine Permissions-Policy pour accéder à UA-CH haute entropie ?

Les UA-CH à entropie élevée dans les en-têtes de requête sont limités aux requêtes multi-origines, quelle que soit la manière dont cette origine est définie côté DNS. La délégation doit être gérée via Permissions-Policy pour toute sous-ressource multidomaine ou obtenue via JavaScript qui s'exécute dans le contexte multidomaine.

Quel est l'impact de la réduction user-agent sur la détection des bots ?

La modification de la chaîne user-agent de Chrome n'a pas d'incidence directe sur la chaîne user-agent qu'un robot choisit d'envoyer.

Les robots peuvent choisir de mettre à jour leurs propres chaînes pour refléter les informations réduites que Chrome envoie, mais c'est entièrement leur choix d'implémentation. Chrome continue d'envoyer le même format User-Agent, et les bots qui ajoutent leur propre identifiant à la fin d'une chaîne User-Agent Chrome peuvent continuer à le faire.

En cas de problème avec des bots spécifiques, il peut être utile de contacter directement leurs propriétaires pour leur demander s'ils prévoient de modifier leur chaîne User-Agent.

Interagir et envoyer des commentaires

En savoir plus