Cohérence entre realms du navigateur et confidentialité
Définir des limites claires entre Window, Worker et iframe sans transformer les différences d objets JavaScript en signal d identité.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Les frontières entre Window, Worker et iframe doivent rester prévisibles et limiter les données échangées; WHATWG HTML définit ces realms et BotBrowser peut répéter un parcours autorisé dans un contexte contrôlé, sans garantir la confidentialité d un site distant.
Une page peut contenir plusieurs realms
La spécification WHATWG HTML définit ces frontières; BotBrowser peut répéter un parcours autorisé dans un contexte contrôlé déclaré, sans transformer ce contrôle local en garantie de confidentialité distante.
Le Window principal n est pas le seul environnement JavaScript. Un Worker dédié possède son propre espace global et un iframe crée un autre realm de document. Chaque realm a ses objets globaux, ses identités d objets internes, ses règles de stockage et son contexte de politique. Une référence comme Array doit donc être interprétée dans le realm qui l a créée.
La cohérence utile n exige pas des objets ni des temporisations identiques. Elle exige de connaître le propriétaire d une valeur, d échanger les données par une frontière explicite et de ne pas transformer une différence normale en identifiant persistant.
Ce qui franchit la frontière
Les frames de même origine peuvent utiliser Window.postMessage et un worker communique avec sa page par postMessage. Le clonage structuré copie de nombreuses valeurs. Le tableau créé dans le récepteur n est pas le même objet que celui de l émetteur, même si le contenu est égal. Un ArrayBuffer transférable déplace la propriété et laisse le buffer de l émetteur détaché.
Les frames d origine différente restent isolées par la same-origin policy. postMessage reste disponible, mais le récepteur doit vérifier event.origin et, si nécessaire, un nonce. event.source est une référence WindowProxy, pas un justificatif. N utilisez ni la forme du message, ni l identité d un constructeur, ni une exception du navigateur pour authentifier.
Un Worker ne partage pas le DOM du document. Il peut recevoir des données, calculer et renvoyer un résultat, mais ne peut pas lire directement les éléments de la page ni supposer son stockage ou ses permissions. Un Service Worker a un autre cycle de vie et une autre portée; il n est pas interchangeable avec un worker dédié ou un iframe.
La cohérence demande un contrat explicite
Définissez le schéma, la propriété et la durée de vie de chaque valeur envoyée du Window vers un Worker ou un iframe. Envoyez des enregistrements, tableaux, chaînes et nombres que le récepteur peut valider; ajoutez une version quand le message peut survivre à une version du produit. N envoyez pas de fonctions, de nœuds DOM ou de prototypes propres au realm en espérant conserver leur comportement. Documentez le propriétaire d une ressource transférée après livraison.
const worker = new Worker('/realm-worker.js', { type: 'module' });
const request = { version: 1, values: [2, 3, 5] };
worker.onmessage = ({ data }) => {
if (data?.version !== 1 || !Array.isArray(data.values)) throw new Error('invalid reply');
console.log({ sum: data.values.reduce((a, b) => a + b, 0), realm: data.realm });
};
worker.postMessage(request);
// realm-worker.js
self.onmessage = ({ data }) => {
if (data?.version !== 1 || !Array.isArray(data.values)) return;
self.postMessage({ version: 1, values: data.values, realm: 'worker' });
};
L étiquette realm est une donnée applicative, pas une empreinte. Elle sert à vérifier le trajet prévu et ne doit pas être conservée comme attribut d identité.
Limites de confidentialité à préserver
Un iframe n observe que ce que son document et ses permissions exposent. Un iframe de même origine peut disposer d un accès large; un iframe d une autre origine ne devrait recevoir que les messages et capacités délégués. Utilisez un protocole postMessage étroit, un targetOrigin exact et, si nécessaire, sandbox ou Permissions Policy. N envoyez pas de jetons ou de données de compte simplement parce que le canal existe.
Déplacer du code dans un Worker peut réduire l exposition au DOM, mais ne rend pas les entrées privées vis-à-vis de la page qui les fournit ou du service qui les reçoit. Minimisation, conservation et consentement relèvent de la politique applicative.
Les différences de realm peuvent être mesurées: identité des constructeurs, fonctionnalités disponibles, langue et observations d ordonnancement. Une observation ne prouve ni marque de navigateur, ni appareil, ni personne. Ne combinez pas les sondes en identifiant caché; testez seulement les capacités nécessaires et supprimez le diagnostic à la fin.
Tableau de décision
| Observation | Responsable | Action sûre | Ne pas inférer |
|---|---|---|---|
| Échec de validation du schéma | Realm récepteur | Rejeter et signaler une erreur synthétique | Identité ou intention malveillante |
event.origin inattendu | Politique du récepteur | Ignorer et journaliser un événement borné | Que tout message de cette origine est fiable |
| Valeur clonée | Clonage structuré | Valider et utiliser les objets du récepteur | Prototype ou objet partagé |
| Transférable détaché | Contrat de transfert | Cesser d utiliser la ressource de l émetteur | Panne du navigateur ou identité |
| Fonction absente | Capacité du realm | Utiliser une solution de repli documentée | Appareil ou navigateur unique |
Capacité et limite de BotBrowser
BotBrowser prend en charge la répétition de parcours autorisés Window, Worker et iframe dans des contextes contrôlés avec un profil déclaré, mais il ne peut pas rendre les realms identiques ni garantir la confidentialité d un site distant. Cela aide à vérifier le protocole de realms, la validation d origine et les solutions de repli d une application. BotBrowser n accorde pas l accès inter-origines, n authentifie pas les messages et ne garantit pas les mêmes fonctions à chaque version. Il ne contrôle pas la conservation par un site distant; un contrôle local ne prouve ni anonymat ni confidentialité en production.
Un test de navigation doit conserver seulement les états visibles nécessaires au diagnostic du contrat.
Le résultat attendu doit décrire le parcours valide ainsi que la récupération lorsqu une capacité manque.
Un contexte neuf aide à repérer un état hérité, sans transformer une observation locale en promesse sur le serveur distant.
L application doit fermer les workers, frames et serveurs temporaires même lorsqu une validation échoue.
Les identifiants de requête bornent les nouvelles tentatives et relient chaque réponse à la bonne opération.
L interface doit annoncer un délai d attente avec un texte accessible et proposer une récupération compréhensible.
Les données synthétiques rendent les tests reproductibles et limitent l exposition de contenu réel.
Après la navigation d un iframe, un changement d origine exige une nouvelle vérification du protocole.
La politique de permissions doit préciser les capacités accordées à chaque frame et leur raison.
La revue de confidentialité doit couvrir la durée de vie des données dans les deux realms et pendant les erreurs.
Une différence entre realms est un signal de compatibilité, pas une identité d utilisateur.
Sources publiques
À lire aussi : politique de même origine et confidentialité entre surfaces.
- WHATWG HTML: Web application APIs and realms
- WHATWG HTML: Web messaging
- MDN: Using web workers
- MDN: Window.postMessage
- BotBrowser advanced features
Articles Connexes
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.