Migrer de User-Agent Reduction vers Client Hints

La réduction de User-Agent est un changement de compatibilité, pas une invitation à créer une nouvelle empreinte. Un site doit lire le signal public minimal nécessaire, demander d’autres indications pour un motif explicite et garder un repli testé.

BotBrowser peut exécuter une version et un profil autorisés pour observer ces signaux dans un contexte contrôlé; il ne peut pas forcer un site à accepter Client Hints, accorder des permissions ni garantir un résultat entre navigateurs.

TL;DR

Chrome fige ou généralise une partie de la chaîne User-Agent. UA-CH déplace certains détails vers des en-têtes structurés et navigator.userAgentData; les valeurs à forte entropie restent soumises aux permissions et aux politiques du navigateur. Faites l’inventaire des parseurs, privilégiez la détection de capacité, envoyez Accept-CH seulement pour un besoin déclaré et testez les deux chemins. BotBrowser peut fournir des contextes contrôlés et autorisés, mais ne garantit ni l’interprétation d’un site ni un résultat universel.

Sommaire

• Ce qui change
• Séquence de migration
• Limites de confidentialité et de compatibilité
• Limite de capacité de BotBrowser
• Conclusion pratique

Ce qui change

La chaîne historique apparaît dans l’en-tête User-Agent et navigator.userAgent. La réduction retire ou fige des détails afin de limiter l’identification passive. UA-CH expose des indications structurées à faible entropie, comme Sec-CH-UA, Sec-CH-UA-Mobile et Sec-CH-UA-Platform, reflétées par navigator.userAgentData.brands, mobile et platform.

platformVersion, architecture, bitness, model et fullVersionList sont des valeurs à forte entropie. Le serveur peut demander certains champs avec Accept-CH, tandis que la page utilise getHighEntropyValues(). Transport sécurisé, politique, permission et réglage utilisateur peuvent modifier le résultat.

const lowEntropy = {
  brands: navigator.userAgentData?.brands ?? [],
  mobile: navigator.userAgentData?.mobile ?? null,
  platform: navigator.userAgentData?.platform ?? 'unknown',
};
const detailed = navigator.userAgentData
  ? await navigator.userAgentData.getHighEntropyValues(['platformVersion', 'architecture'])
  : null;

Une API absente ne prouve ni un modèle précis ni une requête automatisée; elle indique seulement que le signal n’est pas disponible.

Séquence de migration

1. Inventoriez les dépendances. Cherchez parseurs serveur, champs analytiques, règles CDN, contrôles de framework et tests qui attendent un système ou une version mineure complète.
2. Définissez la décision. Pour une capacité, utilisez la détection de fonctionnalité ou l’API standard. Pour une famille de plateforme nécessaire au serveur, utilisez une indication de faible entropie et documentez le but.
3. Gardez un repli. Les anciens navigateurs, réglages de confidentialité et clients non Chromium peuvent omettre l’indication. Utilisez une valeur prudente et n’inférez pas un appareil précis.
4. Demandez le minimum. Envoyez Accept-CH pour des champs nommés, examinez la conservation et ne journalisez pas la valeur brute lorsqu’une catégorie suffit.
5. Testez les deux surfaces. Vérifiez les en-têtes et navigator.userAgentData, puis le repli avec une page synthétique. Contrôlez redirections et clés de cache.

Décision	Preuve privilégiée	Repli sûr
Afficher une fonction	Détection à l’exécution	Contrôle alternatif accessible
Choisir une mise en page générale	Indication mobile et viewport	CSS responsive
Choisir un téléchargement	Choix explicite ou capacité	Paquet compatible général
Diagnostiquer une régression	Version déclarée et résultat	Étapes reproductibles

Limites de confidentialité et de compatibilité

Client Hints n’autorise pas un inventaire d’identité. Les demandes à forte entropie peuvent accroître la corrélation; reliez chaque champ à un but visible, limitez la conservation et excluez comptes, lieux et données sans rapport. Les entrées GREASE changent volontairement: acceptez les marques et leur ordre inconnus.

Considérez UA-CH comme une amélioration progressive. Proxy, cache, document intégré, politique ou navigateur non Chromium peuvent modifier les indications. navigator.userAgentData n’est pas partout disponible et une promesse résolue ne prouve pas la réussite de l’application. Séparez observation du navigateur, permission, accusé de l’application et résultat du service.

Voir cohérence de User-Agent personnalisé et qualité des fonctions du navigateur pour les limites connexes.

Limite de capacité de BotBrowser

BotBrowser peut fournir des profils contrôlés et des parcours autorisés et répétables pour comparer User-Agent et UA-CH sur des versions déclarées. Enregistrez en-têtes, valeurs de page et de Worker, hypothèses de contexte, version du fixture et résultat visible sur votre page de test.

