Reproductibilité de la graine de bruit pour des exécutions répétables

Une graine de bruit répétable rend comparables les exécutions de Canvas, WebGL, audio et texte. BotBrowser répète le même bruit avec la même graine, le même profil et le même build ; une concordance ne prouve pas que deux hôtes sont le même appareil ni qu'un site les traitera pareillement.

Résumé rapide

La graine fixe le bruit appliqué, pas l'hôte : le même fixture avec la graine 42 doit donner la même empreinte après redémarrage, et avec 43 il faut noter si elle change ou entre en collision. Attribuez une graine par identité pour ne pas créer de lien entre comptes.

Sommaire de la guide

• Pourquoi des graines répétables rendent les exécutions comparables
• Ce que la graine répète et ce qu'elle laisse intact
• Attribuer des graines aux identités sans créer de liens
• Vérifier la même graine après des redémarrages
• Reproduire les résultats en CI
• Distinguer un écart de graine d'une dérive du fixture
• Ce qu'un résultat concordant montre et ne montre pas

Pourquoi des graines répétables rendent les exécutions comparables

Un test d'empreinte qui donne une réponse différente à chaque exécution inspire peu confiance. Le bruit d'empreinte ajoute de petites variations aux pixels de Canvas, à la lecture de WebGL, aux échantillons audio et aux mesures de texte, afin que le navigateur ne présente pas la sortie brute d'une seule machine. Si cette variation est tirée à nouveau à chaque démarrage, vous ne pouvez pas savoir si un résultat différent vient de votre configuration, de la page testée ou du bruit lui-même. Une graine de bruit fixe écarte la troisième possibilité. BotBrowser peut répéter la sortie Canvas, WebGL, audio et de mesure de texte pour un profil, une version et une graine fixes dans un contexte contrôlé ; il ne peut pas rendre cette sortie anonyme ni garantir le même résultat avec une autre version, un autre profil ou d’autres arguments.

Le paramètre --bot-noise-seed est un entier qui initialise un générateur de nombres pseudo-aléatoires. Le générateur produit la même séquence à partir de la même valeur de départ : deux démarrages qui utilisent la même graine appliquent donc la même variation au même dessin ou à la même mesure, et une autre graine applique une variation différente, tout aussi stable. Vous décidez quand la sortie doit se répéter et quand elle doit changer. Pour savoir comment choisir des graines pour des identités stables et vérifier qu’une graine se répète, consultez Mode déterministe : empreintes reproductibles, qui couvre ce que la graine contrôle et comment vérifier la reproductibilité.

Quatre besoins justifient généralement une graine fixe :

• Continuité de session. Revenir sur un service au fil de plusieurs démarrages en présentant chaque fois la même sortie de rendu.
• Identités distinctes et stables. Donner à des comptes, des locataires ou des utilisateurs de test séparés leur propre motif de bruit, qui ne change pas d'un démarrage à l'autre.
• Comparaison entre exécutions. Retirer le bruit de rendu des variables lorsque vous comparez deux builds, deux pages ou deux profils.
• Reproduction en CI. Reconstituer les conditions d'une exécution passée pour qu'une comparaison échouée puisse être examinée au lieu d'être devinée.

Les sections suivantes suivent une graine depuis les surfaces qu'elle touche, en passant par l'attribution des graines aux identités, jusqu'à un contrôle après redémarrage et un enregistrement pour la CI, puis jusqu'aux limites à préciser quand vous rapportez un résultat. Les valeurs de référence proviennent de la documentation publique sur la graine de bruit et de la référence des paramètres de ligne de commande, toutes deux citées dans les sources.

Ce que la graine répète et ce qu'elle laisse intact

BotBrowser applique un bruit contrôlé à Canvas 2D, WebGL, WebGPU, AudioContext, ClientRects et TextRects. Le paramètre --bot-noise-seed (ENT Tier2) rend ce bruit déterministe. Avec le même profil, le même build et les mêmes arguments de lancement, une graine fixe donne la même lecture de Canvas, la même lecture de WebGL et WebGPU, les mêmes échantillons audio et les mêmes mesures de texte et d'éléments à chaque session et après chaque redémarrage.

