Revoir la confidentialité du navigateur avant la mise en production

BotBrowser peut rejouer un parcours autorisé avec une version, un profil, une route et une assertion visible déclarés. Il ne peut pas déduire le consentement, identifier des personnes, décider de la légalité, contrôler la conservation d’un service, prouver une suppression côté serveur ni garantir l’accès de tiers. Cette limite doit précéder toute revue de mise en production.

TL;DR

Examinez la pratique de données modifiée, le contrôle de l’utilisateur, la conservation, l’accès et le responsable. Utilisez les Privacy Principles du W3C, la RFC 6973, MDN et la documentation officielle du navigateur. Une observation contrôlée étaye une affirmation étroite ; elle ne prouve ni conformité, ni anonymat, ni suppression, ni résultat universel.

Sommaire

• Définir le périmètre
• Relier la politique aux sources publiques
• Utiliser une preuve navigateur bornée
• Conclusion pratique

Définir le périmètre

Commencez par le changement visible : permission, stockage, télémétrie, fonction intégrée ou règle de conservation. Nommez l’observateur et la finalité. « Le navigateur est privé » n’est pas vérifiable. « Cette version conserve une préférence synthétique dans la portée documentée, offre une réinitialisation et supprime le dossier au terme indiqué » l’est, car le comportement et le responsable sont nommés.

Tracez le flux de la page vers le navigateur, le service, le support et la suppression. Distinguez ce que le produit contrôle de ce qui appartient au navigateur, au réseau ou à un tiers. Consultez la confidentialité entre surfaces et les affirmations de confidentialité.

Relier la politique aux sources publiques

Les Privacy Principles du W3C cadrent acteurs, finalité et proportionnalité ; la RFC 6973 fournit le vocabulaire de liaison et de détectabilité ; MDN Privacy et la documentation officielle décrivent permissions, stockage et protections. Ces sources n’homologuent pas une version produit.

Élément	Preuve et responsable	Limite de décision
Finalité	Clause publique ; produit	Nécessaire et proportionnée, sinon réviser
Contrôle	Interface et permission ; accessibilité	Compréhensible, utilisable, réinitialisable
Conservation	Durée et trace de suppression ; service	Durée et accès explicites
Navigateur	MDN et fixture synthétique ; version	Seulement le contexte déclaré

Utiliser une preuve navigateur bornée

Gardez le fixture minimal : une valeur synthétique, une route, un état de permission et une assertion visible. Notez version, profil, langue, résultats attendu et observé, révision de source et date. N’ajoutez ni compte, ni identifiant client, ni inventaire matériel large. Un fait serveur relève du responsable du service, séparément du reçu navigateur.

« La valeur est isolée dans ce contexte neuf » est une observation utile. « Aucun site ne peut corréler l’utilisateur » ne l’est pas. « La suppression a été demandée » ne signifie pas « toutes les copies sont supprimées ». Marquez inconnu, conditionnel ou hors périmètre.

Limite de capacité de BotBrowser

BotBrowser stabilise les entrées déclarées et rejoue des parcours autorisés. Il ne décide ni consentement ni légalité, ne contrôle pas la conservation, ne prouve pas la suppression, n’identifie personne et ne remplace pas les standards ni la gouvernance. Un profil ou un proxy n’autorise pas l’accès d’un tiers.

Conclusion pratique

Publiez uniquement l’affirmation soutenue par les preuves. Le dossier nomme le changement, la source, le contrôle, le déclencheur de conservation, le responsable, le résultat, les exclusions et la date de revue. Si une condition manque, reportez l’affirmation ou rendez-la conditionnelle. La revue est terminée quand un autre lecteur comprend ce qui a été testé, ce qui reste inconnu et qui doit revoir le dossier.

Questions pour les responsables de la mise en production

La première question est de savoir si le changement est réellement nouveau. Une version peut modifier une demande de permission, la portée du stockage, un parcours de secours, une requête réseau ou la durée de conservation d’un reçu. Comparez les parcours ancien et nouveau et repérez où les données sont créées, lues, transmises, combinées, conservées ou supprimées, sans exiger de détails privés du code.

