Coherencia entre realms del navegador y privacidad

Las fronteras entre Window, Worker e iframe deben ser previsibles y limitar los datos intercambiados; WHATWG HTML define estos realms y BotBrowser puede repetir un flujo autorizado en un contexto controlado, pero no garantiza la privacidad de un sitio remoto.

Una página puede contener varios realms

La especificación WHATWG HTML define estos límites, y BotBrowser puede repetir recorridos autorizados en un contexto controlado declarado, sin convertir la prueba local en una garantía de privacidad remota.

El Window superior no es el único entorno JavaScript. Un Worker dedicado tiene su propio ámbito global y un iframe crea otro realm de documento. Cada realm tiene objetos globales, identidades de objetos internos, reglas de almacenamiento y contexto de políticas propios. Por eso una referencia como Array debe interpretarse dentro del realm que la creó.

La coherencia útil no exige objetos ni tiempos idénticos. Exige saber qué realm es dueño de un valor, intercambiar datos mediante un límite explícito y no convertir una diferencia normal en un identificador persistente.

Qué cruza el límite

Los frames del mismo origen pueden usar Window.postMessage; un worker se comunica con su página mediante postMessage. El algoritmo de clonación estructurada copia muchos valores. El array creado en el receptor no es el mismo objeto que el del emisor aunque sus contenidos coincidan. Un ArrayBuffer transferible mueve la propiedad y deja el buffer del emisor separado.

Los frames de distinto origen siguen aislados por la política de mismo origen. postMessage sigue siendo posible, pero el receptor debe validar event.origin y, cuando corresponda, un nonce. event.source es una referencia WindowProxy, no una credencial. No uses la forma del mensaje, la identidad del constructor ni una excepción del navegador para autenticar.

Un Worker no comparte el DOM del documento. Puede recibir datos, calcular y devolver un resultado, pero no leer elementos de la página ni asumir su almacenamiento o permisos. Un Service Worker tiene otro ciclo de vida y alcance; no es equivalente a un worker dedicado ni a un iframe.

La coherencia necesita un contrato explícito

Define esquema, propiedad y vida útil para cada valor enviado de Window a Worker o iframe. Envía registros, arrays, cadenas y números que el receptor pueda validar; añade una versión cuando el mensaje pueda sobrevivir a una versión del producto. No envíes funciones, nodos DOM ni prototipos propios del realm esperando conservar comportamiento. Documenta quién posee un recurso transferido después de entregarlo.

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' });
};

La etiqueta realm es un dato de aplicación, no una huella. Sirve para probar la ruta prevista y no debe guardarse como atributo de identidad.

Límites de privacidad que conviene conservar

Un iframe solo observa lo que exponen su documento y sus permisos. Un iframe del mismo origen puede tener acceso amplio; uno de otro origen debe recibir únicamente mensajes y capacidades delegados. Usa un protocolo postMessage estrecho, targetOrigin exacto y, cuando corresponda, sandbox o Permissions Policy. No envíes tokens ni registros de cuenta solo porque el canal exista.

Mover código a un Worker puede reducir exposición al DOM, pero no vuelve privados los datos frente a la página que los proporciona ni frente al servicio que los recibe. La minimización, retención y consentimiento son políticas de la aplicación.

Las diferencias entre realms pueden medirse: identidad de constructores, funciones disponibles, idioma y observaciones de planificación. Una observación no demuestra marca del navegador, dispositivo ni persona. No combines sondeos en un identificador encubierto; prueba solo las capacidades necesarias y elimina el diagnóstico al terminar.

Tabla de decisión

Observación	Responsable	Acción segura	No inferir
Falla la validación del esquema	Realm receptor	Rechazar y reportar error sintético	Identidad o intención maliciosa
event.origin inesperado	Política receptora	Ignorar y registrar un evento acotado	Que todo mensaje de ese origen sea fiable
Valor clonado	Clonación estructurada	Validar y usar objetos del receptor	Prototipo u objeto compartido
Transferible separado	Contrato de transferencia	Dejar de usar el recurso del emisor	Fallo del navegador o identidad
Falta una función	Capacidad del realm	Usar una alternativa documentada	Dispositivo o navegador único

Capacidad y limitación de BotBrowser

BotBrowser admite la repetición de recorridos autorizados de Window, Worker e iframe en contextos controlados con un perfil declarado, pero no puede hacer idénticos los realms ni garantizar la privacidad de un sitio remoto. Esto ayuda a comprobar el protocolo de realms, la validación de origen y las alternativas documentadas de una aplicación. BotBrowser no concede acceso entre orígenes, no autentica mensajes ni garantiza el mismo conjunto de funciones en cada versión. Tampoco controla la retención de un sitio remoto; una comprobación local no prueba anonimato ni privacidad en producción.

Una prueba de navegación debe registrar solo los estados visibles que necesita el equipo para diagnosticar el contrato.

El resultado esperado debe describir tanto el camino correcto como la recuperación cuando falta una capacidad.

Un contexto nuevo ayuda a detectar estado heredado, pero no convierte una observación local en una promesa sobre el servidor remoto.

La aplicación debe cerrar workers, frames y servidores temporales incluso cuando una validación falle.

Los identificadores de solicitud acotan los reintentos y permiten asociar una respuesta con la operación correcta.

La interfaz debe comunicar un tiempo de espera con texto accesible y ofrecer una acción de recuperación comprensible.

Los datos sintéticos hacen que las pruebas sean repetibles y reducen la exposición de contenido real.

Un cambio de origen después de navegar un iframe exige comprobar de nuevo el protocolo antes de aceptar mensajes.

La política de permisos debe documentar qué capacidades recibe cada frame y por qué las necesita.

La revisión de privacidad debe considerar la vida útil de los datos en ambos realms y durante los errores.

Una diferencia entre realms es una señal de compatibilidad, no una identidad del usuario.

Fuentes públicas

Lecturas relacionadas: política de mismo origen y privacidad entre superficies.

• WHATWG HTML: Web application APIs and realms
• WHATWG HTML: Web messaging
• MDN: Using web workers
• MDN: Window.postMessage
• BotBrowser advanced features