La lecture est l'endroit où une page voit l'effet. HTMLCanvasElement.toDataURL() renvoie une URL de données pour les pixels que contient le canevas à cet instant, en PNG sauf si l'appelant demande un autre type, de sorte que toute variation du rendu apparaît directement dans la chaîne renvoyée. Un OfflineAudioContext rend un graphe de nœuds audio dans un tampon sans le lire, et la page lit les valeurs d'échantillons dans ce tampon. Des appels comme measureText() et getBoundingClientRect() renvoient des nombres plutôt que des pixels, mais ils se lisent de la même manière : la page interroge, le navigateur répond, et la réponse est soit identique à la précédente, soit différente. La graine s'applique à la réponse, pas à la question. Pour voir comment la sortie audio devient une empreinte et comment vérifier la cohérence audio, consultez Empreinte audio expliquée : comment AudioContext vous piste, qui explique pourquoi l’audio sert de signal de suivi.

La répétition est liée au contenu. Une page qui dessine la même scène avec la graine 42 dans deux sessions relit les mêmes pixels, et la même scène avec la graine 43 relit des pixels différents, tout aussi stables. Si la scène elle-même change d'une exécution à l'autre, la sortie change pour des raisons sans rapport avec la graine : chaque comparaison exige donc une scène fixe. Pour comprendre pourquoi le même dessin diffère d’un appareil à l’autre, consultez Empreinte Canvas : fonctionnement et solutions, qui couvre ce que mesure l’empreinte Canvas et comment vérifier la stabilité.

La plage acceptée va de 1 à 4294967295, le plus grand entier non signé sur 32 bits. La valeur 0 conserve les valeurs par défaut du profil et n'initialise pas le générateur, la répétabilité avec 0 n'est donc pas garantie et il ne faut pas l'utiliser comme référence. Quand la répétabilité compte, passez un entier positif à chaque démarrage et vérifiez que votre lanceur ou votre framework de test transmet réellement l'argument, car un 0 accidentel ou un argument perdu transforme discrètement une configuration déterministe en configuration variable.

La graine ne décide pas du type d'appareil présenté. Le profil définit les valeurs d'identité de l'appareil, comme la chaîne d'agent utilisateur, les dimensions d'écran et la plateforme. La graine ne façonne que la variation de rendu et de mesure au-dessus de ces valeurs. Deux sessions avec le même profil et des graines différentes partagent les valeurs du profil et ne diffèrent que par le bruit, et une graine ne fusionne pas deux profils différents en une seule identité.

Chaque canal de bruit a son propre interrupteur dans la référence des paramètres : --bot-noise-canvas, --bot-noise-webgl-image, --bot-noise-audio-context, --bot-noise-client-rects et --bot-noise-text-rects. Chacun accepte true ou false. La graine décide de l'aspect du bruit, et les interrupteurs décident quelles surfaces le reçoivent : les deux contrôles répondent donc à des questions différentes. Désactiver un canal est une étape de diagnostic utile quand un résultat cesse de se répéter, à condition de le réactiver avant de vous appuyer sur la configuration.

Plusieurs éléments restent hors de portée de la graine. Les cookies, le stockage et l'état de connexion se trouvent dans le répertoire défini par --user-data-dir, et une graine ne restaure pas une connexion. Le minutage d'exécution a son propre contrôle : --bot-time-seed prend un entier de 1 à 4294967295 pour une politique de minutage reproductible, et 0 la désactive. Une graine de bruit seule ne rend pas le minutage répétable, et une graine de minutage ne change pas la sortie de Canvas. Quand un test exige que le rendu et le minutage se répètent, définissez volontairement les deux valeurs et enregistrez-les toutes les deux.

Attribuer des graines aux identités sans créer de liens

Traitez la graine comme une configuration propre à chaque identité. Un profil avec la graine 100 est une empreinte stable. Le même profil avec la graine 200 en est une seconde, avec son propre motif de bruit. Cette séparation est la raison de garder une graine par compte, locataire ou utilisateur de test, et c'est ce qui permet à chaque identité de présenter la même sortie de rendu lors de sa visite suivante.

