Signaux headless et avec interface : méthode de comparaison

Les équipes demandent si une page « voit » un navigateur headless, et la réponse honnête est qu'elle voit un ensemble de valeurs, dont certaines diffèrent d'un mode à l'autre et d'autres non. Cet article donne une méthode pour savoir lesquelles, et il se place à côté du guide sur la protection d'empreinte pour la collecte de données : celui-là décrit ce qu'une session de collecte autorisée doit garder cohérent, celui-ci décrit comment mesurer l'écart entre les modes avant de faire confiance à l'un ou à l'autre.

BotBrowser peut exécuter un profil déclaré en mode avec interface et en mode headless et garder les valeurs visibles du navigateur alignées sur ce profil, ce qui rend possible une comparaison à trois sur un fixture en propre ; il ne peut pas rendre un navigateur headless identique à un navigateur avec interface sur toutes les surfaces, ne prédit pas la décision d'un site tiers et ne remplace pas le test des pages réelles que visite votre flux.

Résumé

• Comparez trois sessions et non deux : avec interface, headless, et avec profil dans le mode que vous déployez.
• Utilisez la même version du fixture et notez les mêmes champs dans chacune.
• Comparez les enregistrements champ par champ et classez chaque écart comme attendu ou inexpliqué.
• Un écart inexpliqué est une observation à expliquer, pas un défaut à masquer.

Sommaire

• Partir d'un fixture en propre
• Noter trois fois les mêmes champs
• Classer chaque écart
• Garder la comparaison exécutable
• Garder la comparaison honnête
• Comparer le déploiement, pas seulement les modes
• Conclusion pratique

Partir d'un fixture en propre

La comparaison n'a de sens que sur une page que vous contrôlez, à version figée, qui rapporte les mêmes champs dans tous les modes. Une page tierce qui modifie ses propres scripts peut produire un écart sans rapport avec le mode headless, et vous ne pouvez pas savoir de l'extérieur de quelle cause il s'agit.

Écrivez le fixture pour qu'il rapporte des valeurs et non des verdicts. Une page qui affiche « headless détecté » est une page dont il faudrait auditer la logique avant de lui faire confiance. Une page qui rapporte navigator.userAgent, navigator.platform, screen.width, screen.height, devicePixelRatio, navigator.hardwareConcurrency, Intl.DateTimeFormat().resolvedOptions().timeZone et la présence de quelques API de construction vous donne des valeurs comparables sans avoir à croire aucune d'elles.

Gardez la version du fixture dans l'enregistrement. Un fixture qui change entre deux exécutions transforme un écart réel en écart de fixture, et la comparaison accusera le navigateur. Incrémentez la version quand les champs rapportés changent et rejouez la référence à ce moment-là.

Incluez au moins un champ dont vous attendez qu'il diffère. Une comparaison où tout concorde peut signifier que les modes s'accordent, ou que le fixture a cessé de rapporter quelque chose. Un écart attendu sert de témoin : s'il disparaît, le fixture a changé.

Noter trois fois les mêmes champs

La première session est avec interface, sans profil. C'est la référence qu'un lecteur reconnaîtra : une fenêtre de navigateur ordinaire sur un écran ordinaire. La deuxième est headless, également sans profil, de sorte que la seule entrée modifiée est le mode. La troisième est la configuration de déploiement : le profil que vous livrez réellement, dans le mode que vous exécutez réellement.

Chaque session utilise la même version du paquet de navigateur, la même version du fixture et la même séquence de requêtes. Changer plus d'une entrée entre sessions rend la comparaison illisible, ce qui est exactement l'erreur que cette comparaison veut éviter.

Notez les champs sous forme d'objet plat pour qu'un outil de comparaison les compare sans connaître la structure. Des objets imbriqués sont acceptables à l'intérieur d'un champ, mais le niveau supérieur doit être une liste de noms et de valeurs qu'une simple différence par lignes peut afficher. Un enregistrement de vingt champs plats se compare plus facilement qu'un autre de quatre champs imbriqués.

Gardez la sortie de chaque session séparée et nommée selon le mode. headed.json, headless.json et profile.json rendent la comparaison à trois évidente et permettent de rejouer une session sans rejouer les trois.

Classer chaque écart

