Fingerprinting des permissions : vie privée et cohérence

Le schéma distingue trois entrées souvent confondues. Le profil actif fournit l'identité du navigateur. Les paramètres et règles fournissent la décision actuelle du site. L'utilisateur ou l'automatisation autorisée décide si l'accès est accordé. Un résultat cohérent respecte les trois, mais le profil ne remplace jamais le consentement.

Pourquoi l'état des permissions peut servir au pistage

Les systèmes de permissions répondent à des besoins normaux. Une carte veut savoir si la localisation a déjà été refusée avant d'afficher un bouton. Une application de réunion doit présenter la bonne configuration de caméra et de microphone. Un service de notifications évite de solliciter à nouveau un utilisateur après un blocage. Ces usages sont légitimes.

Le même état observable peut contribuer au fingerprinting. Le comportement ne dépend pas uniquement du site actuel. Les valeurs par défaut de la famille de navigateur, l'intégration à la plateforme, les règles administrées, l'âge du profil, le mode de navigation et le cycle de vie du contexte peuvent modifier ce qu'une page observe. Des scripts de pistage peuvent combiner ce comportement général avec d'autres traits pour réduire le nombre d'environnements possibles ou relier des visites.

Le problème ne se résume pas à une liste d'éléments autorisés ou refusés. Quatre propriétés générales comptent :

• Disponibilité : la capacité liée aux permissions existe de la manière attendue pour la famille et la version du navigateur.
• Comportement de l'état : un site neuf, un site refusé et un site approuvé suivent le cycle normal du navigateur.
• Portée d'exécution : les pages et tâches d'arrière-plan du même contexte restent alignés.
• Cycle de vie : un état ne change qu'après une décision réelle de l'utilisateur, du site, de l'outil d'automatisation ou d'une règle.

Le résultat pratique est clair : les permissions doivent correspondre au profil sélectionné, rester cohérentes dans le contexte actif et continuer de respecter les décisions d'accès réelles.

Effacer les cookies ne réinitialise pas toutes les permissions

La suppression des cookies enlève une catégorie d'état. Les décisions de permission peuvent être enregistrées dans les données du profil et suivre un autre cycle de vie. Une équipe qui renouvelle les cookies tout en réutilisant le même répertoire persistant ne doit pas supposer que chaque origine est revenue à un premier passage.

Cette distinction change les tests. Un test d'acceptation propre, un test d'utilisateur récurrent et un test de session persistante représentent trois historiques différents. Ils doivent utiliser une politique explicite de répertoires de données, pas la suppression des cookies comme réinitialisation universelle.

La navigation privée n'est pas une stratégie complète

La navigation privée modifie le stockage et le cycle de vie, sans rendre chaque surface uniforme. Elle peut aussi créer un comportement différent d'un profil normal. Pour une validation autorisée, la bonne question consiste à vérifier que le mode choisi correspond au parcours prévu et reste cohérent en interne.

La confidentialité réseau ne contrôle pas l'état local

Un proxy ou un VPN change le routage réseau. Il ne décide pas si un site accède à la caméra, si une invite est gérée par une règle, ou comment le BrowserContext actif présente une ancienne décision. La confidentialité réseau et la cohérence des permissions sont deux couches distinctes.

Ce que BotBrowser maintient cohérent

BotBrowser utilise le profil chargé pour aligner le comportement des permissions avec la famille de navigateur et de plateforme sélectionnée. Cette correspondance vaut pour les profils de lancement et pour ceux attribués à des BrowserContexts séparés. Les décisions côté page et côté navigateur suivent le contexte actif au lieu d'une valeur par défaut du système hôte.

Le premier avantage est la portabilité. Un profil peut passer entre les environnements hôtes pris en charge sans hériter de caractéristiques accidentelles de la machine. Le comportement visible par le site reste lié à la famille du profil.

Le deuxième avantage concerne les exécutions avec et sans interface. Le même profil peut conserver sa politique dans les deux modes. L'absence de fenêtre visible ne doit pas créer une identité de permission indépendante. Les décisions d'accès réelles nécessitent toujours une politique d'automatisation appropriée.

Le troisième avantage est l'isolation par contexte. Chaque BrowserContext suit son profil si celui-ci est affecté avant la première page ou la première tâche d'arrière-plan. Un contexte ne devient pas la source d'identité d'un autre.