C'est le cas inverse dont il faut se garder. Si deux identités utilisent le même profil et la même graine, elles produisent une sortie de rendu identique, et cette sortie partagée peut les relier. Une graine est une configuration, pas un secret qui empêche la corrélation : quiconque détient le même build, le même profil et la même graine reproduit la même sortie. Ce qui protège des identités séparées, c'est que deux d'entre elles ne partagent jamais à la fois un profil et une graine.

Conservez dans le contrôle de version une table graine-identité à côté des noms de fichiers de profil. Chaque ligne doit contenir l'identité, le nom du fichier de profil, la graine et la date de création de la paire.

[
  { "identity": "tenant-a", "profile": "profile-a.enc", "seed": 1001 },
  { "identity": "tenant-b", "profile": "profile-a.enc", "seed": 1002 },
  { "identity": "tenant-c", "profile": "profile-b.enc", "seed": 1003 }
]

Dans cette table, le locataire A et le locataire B partagent un profil mais ont des graines différentes : leurs motifs de bruit diffèrent. Le locataire C utilise un autre profil. Si le locataire B passait à la graine 1001, deux identités auraient le même profil et la même graine, et c'est le cas à signaler comme risque de liaison et à corriger avant la prochaine exécution en attribuant une nouvelle graine à l'une d'elles.

Générez chaque graine une seule fois et conservez-la. Ne dérivez pas une graine d'un horodatage ou d'un compteur qui se réinitialise, car cela transforme discrètement une configuration déterministe en une valeur différente à chaque démarrage. La graine ne peut pas être retrouvée à partir de la sortie, la table est donc le seul enregistrement. Tout entier positif de la plage valide convient, et il n'y a aucun avantage à choisir des valeurs grandes, premières ou régulières. Des valeurs consécutives conviennent, tant que la table indique qui détient laquelle.

Quand un seul processus de navigateur doit porter plusieurs identités, l'empreinte par contexte (ENT Tier3) permet à chaque BrowserContext d'avoir son propre --bot-noise-seed. La documentation définit les paramètres d'un contexte avant la création de sa première page, afin que le moteur de rendu démarre avec les bonnes valeurs. Un second contexte avec une autre graine produit un motif différent, tout aussi reproductible.

Vérifier la même graine après des redémarrages

Le contrôle ci-dessous confirme qu'une graine se répète et qu'une autre graine modifie la sortie. Il nécessite une page que vous maîtrisez, ou une page de test dont vous savez qu'elle dessine la même scène à chaque fois. La page doit dessiner une scène Canvas fixe et la relire avec toDataURL(), relire une scène WebGL fixe, rendre un tampon audio hors ligne fixe et mesurer une chaîne fixe. Enregistrez chaque valeur, ou un court condensat de celle-ci, afin que les comparaisons soient exactes. Chargez la page de la même façon à chaque fois, avec la même taille de fenêtre et le même ordre de chargement, pour que la graine soit la seule différence voulue entre les exécutions.

Un répertoire de données utilisateur neuf garde l'ancien état du navigateur hors de la comparaison :

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-noise-seed=42 \
  --user-data-dir="$(mktemp -d)"

Exécutez la vérification dans cet ordre :

1. Lancez avec le profil et --bot-noise-seed=42, chargez la page et enregistrez les valeurs de Canvas, WebGL, Audio et texte.
2. Fermez le navigateur, relancez avec le même profil et la même graine, puis chargez la même page. Chaque valeur enregistrée doit correspondre à celle de la première exécution.
3. Passez la graine à 43 et exécutez la page une troisième fois. Notez si chaque valeur diffère ou entre en collision avec la première : une différence montre que la graine façonne cette surface, tandis qu'une collision montre qu'un nouvel entier ne garantit pas l'unicité.
4. Lancez deux fois avec --bot-noise-seed=0. La répétabilité avec 0 n'est pas garantie, n'utilisez donc pas ces valeurs comme référence, car 0 n'initialise pas le générateur.
5. Conservez le build, le fichier de profil, le système d'exploitation hôte et la liste complète des arguments avec les résultats.

La cinquième étape est celle que l'on saute le plus souvent, et c'est elle qui explique un écart ultérieur. Un résultat n'est comparable à un autre que si le build, le profil, la graine et les arguments de lancement sont identiques.