Un écart entre avec interface et headless n'est pas automatiquement un problème. Certains sont attendus parce que le mode change ce que fait le navigateur, d'autres parce que votre profil de déploiement déclare une valeur qu'aucune des deux sessions par défaut n'avait.

L'agent utilisateur (navigator.userAgent) est l'écart attendu le plus net. Un navigateur headless rapporte souvent une marque headless, et un profil peut en déclarer une autre. C'est une déclaration, pas une fuite, et l'enregistrement doit dire quelle session l'a déclarée.

Les dimensions d'écran (screen.width et screen.height) peuvent différer parce que l'écran virtuel d'une session headless n'est pas l'écran physique de la session avec interface. Un profil qui déclare une taille d'écran la modifie encore. La question intéressante n'est pas de savoir si elles diffèrent, mais si la taille déclarée par le déploiement est cohérente avec les autres valeurs qui en dépendent, comme la taille de fenêtre et le viewport.

Le ratio de pixels (devicePixelRatio) diffère souvent pour la même raison. Une session headless avec écran virtuel par défaut peut rapporter un ratio tandis qu'une session avec interface rapporte celui de l'écran physique, et un profil peut en déclarer un troisième. Notez le ratio et le viewport qui en résulte ensemble, car un ratio sans viewport ne décrit pas ce qu'une page a mesuré.

Les surfaces de temporisation et de rendu sont celles qui diffèrent le plus probablement pour de vraies raisons. Une session headless peut ne pas avoir de GPU, composer autrement et produire une sortie canvas différente. Ces écarts sont ceux qui méritent examen, car ce sont ceux qu'une page pourrait utiliser pour distinguer les modes même quand toutes les valeurs déclarées concordent.

Un écart qui n'apparaît que dans la session avec profil est généralement une déclaration qui prend effet. Comparez-le au fichier de profil et non à la session avec interface, et notez si la valeur déclarée et la valeur observée concordent. Cette vérification est la raison d'être de la troisième session.

Un écart qui n'apparaît que dans une exécution d'un mode n'est ni attendu ni un écart de mode. C'est une variation d'une exécution à l'autre, et la comparer aux deux autres sessions induira en erreur. Exécutez deux fois la même session avant de classer, et traitez un écart qui n'apparaît qu'une fois comme du bruit tant qu'il ne se répète pas.

Garder la comparaison exécutable

Une comparaison qui vit dans un script jetable est une comparaison que personne ne rejoue. Mettez les trois sessions derrière une seule commande, par exemple npm run compare:modes, écrivez les trois enregistrements dans un répertoire fixe et faites de la différence une commande plutôt qu'un jugement. Quand une mise à jour du navigateur change quelque chose, la comparaison à trois le montre sur une ligne par champ.

Gardez le fixture et les enregistrements sous gestion de versions, avec la version du fixture dans le nom du fichier. Un lecteur ultérieur voit alors quels champs ont été comparés à quel moment, et l'historique d'un champ qui change sans cesse est visible sans rien demander à personne.

Rejouez la comparaison après une mise à jour du navigateur, un changement de format de profil et une mise à niveau du pilote. Ce sont les trois événements qui changent le plus probablement un champ sans toucher à votre code, et la comparaison coûte assez peu pour tourner à chaque fois.

N'en faites pas une barrière réussite ou échec sur la concordance des modes. Les modes ont le droit de différer ; ce que la barrière doit attraper, c'est un champ qui a cessé d'être noté en silence ou une valeur déclarée qui a cessé d'apparaître. Une barrière qui échoue chaque fois que avec interface et headless divergent sera ignorée en un mois.

Garder la comparaison honnête

Décider ce qu'elle permet de conclure

Une comparaison à trois répond à une question étroite : pour ces champs, sur ce fixture, dans ce paquet de navigateur, qu'est-ce qui diffère entre les modes et qu'est-ce qui diffère après application d'un profil. Elle ne dit pas si un site acceptera une session headless, si une session headless est détectable en général, ni si une session avec interface est plus sûre. Ces questions relèvent de la logique du site, de sa politique de comptes et de ses règles de risque, que le fixture ne peut pas observer.

Écrivez la conclusion sous cette forme étroite, en citant le paquet (package@155) et le fixture utilisé. « Sur fixture@v4 avec le paquet 155, l'agent utilisateur et la taille d'écran diffèrent entre avec interface et headless avant application d'un profil, et concordent avec les valeurs déclarées du profil après » est une conclusion que l'enregistrement soutient. « Headless, ça va » n'en est pas une, et elle invite à une décision que les données ne peuvent pas porter.