La deuxième question porte sur la finalité. « Améliorer l’expérience » ne suffit pas à justifier une propriété du navigateur. Indiquez la décision qui nécessite la donnée et l’observation minimale qui peut l’étayer. Un repli de compatibilité peut vérifier la disponibilité d’une fonction, pas tout l’inventaire de l’appareil. Le dossier de version décrit le bénéfice et la limite, tandis que le responsable du service confirme la finalité.

La troisième question concerne le choix de l’utilisateur. Une permission peut être refusée, un réglage réinitialisé et une durée de conservation écoulée. Les contrôles doivent rester compréhensibles au clavier, avec lecteur d’écran et avec zoom. Vérifiez le libellé, le message, le focus et le repli, en distinguant un état indisponible d’un état refusé.

La quatrième question fixe la fin de la frontière navigateur. La page peut observer un état local, demander une permission et envoyer une requête ; le service peut la conserver, la relier à un compte ou la partager. Attribuez ces questions au responsable compétent et gardez durée, accès et suppression séparés du reçu navigateur.

Fiche de revue de version

Une ligne décrit chaque pratique modifiée : affirmation claire, observateur, finalité, catégorie de données, contrôle, clause source, assertion synthétique, déclencheur de conservation, responsable et condition de nouvelle revue. Étiquetez l’état documenté, observé, conditionnel, inconnu ou hors périmètre. Gardez les valeurs synthétiques courtes et n’ajoutez ni jeton, nom client, identifiant, URL privée complète ni route opérationnelle.

Standards et notes d’implémentation

Lisez le standard pour sa signification et sa modalité : « doit », « devrait » et « peut » n’ont pas le même poids. MDN et la documentation officielle précisent compatibilité, contexte sécurisé, permissions et replis ; notez la date ou la version consultée. La RFC 6973 fournit un vocabulaire, les principes du W3C cadrent acteurs et proportionnalité, et MDN décrit les API : aucune de ces sources ne certifie la conservation serveur ni la légalité universelle.

Comparaison bornée après une mise à jour du navigateur

Rejouez le même parcours synthétique après une mise à jour. Gardez route, langue, permission, profil et assertion, et ne changez que la version si c’est la question. Signalez d’abord toute différence sans lui attribuer une cause sans source ou fixture complémentaire. Arrêtez-vous lorsque la question est répondue, qu’un prérequis manque ou que l’étape suivante recueillerait des données sans rapport ; transmettez alors le point au responsable.

Communiquer la décision de mise en production

Placez la condition près de la conclusion. « La préférence est isolée dans un contexte HTTPS neuf et la réinitialisation l’efface » est vérifiable ; « le navigateur protège la vie privée » ne l’est pas. Indiquez ce que l’utilisateur peut vérifier, le contrôle à utiliser et la date d’expiration de la preuve. Le contenu public peut citer des standards et une assertion synthétique, mais ne doit pas divulguer données client, routes privées, identifiants ou instructions de contournement.

Déclencheurs d’une nouvelle revue

Réexaminez le dossier si changent le navigateur, le texte du standard, les permissions, le profil, la route, la finalité, la conservation, le sous-traitant ou la suppression ; faites de même après un incident, un problème d’accessibilité ou un signalement. Conservez l’ancien dossier et créez-en un nouveau avec la raison du changement. La chaîne utile reste changement visible, source publique, observation minimale, responsable et limite explicite.

Les états ont un sens précis : « documenté » signifie qu’une source publique décrit un comportement ou une exigence ; « observé » signifie que le fixture l’a vu avec des entrées nommées ; « conditionnel » indique qu’un prérequis était présent ; « inconnu » signifie que la preuve ne répond pas ; « hors périmètre » signifie que le service concerné échappe au test.

Ne transformez pas la fiche en export de données. Gardez les valeurs synthétiques courtes et jetables, sans jeton de session, nom de client, identifiant, métadonnée réseau brute ou URL privée complète. Si la version dépend d’une politique de navigateur administrée, notez sa classe et son responsable, pas le fichier. La preuve reste ainsi utile sans exposer une recette opérationnelle ni un environnement client.

