Aislamiento multicuenta del navegador: ajustes independientes

El aislamiento de varias cuentas implica asignar a cada identidad autorizada su propia ruta, perfil, límite de almacenamiento y registro de revisión. BotBrowser puede aislar cuentas aprobadas por perfil y contexto; no puede autorizar el uso de cuentas, anular reglas de plataforma ni garantizar que una plataforma nunca correlacione cuentas.

Resumen

Use BrowserContext para almacenamiento aislado y ajustes de identidad por contexto o instancias separadas para el resto del límite aprobado. Verifique exitIp, locale, lecturas de renderizado y particiones de almacenamiento para cada identidad después de un cambio de configuración o versión de navegador.

Contenido

• Cinco señales que pueden vincular una cuenta con otra
• Una instancia con varios contextos o varias instancias
• Cómo asignar ajustes independientes a cada identidad
• Cómo comprobar cada identidad por separado
• Conclusión práctica

Cinco señales que pueden vincular una cuenta con otra

Quien gestiona varias cuentas a propósito, como una agencia que administra páginas de clientes, un equipo de soporte que reproduce incidencias regionales o una persona investigadora que compara contenido localizado, se encuentra con el mismo problema: las cuentas comparten más cosas que la persona que las usa. Un sitio no necesita un nombre para notar que dos sesiones tienen algo en común. Le bastan unos pocos valores que se repiten. Por eso el trabajo de aislamiento consiste en decidir qué valores deben ser independientes en cada identidad y en asegurarte de que cada uno se fija a propósito, en lugar de heredarse por casualidad de la máquina. Los consejos siguientes suponen que cada cuenta es tuya, o que la gestionas con permiso de su titular y dentro de las condiciones de la plataforma. BotBrowser puede mantener cada cuenta autorizada en su propio perfil y contexto aislados; no puede conceder permiso para operar una cuenta ni sustituir las condiciones de la plataforma.

En la práctica importan cinco dimensiones. Se enumeran en el orden en que suelen causar problemas.

• Ruta de red. Dos cuentas que inician sesión desde la misma dirección IP se relacionan con facilidad. Cada identidad necesita su propia ruta aprobada, y esa ruta debe venir de un proveedor que hayas evaluado.
• Señales de huella. El resultado de renderizado de Canvas y WebGL, las características de audio, las dimensiones de pantalla y los valores de navigator proceden del hardware y del sistema operativo, así que se repiten en todo lo que se ejecuta en una misma máquina mientras nada los cambie.
• Cookies y almacenamiento. Las cookies, localStorage, IndexedDB, la caché y los service workers guardan estado. Registra el límite de cada identidad como storagePartition: cualquier uso compartido aquí vincula las cuentas de forma directa, sin necesidad de inferir nada.
• Metadatos geográficos. La zona horaria, la configuración regional y el idioma deben coincidir entre sí y con la ruta. Una cuenta que parece iniciar sesión desde Berlín pero informa de una zona horaria de Nueva York es incoherente consigo misma.
• Horario de actividad. Las cuentas que siempre empiezan, hacen pausas y actúan en los mismos momentos desde la misma máquina forman un patrón que ningún ajuste del navegador puede eliminar.

Las cuatro primeras son cuestiones de configuración, y un navegador puede ayudar con ellas. La quinta depende de cómo se comportan las personas y los calendarios, por eso aparece más abajo como hábito de trabajo y no como ajuste.

Conviene tener presente una idea durante el resto del texto: el aislamiento reduce la vinculación en estas dimensiones y nunca la reduce a cero. Un conjunto de identidades bien configurado elimina las conexiones baratas y accidentales. No impide que un analista decidido correlacione cuentas por su comportamiento, por datos de pago compartidos o por la forma de escribir de la misma persona. Planificar con ese límite en mente da mejores decisiones que suponer una separación perfecta.

La independencia es solo la mitad del objetivo: cada identidad también debe ser coherente consigo misma. Un perfil que describe un equipo de escritorio, una configuración regional de otro país y una ruta en una tercera región hacen que una identidad parezca contradictoria, y eso ya es una señal en sí misma. Al preparar una identidad, hazte dos preguntas: ¿se diferencia de las demás en todas las dimensiones? y ¿sus propios ajustes describen un único dispositivo coherente en un único lugar coherente? Las dos respuestas deben ser afirmativas.

Una instancia con varios contextos o varias instancias

Disposición	Límite de almacenamiento	Límite de configuración de identidad	Compromiso operativo
una instancia, varios objetos BrowserContext	un almacén aislado por contexto	perfil, ruta, locale y semilla por contexto	menor coste de memoria; la huella por contexto exige licencia ENT Tier3
una instancia por identidad	un directorio de datos de usuario por proceso	un archivo de perfil y una ruta por instancia	alcance de fallo más claro; mayor coste de arranque y memoria

