Vie privée du navigateur entre surfaces : garder un contexte cohérent

BotBrowser peut garder un profil cohérent entre page, affichage, langue, rendu et requêtes dans un BrowserContext contrôlé ; il ne rend pas le navigateur anonyme et ne contrôle pas la conservation des données d’un site.

Résumé

• Gardez le rendu, l’affichage, la langue et les métadonnées de requête cohérents dans un BrowserContext prévu.
• Considérez une vérification publique comme une observation ponctuelle, pas comme une preuve d’anonymat ou de conservation.
• Changez de contexte lorsque le but, le compte, les permissions ou la sensibilité des données changent.

Sommaire

• La vie privée relie plusieurs surfaces
• Comment les sites relient les observations
• Le rendu est une observation publique
• Un profil dans un BrowserContext prévu
• Une revue pratique du contexte
• Conclusion pratique

La vie privée relie plusieurs surfaces

La vie privée du navigateur est souvent décrite comme une série de réglages indépendants. Une page observe un résultat graphique, une requête transporte des métadonnées du navigateur et un script voit une préférence d’affichage. La question importante n’est pas de savoir si une observation isolée paraît inhabituelle. Il faut plutôt demander si les observations qui devraient décrire un même contexte restent cohérentes lorsque la personne change de page, de site, d’onglet ou de contenu intégré. BotBrowser peut appliquer un même profil de façon cohérente sur les surfaces page, worker et requête d’un contexte contrôlé ; il ne peut pas décider de ce qu’un site fait des données qu’il reçoit.

BotBrowser documente des ensembles d’empreinte par contexte (ENT Tier3) qui donnent à chaque BrowserContext son propre profil, son user agent et userAgentData, ses métriques d’écran, son fuseau horaire, sa locale et ses langues, ainsi que des graines de bruit pour canvas, WebGL et audio. Pour cette revue, une équipe peut ainsi garder alignés le rendu, l’affichage, la langue et les données de user agent dans un contexte, séparés des autres contextes, puis confirmer le résultat avec une vérification publique. BotBrowser ne peut pas rendre un navigateur anonyme, ne peut pas contrôler ce qu’un site conserve ou partage et ne remplace ni le consentement, ni l’hygiène de stockage et de connexion, ni la politique de conservation. Les contextes ne sont isolés que dans le modèle d’empreinte de BotBrowser.

C’est le problème entre surfaces. Un site peut combiner ce que la page voit avec ce que son serveur reçoit. Une ressource intégrée peut envoyer une requête à un service différent du site affiché, tandis qu’un script de première partie observe l’environnement qui a produit cette requête. Quand le même service apparaît sur plusieurs sites sans lien apparent, il peut comparer ces observations.

Le service n’a pas toujours besoin d’un compte stable. L’association de caractéristiques de rendu, de relations d’affichage, de préférences linguistiques et de métadonnées de requête peut suffire à établir une corrélation probabiliste. Le résultat n’est pas nécessairement un nom. Il peut s’agir d’un niveau de confiance, d’un groupe de navigateur mémorisé ou d’une demande ultérieure d’un autre signal.

L’objectif défensif est précis : garder le comportement public d’un profil cohérent dans son BrowserContext prévu, réduire l’exposition inutile et rendre l’exposition restante compréhensible. La cohérence ne rend pas le navigateur anonyme et ne décide pas si un site peut recueillir des données. Ces questions dépendent des réglages, du consentement, des règles de l’organisation et du droit applicable.

Comment les sites relient les observations

Par exemple, une requête faite avec fetch() peut être comparée à navigator.language et navigator.userAgentData lorsque le même service reçoit ces données.

La collecte ne dépend presque jamais d’une seule lecture spectaculaire. Elle se construit à partir d’activités ordinaires que l’on remarque peu.

Une image intégrée, une police, un script d’analyse, un composant publicitaire ou une bibliothèque de mesure peuvent envoyer une requête à un service différent du site visible. Cette requête peut transporter des métadonnées du navigateur avant la fin du chargement. Le code intégré peut aussi observer des propriétés générales de l’environnement. Si le même service apparaît sur des sites distincts, il peut comparer ce qu’il reçoit.

La collecte de première partie peut produire un effet comparable au sein d’une même entreprise. Une personne visite une boutique, un portail d’assistance et une documentation qui partagent une infrastructure de mesure. Même avec des marques différentes, les événements peuvent être reliés. La connexion d’un compte facilite ce rapprochement, mais toutes les corrélations ne l’exigent pas.

