Navigation privée et fingerprinting : pourquoi elle ne suffit pas
La navigation privée efface les cookies mais laisse l’empreinte du navigateur intacte. Voici pourquoi elle ne suffit pas et comment comparer sessions privées et normales.
BotBrowser Team
Vous préférez la doc produit maintenue ?
Cet article a une page équivalente dans le centre de documentation. Utilisez les docs pour le flux canonique, les flags à jour et la référence durable.
La navigation privée, que Chrome appelle Incognito et Edge InPrivate, est souvent présentée comme un moyen de naviguer sans être suivi. La fonction est plus limitée. Une fenêtre privée empêche le navigateur de conserver en local l’historique, les cookies, les données de sites et les saisies de formulaires une fois la session terminée. Elle ne change pas l’adresse IP qu’un site voit, et elle ne change pas non plus les signaux que le navigateur expose sur son matériel et son logiciel tant qu’une page est ouverte. La page d’aide de Chrome indique elle-même qu’Incognito ne vous rend pas invisible et que les sites que vous visitez ainsi que les organisations qui gèrent votre réseau peuvent encore observer votre activité.
Les sections ci-dessous séparent les effets locaux du mode privé des effets qui se produisent côté site. Elles traitent des différences de stockage et d’API que le mode privé peut ajouter, de la raison pour laquelle les signaux centraux de l’empreinte restent identiques, d’une comparaison pratique entre une session normale et une session privée qui utilisent le même profil, et de choix d’isolation qui fonctionnent sans mode privé. Elles précisent aussi ce que BotBrowser couvre et ce qu’il laisse à votre charge.
Regarder la vidéo
Cette vidéo en anglais compare une fenêtre normale et une fenêtre privée (Incognito) dans Chrome, sur des machines Ubuntu et Windows, avec une page de laboratoire locale. Ce qui diffère entre les deux contextes est la couche de stockage, alors que les valeurs de matériel, de plateforme, de langue et de version que la page lit restent identiques. Une seconde page de laboratoire montre un cookie posé à la première visite absent à la seconde visite dans un contexte privé neuf, tandis que la signature du laboratoire se répète. Elle montre ce que ces machines ont renvoyé, pas un verdict pour tous les navigateurs ou sites. L’audio est en anglais.
TL;DR
- Le mode privé supprime l'état local à la fermeture, mais ne change ni l'IP ni les signaux d'empreinte de l'appareil.
- Comparez
navigator.storage.estimate(), les API de page et les valeurs d'empreinte avec le même--bot-profileavant d'attribuer une différence au mode. - Utilisez un
--user-data-dirséparé pour isoler les données ; l'identité réseau et l'état du compte exigent des décisions distinctes.
Sommaire
- Ce qu’une fenêtre privée change et ce qu’elle laisse intact
- Différences de stockage et d’API qu’un site pourrait observer
- Pourquoi les signaux de l’empreinte restent identiques en mode privé
- Comparer une session normale et une session privée pas à pas
- Choisir une isolation qui ne dépend pas du mode privé
- Ce que BotBrowser couvre et ce qui reste hors de son champ
- Conclusion pratique
Ce qu’une fenêtre privée change et ce qu’elle laisse intact
| Surface | Résultat de la session privée |
|---|---|
| Historique local et cookies | Supprimés à la fermeture de la dernière fenêtre privée |
| Adresse réseau | La même IP et la même route restent visibles |
| Compte | Le service reconnaît toujours un compte connecté |
| Signaux de l’appareil | Les valeurs du matériel et du navigateur restent disponibles |
Une fenêtre privée démarre avec une session vide et temporaire. Elle ne charge pas les cookies, le stockage local ni les connexions du profil normal, et lorsque la dernière fenêtre privée se ferme, le navigateur supprime ce que la session a créé. C’est utile sur un ordinateur partagé, pour vérifier le comportement d’une page publique sans session existante sur le site, ou pour terminer une tâche ponctuelle qui ne doit pas entrer dans l’historique habituel. Les téléchargements et les favoris ne font pas partie de ce nettoyage, pas plus que ce qu’un service a déjà enregistré sur ses propres serveurs.
La page d’aide de Chrome apporte des précisions sur ce qui change dans une fenêtre privée. Chrome ne conserve ni les données de sites ni la trace des sites visités une fois la session terminée, les cookies tiers sont bloqués par défaut et vous n’êtes pas connecté automatiquement à vos comptes. Les favoris que vous enregistrez et les fichiers que vous téléchargez restent sur l’appareil. Ce sont tous des effets locaux. Ils décrivent ce que le navigateur garde sur votre machine, pas ce qu’un site web ou un réseau peut observer pendant que vous êtes connecté.
Les limites comptent autant que l’avantage. L’adresse IP qui parvient à un site est décidée par le réseau et non par le mode du navigateur : une fenêtre privée utilise donc la même connexion que n’importe quelle autre fenêtre de cette machine. Les employeurs, les établissements scolaires et les fournisseurs d’accès qui gèrent un réseau peuvent toujours voir le trafic qui le traverse. Un site auquel vous vous connectez sait toujours qui vous êtes. Et le navigateur continue de communiquer à chaque page qu’il charge son agent utilisateur habituel, la taille de l’écran, les polices, le comportement graphique et le comportement audio, car ces valeurs décrivent l’appareil et la version du navigateur, pas la session.
- L’historique local, les cookies, les données de sites et les saisies de formulaires sont supprimés à la fin de la session privée.
- L’adresse IP, le chemin réseau et ce que peuvent observer les gestionnaires de ce réseau restent identiques.
- Un compte connecté reste connu du service tant que vous restez connecté.
- Les signaux de l’empreinte décrivent l’appareil et la version du navigateur, ils restent donc identiques.
On lit parfois « privé » comme « non corrélable ». Ce sont des propriétés différentes. Non corrélable signifierait qu’un site ne peut pas relier deux visites. Une fenêtre privée signifie seulement que la seconde visite ne reprend pas les cookies de la première. Si le même appareil présente la même empreinte lors des deux visites, un site qui collecte ces signaux peut quand même les relier sans aucun cookie. L’article sur la navigation privée au quotidien décrit le versant quotidien de cette frontière, et l’article sur ce qu’est le fingerprinting du navigateur explique les signaux eux-mêmes.
Différences de stockage et d’API qu’un site pourrait observer
| Vérification | Valeur concrète à comparer |
|---|---|
| Quota | Quota et usage de navigator.storage.estimate() |
| Stockage persistant | Requête acceptée ou refusée |
| IndexedDB | Écriture et lecture contrôlées dans les deux contextes |
| Service worker | Résultat de l’enregistrement et durée après fermeture |
Comme une session privée garde ses données dans un stockage temporaire, les navigateurs se comportent parfois un peu différemment à l’intérieur. Le guide de MDN sur les quotas de stockage et les critères d’éviction indique qu’en mode de navigation privée, que Chrome appelle Incognito et Edge InPrivate, les navigateurs peuvent appliquer des quotas différents et que les données stockées sont généralement supprimées à la fin du mode. Une page peut lire le quota et l’utilisation actuelle de son origine avec navigator.storage.estimate(). La même page de MDN précise que cette méthode renvoie une estimation et non une valeur exacte, et que les navigateurs peuvent gonfler la taille des données d’autres origines lorsqu’ils indiquent l’utilisation totale.
Le quota est la différence la plus souvent citée, mais pas la seule. Au fil des années, les navigateurs ont modifié la manière dont certaines interfaces liées au stockage répondent en mode privé. On peut citer les anciennes interfaces de système de fichiers, la façon de répondre aux demandes de stockage persistant, l’enregistrement des service workers et leur survie, ainsi que le comportement d’IndexedDB lorsqu’elle ne peut pas écrire sur le disque. Ces détails varient selon le navigateur et la version, et un comportement présent dans une version peut avoir disparu dans la suivante. Considérez toute différence de ce genre comme quelque chose qui peut exister, et non comme une règle valable partout.
Chaque navigateur fait aussi ses propres choix de quota, même hors mode privé. MDN indique des limites différentes pour Firefox, Chrome et Safari, exprimées comme des parts différentes de l’espace disque total, et précise que les chiffres dépendent de la manière dont le stockage est utilisé. Cette dispersion explique en partie pourquoi une valeur de quota isolée est un signal faible. Une petite valeur peut venir d’une session privée, d’un disque presque plein, d’une vue web intégrée ou d’un navigateur qui fixe simplement une limite plus basse.
Pourquoi cela compte-t-il pour la vie privée ? Une différence visible par une page est un signal. Si un script lit un quota plus faible que celui que le même navigateur indique d’habitude, il peut supposer que la session est privée. Cette supposition n’est ni un identifiant fort ni un test fiable, car le quota dépend de l’espace disque libre, de la version du navigateur et de la configuration du profil, de sorte que les sessions ordinaires affichent aussi une large plage de valeurs. Malgré tout, une fonction que l’on utilise pour être moins repérable ne devrait pas ajouter de différence visible qui lui soit propre.
Deux précautions permettent de garder le sujet à sa juste mesure. D’abord, une différence liée au mode privé n’identifie pas une personne. Au plus, elle place la session dans le groupe des sessions privées, qui est plus restreint que l’ensemble des sessions. Ensuite, les sites ont de nombreuses raisons légitimes de lire les chiffres de stockage, par exemple pour décider de la quantité de données à conserver pour un usage hors ligne : les lire est un comportement normal et non une preuve de suivi. L’article sur le fingerprinting du quota de stockage approfondit la manière dont ces chiffres sont utilisés et leur stabilité.
Pourquoi les signaux de l’empreinte restent identiques en mode privé
| Famille de signaux | Source extérieure au profil privé |
|---|---|
| Graphisme | Rendu et comportement de dessin de la pile navigateur/OS |
| Audio | Résultat du test audio de la version du navigateur |
| Polices | Inventaire installé et comportement de repli |
| Affichage | Dimensions de l’écran et ratio de pixels |
Une empreinte de navigateur est une combinaison de valeurs qui décrivent l’appareil et la version du navigateur. Elle comprend la façon dont la pile graphique dessine les formes et le texte, la façon dont la pile audio traite un signal de test, les polices installées, les dimensions de l’écran et le rapport de pixels, le nombre de processeurs logiques, la chaîne de plateforme et la liste des langues. Aucune de ces valeurs ne se trouve dans le dossier de profil que le mode privé remplace. Elles proviennent du matériel, du système d’exploitation et de la version du navigateur, et elles sont les mêmes que la fenêtre soit privée ou non.
C’est pourquoi une visite normale et une visite privée depuis la même machine peuvent être reliées. Imaginez que quelqu’un parcoure une boutique dans une fenêtre normale, puis ouvre une fenêtre privée et retourne dans la même boutique pour éviter les recommandations que déclencheraient les cookies. Les cookies ont disparu. L’empreinte, non. Un site qui enregistre des valeurs d’empreinte pour la prévention de la fraude ou à des fins d’analyse voit deux visites aux valeurs concordantes et peut raisonnablement les traiter comme un seul appareil.
Une empreinte est utile à un site justement parce qu’elle est stable. Une valeur qui changerait à chaque chargement de page serait inutile pour reconnaître quelqu’un : les signaux que privilégie un site sont donc ceux qui restent en place d’une session à l’autre, après un redémarrage et lors d’un changement de mode. Cette stabilité est précisément ce qui rend le mode privé inefficace face à eux. Effacer les cookies réinitialise l’état que le site avait stocké dans le navigateur. Cela ne réinitialise rien de ce que le navigateur indique sur lui-même.
Les extensions qui prétendent rétablir la confidentialité dans les fenêtres privées ont une limite semblable. Un outil qui modifie quelques valeurs dans les scripts de la page doit garder toutes les autres réponses cohérentes avec les valeurs modifiées, et ces changements peuvent constituer en eux-mêmes une anomalie visible. Une empreinte qui se contredit elle-même est souvent plus distinctive qu’une empreinte ordinaire. C’est une raison de considérer l’environnement du navigateur comme un tout et non comme une liste de valeurs indépendantes.
La conclusion pour le mode privé est simple. Il traite une seule catégorie de reconnaissance, celle qui dépend d’un état stocké comme les cookies. Il ne traite pas la reconnaissance qui dépend de ce que l’appareil et le navigateur indiquent. Lorsqu’une tâche exige de maîtriser la seconde catégorie, une fenêtre privée est le mauvais outil, et un profil choisi délibérément et cohérent en lui-même est le bon.
Comparer une session normale et une session privée pas à pas
| Variable à maintenir | Relevé avant comparaison |
|---|---|
| Navigateur et profil | Version, fichier --bot-profile et options de lancement |
| Stockage | Quota, usage et résultat du stockage persistant |
| API de page | Service worker, IndexedDB, stockage local et Cache API |
| Redémarrage | Les mêmes valeurs après fermeture de toutes les fenêtres |
Quand on veut savoir si deux sessions se ressemblent du point de vue d’une page, une comparaison écrite vaut mieux que des suppositions. Les étapes ci-dessous supposent une seule version du navigateur et un seul profil, de sorte que la seule variable est le mode de session. Utilisez une page que vous maîtrisez, ou un visualiseur d’empreintes public en lequel vous avez confiance, et gardez la même page pour les deux exécutions.
- Notez la situation de départ. Écrivez la version du navigateur, le système d’exploitation, le nom du fichier de profil et les options de lancement. Une comparaison n’a de sens que si tout cela est identique dans les deux exécutions.
- Ouvrez la session normale et lisez le quota de stockage et l’utilisation que renvoie
navigator.storage.estimate(). Notez si le stockage persistant est accordé. - Ouvrez une session privée avec le même profil et lisez les mêmes valeurs depuis la même page. Les valeurs devraient concorder, en tenant compte des variations d’utilisation dues aux données écrites pendant l’exécution. Cette concordance est attendue avec un profil BotBrowser ; un navigateur non modifié peut signaler des quotas différents en mode privé.
- Comparez la disponibilité des service workers, d’IndexedDB, du stockage local et de l’API Cache. Dans les deux sessions, chaque interface devrait être présente et répondre de la même façon à une simple écriture de test.
- Comparez les valeurs d’empreinte que rapporte votre visualiseur, comme le moteur de rendu graphique, le résultat audio, la liste des polices, les valeurs d’écran et la liste des langues. Toute différence entre les sessions devrait s’expliquer par le mode et non par un profil ou une option modifiés.
- Recommencez après un redémarrage. Fermez toutes les fenêtres, relancez avec le même profil et effectuez la même comparaison. Des résultats qui changent d’une exécution à l’autre indiquent un problème de configuration et non une propriété stable.
Lisez les résultats par catégorie. Si le quota diffère mais que les valeurs d’empreinte concordent, la différence vient de la couche de stockage. Si les valeurs d’empreinte diffèrent, vérifiez que les deux sessions utilisent le même profil et les mêmes options avant d’aller plus loin. Si les service workers s’enregistrent dans une session et pas dans l’autre, notez la version du navigateur, car un comportement normal dans un navigateur non modifié peut tout de même apparaître comme une différence dans la comparaison. Conservez les notes à côté du nom du profil afin de pouvoir y comparer la prochaine mise à jour du navigateur.
Gardez des conditions de test stables. Utilisez la même taille de fenêtre, les mêmes extensions ou aucune, et une quantité d’espace disque libre comparable, car chacun de ces facteurs peut déplacer une valeur pour des raisons étrangères au mode. Les chiffres de quota et d’utilisation sont des estimations : comparez-les d’une manière qui tolère de petites variations et considérez un écart important et reproductible entre les deux sessions comme le constat qui mérite d’être examiné.
Gardez à l’esprit les limites de cette vérification. Elle compare une session à une autre. Elle ne dit pas comment un site donné évalue une visite, et un résultat propre ne garantit pas qu’un site accepte la session. Un site peut aussi s’appuyer sur des signaux que cette vérification ne couvre pas, notamment l’adresse IP, l’historique du compte et le comportement dans la durée. Considérez une concordance comme la preuve que le mode privé n’a ajouté aucune différence supplémentaire, et rien de plus.
Consigner une comparaison que vous pourrez relire
| Champ écrit dans le fichier | Pourquoi il appartient au relevé |
|---|---|
mode | L'étiquette que vous posez sur chaque exécution ; la page ne peut pas la lire |
quota et usage | Les valeurs de stockage réellement rendues |
persistent | Si l’autorisation a été accordée ou refusée |
apis | Un booléen par interface testée |
Les notes prises dans un onglet disparaissent dès la fermeture de la fenêtre, et le mode que vous compariez est précisément ce qui est jeté. Écrire un petit fichier JSON par exécution fait survivre la comparaison à un redémarrage et donne à la mise à jour suivante du navigateur un point de comparaison. Le script ci-dessous ne lit que des valeurs que la page elle-même peut lire ; il fonctionne donc de la même façon sur une page de laboratoire que vous maîtrisez et sur un visualiseur d’empreintes auquel vous faites confiance.
display-mode n'est pas un signal de mode privé : une fenêtre normale et une fenêtre privée correspondent toutes deux à browser, et seule une fenêtre d'application installée correspond à une valeur d'application comme standalone. Le script enregistre la valeur trouvée : ce champ décrit donc l'affichage de la page, pas le mode de navigation privée. mode est l'étiquette que vous posez vous-même, une fois par exécution. Le reste de l'enregistrement est lu depuis la page.
// exécutez ceci dans les deux sessions, puis copiez le JSON imprimé dans deux fichiers
const record = { mode: 'regular' }; // set this to 'private' in the private window
const est = await navigator.storage.estimate();
record.displayMode =
['browser', 'standalone', 'minimal-ui', 'fullscreen', 'window-controls-overlay'].find(
m => window.matchMedia(`(display-mode: ${m})`).matches
) ?? 'none';
record.quota = est.quota;
record.usage = est.usage;
record.persistent = await navigator.storage.persisted();
record.apis = {
serviceWorker: 'serviceWorker' in navigator,
indexedDB: 'indexedDB' in window,
localStorage: 'localStorage' in window,
caches: 'caches' in window,
};
console.log(JSON.stringify(record));
Nommez les deux fichiers d’après la session, par exemple regular.json et private.json, puis différez-les. Un diff de deux relevés pris avec le même profil ne devrait montrer que usage, et seulement si la première exécution a écrit des données que la seconde n’avait pas encore écrites. Tout autre champ qui diffère est un constat à expliquer, pas un bruit à moyenner.
Deux détails rendent le relevé comparable. Lisez navigator.storage.estimate() avant d’écrire quoi que ce soit d’autre dans le stockage, car l’écriture elle-même modifie usage. Et notez la version du navigateur à côté du fichier, puisqu’un changement de quota entre deux versions du navigateur est attendu et qu’un changement de quota entre deux sessions d’une même version ne l’est pas.
Trier un écart dans un ordre fixe
| Ordre | À vérifier avant d’accuser le mode |
|---|---|
| 1 | Les deux exécutions ont utilisé le même --bot-profile |
| 2 | Les deux exécutions ont reçu les mêmes options --bot-* |
| 3 | Aucune n’a changé la taille de fenêtre ni les extensions |
| 4 | La page et le visualiseur étaient la même version |
La plupart des écarts viennent d’une variable qui a bougé entre les deux exécutions, et non du mode privé lui-même. Travailler dans un ordre fixe évite de relancer la comparaison avant d’avoir vérifié les entrées qui en font une comparaison. Comparez d’abord les deux fichiers de relevé, puis les deux lignes de commande de lancement, et seulement ensuite le comportement du navigateur.
Commencez par le fichier de profil. --bot-profile accepte un chemin, et deux sessions pointées vers des fichiers différents définissent des quotas et des surfaces d’empreinte différents : un écart à cette étape est donc une comparaison cassée, pas un constat sur le navigateur. Comparez les chemins absolus résolus, pas les chaînes saisies dans deux shells différents.
Ensuite les options. Une session qui a ajouté une option --bot-* pour une exécution et pas pour l’autre compare deux configurations. Affichez la ligne de commande effective des deux exécutions et différez-la. La même règle couvre les différences d’environnement qui modifient le lancement, comme une variable de proxy définie dans un seul shell.
Ensuite les variables de présentation. La taille de fenêtre, le rapport de pixels de l’appareil, les extensions installées et l’espace disque libre déplacent chacun une valeur, et aucun n’est décidé par le mode de navigation. Maintenez-les constants ou notez-les à côté du résultat pour que l’écart soit attribuable.
Ce n’est qu’après ces trois vérifications qu’il devient utile de regarder le navigateur. Si le profil, les options et la présentation sont identiques et qu’un champ diffère encore, l’écart mérite d’être signalé avec les deux fichiers de relevé, les deux lignes de commande et la version du navigateur. C’est ce compte rendu qui rend le constat exploitable plutôt qu’anecdotique.
Fixez l’ordre par écrit et réutilisez-le. Une liste de tri qui change de forme d’une enquête à l’autre produit des listes incomparables, ce qui est le même problème que de comparer deux sessions dans des conditions différentes.
Choisir une isolation qui ne dépend pas du mode privé
Si le vrai besoin est d’avoir des sessions qui ne partagent ni ne conservent de données, un dossier de données utilisateur remplit directement ce rôle. Les navigateurs basés sur Chromium stockent les cookies, le stockage local, IndexedDB et les caches dans le dossier indiqué par --user-data-dir. Faire pointer chaque session vers son propre dossier les garde séparées, et un nouveau dossier temporaire ne laisse rien derrière lui une fois supprimé. Cela donne la même non-persistance locale que le mode privé, sans différences propres à un mode à comparer.
# une session avec son propre dossier de données temporaire
chromium-browser --bot-profile="path/to/profile.enc" \
--user-data-dir="$(mktemp -d)"
Choisissez selon l’objectif. Un dossier distinct par compte garde séparés les cookies, l’état de connexion et les données locales, ce dont a besoin le travail avec plusieurs comptes. Un dossier temporaire convient à une tâche ponctuelle qui ne doit rien laisser sur le disque. Un dossier persistant convient à une session qui doit survivre aux redémarrages. L’article sur l’isolation du navigateur pour plusieurs comptes décrit comment planifier ces frontières. Dans tous les cas, le dossier décide seulement de ce qui est stocké. Il ne décide pas de l’aspect de l’empreinte, et le profil se choisit donc séparément.
Supprimez les dossiers temporaires à la fin de la tâche. Un script qui en crée un devrait aussi le supprimer, et une personne qui en crée un à la main ne devrait pas le réutiliser pour une autre tâche. Réutiliser un dossier annule l’intérêt de la démarche, car les cookies et les données de sites de la première tâche seraient alors disponibles pour la seconde.
L’identité réseau est encore une autre couche. Ni une fenêtre privée ni un dossier de données ne changent l’adresse IP. Un site qui voit la même adresse d’une session à l’autre peut les relier quel que soit le stockage. Si une identité réseau distincte compte pour votre tâche, configurez volontairement un proxy pour cette session et vérifiez que sa localisation, sa langue et son fuseau horaire concordent avec le profil. Les cookies, l’empreinte et l’adresse IP sont trois surfaces distinctes, et chacune demande sa propre décision.
Ne considérez aucun de ces choix comme de l’anonymat. Un dossier temporaire supprime des fichiers locaux. Un proxy change l’adresse visible. Un profil garde cohérentes les valeurs que le navigateur indique. Ensemble, ils réduisent la part d’une session qui passe d’une visite à la suivante, mais un compte connecté reste connu du service, et un site peut encore utiliser des signaux qu’une comparaison locale ne couvre pas.
Ce que BotBrowser couvre et ce qui reste hors de son champ
BotBrowser peut garder cohérents les surfaces de l’empreinte, les valeurs de quota de stockage et le comportement des API de stockage entre les sessions normales et incognito pour un même profil, et la documentation de BotBrowser sur le mode incognito décrit ce comportement. Pour la comparaison ci-dessus, cela signifie qu’un contexte privé ne devrait montrer aucune différence supplémentaire de stockage ou d’API par rapport à un contexte normal : un écart est donc une raison de vérifier le profil et les options, et non quelque chose que vous devez accepter. BotBrowser ne peut pas faire en sorte que la navigation privée masque l’adresse IP ni l’activité côté site, ne contrôle pas la façon dont un site évalue ou corrèle d’autres signaux et ne remplace ni la configuration du proxy ni les choix concernant les comptes.
La documentation décrit aussi --bot-enable-variations-in-context, une option pour l’en-tête X-Client-Data que reçoivent les domaines Google dans les contextes incognito. Elle est indiquée comme une fonction ENT Tier2 et elle est désactivée par défaut. La plupart des lecteurs n’en ont pas besoin pour la comparaison décrite ici, mais elle montre que le travail de cohérence s’étend à des détails qui dépassent le stockage.
Pour démarrer concrètement, lancez BotBrowser avec un profil, effectuez la comparaison de la section précédente et attendez-vous à ce que le contexte normal et le contexte privé concordent. S’ils ne concordent pas, les conseils de dépannage de la documentation s’appliquent : vérifiez que les deux sessions utilisent le même --bot-profile et les mêmes options --bot-*, car un autre profil peut définir d’autres valeurs de quota. L’isolation des sessions reste votre décision, et les options de dossier de données décrites plus haut sont le moyen de la mettre en œuvre.
Gardez un rôle limité au produit. Il s’occupe de la cohérence entre les contextes normaux et privés. Qu’un site accepte une session dépend du site, de l’identité réseau et de l’historique du compte, et rien de tout cela ne peut être promis par un mode du navigateur ou par un profil. Utilisez la comparaison comme une vérification parmi d’autres dans un examen plus large de votre configuration, à côté des choix de réseau et de compte qui restent les vôtres.
Conclusion pratique
Considérez le mode privé comme un nettoyage de session locale, pas comme un changement d'identité réseau ou d'appareil. Une comparaison utile garde le profil, la version du navigateur et la page constants, relève les résultats de stockage et d'API, puis choisit un dossier de données ou un proxy séparé seulement lorsque cette limite précise est nécessaire.
Sources publiques
Cet article fait partie du guide : Surfaces d’identité du navigateur : vue de cohérence pratique
Articles Connexes
Ce que fait et ne fait pas la navigation privée
EmpreintePrivate Verification Tokens : proposition de Chrome et BotBrowser
EmpreinteFingerprinting DRM : ce que révèlent les requêtes EME et Widevine
IdentitéGestion multi-comptes des réseaux sociaux avec isolation du navigateur
IdentitéChangement de marque : Chrome, Edge, Brave, Opera
IdentitéPartitionnement du stockage du navigateur et confidentialité
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.