Lisez chaque standard pour le sens et la modalité de l’exigence. « Doit », « devrait », « peut » et le comportement défini par l’implémentation n’ont pas le même poids. Conservez la date ou la version consultée. Une révision peut préciser un terme sans changer l’implémentation, ou une mise à jour du navigateur peut modifier le comportement tandis que l’exigence normative reste stable ; rendez ces possibilités visibles.

La RFC 6973 fournit le vocabulaire de liaison, de détectabilité et d’usage secondaire, mais ne rend pas le verdict produit. Les principes du W3C aident à identifier acteurs, finalités, nécessité et proportionnalité, sans décider de la légalité dans chaque juridiction. MDN décrit une API web, pas la conservation côté serveur. Gardez la source près de sa clause et distinguez toute inférence produit.

Après une mise à jour, gardez route, langue, permission, limite du profil et assertion, et ne changez que la version si c’est la question. Signalez d’abord une différence visible. Un repli modifié peut relever de la compatibilité, non d’une régression de confidentialité ; un état de permission peut refléter une politique administrée. Conservez les observations ancienne et nouvelle et nommez le responsable du suivi.

Appliquez une règle d’arrêt : arrêtez lorsque le fixture répond, qu’un prérequis manque ou que l’étape suivante recueillerait des données sans rapport. N’élargissez pas un contrôle de stockage à un inventaire de signaux et n’ajoutez pas de comptes réels parce qu’une page synthétique ne reproduit pas le service. Transmettez la question au responsable et marquez la vérification terminée à sa frontière.

Une décision peut être positive, conditionnelle, inconnue ou différée. Chacune est utile si la preuve et le responsable sont visibles. Évitez « toujours », « jamais », « invisible », « sûr », « bloqué » ou « garanti » lorsque la source et le périmètre ne les soutiennent pas. Proposez une étape sûre : relire l’explication d’une permission, utiliser la réinitialisation documentée ou contacter le responsable de la conservation.

Planifiez une nouvelle revue si changent navigateur, spécification, politique de permission, classe de profil, route, finalité, durée, sous-traitant ou suppression. Faites de même après un incident, une découverte d’accessibilité ou un signalement indiquant que le contrôle échoue. Gardez l’ancien dossier et expliquez pourquoi la décision change ou reste la même.

Conservez liens, version, nom du fixture, assertion attendue, responsable et date. Rejouer le même petit parcours permet de placer les observations côte à côte. L’utilisateur doit comprendre pourquoi une permission est demandée, la refuser sans perdre une fonction sans rapport et retrouver ensuite la réinitialisation ou la suppression.

Vérifiez les valeurs par défaut et la récupération : une modification silencieuse touche chaque nouvel utilisateur, tandis qu’un choix explicite laisse décider. Testez explication initiale, refus et réinitialisation après redémarrage, sans invites répétées ni nouvelle tentative cachée. Politique et interface forment une expérience : la première nomme catégorie, finalité, durée, rôles et contact ; la seconde montre le choix et l’état.

L’accessibilité fait partie de la décision de confidentialité. Vérifiez l’annonce des états, la visibilité du focus, un signal autre que la couleur et des noms significatifs pour les contrôles. Testez séparément permission refusée et indisponible. Si la preuve est incomplète, gardez cet état : une durée inconnue crée une tâche côté service, et un désaccord entre documentation et observation conserve les deux dossiers avec la question à résoudre.

Faites une courte passation : changement, observation, source publique, éléments non testés et date de revue. Elle peut pointer vers un réglage documenté ou un reset synthétique, mais ne doit jamais exiger profil client, secret de session ou route opérationnelle non publiée. Tenez aussi un journal des versions, politiques et fixtures ; signalez d’abord une différence et assignez le suivi avant d’en supposer la cause.

Sources

• W3C Privacy Principles
• RFC 6973 Privacy Considerations
• MDN Privacy and security
• BotBrowser advanced features