Quand la seconde session ne correspond pas à la première, écartez les causes habituelles avant de soupçonner la graine :

• La scène a changé : le texte, la taille du canevas ou l'ordre de dessin diffère d'une exécution à l'autre.
• La graine n'est pas arrivée : un lanceur a supprimé l'argument, ou la valeur est 0.
• Un autre fichier de profil ou une autre version du profil a été chargé.
• Un autre build de BotBrowser ou une autre cible de système d'exploitation hôte a été utilisé.
• Un framework ou un script d'enrobage a ajouté des arguments supplémentaires.
• Un canal de bruit a été désactivé dans une exécution et laissé actif dans l'autre.

La documentation donne le même conseil pour une configuration qui se comporte différemment sur une autre machine : comparer le build de BotBrowser, la version du profil, la cible de système d'exploitation hôte et les arguments de lancement complets. Elle conseille aussi de garder stables la route réseau, les paramètres régionaux et le fuseau horaire, ainsi que la charge de la machine pendant que vous comparez des exécutions, car ces éléments peuvent modifier le comportement d'une page même si la graine n'a pas changé.

Un écart est un constat, pas du bruit à moyenner. Signalez-le comme une différence de build, de profil ou d'arguments tant que vous n'avez pas montré le contraire, et conservez les deux jeux de résultats avec leurs enregistrements. Relancer jusqu'à ce que les valeurs concordent par hasard masque la cause et laisse l'exécution suivante tout aussi incertaine.

Cerner un écart sans deviner

Étape	Quoi comparer d'abord	Une correspondance ici signifie
1	La liste complète des arguments	La graine et les commutateurs de canal sont arrivés
2	L'empreinte du fichier de profil	Les mêmes octets de profil ont été chargés
3	La chaîne de compilation	Le même binaire a produit les deux exécutions
4	Les entrées de la scène	La page a dessiné la même chose deux fois

Les six causes ci-dessus sont faciles à énumérer et difficiles à séparer, car toutes produisent le même symptôme : deux relevés qui diffèrent. Parcourir les quatre entrées dans cet ordre coûte une comparaison chacune et écarte les explications bon marché avant de toucher à la page.

Comparez d'abord la liste des arguments, et comparez-la comme du texte plutôt que de mémoire. Un lanceur qui perd une option, un wrapper qui ajoute la sienne et un shell qui a développé une variable autrement laissent la même trace : l'exécution qui a produit les valeurs divergentes n'avait jamais la graine que vous croyez. Affichez les arguments effectifs des deux exécutions et comparez-les.

Comparez ensuite le fichier de profil, par empreinte et non par nom. Deux fichiers du même nom dans des dossiers différents, ou un fichier remplacé lors d'une mise à jour de profil, produisent un écart qui ressemble à un problème de graine et qui est un problème de profil. La comparaison d'empreintes en fait une réponse par oui ou non.

Puis la chaîne de compilation, complète et pas seulement la version majeure. Une mise à jour mineure dans la même version majeure peut changer un chemin de dessin alors que tous les numéros visibles restent familiers. Si la compilation diffère, cessez de traiter les deux relevés comme comparables et conservez-les comme deux références distinctes.

Ce n'est qu'une fois ces trois concordances établies que la scène mérite un contrôle. Comparez les dimensions du canevas, la chaîne de texte, l'ordre de dessin et les paramètres du tampon audio, car chacun modifie l'entrée reçue par le générateur et donc la sortie produite avec la même graine. Un changement de scène est la seule cause où la graine fonctionne correctement et où le résultat diffère quand même.

Pour isoler une surface qui cesse de se répéter, désactivez un canal à la fois, comparez, puis rétablissez-le :

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-noise-seed=42 \
  --bot-noise-canvas=false

Si les autres surfaces se répètent alors que le bruit de Canvas est désactivé, c'est la scène Canvas ou sa lecture qui varie. Rétablissez l'interrupteur et conservez la ligne de commande finale dans vos notes, afin de pouvoir coller les mêmes arguments dans la session suivante.

Reproduire les résultats en CI