Los navegadores basados en Chromium separan el almacenamiento por contexto de navegación. Playwright describe un contexto como una sesión de navegador aislada: cada uno tiene sus propias cookies, almacenamiento local, datos de IndexedDB, caché y service workers, y una prueba puede abrir muchos dentro de un solo navegador a bajo coste. Es el comportamiento estándar y no depende de ninguna compilación especial. Cubre la tercera dimensión de la lista anterior y es la razón por la que un contexto es la unidad natural para una identidad.

Lo que un contexto estándar no separa son las señales que proceden del hardware y del sistema operativo. El resultado de renderizado, las características de audio, las dimensiones de pantalla y los valores de navigator son idénticos en todos los contextos de un navegador corriente, porque todos se ejecutan en la misma máquina. Una configuración de serie te da aislamiento de almacenamiento y nada más. Los contenedores de Firefox y los directorios de datos de usuario separados comparten la misma frontera: las cookies quedan aparte, mientras que las señales que vienen del dispositivo siguen siendo las mismas.

En el otro extremo de la escala existen opciones más pesadas. Las instalaciones de navegador separadas y las máquinas virtuales ofrecen una separación fuerte, porque cada una tiene sus propios binarios, su sistema operativo o su perfil de hardware, pero multiplican el trabajo de actualizar, vigilar y almacenar cada entorno, y cada máquina virtual reserva memoria para un sistema operativo completo. Encajan cuando las normas de cumplimiento exigen que las identidades no compartan ningún equipo. Para la mayoría del trabajo multicuenta, los contextos y las instancias de navegador separadas cubren la necesidad con un coste operativo menor.

Hay dos disposiciones habituales. En la primera, una instancia del navegador contiene varios contextos y cada uno se asigna a una identidad. Arranca rápido, reparte el coste de la instancia y usa menos memoria por identidad. La función de huella por contexto de BotBrowser se diseñó para esta disposición: cada contexto puede llevar su propio perfil, zona horaria, configuración regional, semilla de ruido y proxy, y la documentación indica que la mayoría de las opciones de línea de comandos de BotBrowser se admiten por contexto. Esa función exige la licencia ENT Tier3, así que confirma tu nivel de licencia antes de basar el diseño en ella.

En la segunda disposición, cada identidad tiene su propia instancia del navegador con su propio archivo de perfil y su propio directorio de datos de usuario. No se comparte nada entre instancias, lo que da la separación más limpia y la explicación más sencilla para una auditoría. El precio es el coste: cada instancia tiene su propio tiempo de arranque y consumo de memoria, y el número de instancias que admite una máquina lo limita su hardware, no el navegador. Además, un fallo o una página bloqueada afecta solo a una identidad, lo cual es una ventaja operativa real.

Elige según el riesgo y el volumen. Si las identidades son pocas y un error sale caro, las instancias separadas son fáciles de razonar. Si necesitas muchas identidades con hardware limitado, una instancia con varios contextos es más eficiente, siempre que aceptes que los contextos comparten una instancia del navegador y confíes en los ajustes por contexto para todo lo demás. Muchos equipos usan ambas: contextos dentro de cada instancia para identidades relacionadas e instancias separadas para los grupos que nunca deben compartir infraestructura. Elijas la disposición que elijas, da a cada instancia su propio directorio de datos de usuario para que los datos del perfil nunca choquen.

La capacidad es una medición, no una promesa. Cuántas identidades aguanta una máquina depende de la memoria disponible, de los núcleos del procesador y de lo pesadas que sean las páginas de cada contexto, así que prueba con tus cargas reales en lugar de copiar una cifra de la configuración de otra persona. Planificación de capacidad de contextos del navegador muestra cómo planificar y vigilar el uso de recursos a medida que crece el número de contextos. Añade identidades poco a poco, observa la memoria y los tiempos de carga, y detente cuando la máquina empiece a ir más lenta.

Cómo asignar ajustes independientes a cada identidad

Empieza con un registro sencillo de identidades antes de tocar la configuración. Para cada una, anota el archivo de perfil, la ruta, la zona horaria, la configuración regional y los idiomas, la semilla de ruido y el directorio de datos o el contexto que guarda su estado. El registro es corto, pero evita el fallo más común: reutilizar un valor porque ya estaba en la línea de comandos. Trata cada fila como una unidad que no comparte ningún valor con otra fila, salvo donde hayas decidido que compartir es aceptable.

