Journalisation du déploiement et vie privée

Les journaux d’un déploiement de navigateur doivent expliquer si un contexte déclaré a démarré, quel résultat visible a suivi et quelle action vient ensuite. Ils ne doivent pas devenir le profil caché d’une personne, une base d’empreintes ou un vidage inexpliqué des composants internes. BotBrowser peut répéter un déploiement autorisé et une assertion de navigateur dans un contexte déclaré ; il ne décide pas de la conservation, ne prouve pas l’anonymat et ne certifie pas la sécurité d’un site tiers.

Définir la question du déploiement

Commencez par une question opérationnelle : le navigateur a-t-il démarré avec la version, l’état du profil, le parcours et la révision d’application prévus, puis atteint la branche attendue ? C’est plus précis que de collecter toutes les propriétés du navigateur. Écrivez le résultat attendu en termes visibles et consignez l’observation avec les mêmes termes.

La spécification WebDriver du W3C décrit un protocole de contrôle distant ; elle n’impose pas de conserver des sessions complètes ou des données personnelles. La documentation navigateur de MDN décrit les surfaces exposées ; le propriétaire de l’application choisit l’observation nécessaire à la décision.

Journaliser l’événement minimal utile

Un événement opérationnel nécessite généralement l’heure, le type, un identifiant de déploiement ou d’exécution qui ne soit pas celui d’une personne, la version déclarée, la classe de plateforme, la révision de l’application, la classe de parcours, le résultat et un code d’erreur borné. Ajoutez l’état du profil ou des permissions uniquement s’il peut changer le résultat. N’inscrivez pas par défaut les URL complètes, le texte des pages, les cookies, les en-têtes d’autorisation, les corps de requête ou les captures.

Champ	Utilité	Limite de vie privée
Heure et durée	Ordre et latence	Précision temporelle minimale
Identifiants d’exécution	Corréler une exécution autorisée	Identifiants opaques, sans identité encodée
Version et classe de plateforme	Rejouer une configuration	Ni personne ni attestation de sécurité
Classe de parcours et résultat	Action produit et régression	Préférer une étiquette à une URL complète
Classe et message d’erreur borné	Triage	Masquer tokens, texte, en-têtes et données personnelles

Consignez des transitions comme launch_started, context_ready, journey_passed ou journey_failed, plutôt qu’un flux continu de chaque appel. Un échec doit décrire la branche visible et le repli proposé, sans transformer un symptôme en cause racine.

Traiter les signaux d’empreinte comme sensibles

Les API du navigateur peuvent exposer la langue, l’écran, le matériel, le stockage, le réseau et le rendu. Le guide d’empreinte du W3C explique que leur combinaison augmente la possibilité de liaison. Le guide vie privée et sécurité de MDN invite aussi à examiner ce qu’un site peut observer.

Ne copiez pas les propriétés navigator, les résultats canvas, les polices, WebGL, les client hints, les métriques d’écran ou les mesures de temps dans les journaux, sauf si une question documentée exige l’un de ces éléments. Une capacité peut être consignée grossièrement : « disponible » ou « repli affiché ». Une collection stable entre versions, parcours et exécutions peut devenir une empreinte.

Ne transformez pas l’identifiant de déploiement en identité durable du navigateur. Faites tourner les identifiants selon le but et la durée de conservation. Si un diagnostic requiert une capture ou une trace, placez l’artefact masqué dans un espace contrôlé et conservez dans l’événement seulement son type, son responsable, son expiration et sa référence.

Séparer navigateur et noyau

Le navigateur expose les comportements de la plateforme Web au moyen de standards comme le standard HTML WHATWG et Permissions du W3C. Le système et le noyau implémentent les processus, l’affichage, le stockage et le réseau. Un journal peut déclarer la version du navigateur, la classe de l’hôte, le mode d’affichage et le résultat visible ; il ne peut pas déduire l’état complet du noyau à partir d’une observation de page.

« La demande de permission n’est pas apparue dans ce profil » est une observation. « Le noyau a bloqué la permission » est une hypothèse qui exige une comparaison contrôlée. BotBrowser peut répéter une exécution autorisée entre versions, profils, parcours et plateformes déclarés, mais ne prouve ni la cause d’une branche absente ni la sécurité du noyau.

Réduire conservation et accès

Définissez une finalité et une expiration pour chaque classe de journal. Conservez plus longtemps la santé de lancement et les métriques agrégées que les diagnostics détaillés. Supprimez ou archivez les traces après la fenêtre de revue, limitez l’accès par rôle et auditez les artefacts contenant du contenu de page ou des identifiants. Un résumé destiné aux utilisateurs peut donner le résultat et le contexte sans inclure le détail de la trace.

Avant export, retirez cookies, en-têtes, tokens, paramètres, identifiants, noms privés, texte saisi et origines sans rapport. Une transformation stable n’est pas toujours une anonymisation : elle peut encore relier des événements. Si une valeur ne change pas l’action suivante, omettez-la.

Question : le déploiement déclaré a-t-il atteint la branche attendue ?
Contexte : version, plateforme, application, classe de parcours, état du profil.
Observation : résultat visible, durée bornée et nombre d’exécutions.
Vie privée : contenu, identifiants, secrets et origines exclus.
Incertitude : conditions non contrôlées et causes non établies.
Action : publier, utiliser une alternative sûre, refaire un contrôle borné ou enquêter.
Expiration : date ou événement rendant le diagnostic périmé.

Pour un échec intermittent, notez numérateur, dénominateur, méthode de réinitialisation et fenêtre. Pour comparer des versions, gardez application, parcours, données et profil constants et ne changez qu’une dimension. Une comparaison indique une frontière à étudier ; elle n’établit pas à elle seule la causalité.

Une fiche de revue doit garder le contexte déclaré, le résultat visible, la date d’expiration et le responsable de la décision. Si le résultat reste inconnu, indiquez la condition non contrôlée et une seule vérification bornée. L’opérateur suivant peut ainsi agir sans reconstruire tout l’historique de navigation.

Lorsqu’une revue passe à une autre équipe, transmettez le schéma, l’assertion visible et la règle d’expiration, pas le contenu de page sans rapport. Une enquête plus large doit avoir sa propre finalité, sa liste d’accès et son délai.

Décrire les capacités et limites de BotBrowser

BotBrowser sert aux vérifications autorisées et répétables de déploiements, avec versions, profils, parcours et données synthétiques déclarés. Il peut soutenir une comparaison et conserver le résultat visible utile au propriétaire produit. Il ne décide pas ce qu’un site conserve, ne rend pas une valeur anonyme, n’identifie pas un visiteur, ne remplace pas la revue vie privée et ne prouve pas la sécurité d’un noyau ou d’un service tiers.

Utilisez WebDriver, HTML, Permissions et le guide vie privée de MDN pour les définitions publiques. Écrivez « non testé » pour l’inférence d’identité, le comportement universel, la conservation par des tiers et la certification de sécurité. Pour valider une version, consultez la validation des versions du navigateur ; pour isoler les tests, consultez les tests d’automatisation et d’isolation ; pour revoir les profils et permissions, consultez la migration de profil et le consentement.

Sources

• W3C WebDriver
• Guide d’empreinte du W3C
• W3C Permissions
• Standard HTML WHATWG
• Vie privée et sécurité sur MDN

Réexaminez les champs, accès, durées de conservation, sources et contexte déclaré lorsque la décision produit change.