Pour cette migration User-Agent vers UA-CH, cette capacité couvre la comparaison du signal observé; sa limite reste l’absence de garantie sur l’interprétation du site ou sur la réussite de l’application.

BotBrowser ne force pas l’acceptation d’une indication, n’accorde pas une permission, ne retire pas une politique d’origine et ne certifie pas un compte ou une transaction de production. Un contexte contrôlé ne justifie pas une empreinte complète. Combinez l’observation avec les définitions W3C/MDN et les assertions applicatives, en précisant version, origine, politique et repli.

Parseur tolérant et responsabilités séparées. Les marques GREASE sont extensibles: acceptez les marques inconnues et tout ordre, et ignorez les champs futurs. Une API absente n’est pas mobile: false; conservez un état explicite «signal indisponible». Le serveur décide à partir des en-têtes avant JavaScript, tandis que la page vérifie les capacités. Si la réponse dépend d’une indication, envoyez Vary et testez cache froid et cache chaud.

Fixture synthétique, redirections et cache. Créez une page de test détenue par l’équipe, affichant seulement les champs examinés et un état visible pour disponible, absent, refusé ou retardé. Testez navigation initiale, redirigée et répétée avec cache chaud; vérifiez Accept-CH, les clés et Vary afin qu’une représentation ne soit pas servie à un autre contexte. Utilisez du texte synthétique, sans compte ni endpoint de production, et vérifiez la conservation de la saisie dans le repli.

Workers, iframes et accessibilité. Ajoutez une vérification Worker et iframe lorsque le produit les utilise: modifier la page principale ne prouve pas la parité des contextes. Le repli doit être étiqueté, utilisable au clavier et accompagné d’un statut; déplacez le focus après absence ou refus et ignorez un résultat tardif après le choix de l’utilisateur.

Observabilité et conservation. Conservez des états normalisés (hint-present, hint-denied, api-missing, fallback-used), la version déclarée, la classe d’origine, la révision du fixture et la prochaine date de revue. Donnez un propriétaire et une échéance à chaque champ à forte entropie; n’enregistrez pas les dumps navigator, polices, moteur de rendu, comptes, lieux ni entrées brutes.

Déploiement, retour arrière et fiche de migration. Publiez le parseur derrière une configuration réversible, comparez l’ancienne et la nouvelle décision avec des requêtes synthétiques et revenez au repli en cas d’indication absente ou malformée. La fiche nomme décision, signal minimal, spécifications et pages MDN, versions, contextes, propriétaire du repli et distinction en-tête/page/Worker/confirmation applicative. Planifiez une revue après chaque version majeure, changement CDN ou intégration embarquée.

Clients non Chromium et anciens. Firefox, Safari, WebViews intégrées, outils de confidentialité et anciennes versions peuvent n’envoyer que la chaîne réduite ou aucun signal. Le repli est une décision produit, pas une supposition d’après le nom du navigateur: téléchargement générique, CSS responsive ou choix explicite sont plus sûrs qu’un modèle inféré. Écrivez «indication indisponible» plutôt que «appareil non pris en charge».

Communication et limites des wrappers. Dites au support quelle observation demander: par exemple Sec-CH-UA-Platform absent et mise en page responsive affichée. Ne demandez ni dump complet, ni inventaire, ni capture de compte. Une option de framework peut modifier une chaîne de page, masquer une exception ou différer un appel; elle ne modifie pas automatiquement les en-têtes, la portée du Worker ou la politique d’origine. Gardez un fixture navigateur et un parcours utilisateur distincts.

Ce que la migration ne résout pas et exemples. Elle n’identifie pas tous les navigateurs, ne force pas un serveur à accepter un en-tête, ne fait pas réussir une permission et ne prouve pas un système d’exploitation précis. Utilisez des valeurs synthétiques et des versions grossières, jamais des en-têtes clients réels; révisez les exemples quand la chaîne réduite ou les indications changent.

Propriété et revue. Nommez un responsable du parseur serveur, du repli de page et de la revue confidentialité. Notez la transition attendue et la prochaine date; rapportez la limite («en-tête absent, repli responsive affiché») plutôt que d’accuser le navigateur. Faites relire la note par ingénierie et confidentialité, avec but, signal minimal, propriétaire de conservation et déclencheur de nouvelle revue.

Conclusion pratique

Commencez par la décision utilisateur, pas par un nouveau parseur. Utilisez la détection de capacité, UA-CH à faible entropie pour une décision générale et la forte entropie seulement avec une justification concrète. Testez absence, refus, délai et repli; préservez la saisie et séparez preuve navigateur et réussite applicative. Vous réduisez ainsi les hypothèses fragiles dans la limite de ce qu’un contexte peut démontrer.

Sources

• WICG User-Agent Client Hints
• MDN NavigatorUAData
• MDN détection du navigateur
• W3C Fingerprinting Guidance
• Fonctions avancées BotBrowser