El perfil fija la huella base. Los archivos de perfil separados dan la separación más fuerte porque cada uno describe un dispositivo distinto, mientras que un mismo perfil combinado con semillas de ruido diferentes da resultados distintos sobre la misma base. La semilla de ruido controla pequeñas variaciones en el renderizado y en el audio. La misma semilla produce siempre el mismo resultado, de modo que una identidad se mantiene estable entre sesiones, y una semilla distinta da a otra identidad un resultado diferente. Elige la semilla una vez, guárdala en el registro de la identidad y no la cambies sin motivo. Reproducibilidad de la semilla de ruido explica los detalles.

La ruta y los metadatos geográficos deben coincidir. Cuando asignas el proxy a un contexto mediante sus ajustes de BotBrowser, BotBrowser deriva la zona horaria, la configuración regional y el idioma a partir de la dirección de salida de esa ruta. La documentación también permite indicar tú mismo la dirección de salida, lo que omite la consulta y acelera la creación del contexto. Advierte de que un proxy configurado solo con la opción integrada de Playwright deja la zona horaria desajustada respecto a la ruta, así que usa el ajuste --proxy-server de BotBrowser para las rutas por contexto. Los valores explícitos de zona horaria, configuración regional e idioma siguen disponibles cuando necesites sustituir los derivados, como se describe en Configuración de zona horaria, configuración regional e idioma.

La estabilidad en el tiempo forma parte del diseño. Una cuenta que conserva el mismo perfil, la misma semilla, la misma región de ruta y el mismo directorio de datos de una sesión a otra parece una persona que vuelve a un mismo dispositivo. Una cuenta cuyos ajustes cambian de una sesión a otra parece varios dispositivos, y puede provocar verificaciones adicionales en plataformas que vigilan los dispositivos nuevos. Si una identidad necesita una ruta nueva, por ejemplo tras un cambio de proveedor, mantén estables la región y los metadatos geográficos y actualiza el registro. Cambia el perfil o la semilla solo cuando retires la identidad de forma intencionada.

El orden importa dentro de una instancia. Los ajustes por contexto deben aplicarse después de crear el contexto y antes de abrir su primera página, porque la página los lee al arrancar, y los ajustes aplicados a un contexto que ya tiene una página no surten efecto. Los workers creados desde páginas de ese contexto, ya sean dedicados, compartidos o service workers, heredan la identidad del contexto, así que no necesitan ningún paso adicional. Crea cada contexto, aplica sus ajustes y solo entonces abre páginas.

Los detalles de la ruta merecen su propio cuidado. Da a cada identidad una ruta aprobada distinta y comprueba cómo gestionan tu proveedor y el navegador el DNS y WebRTC, de modo que la ruta elegida sea la que transporta todas las conexiones. BotBrowser documenta controles para ambos en el lado de red, y Proxy por contexto explica cómo asignar y validar rutas por contexto. Guarda las credenciales de cada ruta en un gestor de secretos y no en scripts que compartan varias identidades.

Cómo comprobar cada identidad por separado

Lectura	Comparación esperada	Campo del registro
dirección pública	difiere y coincide con la ruta aprobada	exitIp
configuración regional y zona horaria del navegador	coincide con la región de la ruta aprobada	locale y timeZone
salida de Canvas y WebGL	difiere cuando deben diferir el perfil o la semilla elegidos	canvasHash y webglRenderer
cookies y almacenamiento	no aparece fuera del contexto propietario	storagePartition

Verificar significa leer los valores observables de cada identidad y compararlos con tu registro. Hazlo tras cada cambio de configuración y cada vez que cambie la versión del navegador. Usa una página de prueba que controles o una página pública neutral, y mantén las comprobaciones breves. El objetivo es confirmar que tus ajustes llegaron a cada contexto, no estudiar cómo funciona un sitio concreto. Ejecuta las mismas comprobaciones en todas las identidades para poder comparar los resultados línea a línea.

1. La dirección IP pública difiere entre identidades y coincide con la ruta asignada a cada una.
2. La zona horaria, la configuración regional y el idioma informados corresponden a la región de esa ruta.
3. El resultado de renderizado de Canvas difiere entre identidades que usan perfiles o semillas de ruido distintos.
4. La cadena del renderizador de WebGL difiere entre identidades que usan perfiles distintos.
5. Las cookies y el almacenamiento escritos en una identidad no aparecen en ninguna otra.

Interpreta los resultados con las expectativas adecuadas. Las diferencias en la cadena del renderizador se esperan entre perfiles separados, mientras que las semillas de ruido cambian sobre todo el resultado de renderizado, así que dos identidades con un mismo perfil pueden informar legítimamente de la misma cadena de renderizador. Si falta una diferencia esperada, revisa primero el registro: una semilla repetida, un archivo de perfil compartido o un contexto cuyos ajustes se aplicaron tras su primera página son las causas habituales, y un directorio de datos compartido explica el almacenamiento compartido.

