Frontières d’identité du navigateur pour les comptes d’équipe

BotBrowser peut rejouer un parcours autorisé de compte d’équipe dans un context et un profile déclarés. Il ne peut pas accorder l’accès, partager des identifiants en sécurité, contourner les règles d’origin ou de permission, ni prouver que deux comptes ne sont pas liés. La séparation est une limite de propriété et de confidentialité, pas une méthode de contournement.

Attribuer la propriété avant d’ouvrir un context

Indiquez le responsable, le but, les opérateurs autorisés, le contact de récupération et la date de revue. Un compte d’équipe doit avoir un responsable identifiable. Précisez si le context sert à la production, à un fixture synthétique, au support ou à une revue. Ne mettez pas d’identifiants personnels dans un script partagé et ne prenez pas un profile pour une preuve d’autorisation.

Séparer le context et l’état du site

Les cookies, Web Storage, IndexedDB, Cache Storage et enregistrements de service worker sont des états du navigateur liés à l’origin. Un BrowserContext ou répertoire de données distinct sépare l’état local, mais ne transfère pas la propriété serveur, ne révoque pas une session distante et n’efface pas les journaux. WHATWG HTML et MDN Storage API décrivent ces limites, pas un format d’identité d’équipe portable.

Un compte doit avoir un but et un responsable. Gardez les fixtures de test synthétiques. Ne copiez jamais cookies, mots de passe, tokens ou exportations de stockage entre comptes. Lors d’une déconnexion ou d’un retrait, distinguez le nettoyage local de la révocation serveur et notez l’action réellement terminée.

Appliquer le moindre privilège et des permissions visibles

Accordez seulement le rôle et les permissions nécessaires. Une demande de permission est une décision de l’utilisateur, pas une preuve de propriété. Réexaminez l’accès si l’opérateur, le but, la destination ou la conservation change. Les W3C Privacy Principles soutiennent la limitation de finalité et la minimisation; la politique relève du propriétaire de l’application.

Tenez un registre du responsable, opérateur, but, portée, expiration et retrait. Examinez séparément extensions, téléchargements, notifications, presse-papiers et appareils. Nettoyer un context local ne rend pas un rôle serveur étendu conforme au moindre privilège.

Passation, récupération et retrait

Une passation révoque l’opérateur sortant, accorde l’accès via le parcours approuvé du service et confirme la portée du nouvel opérateur. Ne remettez pas une archive de profile à la place de l’administration du compte. Conservez seulement la preuve nécessaire, jamais les identifiants ou le contenu privé. Utilisez les états: planifié, accès révoqué, état local effacé, action serveur en attente, terminé.

Si un context est mélangé ou qu’un identifiant est exposé, arrêtez l’usage concerné, prévenez le responsable, faites une rotation par le parcours approuvé et créez un context propre. Ne réparez pas discrètement une archive partagée pour la déclarer isolée.

Capacité et limite de BotBrowser

BotBrowser peut rejouer un parcours autorisé avec un profile et un context déclarés et comparer des résultats visibles entre versions approuvées. Il ne décide pas de la propriété, n’accorde ni ne révoque les rôles serveur, ne contourne pas origin ou permissions, ne garantit pas l’effacement des données distantes et ne rend pas des identifiants partagés sûrs. Associez ses résultats aux registres d’accès et à la revue de confidentialité.

Liste pratique

• Nommez un responsable et le but du context.
• Séparez cookies, stockage, cache, workers, permissions et téléchargements.
• Utilisez le moindre privilège avec expiration et retrait.
• Distinguez nettoyage local et révocation serveur.
• Lors d’une passation ou exposition, révoquez, faites tourner et recréez un context propre.

À lire: Nettoyage des données de site et limites de compte et Isolation du navigateur multi-compte.

Avant d’ouvrir un compte partagé, vérifiez la destination, le rôle attendu et la durée de conservation. Si un élément manque, arrêtez le parcours et consultez le responsable.

Décrivez les échecs comme des observations limitées. Notez la version, le contexte et le résultat visible, sans transformer un refus de permission en affirmation sur tout le compte.

Lors du partage de preuves, retirez les identifiants, les URL privées et les valeurs de stockage. Gardez la version, le but, le résultat et la confirmation du service.

Séparez l’observation du navigateur de la confirmation du service. Un résultat visible ne prouve pas qu’une session distante a été révoquée.

Réexaminez la conservation lorsque l’opérateur ou le but change. Le nettoyage local et la suppression côté serveur doivent avoir des états différents.

Si personne ne peut expliquer qui approuve l’étape suivante, mettez le parcours en pause et adressez la décision au propriétaire.

Une frontière claire permet de corriger l’accès sans exposer l’état privé du navigateur.

Sources

WHATWG HTML Web Storage, MDN Storage API, W3C Privacy Principles, NIST SP 800-63B et isolation multi-compte BotBrowser.