Les contrôles de vie privée doivent donc être vérifiés pendant les transitions. Un profil cohérent sur une page, mais différent après le chargement d’un cadre intégré, ne règle pas le problème central. Un contexte qui expose une préférence de langue dans le document et une autre dans la requête laisse une relation enregistrable par le service.

Le rendu est une observation publique

Les surfaces visibles par la page comprennent WebGLRenderingContext et WebGPU ; ce sont des API observables, pas des canaux matériels privés.

Les surfaces graphiques sont utiles parce qu’elles décrivent un résultat calculé, et pas seulement une préférence d’un panneau de réglages. WebGL et WebGPU peuvent révéler des caractéristiques du chemin de rendu par leurs capacités et leur sortie. Une page peut aussi comparer un comportement graphique dans plusieurs contextes. Une observation isolée est parfois générale, mais elle peut contribuer à une corrélation avec d’autres signaux.

Le risque n’est pas qu’un site connaisse le modèle d’une carte graphique. Le risque est que la sortie de rendu devienne une partie durable de l’identité du navigateur. Une différence entre sites, onglets ou cadres peut être aussi informative qu’un résultat stable. Un affichage annoncé qui ne correspond pas au rendu crée une autre relation que le service peut conserver.

Bloquer la surface graphique n’est pas la seule réponse. Le blocage réduit parfois la visibilité, mais il peut aussi modifier le comportement d’une page et produire une configuration rare. Une revue utile demande si le résultat autorisé s’accorde avec le reste du contexte, si la personne sait que des capacités graphiques sont observables et si le site a une raison légitime de les utiliser. Pour comparer ces résultats graphiques entre rendu logiciel et rendu matériel, voir Valider la confidentialité selon le backend de rendu, qui couvre la revue de Canvas, WebGL et WebGPU.

Les relations d’affichage portent du contexte

Les dimensions de l’écran et la densité de pixels ne sont pas de simples détails de mise en page. Leur relation influence le rendu, les requêtes de média et l’interprétation de la surface disponible. La taille de la fenêtre, de la zone visible, le zoom et la densité peuvent changer lorsqu’une personne déplace une fenêtre ou branche un écran. Certains changements sont normaux et visibles. D’autres révèlent un écart entre le profil et l’environnement hôte.

Le risque vient de la combinaison. Une identité d’affichage qui annonce un appareil mais rend à une autre échelle peut ressortir. Une relation qui change dans un nouvel onglet peut aussi servir de repère. Le contenu web peut observer une partie de cette relation par la mise en page sans permission particulière.

Une configuration défensive doit respecter les actions réelles de l’utilisateur. Une personne qui redimensionne une fenêtre ne doit pas être enfermée dans un état artificiel. En parallèle, un BrowserContext isolé ne devrait pas hériter silencieusement d’hypothèses d’affichage de l’hôte qui contredisent le profil choisi. Il faut décider ce qui appartient au contexte et garder les surfaces associées cohérentes pendant son activité.

Les préférences de langue donnent un contexte régional

Les préférences linguistiques aident un site à choisir son contenu, mais elles peuvent aussi devenir un indice régional et comportemental. Le navigateur peut exposer des langues préférées à la page et la couche de requête peut les communiquer au serveur. Le site peut les comparer à la langue du document, à la région choisie, à des réglages liés au temps ou à la région de la connexion.

Aucune préférence de langue isolée n’identifie une personne. Le risque vient d’une combinaison inattendue ou d’un changement entre surfaces. La page affiche une région et la requête en annonce une autre. Une ressource intégrée reçoit une préférence différente de celle de la page principale. Un profil reste stable sur plusieurs sites mais change dans un nouveau BrowserContext. Chaque écart peut séparer des sessions destinées à partager un contexte ou relier des sessions qui devaient rester séparées.

Une configuration attentive traite la langue comme une décision de contexte, pas comme une étiquette décorative. La langue choisie doit correspondre au contenu et à la région attendus, puis être appliquée aux parties visibles pour la page et pour les requêtes. La personne doit pouvoir la changer volontairement en sachant que ce changement affecte le contenu et la relation observée par les services.

User Agent Client Hints et frontière des requêtes