Mantén las comprobaciones separadas de las sesiones normales de la identidad. Abre la página de verificación en una página nueva del mismo contexto, anota los valores y ciérrala, para que una comprobación no deje estado adicional en el almacenamiento, el historial o el horario de la cuenta. No inicies sesión en nada ni cargues páginas que pertenezcan a la cuenta real durante una comprobación. Guarda los valores anotados junto al registro de la identidad para poder comparar un cambio posterior.

Programa las comprobaciones. Hazlas al crear una identidad, tras cualquier cambio de perfil, ruta o semilla, tras una actualización del navegador y según un calendario regular para identidades de larga vida, por ejemplo una vez al mes. Una lista breve y repetible sirve más que una larga que nadie termina. Cuando un valor cambia sin una entrada correspondiente en el registro, trátalo como un hallazgo: averigua quién cambió qué y corrige la configuración o el registro antes de volver a usar la identidad.

Recuerda qué significa una comprobación superada. Estas lecturas confirman que los ajustes se aplicaron como se pretendía y que las identidades son distintas en los valores que has leído. No prueban que un sitio concreto no pueda conectar dos identidades, porque un sitio puede usar señales que no has leído y porque la vinculación puede venir del comportamiento y no de los valores del navegador. Considera un resultado limpio como evidencia de que la configuración es correcta, nunca como garantía sobre cómo se comportará una plataforma.

Conclusión práctica

El horario es la primera laguna. Las cuentas que siempre actúan en los mismos minutos, inician sesión justo una tras otra o siguen rutinas idénticas presentan un patrón que no tiene nada que ver con el navegador. Escalona los calendarios, varía la duración de las sesiones y deja que cada cuenta siga el ritmo que corresponde a su propósito. No manejes varias cuentas desde un único script que las ejecute a la vez.

La segunda laguna es el material compartido. La misma dirección de correo, el mismo teléfono, el mismo método de pago, el mismo contacto de recuperación o el mismo archivo subido unen cuentas en el nivel de la plataforma. Las cookies merecen mención aparte: copiar una cookie de una identidad a otra arrastra consigo la sesión y sus identificadores, y deshace la separación que aporta el aislamiento del almacenamiento. No muevas nunca cookies, sesiones exportadas ni contraseñas guardadas entre identidades.

La higiene rutinaria cubre las lagunas restantes. Cierra los contextos que ya terminaron para liberar memoria y evitar que se acumule estado. Usa directorios de datos persistentes solo para las identidades que deben conservar estado entre ejecuciones, con un directorio por identidad. Guarda las credenciales de las rutas, los archivos de perfil y las semillas en un almacenamiento con control de acceso y un responsable designado. Lee las condiciones de cada plataforma que uses: algunas limitan el número de cuentas que una persona puede manejar, y ninguna configuración del navegador cambia esas reglas ni la forma en que la plataforma las aplica.

Prevé los errores, porque ocurrirán. Si se copió una cookie a mano, se reutilizó un archivo de perfil o se abrieron dos contextos con los mismos ajustes, considera mezcladas las dos identidades implicadas. Deja de usarlas para el trabajo afectado, documenta lo ocurrido y reconstruye la identidad afectada con un directorio de datos nuevo y sus propios ajustes en lugar de parchearla. Reconstruir es más lento en el momento, pero deja un registro fácil de creer, mientras que una identidad parcheada conserva todo el estado que se filtró en ella.

Antes de añadir una identidad nueva, revísala frente a las cinco dimensiones y frente al material compartido descrito arriba. ¿Tiene su propia ruta, su propio perfil y semilla, su propio directorio de datos, su propio horario y sus propios datos de cuenta? Una identidad nueva que no supere alguna de estas preguntas aún no está aislada, aunque los ajustes del navegador sean correctos.

BotBrowser permite asignar un perfil, un proxy, una zona horaria, una configuración regional y una semilla de ruido distintos a cada BrowserContext dentro de una misma instancia del navegador (la huella por contexto exige la licencia ENT Tier3 documentada), o ejecutar instancias separadas con sus propios perfiles y directorios de datos de usuario, de modo que cada identidad presente ajustes de huella y de red independientes y puedas mantener las cuentas separadas sin mantener un parque completo de máquinas. BotBrowser no puede garantizar que las cuentas nunca se vinculen: no proporciona proxies ni reputación de IP, no controla la correlación de comportamiento u horario, ni cómo gestionas las cookies, ni las políticas de cuentas de una plataforma, y no sustituye una separación operativa sólida de las cuentas.

Fuentes públicas

• BotBrowser: Multi-Account Isolation
• BotBrowser: Per-Context Fingerprint
• BotBrowser: Per-Context Proxy
• Playwright: Isolation with browser contexts
• Playwright: HTTP proxy