Gardez la comparaison indépendante de tout site cible. Dès qu'une session visite aussi une page tierce, l'enregistrement mélange le comportement de votre navigateur et la réponse de cette page, et l'écart peut venir de l'un ou de l'autre. Si vous devez vérifier une page réelle, faites-le dans une exécution séparée avec son propre enregistrement et gardez propre la comparaison du fixture.

Partagez la différence, pas la conclusion. Un collègue qui examine un champ modifié peut décider ce qu'il signifie pour son flux ; un collègue qui reçoit un verdict doit le croire sur parole. Les trois enregistrements et la différence d'une ligne sont l'artefact qui mérite d'être conservé.

Rafraîchissez la conclusion quand le paquet ou le format de profil change. Une conclusion écrite pour une version du paquet décrit cette version, et un lecteur ultérieur qui la trouve rattachée à une autre l'appliquera à tort. Datez la conclusion et nommez les entrées auxquelles elle s'applique.

Traiter les champs faciles à confondre

Certains champs ressemblent à des signaux du navigateur mais sont en réalité des valeurs de requête ou d'environnement, et les comparer entre modes sans le savoir gaspille la comparaison. Les en-têtes HTTP qu'envoie une session sont construits à partir de plusieurs sources, et l'en-tête d'agent utilisateur peut différer de navigator.userAgent selon le pilote et les options de lancement.

Notez à la fois la valeur visible par la page et l'en-tête de requête quand les deux sont censés concorder. Un décalage entre eux est une vraie observation, invisible si le fixture ne rapporte que la valeur de la page. Capturez l'en-tête de requête au même moment que la valeur de la page pour qu'ils décrivent la même navigation.

Les paramètres régionaux et le fuseau horaire méritent le même traitement. Intl.DateTimeFormat().resolvedOptions().locale, Intl.DateTimeFormat().resolvedOptions().timeZone et navigator.language sont des valeurs distinctes qui peuvent diverger, et une session headless sur un serveur aux paramètres régionaux système différents peut produire une combinaison que la session avec interface ne montre jamais. Notez les trois et non un seul.

Les mesures de canvas et de polices demandent de la prudence car elles dépendent du rendu, précisément là où une session headless peut légitimement différer. Notez la mesure et le chemin de rendu ensemble, et traitez un écart comme attendu quand le chemin diffère et comme digne d'examen quand il ne diffère pas. Le guide des chemins de rendu canvas explique pourquoi deux chemins logiciels peuvent produire des sorties différentes sur la même machine.

Rendre la différence lisible

La différence entre deux enregistrements JSON est lisible quand ils partagent une forme plate et que les valeurs sont courtes. Formatez les enregistrements avec des clés triées, un champ par ligne et pas d'imbrication au-delà d'un niveau. Un outil qui affiche <field>: <headed> -> <headless> pour chaque champ modifié suffit ; un format de rapport sur mesure n'est pas nécessaire.

Incluez dans chaque enregistrement un champ pour le mode de la session et un pour le profil, afin qu'un enregistrement copié hors contexte dise encore ce qui l'a produit. Un enregistrement sans ces deux champs ne peut plus être comparé, et la comparaison repose sur la connaissance de la session concernée.

Tenez un petit journal des champs à côté du fixture. Quand un champ est ajouté, notez la date et la raison ; quand il est retiré, notez-le aussi, car un champ retiré ressemble à un champ qui a cessé d'être rapporté. Le journal distingue un changement voulu d'un changement silencieux.

Exécutez la différence en intégration continue et ne la faites échouer que lorsqu'un champ disparaît ou qu'une valeur déclarée ne correspond plus au profil. Une différence qui échoue à chaque écart de mode sera désactivée, et une comparaison désactivée est pire qu'une comparaison qui rapporte et laisse un humain lire.

Relire avant une livraison

Une revue de livraison demande si le déploiement rapporte toujours ce qu'il a déclaré. La comparaison à trois y répond directement : les valeurs de la session avec profil face au fichier de profil, et les deux sessions par défaut face à leur propre référence. Exécutez-la dans la revue de livraison et non après un incident, et conservez le résultat à côté de profile.json.

