Una ventana de Chrome con varios espacios de trabajo aislados: cómo funciona por dentro
El aislamiento en una sola ventana son tres capas superpuestas: sesión y almacenamiento, enrutado de red, ciclo de vida; no es virtualización del núcleo. No cambia la huella.
Por qué abrir más ventanas no equivale a varias cuentas conectadas a la vez
Empecemos desmontando una intuición: una ventana no es una unidad de aislamiento. Diez ventanas en un mismo perfil comparten un almacén de cookies, un localStorage y una caché HTTP, y el sitio ve una sola sesión. El modo incógnito sí tiene un almacén aparte, pero solo hay uno y muere con la ventana, así que no sirve para diez cuentas. La unidad real es el contenedor de sesión: un conjunto de cookies propio, un espacio de nombres de almacenamiento propio y un mapa de pertenencia estable. Chrome no tiene una API de contenedores —la excepción es contextualIdentities de Firefox—, así que la extensión lo construye en la capa de sesión: anota qué pestaña pertenece a qué contenedor y reparte peticiones y almacenamiento según ese mapa. CrispLogin funciona así: el contenedor es un registro que mantiene la extensión, no una primitiva de Chrome. La unidad de aislamiento es la sesión, no el proceso.
Capa uno: por qué las cookies no se mezclan
Las cuentas no se mezclan gracias a un frasco de cookies virtual más la reescritura de la cabecera de petición por pestaña. Cada contenedor guarda dentro de la extensión sus propios registros de cookies. Antes de que salga una petición, una session rule de declarativeNetRequest empareja la pestaña mediante condition.tabIds y fija la cabecera cookie al valor de ese contenedor; cuando llega la respuesta, webRequest observa Set-Cookie y lo escribe en el frasco correspondiente. El frasco debe serializar sus cookies ordenadas por longitud de ruta y luego por fecha de creación, o la cabecera no coincidirá con la que el navegador habría enviado.
Lo que suele pasarse por alto es la vida útil: tabIds solo funciona en session rules, y las session rules se borran al cerrar el navegador y al actualizar la extensión. Por eso hay que reinstalar las reglas en cada arranque; si se omite, el síntoma es «tras reiniciar, todos los espacios de trabajo son la misma cuenta». El almacenamiento de página es otra cara: document.cookie lee el almacén real y localStorage tiene un único espacio de nombres, así que un script en MAIN world debe intermediar lecturas y escrituras por contenedor. Esto es aislamiento en la capa de aplicación: separa dos cuentas del mismo sitio, pero no toca la huella del núcleo.
Capa dos: cómo el proxy sigue al espacio de trabajo
Chrome no tiene una API de proxy por pestaña. chrome.proxy.settings se aplica a todo el perfil, y FindProxyForURL(url, host) de un PAC nunca recibe un tabId; declarativeNetRequest puede reescribir cabeceras y redirigir, pero no tiene la acción «elegir un proxy de salida». Lo que sí puede hacer una extensión es mantener un mapa espacio de trabajo → salida y reescribir esa configuración global cuando cambia la pestaña en primer plano.
PAC puede separar por dominio, pero su insumo es la URL, no la pestaña: el mismo sitio abierto en dos espacios de trabajo recibe una sola respuesta de PAC. Por eso «diez espacios de trabajo, cada uno con su túnel» no existe en una extensión; lo que se garantiza es «el espacio de trabajo que está delante es el que tiene su salida». También es la razón de que al cambiar de espacio se vea una reconexión: al modificar la configuración del proxy se reconstruyen las conexiones ya establecidas. Límite: esta capa cambia la IP de salida y la ruta de la petición, no la huella TCP/TLS (JA3/JA4); WebRTC puede restringirse con chrome.privacy.network.webRTCIPHandlingPolicy para descartar UDP no proxyado, pero es una política de todo el navegador, no por espacio de trabajo.
Capa tres: ¿sobrevive el vínculo al cerrar la pestaña o reiniciar?
El fondo de MV3 es un service worker: 30 segundos sin eventos y se termina, llevándose las variables de módulo y cualquier Map dentro de un closure. Por eso «qué pestaña pertenece a qué espacio de trabajo» no puede vivir en memoria: va a chrome.storage.session, que permanece en memoria mientras la extensión está cargada y sobrevive a que el worker se recicle, pero se borra al reiniciar el navegador. Ojo: no está expuesto a los content scripts por defecto; si el lado de la página necesita leer el vínculo, hay que llamar a setAccessLevel de forma explícita.
Eso divide los datos en dos: los vínculos de ejecución en session, y todo lo que debe sobrevivir a un reinicio —lista de espacios, configuración de proxy, índice de instantáneas— en storage.local. La cadena causal es directa: como el vínculo está en session y no en una variable, tras despertar el worker la extensión sigue sabiendo a quién pertenece cada pestaña y no vierte las cookies de un espacio en la página de otro. Si solo estuviera en memoria, en cuanto el worker duerme la siguiente petición no tendría dueño que consultar, y eso se ve como grupos duplicados e instantáneas restauradas en el contenedor equivocado.
Capa cuatro: qué guarda una instantánea de sitio y qué restaura
La instantánea responde a otra pregunta: la portabilidad del estado de sesión, no el aislamiento en ejecución. Ocupa el cuarto lugar de la lista, pero no forma parte del aislamiento en sí. Serializa las cookies de un sitio dentro de un contenedor y el almacenamiento de ese sitio, y al restaurar las vierte en el espacio de nombres de ese contenedor. Son ortogonales: el aislamiento impide que dos espacios se estorben mientras ambos existen; la instantánea evita tener que iniciar sesión otra vez. El grano es el sitio, no el navegador: dos sitios en un contenedor son dos registros independientes.
De ahí que una instantánea deba pertenecer a un contenedor: volcar el estado de A en B fusiona dos cuentas en una. Igual de importante es decir qué no hace: restaura estado de sesión de la capa de aplicación, no una huella del núcleo, y no promete sortear los controles de riesgo ni la validación de dispositivo de una plataforma. Uso: Enlace interno: uso real de las instantáneas de sitio.
¿En qué se diferencia de abrir varios perfiles?
Los perfiles múltiples de Chrome son un corte físico a nivel del directorio raíz de almacenamiento: cada perfil tiene su propio almacén de cookies, su almacenamiento, sus extensiones y su caché, de modo que el aislamiento es completo. El coste aparece en cuatro ejes: memoria, porque cada perfil tiene su contexto de red y sus procesos de renderizado, así que tres perfiles son aproximadamente tres veces el coste residente; procesos, porque los árboles son independientes; ventanas, porque un perfil es una ventana y cambiar equivale a cambiar de ventana; huella, porque los perfiles comparten núcleo y máquina, y UA, Canvas y fuentes son idénticos por defecto. Hay un coste más silencioso: marcadores, extensiones e historial no se comparten, y a partir del tercero cada perfil empieza a divergir.
La vía de la extensión invierte esto: un perfil, una ventana, procesos y núcleo compartidos, a cambio de paralelismo en una sola ventana con un coste incremental casi nulo, y con el precio de no alcanzar la capa de huella del núcleo. No son dos grados de lo mismo, sino dos formas de cortar la granularidad del aislamiento. Comparación detallada: Enlace interno: perfiles de Chrome frente a aislamiento por extensión.
Límites: qué capas cubre una extensión y cuáles no
Los límites anteriores, comprimidos en una tabla. Se lee preguntando qué revisa la plataforma: para sesión y salida, la columna central; para consistencia de huella, la de la derecha. Y conviene repetirlo: una extensión hace aislamiento de sesión, que no es el mismo grado que un navegador antidetect; tomarla por un antidetect más ligero es leer mal el riesgo.
| Capa | Lo que cubre la extensión | Fuera de alcance, o el precio |
|---|---|---|
| Cookies y estado de sesión | Separados por contenedor, serializables en una instantánea | El núcleo no conoce contenedores; se reescriben cabeceras y, si se pierden las reglas, hay fuga |
| Almacenamiento de página | localStorage e IndexedDB pueden prefijarse o proxyarse por contenedor | Service worker, SharedWorker y otros contextos aparte necesitan cobertura propia |
| IP de salida | Ligada al espacio de trabajo; cambiar el frontal cambia la salida | Una sola salida frontal a la vez; sin túneles concurrentes |
| WebRTC | Puede descartarse el UDP no proxyado (política de todo el navegador) | No es por espacio de trabajo; las rutas de medios aún pueden saltarse el proxy |
| Huella TLS | Nada | JA3/JA4 los determina el núcleo y la pila de red |
| Canvas / WebGL / Audio | Nada | El renderizado ocurre en el núcleo; no hay API para reescribirlo |
| Enumeración de fuentes | Nada | Solo parches de JS en la página, y son detectables |
| Caché HTTP | Nada | La caché es del perfil y se comparte entre contenedores |
La tabla también señala dónde está el techo: lo que sustituye una extensión es el motivo de comprar un cliente solo para iniciar sesión por separado, no el cliente. Qué vía elegir es otra pregunta, comparada punto por punto en Enlace interno: extensión frente a navegador antidetect.
Preguntas frecuentes
¿El aislamiento de cookies de una extensión es lo mismo que las Partitioned Cookies de Chrome?
No. Las Partitioned Cookies se indexan por sitio de nivel superior, así que un sitio tiene un solo frasco por página de nivel superior; partitionKey en la API de cookies es únicamente la clave para leer y escribir esas cookies, y su único componente es topLevelSite: con ella no se inventan particiones nuevas. El frasco de un espacio de trabajo se separa por contenedor, un sitio puede tener tantos como haga falta y la extensión lleva la contabilidad. Lo primero es particionado de privacidad del navegador; lo segundo, una abstracción de sesión de la extensión.
¿Se conserva el estado del espacio de trabajo al cerrar la pestaña?
Tres casos. La pestaña desaparece y el vínculo se va con ella. Las definiciones del espacio —nombre, proxy, índice de instantáneas— son datos que deben sobrevivir a un reinicio y suelen ir en storage.local. El estado de sesión solo se recupera si guardaste una instantánea; si no, hay que iniciar sesión de nuevo. Lo que está en storage.session se borra al cerrar el navegador, así que no lo trates como almacenamiento duradero.
¿Afecta al rendimiento del navegador el enfoque de una sola ventana?
El incremento viene de las pestañas, no del aislamiento. No se inicia un segundo navegador ni se copia el núcleo; el coste es emparejar reglas y reescribir cabeceras, una cantidad constante por petición. El coste real está en el número de pestañas y en las páginas: con veinte espacios, lo que se atasca es el renderizado, no la capa de aislamiento.
¿Pueden dos espacios de trabajo usar IP de salida distintas a la vez?
No. La configuración de proxy es del perfil y la extensión solo puede reescribirla al cambiar de pestaña, así que en cada momento solo el espacio en primer plano usa su propia salida; los de fondo quedan bloqueados por reglas o salen directo. Para túneles concurrentes de verdad hace falta un cliente con su propia pila de red.
Fuentes y última actualización
Donde este artículo toca comportamiento de API, manda la documentación oficial. Los límites de una extensión se mueven con las versiones de Chrome: revísalos antes de adoptarla.
- Chrome for Developers, chrome.declarativeNetRequest — vida útil de las session rules, alcance de condition.tabIds y modifyHeaders sobre la cabecera cookie: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers, chrome.storage — el área session vive en memoria, se borra al reiniciar el navegador y no está expuesta a los content scripts por defecto: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers, chrome.cookies — partitionKey y la semántica de clave de las Partitioned Cookies (CHIPS): developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers, chrome.proxy — la configuración de proxy se aplica a todo el perfil del navegador y PAC solo recibe la URL y el host: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers, The extension service worker lifecycle — terminación tras 30 segundos inactivo y pérdida de las variables globales con el worker: developer.chrome.com/…/service-workers/lifecycle
Última actualización: 11 de noviembre de 2026. Aquí se describe la ruta de implementación habitual de este tipo de extensión; qué API y qué ubicación de datos usa cada producto puede variar, y su documentación manda sobre sus interioridades.