Une tâche de CI est un lancement que personne ne surveille : elle a donc besoin de l'enregistrement qu'une personne garderait autrement en tête. Figez dans la configuration de la tâche le build de BotBrowser, le fichier de profil, la graine et les arguments de lancement complets, et écrivez-les dans la sortie de la tâche avec les valeurs rapportées par la page de vérification. Quand une comparaison échoue des semaines plus tard, cette sortie vous permet de reproduire l'exécution sur une autre machine au lieu de deviner.

Un enregistrement utile comporte quelques champs pour chaque graine :

• La valeur de la graine et l'identité ou le cas de test auquel elle appartient.
• Le nom du fichier de profil et sa version.
• Le build de BotBrowser.
• La cible de système d'exploitation hôte et le type de machine.
• La liste complète des arguments, y compris toute graine de minutage.
• Les valeurs rapportées par la page de vérification, avec la date de l'exécution.

Utilisez un répertoire de données utilisateur neuf pour chaque exécution de CI, comme dans le lancement ci-dessus, afin que les anciens cookies et le stockage ne puissent pas influencer la comparaison. Gardez la graine dans la configuration de la tâche plutôt que de la choisir à l'intérieur de la tâche, car une graine choisie à l'exécution est une valeur différente à chaque exécution.

Exécutez la page de vérification comme première étape de la tâche, avant les tests qui en dépendent. Si elle rapporte des valeurs conformes à la référence enregistrée, continuez. Si elle rapporte des valeurs différentes, arrêtez-vous et indiquez lequel de ces éléments a changé : le build, le profil, la graine ou les arguments, plutôt que de laisser les tests suivants échouer pour une raison difficile à voir.

Les mises à jour sont l'autre moment où il faut vérifier de nouveau. Après avoir mis à jour BotBrowser, remplacé un fichier de profil, changé de machine d'exécution ou modifié les arguments, exécutez la page une fois avec la graine enregistrée et comparez-la aux valeurs enregistrées. Si elles correspondent, poursuivez. Si elles diffèrent, considérez les nouvelles valeurs comme une nouvelle référence, notez le build qui les a produites, et ne modifiez pas la graine pour retrouver l'ancienne sortie, puisque la graine n'est pas ce qui a changé.

Parfois, un nouveau motif est précisément ce que vous voulez, par exemple quand vous retirez une identité de test pour en démarrer une autre. Changez la graine volontairement, mettez à jour la table et la référence dans le même commit, et conservez l'ancienne ligne avec son numéro de build. L'ancienne graine reste une description correcte de ce que ce build a produit pour ce profil.

La répétabilité entre machines et entre systèmes d'exploitation suit la même règle. Exécutez la page sur chaque machine d'exécution avec le même build, le même profil et les mêmes arguments, et comparez les valeurs. Une correspondance est une preuve pour ces machines. Une différence est signalée comme un écart de build, de profil ou d'arguments à tracer, et non ignorée.

Distinguer un écart de graine d'une dérive du fixture

Une exécution répétée est le seul moyen de distinguer un changement de graine d'un changement de fixture, et la comparaison ne vaut que tant que la scène, le build et le profil restent fixes. Les mesures ci-dessous proviennent d'une page de test sur une seule machine : build Chromium 144.0.7559.97, profil Windows 10, hôte Linux headless, dessin canvas fixe de 220×60, clear WebGL fixe de 64×64 et tampon audio hors ligne fixe. L'empreinte correspond aux 32 premiers caractères hexadécimaux du SHA-256 de canvas.toDataURL().

Graine	Empreinte canvas	Appariement	Lecture
42	fd0881c19451370e66313f61e760c77c	exécutée deux fois, identique	la même graine se répète
43	fd0881c19451370e66313f61e760c77c	identique à la graine 42	une graine différente peut reproduire une sortie antérieure
44	06ff31e59678fe4d923a85d73479fe2e	nouvelle sortie	une graine différente peut produire une sortie nouvelle
45	06ff31e59678fe4d923a85d73479fe2e	identique à la graine 44	la collision n'est pas un accident isolé
46	5877be94c6969400c80033f0a2f4528d	nouvelle sortie	une troisième sortie distincte
77	8138eccb72cb091408fc684572c3504a	nouvelle sortie	confirme que l'empreinte répond à la graine
12345	5877be94c6969400c80033f0a2f4528d	identique à la graine 46	une seconde collision