Gardez la comparaison précédente pendant la période prise en charge. La différence entre les enregistrements de cette livraison et ceux de la précédente est plus informative que chacun seul, et c'est le seul moyen de voir un champ qui a changé progressivement sur deux mises à jour.

Retirez une comparaison quand la version du fixture qu'elle a utilisée n'est plus en service, et conservez la note qui dit quelle livraison elle décrivait. Une comparaison périmée qui paraît à jour est la forme de document la plus coûteuse, car on lui fait confiance.

Comparer le déploiement, pas seulement les modes

La comparaison à trois dit ce qui diffère entre modes. Elle ne dit pas si le déploiement est cohérent avec lui-même, ce qui est une autre question avec un autre enregistrement. Une session avec profil peut concorder avec son agent utilisateur déclaré tout en déclarant une taille d'écran incompatible avec la taille de sa fenêtre, et ni la différence ni une vérification champ par champ ne l'attrape.

Ajoutez un passage de cohérence qui compare entre eux les champs de la session avec profil plutôt qu'aux autres sessions. Le viewport (window.innerWidth et window.innerHeight) doit tenir dans l'écran déclaré ; le fuseau horaire, les paramètres régionaux et la langue doivent décrire la même région ; la plateforme doit être compatible avec l'agent utilisateur. Chacune est une règle qu'on énonce en une ligne et qu'on vérifie dans la même exécution du fixture.

Gardez les règles à côté du fixture et nommez chacune. Quand une règle échoue, l'enregistrement dit laquelle, et pas seulement quel champ a changé, et le lecteur n'a pas à redécouvrir la relation. Les règles survivent aussi au renommage d'un champ, contrairement à une comparaison codée en dur.

Exécutez le passage de cohérence sur chaque type de session, pas seulement celle du profil. Une session avec interface et sans profil peut violer une règle si les paramètres régionaux et le fuseau horaire de la machine divergent, et savoir que la référence elle-même est incohérente change la façon de lire tous les autres écarts.

Rapportez les échecs de règle séparément des écarts de mode. Un écart de mode est attendu et informatif ; un échec de règle est un problème de configuration dont le déploiement est responsable. Les mélanger dans une même liste rend bruyants les écarts attendus et facilement manqués les problèmes de configuration.

Utiliser la comparaison quand un signalement arrive

Un signalement disant qu'un site « détecte l'automatisation » arrive sous forme de phrase, pas d'enregistrement. La comparaison transforme la phrase en question : quel champ a changé depuis la dernière comparaison connue comme bonne, et a-t-il changé dans le mode qu'utilise le flux.

Demandez d'abord l'identifiant d'exécution (runId) et la comparaison du même déploiement. Sans eux, la première heure sert à établir ce qui tournait, information que la comparaison détient déjà. Avec eux, le relecteur peut aller directement au champ modifié.

Comparez avec le dernier bon enregistrement de la même version du fixture. Une différence avec une version plus ancienne du fixture mélange écart de navigateur et écart de fixture, et la liste obtenue est plus longue que nécessaire. Quand il n'existe pas d'enregistrement pour le fixture actuel, générez-en un avant d'enquêter.

Traitez un champ manquant comme une observation à part entière. Un champ noté la semaine dernière et absent cette semaine peut signifier que le fixture a cessé de le rapporter, que la page a échoué avant de l'atteindre ou que la valeur est devenue indisponible. Chaque cas a une suite différente, et aucun n'est « le site a commencé à nous détecter ».

Gardez la comparaison assez peu coûteuse pour l'exécuter à la demande. Une comparaison qui demande une après-midi de préparation sera exécutée après l'incident et non pendant, et l'incident sera terminé avant que les enregistrements existent.

Conclusion pratique

Les navigateurs headless et avec interface diffèrent de façons attendues, de façons déclarées par un profil et de façons qui méritent examen. Exécutez trois sessions sur un fixture en propre, notez les mêmes champs plats, classez chaque écart et gardez la comparaison exécutable. Utilisez-la avec le guide de collecte de données et le guide de configuration de serveur headless.

Sources publiques

• MDN : Navigator userAgent
• MDN : Window devicePixelRatio
• MDN : Screen width
• Chrome Developers : Headless mode
• Documentation BotBrowser : configuration de serveur headless