User Agent Client Hints fournit aux serveurs des métadonnées structurées sur le navigateur et la plateforme. Les serveurs utilisent ces informations pour négocier le contenu de manière sélective. Du point de vue de la vie privée, cela reste une surface observable par le serveur. Celui-ci peut comparer les métadonnées reçues avec l’identité visible pour la page, le rendu et la plateforme suggérée par l’affichage. Pour savoir comment ces en-têtes sont envoyés et d’où viennent les incohérences, voir Client Hints Fingerprinting : en-têtes HTTP et identité, qui compare les en-têtes de requête avec les valeurs JavaScript.

La cohérence entre types de requête et contextes est centrale. Une navigation, une ressource intégrée et une requête ultérieure ne devraient pas décrire des identités incompatibles si elles appartiennent au même BrowserContext. Le même profil ne devrait pas non plus présenter une famille de navigateur au serveur et une autre à la page. Modifier uniquement le texte de l’agent ne répare pas les écarts des autres surfaces. Pour connaître les surfaces qui doivent concorder et la façon de les vérifier dans la page, dans un worker et dans la requête, voir User-Agent et Client Hints : garder une identité cohérente.

Client Hints montre aussi une limite concrète. Certaines métadonnées arrivent au serveur avant que la personne puisse inspecter la page. Une vérification publique peut afficher ce qui a été reçu, mais elle ne peut pas dire combien de temps le service le conserve, s’il le partage ou si une autre entreprise en a obtenu une copie. La cohérence technique réduit les corrélations accidentelles, sans remplacer la notice de vie privée ni le consentement.

Un profil dans un BrowserContext prévu

Un profil rassemble les choix sur la manière dont un contexte se présente. Un BrowserContext est la limite opérationnelle dans laquelle pages, requêtes, stockage et permissions doivent partager une session contrôlée. Cette relation compte. Réutiliser un profil dans des contextes sans lien peut créer un rapprochement voulu. Mélanger des choix de profils différents dans un contexte peut créer un rapprochement accidentel ou une combinaison incohérente.

Pour une démarche défensive, commencez par définir la limite. Décidez quelles pages et requêtes vont ensemble, quel stockage doit rester dans cette limite et quand un nouveau contexte est nécessaire. Chargez un profil pour cet objectif et évitez de modifier les choix liés à l’identité pendant une session active, sauf si le changement est prévu. Gardez ensemble les décisions d’affichage, de rendu, de langue et de requête afin de les revoir comme une seule configuration.

Cela ne demande pas de publier des détails d’implémentation. Cela demande une discipline opérationnelle. Un profil doit avoir un cycle de vie : le choisir pour un objectif, l’utiliser dans son contexte, vérifier le comportement public, puis le retirer ou le renouveler selon la politique de conservation. Le navigateur peut aider à garder la cohérence, mais il ne peut pas décider de la politique à la place de l’utilisateur.

Ce qu’une vérification publique peut montrer

Notez l’URL du contrôle et un horodatage comme 2026-10-18T14:00Z afin que les comparaisons ultérieures aient un point d’observation défini.

Une page de vérification visible peut répondre à une question limitée mais utile : qu’expose ce contexte maintenant ? Elle peut afficher un échantillon graphique, montrer la réaction de la mise en page à l’affichage actif, indiquer la langue de la page et présenter les métadonnées arrivées à son serveur. Refaire la vérification dans un autre onglet ou contexte peut révéler une variation inattendue.

La meilleure vérification est comparative et fondée sur le consentement. Utilisez une page que vous contrôlez ou un service public reconnu, lisez sa notice de vie privée et ne fournissez pas de données de compte lorsqu’un simple contrôle suffit. Comparez le même contexte avant et après une modification volontaire. Comparez des contextes distincts seulement pour vérifier leur séparation. Conservez uniquement le niveau d’information nécessaire au dépannage.

Un contrôle public est une observation, pas une certification. Il montre les surfaces accessibles à la page et à son serveur à un moment donné. Il ne permet pas d’inspecter une base distante, de déduire tous les partages ni de prouver qu’un autre site prendra la même décision. Il ne garantit pas non plus qu’un profil convienne à tous les appareils physiques ou à toutes les conditions de réseau.

Ce qui reste hors du navigateur

Le contrôle peut documenter la sortie de navigator et de la requête, mais il ne certifie ni la durée de conservation ni la politique de partage d’un service.

Du côté serveur, de nombreuses questions de vie privée relèvent de la politique. Un site peut conserver des journaux, relier des événements à un compte, partager des données avec un prestataire ou les utiliser pour un objectif que la page ne montre pas. Un contrôle local ne peut pas vérifier ces pratiques. Il faut consulter la notice du service, ses contrôles de consentement et, si nécessaire, exercer un droit d’accès ou d’effacement.