Le consentement et les règles du site restent déterminants

La cohérence des permissions n'approuve pas silencieusement un accès sensible. Si l'utilisateur, les paramètres, l'outil d'automatisation, une règle administrée ou le site refuse l'accès, le refus reste effectif. Le profil décrit un comportement de famille de navigateur. Il ne constitue pas une autorisation générale.

Elle ne remplace pas non plus les tests applicatifs. Une réunion doit toujours tester caméra et microphone. Une carte doit tester la localisation. Un parcours de notifications doit vérifier l'expérience utilisateur. BotBrowser fournit une base d'identité cohérente afin que ces tests visent le profil prévu plutôt que des traits accidentels de l'hôte.

Cette distinction aide à planifier un déploiement. L'automatisation de l'accès et la protection contre le fingerprinting répondent à des besoins différents. La cohérence fondée sur le profil est utile lorsque le comportement doit rester prévisible sans affaiblir le modèle de sécurité normal.

Charger le profil avant la navigation

La cohérence est automatique lorsqu'un profil correspondant est chargé avant la navigation. Utilisez un répertoire de données distinct quand le parcours exige un état neuf.

botbrowser \
  --bot-profile="/path/to/profile.enc" \
  --user-data-dir="/path/to/profile-data"

Le paquet de profil doit correspondre à la version majeure de BotBrowser. Le comportement du navigateur évolue. Un profil préparé pour une autre version majeure peut ne plus représenter correctement la famille active.

Pour un profil par processus, la commande de lancement suffit généralement. Réutilisez le même user-data-dir lorsque l'historique doit persister. Utilisez un nouveau répertoire pour un parcours de premier passage. Ne partagez pas un répertoire persistant entre des identités sans rapport.

Lancement avec Playwright

Chargez le profil au démarrage, puis utilisez les contrôles normaux de Playwright pour les tests applicatifs autorisés.

const { chromium } = require('playwright-core');

const browser = await chromium.launch({
  executablePath: '/path/to/botbrowser',
  headless: true,
  args: [
    '--bot-profile=/path/to/profile.enc',
    '--user-data-dir=/path/to/profile-data',
  ],
});

const context = await browser.newContext({ viewport: null });
const page = await context.newPage();
await page.goto('https://your-authorized-test.example');

Les permissions de l'application restent sous le contrôle de Playwright et de la politique du navigateur. Conservez ces décisions explicitement dans les fixtures. Les échecs deviennent plus simples à expliquer et le profil ne se transforme pas en politique d'accès implicite.

Lancement avec Puppeteer

Puppeteer suit la même règle : charger le profil avant la première navigation et garder une propriété claire de l'état.

const puppeteer = require('puppeteer-core');

const browser = await puppeteer.launch({
  executablePath: '/path/to/botbrowser',
  headless: true,
  args: [
    '--bot-profile=/path/to/profile.enc',
    '--user-data-dir=/path/to/profile-data',
  ],
});

const page = await browser.newPage();
await page.goto('https://your-authorized-test.example');

Utilisez ces exemples avec des applications que l'équipe possède ou qu'elle est autorisée à évaluer. Vérifiez le parcours d'accès visible et les contrôles normaux du navigateur.

Cohérence par BrowserContext

L'automatisation multi-contexte modifie la propriété de l'état. Chaque BrowserContext peut représenter un profil, une session et un historique de permissions séparés. Le profil doit être attribué avant la création de la première page, de la première tâche d'arrière-plan ou d'une autre cible.

La documentation publique Per-Context Fingerprint fournit la séquence d'intégration actuelle. Suivez-la plutôt que de modifier les paramètres d'identité après le démarrage du contexte. Une modification tardive peut mélanger ancien et nouvel état, ce qui convient mal à la validation de confidentialité et complique le diagnostic.

Un cycle fiable suit cet ordre :

1. Créer le BrowserContext.
2. Attribuer immédiatement son profil correspondant.
3. Appliquer la politique explicite de permissions du test.
4. Créer la première page.
5. Conserver les paramètres d'identité jusqu'à la fermeture du contexte.

Cette séquence attribue à chaque contexte un propriétaire d'identité et une politique d'accès clairs.

Contextes persistants et jetables

