Un navegador remoto ingenuo comparte un único proceso de navegador entre muchos usuarios. Las cookies establecidas en una sesión aparecen en la siguiente; los datos de localStorage cruzan los límites de la sesión; el estado de autenticación de un usuario puede ser asumido por otro. Aunque la propia aplicación protegida se comporte bien, el navegador compartido se convierte en un canal lateral que evita todo control de acceso a nivel de aplicación.
Y luego está la navegación. Un usuario con permiso solo de visualización sobre un único panel interno hace clic en un enlace de phishing dentro de ese panel, abre una nueva pestaña para una cuenta personal o sigue un enlace externo que no pretendía. Sin imposición en la capa del navegador, la sesión escapa de la aplicación protegida — y ahora el identificador de sesión de la aplicación protegida, la identidad del usuario y el estado de navegación activo se vuelven visibles allá donde el navegador haya ido.
El aislamiento de contexto de navegador cierra ambos problemas. Cada sesión corre en su propio contexto de navegador sin estado compartido. El propio navegador impone una lista de permitidos de los dominios que la sesión puede alcanzar y bloquea todos los canales que el usuario podría usar para ir a otro sitio — nuevas pestañas, popups, clics en enlaces a dominios no permitidos, navegación programática por la propia página.
Cada sesión obtiene su propio contexto de navegador dentro del motor de render — completamente separado del estado de cualquier otra sesión. Una estricta lista de permitidos de dominios se detiene en la capa de navegación — la intercepción de solicitudes, el sondeo de navegación de aplicaciones de página única y la intercepción de clics en enlaces se aseguran juntos de que la sesión nunca alcance un dominio que no esté permitido. Por debajo, los propios píxeles renderizados portan modificaciones continuas de bajo nivel que rompen las herramientas de automatización que intentan leer la sesión o interactuar con ella.
Cada sesión de usuario se abre en su propio contexto de navegador aislado — un perfil nuevo con su propio frasco de cookies, su propio almacenamiento local, su propio estado de sesión. Dos usuarios en la misma aplicación protegida tienen navegadores completamente independientes; nada de una sesión es visible para la otra. El fin de la sesión destruye por completo el contexto; no sobrevive ningún estado.
Cada intento de navegación se atrapa antes de ejecutarse. La capa de solicitudes bloquea los dominios no permitidos a nivel de red; los clics en enlaces dentro de la página se atrapan en la capa de render; las navegaciones de aplicaciones de página única (pushState, replaceState) se atrapan mediante sondeo. La sesión no puede alcanzar un dominio fuera de la lista de permitidos, ya sea que el usuario lo intente deliberadamente o que la página lo intente por sí misma.
El navegador estilo kiosco no permite al usuario abrir nuevas pestañas, crear popups ni usar el menú contextual de clic derecho. Todos los canales que el usuario podría usar para escapar de la aplicación protegida se cierran en la configuración del navegador. El usuario trabaja dentro de la sesión que se abrió para él — nada más.
Bajo el contenido visible, el flujo de píxeles renderizado porta modificaciones continuas de bajo nivel — ruido aleatorio, desplazamientos de color sutiles, microdesplazamiento de elementos, vibración sub-píxel. Estas no afectan lo que el usuario ve, pero rompen las herramientas de automatización (scripts de Selenium, Puppeteer, raspadores de pantalla) que intentan leer la sesión o interactuar con ella desde fuera del canal de entrada oficial.
Cada comportamiento siguiente se configura por servicio protegido y se impone en la capa del navegador, no en el código de la aplicación protegida. La aplicación protegida no necesita saber de su existencia — el límite es invisible desde el tiempo de ejecución de la aplicación.
Cada sesión corre en su propio contexto de navegador — una estructura a nivel de Chromium que da a la sesión su propio frasco de cookies, su propio almacenamiento local, su propio registro de service worker, sus propios permisos, su propio estado de sesión. Dos sesiones en la misma aplicación protegida no comparten nada a nivel de navegador.
Cada solicitud de navegación — documento principal, subdocumento, fetch, XHR — pasa por un interceptor que comprueba el dominio de destino contra la lista de permitidos de la sesión. Los dominios no permitidos se bloquean antes de que se establezca la conexión. No hay condición de carrera entre el clic del usuario y la comprobación de la navegación.
Las aplicaciones de página única modernas navegan llamando a pushState o replaceState sin hacer una solicitud de red. Un simple interceptor de solicitudes no puede atrapar estas. ZeroLeak además sondea la URL actual dentro de la página a un intervalo corto, de modo que las navegaciones SPA a rutas no permitidas se atrapan y revierten en segundos.
Los elementos de enlace con destino no permitido, las llamadas a window.open(), los cambios programáticos de ubicación — todos se atrapan dentro de la página renderizada antes de ejecutarse. El usuario que hace clic en un enlace que no puede seguir se bloquea en el momento del clic, no después de que la solicitud de red ya haya empezado.
El navegador está configurado de modo que cualquier intento de crear un nuevo destino de navegación — por el usuario, la página o un script — se atrapa y descarta al instante. La sesión siempre tiene exactamente una pestaña visible, y esa es la pestaña de la aplicación protegida.
Cada sesión monitorea la interacción del usuario. Si el usuario está inactivo más tiempo del configurado, la sesión se termina de forma ordenada, el contexto de navegador se destruye y (cuando se configura) un webhook informa al coordinador, de modo que la política de destino pueda actualizarse. No hay navegadores aislados abandonados consumiendo memoria.
Más allá del aislamiento por sesión y del límite de navegación, el propio flujo de píxeles renderizado porta modificaciones continuas de bajo nivel. Su propósito es romper las herramientas de automatización — los scripts que de otro modo leerían la pantalla de la sesión, identificarían elementos e interactuarían a través de canales no oficiales — sin afectar cómo la página se ve o se comporta para el usuario humano.
Una superposición de canvas dibuja de forma continua ruido aleatorio de baja intensidad sobre toda la página renderizada. El ojo humano percibe a lo sumo una textura leve; los scripts de OCR y de coincidencia de plantillas que intentan leer la pantalla pierden los bordes de píxel consistentes en los que confían. La intensidad del ruido y la tasa de refresco se pueden configurar por servicio protegido.
Una superposición semitransparente aplica un tinte de color aleatorio que cambia lentamente sobre toda la página renderizada. Las áreas blancas y negras siguen pareciendo efectivamente blancas y negras a la vista, pero los valores de píxel reales se desplazan. Las herramientas de automatización basadas en visión que coinciden contra firmas de color pierden sus referencias.
Se aplica un desenfoque continuo muy ligero como filtro de pantalla. Cada fotograma es ligeramente diferente en su detalle de alta frecuencia, lo que dificulta que el OCR y los coincidentes de patrones encuentren puntos de característica fijos. El usuario no percibe el desenfoque a distancia normal de lectura.
Los elementos de la página se desplazan de su posición normal de 1 a 3 píxeles de forma aleatoria. El desplazamiento está por debajo de la percepción humana, pero rompe los scripts que localizan elementos por coordenadas de pantalla absolutas. Las herramientas de automatización no pueden confiar en una posición de elemento fija de un fotograma al siguiente.
A un intervalo corto, toda la superficie renderizada se desplaza unos pocos píxeles — lo bastante pequeño como para no romper la lectura, lo bastante grande como para vencer las herramientas de automatización que dependen de coordenadas de píxel absolutas consistentes para la simulación de entrada. Los ataques de replay estilo Selenium pierden sus puntos fijos.
Interfaces de infraestructura crítica donde la fuga de estado entre sesiones o la navegación no deseada podrían afectar sistemas físicos. El aislamiento por sesión garantiza que dos operadores en la misma consola no puedan ver la sesión del otro; la estricta lista de permitidos asegura que ninguno pase de la consola operativa a un enlace externo.
Paneles internos, interfaces de auditoría, herramientas de reporting accedidas por muchos usuarios — incluidos contratistas y auditores externos. Cada sesión es su propio navegador, la política de acceso se impone en la capa de navegación, y las defensas de la capa de render resisten la automatización de cualquiera que intente raspar la pantalla.
El contexto por sesión significa que un contratista que visualiza un data room no puede ver las cookies, el historial de búsqueda ni los identificadores de sesión de un contratista distinto en un data room distinto. La lista de permitidos asegura que la sesión del data room nunca vaya a la internet más amplia.
Portales de estudio donde múltiples investigadores acceden a datos de pacientes bajo estrictos límites de divulgación. El aislamiento por sesión impone el límite en la capa del navegador; la lista de permitidos lo impone en la capa de navegación; las defensas de render resisten la automatización de cualquiera que intente raspar a través del canal de pantalla de datos.
Ejecutaremos dos sesiones lado a lado en la misma aplicación protegida, mostraremos que nada se filtra entre ellas, intentaremos salir de la lista de permitidos e intentaremos conducir la sesión con una herramienta de automatización externa — y le mostraremos lo que ocurre.