Deux conclusions en découlent, et toutes deux sont plus étroites qu'elles n'en ont l'air.

La même graine se répète exactement, ce qui est la garantie de l'option. Mais deux graines différentes peuvent aussi produire la même sortie : dans cette exécution, trois des sept graines ont rencontré une sortie antérieure. Changer la graine n'est donc pas un moyen fiable d'obtenir une empreinte différente. Traitez la graine comme une entrée d'une correspondance finie et non comme un identifiant unique, et lorsque deux identités ne doivent pas partager de sortie de rendu, vérifiez la sortie au lieu de supposer qu'un nouvel entier suffit.

La même exécution a laissé inchangés l'empreinte WebGL, les échantillons audio et la largeur de texte pour toutes les graines, seule l'empreinte Canvas a bougé. C'est une observation sous un build, un profil et un hôte, pas une affirmation sur les surfaces couvertes par l'option sur chaque plateforme ; les interrupteurs de canal de bruit sont des contrôles séparés et cette sonde ne les a pas basculés. Refaire la sonde en affichage headful, derrière un profil macOS et avec le canal de bruit WebGL activé montrerait si la même répartition tient ailleurs.

Ce qu'un résultat concordant montre et ne montre pas

Une vérification réussie appuie une affirmation étroite : un build, un profil et une graine donnés ont répété la même sortie de Canvas, WebGL, Audio et de mesures de texte sur une machine donnée, tandis qu'une autre graine l'a modifiée ou a produit une collision sur les surfaces mesurées. Elle n'appuie pas l'affirmation que le même résultat vaut sur toutes les machines, après chaque mise à jour ou sur toutes les pages. Rédigez les résultats sous la première forme et l'enregistrement restera exact des mois plus tard.

Une empreinte répétable est un compromis. Présenter la même sortie à chaque visite est ce qui donne la continuité de session, et c'est aussi ce qui permet de reconnaître les visites répétées comme répétées. Une graine fixe ne rend pas une empreinte anonyme ni unique, et elle ne dit rien de la manière dont un site précis la traitera. Le rendu n'est qu'un groupe de signaux. L'identité de l'appareil issue du profil, la route réseau, le minutage et ce qu'un site fait de la visite relèvent d'autres contrôles.

BotBrowser prend en charge un --bot-noise-seed entier fixe, de 1 à 4294967295, qui fait se répéter la sortie de Canvas, WebGL, AudioContext et des mesures de texte pour un même profil entre sessions et redémarrages, afin que les équipes puissent comparer des exécutions, reproduire des résultats de CI et conserver une référence de rendu stable pour chaque identité. BotBrowser ne peut pas rendre une sortie à graine anonyme ni à l'abri des vérifications propres à un site, ne garantit pas des résultats identiques avec un autre build, un autre profil ou d'autres arguments de lancement, et ne remplace ni l'attribution d'une graine par identité ni les contrôles réseau ou côté site.

Pour plus de contexte, consultez Mode déterministe, Empreinte Canvas, Protection de l'empreinte audio et Gestion des profils.

Ce que cette page ajoute à la référence

La page de référence liste l'option de graine, sa plage et les surfaces concernées. Gardez le profil, le build, les arguments de lancement et la scène de test fixes, comparez deux lancements avec la graine 42, puis un lancement avec 43 : c'est une méthode à exécuter, pas un résultat rapporté ici. En cas d'écart, suivez les étapes de diagnostic ci-dessus pour distinguer un changement de scène ou d'argument d'une différence de profil, de build ou d'hôte avant de modifier la graine.

Sources

• Documentation BotBrowser sur la reproductibilité de la graine de bruit
• Référence BotBrowser des paramètres de ligne de commande
• Référence MDN sur HTMLCanvasElement.toDataURL
• Référence MDN sur OfflineAudioContext

Conclusion pratique

Ne changez la graine que pour obtenir une identité différente, pas pour corriger un écart d'hôte. Si l'empreinte change avec la même graine, le même profil et le même build, notez cet écart comme dépendant de l'hôte.