Les contextes jetables conviennent aux tests qui exigent une relation neuve avec le site à chaque exécution. Les contextes persistants conviennent aux choix mémorisés, à l'authentification et aux parcours d'un utilisateur récurrent. Aucun modèle n'est toujours supérieur.

• Utilisez un contexte jetable pour le consentement initial, l'accueil et les régressions propres.
• Utilisez un contexte persistant quand le parcours doit conserver les choix précédents.
• Séparez le stockage de chaque identité, même pour une même famille de navigateur.
• Notez si le test commence dans un état neuf, autorisé, refusé ou administré.

Ce relevé est plus utile qu'une capture seule. Il explique pourquoi une invite apparaît, pourquoi un accès manque et si l'exécution suivante devait mémoriser la décision.

Constituer des preuves à partir de parcours réels

La validation peut utiliser les pages de test de l'équipe et l'interface normale du navigateur.

Choisissez quelques parcours représentatifs du déploiement réel. Couvrez les familles de profils, les modes d'exécution, le modèle de contexte, l'historique du site et les environnements hôtes utilisés par l'équipe. Une application de réunion peut couvrir les décisions liées à la caméra et au microphone. Une application interne peut couvrir la localisation. Une page de notifications peut couvrir le cycle de l'invite. Ces parcours fournissent des preuves plus utiles qu'un inventaire étendu des surfaces du navigateur.

Conservez quatre éléments :

1. Version de BotBrowser et version du paquet de profil correspondant.
2. Famille du profil et environnement hôte.
3. État initial du site et décision prévue par le test.
4. Résultat observé dans l'application et l'interface du navigateur.

Les attentes doivent rester au niveau de la capacité. Par exemple, « le refus reste effectif après redémarrage » est un résultat client approprié.

Régressions de version

Les mises à niveau du navigateur, de l'outil d'automatisation, des règles et des profils peuvent affecter les permissions. Ajoutez des parcours représentatifs à la qualification de version lorsqu'ils comptent pour le produit.

Comparez le même parcours interne entre la version approuvée et la candidate. Une invite modifiée, une décision mémorisée perdue, une différence entre modes ou un comportement traversant une frontière de BrowserContext mérite une analyse.

Ne normalisez pas chaque différence automatiquement. Les familles de navigateurs évoluent. Le résultat correct correspond au profil actuel tout en conservant la sémantique normale d'accès.

Problèmes de configuration courants

Profil chargé trop tard

Si la première page ou la première tâche d'arrière-plan démarre avant le profil, l'état initial peut appartenir à l'environnement par défaut. Fermez le contexte et créez-en un nouveau dans le bon ordre. Ne réparez pas une identité active en modifiant ses paramètres sur place.

Versions incompatibles

Utilisez un paquet de profil préparé pour la version majeure installée. Quand les versions diffèrent, plusieurs comportements de famille peuvent ne plus être alignés. Mettez à jour le navigateur et le profil ensemble, puis répétez le parcours autorisé.

Le site reste refusé

Vérifiez les paramètres du site, les réglages du contexte d'automatisation, l'historique du répertoire persistant et les règles administrées. La cohérence du profil ne remplace pas un refus explicite. Modifiez-le uniquement si le test autorisé l'exige.

Invite visible seulement en mode avec interface

Un système sans interface ne présente pas de surface d'interaction visible. Configurez la décision réelle par l'outil d'automatisation ou une règle administrée, puis vérifiez le résultat applicatif. L'absence d'invite visible ne signifie pas que l'accès est accordé.

Des contextes semblent partager leur comportement

Confirmez que chaque BrowserContext possède sa configuration et reçoit son profil avant sa première cible. Vérifiez aussi si les fixtures réutilisent volontairement stockage ou permissions. Une initialisation partagée peut ressembler à une fuite du navigateur.

L'hôte semble influencer le résultat

Répétez le même profil et le même parcours sur un autre hôte pris en charge. Gardez constantes versions, historique du site et politique de test. Si le résultat visible change, rassemblez les informations de déploiement et contactez le support. N'ajoutez pas de remplacement JavaScript, car il créerait une seconde source d'état.

Propriété de l'état en production

L'état des permissions doit avoir un propriétaire clair dans chaque déploiement. BotBrowser lie le comportement de la famille du navigateur à un profil versionné plutôt qu'à une valeur accidentelle de l'hôte. Le même modèle s'applique avec et sans interface, et chaque BrowserContext reçoit son profil avant sa première cible. Les refus, les choix utilisateur et les règles administrées restent effectifs pendant tout le cycle.