La vie privée réseau dépasse aussi l’identité du navigateur. Un profil cohérent ne masque pas l’adresse IP, ne change pas la confiance accordée à un fournisseur de proxy et n’empêche pas la reconnaissance après une connexion. Le stockage et les permissions comptent toujours. Les cookies, le stockage local, l’état de connexion et l’accès à un appareil peuvent créer des liens même lorsque le rendu et l’affichage restent cohérents.

Il existe enfin une limite humaine. Un navigateur ne doit pas servir à casser un contrôle d’accès, à dissimuler une activité interdite ou à faire croire que l’observation est devenue impossible. La promesse utile est plus étroite : garder prévisibles les contextes approuvés par l’utilisateur, limiter les liens accidentels et faciliter l’examen du comportement public.

Une revue pratique du contexte

Lors de la revue d’un profil et de son BrowserContext, posez ces questions :

• Objectif : quelles pages et quelles requêtes appartiennent à ce contexte, et pourquoi ?
• Accord : le rendu, l’affichage, la langue et les métadonnées décrivent-ils le même contexte choisi ?
• Changements : si une fenêtre, un écran, une langue ou une connexion change, le changement est-il attendu et documenté ?
• Séparation : le nouveau contexte commence-t-il avec le stockage et les permissions prévus, sans état hérité par accident ?
• Preuve : une page publique contrôlée ou reconnue peut-elle confirmer le comportement visible sans données personnelles superflues ?
• Gouvernance : une politique de conservation, de consentement et d’effacement existe-t-elle pour les observations reçues ?

Ces questions résistent mieux à l’évolution des navigateurs et des sites qu’une liste fixe. Elles gardent aussi la revue centrée sur le résultat de vie privée plutôt que sur la reproduction de la collecte d’un site.

Quand changer de contexte

Fixez une date de revue, par exemple 2026-10-18, puis supprimez le relevé lorsque la règle de conservation indique qu’il n’est plus nécessaire.

Avant de démarrer le nouveau contexte, vérifiez que localStorage et l’état de connexion appartiennent bien à la frontière prévue.

La cohérence ne signifie pas conserver toute activité dans une session permanente. Changez de contexte lorsque l’objectif, les permissions, le compte ou la sensibilité des données changent. Une recherche, un compte personnel et une tâche administrative peuvent mériter des limites distinctes sur le même poste. La séparation réduit l’historique qui peut être relié et facilite la revue ultérieure.

Le changement doit être volontaire. Fermez ou isolez la session précédente selon la politique locale, démarrez le nouveau contexte avec le profil prévu et vérifiez le comportement avant une tâche sensible. N’emportez pas par inadvertance une connexion, une préférence de langue, une hypothèse d’affichage ou une permission. Un état partiellement hérité rend souvent le nouveau contexte plus difficile à comprendre.

Le même principe vaut lorsqu’un service modifie sa page ou ses requêtes. Un nouveau composant intégré peut créer un chemin de collecte absent de la revue précédente. Une mise à jour du navigateur peut changer le rendu ou la négociation des métadonnées. Revoyez le contexte après un changement important, notez l’objectif et la date, puis supprimez ces notes quand elles ne sont plus nécessaires.

Sources publiques

• W3C User Agent Client Hints
• MDN WebGL API

Conclusion pratique

La vie privée entre surfaces est un problème de cohérence et de gouvernance. La sortie graphique, les relations d’écran, les préférences de langue et User Agent Client Hints peuvent être des comportements ordinaires séparément. Ensemble, surtout entre sites, ils peuvent devenir un signal durable lorsqu’ils se contredisent ou sont particulièrement distinctifs.

Garder un profil cohérent dans un BrowserContext réduit les liens accidentels entre surfaces. Cela ne remplace ni le consentement, ni un stockage prudent, ni des services fiables, ni des règles de conservation. La vérification publique confirme ce qu’une page et son serveur observent dans un scénario défini, tandis que les notices et contrôles de l’organisation traitent la suite.

Pour aller plus loin, consultez Qu’est-ce que l’empreinte du navigateur, Empreinte Client Hints, Empreinte WebGL, Empreinte WebGPU et Empreinte écran et fenêtre. Pour un parcours public de validation, ouvrez le Proof Center.