Les équipes d'exploitation maintiennent le navigateur et le paquet de profil comme une même paire de version. Aucun script distinct n'est nécessaire pour chaque permission, mais les décisions d'accès réelles restent définies dans le test applicatif ou la règle administrée. Cette séparation évite les conflits entre des réponses figées et les paramètres du site, tout en maintenant le consentement distinct de la cohérence d'identité.

BotBrowser convient particulièrement aux équipes qui utilisent des profils versionnés, plusieurs familles d'hôtes, les modes avec et sans interface, ou plusieurs identités isolées par BrowserContext. Pour un navigateur local unique où il suffit de cliquer sur une invite, cette capacité seule apporte moins de valeur. Elle devient importante lorsque le comportement doit rester prévisible entre déploiements, versions et contextes.

Pratiques de confidentialité et d'exploitation

• Utilisez un répertoire persistant par identité durable.
• Chargez le profil avant la navigation et les tâches d'arrière-plan.
• Faites correspondre les versions majeures du navigateur et du profil.
• Séparez les décisions d'accès de l'identité de fingerprinting.
• Revalidez les parcours après une mise à jour du navigateur, du profil, de l'outil d'automatisation ou des règles.
• Ne conservez que les preuves nécessaires à la QA et au support.
• Limitez les tests aux applications possédées ou évaluées avec autorisation.

L'historique des permissions peut être sensible. Les journaux doivent être contrôlés et conservés selon la même politique que les autres données de profil. Ne placez pas les profils, répertoires utilisateur ou rapports de permission dans des artefacts CI publics.

État, stockage et réseau

Le comportement des permissions peut contribuer à une empreinte, car il reflète la famille du navigateur, l'historique du profil, les règles et le cycle du contexte. Le but est un comportement cohérent, pas une réponse fixe pour tous les sites. Un profil neuf peut toujours suivre les attentes normales de sa famille, des règles et de l'application. Il faut donc valider le parcours prévu plutôt qu'imposer un état neutre universel.

Les cookies, l'historique des permissions et le routage réseau ont des cycles distincts. Effacer les cookies ne réinitialise pas nécessairement les permissions. Un proxy protège le routage, mais ne définit pas les décisions locales du navigateur. Les tests neufs et récurrents nécessitent donc une stratégie explicite pour le répertoire de données et pour le réseau.

Exécution sans interface et contextes multiples

BotBrowser n'accorde pas automatiquement l'accès à la caméra, au microphone ou à la localisation. Les choix utilisateur, paramètres, outils d'automatisation, états du site et règles administrées contrôlent toujours l'accès. Aucun paramètre distinct n'est requis, car la cohérence suit le profil chargé et compatible avec la version.

Le même modèle s'applique avec et sans interface. Sans interface visible, les tests autorisés définissent les décisions d'accès via l'outil d'automatisation ou une règle administrée. Dans une exécution à contextes multiples, chaque BrowserContext suit son profil si celui-ci est appliqué avant la première cible. L'historique du site et les paramètres d'automatisation doivent également rester isolés.

Transmettre une différence reproductible

Utilisez une application interne ou une page de test de l'équipe, les contrôles normaux du navigateur et des décisions gérées par l'outil d'automatisation. Comparez des parcours représentatifs entre hôtes et modes. Notez la version du profil, l'état initial, la décision prévue et le résultat applicatif.

Contactez l'assistance lorsqu'un profil compatible, chargé avant la navigation, produit des résultats visibles différents entre hôtes pris en charge ou BrowserContexts avec le même historique et la même règle d'accès. Indiquez les versions et les étapes sans transmettre d'identifiants de production ni de données de profil sans restriction.

Appliquer la politique au déploiement

La documentation sur la cohérence des permissions décrit la configuration prise en charge. Alignez-la avec la gestion des profils et les profils par contexte. La présentation du fingerprinting replace l'état des permissions parmi les autres signaux de confidentialité.

BotBrowser est destiné à la protection de la vie privée, aux tests de compatibilité et à la recherche autorisés. La cohérence des permissions maintient l'identité sélectionnée tout en conservant les contrôles d'accès normaux du navigateur.