Partición del almacenamiento del navegador y privacidad

En los navegadores que particionan el estado embebido, el sitio de nivel superior puede formar parte del límite: el mismo origen embebido puede encontrar estados gestionados por el navegador separados bajo sitios distintos. Esto puede reducir parte del intercambio de estado entre sitios, pero las API, los detalles de la partición y las excepciones varían según el navegador y la versión. El producto debe definir qué estado comparte, qué estado separa y qué ve el usuario cuando aparece un contexto nuevo.

Es un comportamiento de privacidad y compatibilidad, no un aislamiento total ni un bloqueo de todo intercambio de datos. El navegador puede ofrecer un mecanismo de acceso al almacenamiento embebido mediado por el usuario, pero su disponibilidad y alcance dependen de sus reglas. El almacenamiento gestionado por el navegador es distinto de los flujos de datos de la aplicación y del servidor. No deduzca la identidad de una persona o dispositivo a partir de una lectura de almacenamiento embebido.

Qué cambia la clave de partición

Cookies, almacenamiento creado por scripts y otros estados pueden asociarse a una partición que incluye el sitio superior. MDN State Partitioning describe el modelo general y Privacy Sandbox Storage Partitioning su contexto Chromium. Las API exactas dependen del navegador y la versión.

El mismo origen puede encontrar estados distintos bajo A y B. Una elección de consentimiento, preferencia o sesión de un contexto puede no existir en el otro. Es una consecuencia esperada de aislar el estado, no necesariamente un fallo de la aplicación. El componente debe ofrecer un primer uso claro y explicar cuándo el usuario debe elegir de nuevo una cuenta o una preferencia.

La navegación de nivel superior y la inserción tienen relaciones diferentes. Un servicio abierto como sitio principal usa su contexto propio; dentro de otra página sigue las reglas embebidas. Pruebe ambas rutas por separado y no asuma que un inicio propio garantiza el mismo estado embebido.

La partición también puede afectar service workers, cachés, IndexedDB y preferencias del cliente. Un worker que espera una caché creada en otro contexto quizá tenga que volver a descargar recursos. Un modelo o idioma elegido en otro lugar puede parecer ausente aunque el usuario ya lo haya seleccionado. Defina qué recursos se pueden volver a descargar, qué elecciones deben solicitarse otra vez y cómo explicar el nuevo contexto sin perder la tarea actual.

El cambio se nota al mover un componente entre pestañas, ventanas o rutas. El usuario puede reconocer la marca y aun así ver un consentimiento nuevo. Explique si debe abrir el servicio o elegir la cuenta otra vez, en lugar de dejarle adivinar la causa.

Los equipos que usan SDK embebidos deben versionar los supuestos de almacenamiento junto con el SDK. Una actualización del componente puede cambiar nombres de claves, formatos de caché o el momento en que solicita acceso. Mantenga una ruta de migración para borradores y preferencias, pruebe una actualización interrumpida y conserve la revisión de la aplicación y el fixture al comparar cambios simultáneos del navegador y el SDK.

Qué demuestra cada observación

• Partición del almacenamiento: Si un valor sintético se lee en un marco embebido propio bajo el sitio A, pero no bajo el B, el resultado es compatible con particiones separadas; no identifica a una persona ni demuestra que todas las API estén particionadas. Compare la escritura y lectura del mismo marco y origen en ambos contextos. Privacy Sandbox describe este límite para API de almacenamiento como Local Storage e IndexedDB.
• Autorización del servidor: Una respuesta permitida demuestra que el servidor aceptó esa solicitud con la cuenta de prueba y la política aplicable; no demuestra que el almacenamiento del navegador carezca de particiones ni que otras rutas estén autorizadas. Compare la respuesta a una solicitud de prueba autorizada con la de otra no autorizada.
• Excepción de acceso al almacenamiento: Una solicitud satisfactoria a la Storage Access API muestra que se concedió acceso a ese documento en ese contexto; no demuestra un acceso permanente ni universal. Anote el resultado de la API y una lectura posterior en un marco de prueba propio.
• Flujo de datos embebido: Una solicitud observada muestra qué datos llegaron a ese destino en esa prueba; no demuestra que no se envíen otros datos ni qué conserva el servidor. Inspeccione el destino y la carga sintética de una solicitud propia y compárelos con la elección indicada por el usuario.

Diseño de aplicaciones embebidas

Empiece por el recorrido del usuario, no por una API de almacenamiento. Decida si el componente recuerda el consentimiento, conserva un borrador, muestra un estado de sesión o solo presenta contenido público, e indique el contexto válido para cada estado. Un registro pequeño y específico para la finalidad es más fácil de explicar que asumir que todos los frames embebidos comparten una cuenta.

Si un flujo necesita una relación de primera parte, ofrezca una ruta visible a la página propia del servicio para que el usuario pueda revisar allí la cuenta, el consentimiento o la configuración. Al volver al sitio que lo integra, conserve la tarea mediante una transferencia explícita y de duración limitada, autorizada por el servidor, no mediante una dependencia no documentada de una cookie compartida.

Un componente debe tratar la partición vacía como estado normal. Muestre configuración o inicio de sesión, conserve los datos introducidos que no sean sensibles y explique la ausencia de una preferencia. No copie silenciosamente el estado de otro sitio superior.

Las solicitudes de permiso necesitan una alternativa centrada en el usuario. Si el navegador ofrece un mecanismo de acceso, explique qué necesita el componente y qué se compartirá. Si se deniega, las funciones no relacionadas de la página deben seguir disponibles: no repita la solicitud, bloquee la navegación ni sugiera que hace falta conceder acceso para leer contenido público.

La partición no sustituye la autorización del servidor: el servicio aún debe validar allí los permisos de la cuenta y la integridad de cada solicitud. El almacenamiento del cliente sirve de comodidad y caché, no prueba que una persona haya iniciado sesión. Si expira una sesión embebida, muestre un estado recuperable y pida la acción adecuada; no trate una cookie ausente como prueba sobre el navegador.

Privacidad y minimización

La partición puede reducir el intercambio pasivo de estado entre sitios superiores, pero no vuelve privada toda interacción embebida. El servicio integrado aún recibe los datos de solicitud necesarios para mostrar su función, y la página superior puede observar lo que coloca dentro de ella. Revise el recorrido completo de datos: parámetros de URL, mensajes postMessage, solicitudes de red, registros del servidor, analítica, descargas y eliminación.

Recoja solo el estado necesario. Una preferencia visual puede quedarse en la partición sin un identificador de cuenta; un borrador necesita plazo y acción de limpieza. El soporte suele necesitar resultado y versión, no toda la base de almacenamiento.

No convierta la disponibilidad de una clave en una señal de identidad estable. Una clave ausente puede deberse a un contexto nuevo, un perfil limpiado, la configuración del navegador, un permiso denegado o un cambio de aplicación. Una clave presente puede reflejar una relación de primera parte compartida sin identificar a una persona. Use resultados funcionales para elegir una ruta y borre los datos de diagnóstico cuando termine su finalidad de soporte.

El contenido de terceros puede tener un propietario distinto del de la aplicación superior. Aclare quién controla los datos de cuenta, los registros de consentimiento, el acceso de soporte y la retención. Si un componente de pago, medios o identidad necesita un límite de servicio, avise al usuario antes de que los datos salgan de la página. La partición local no responde quién puede ver un valor enviado al servicio.

La gestión de cookies explica la sesión y las decisiones de retención. Storage quota y privacidad trata las observaciones de capacidad. Mantenga esos temas separados de las claves de partición: una cuota no demuestra cuál es el contexto superior y la partición no justifica recopilar mediciones de cuota.

Probar el estado particionado

Use dos sitios superiores propios y un servicio embebido propio. Con perfiles limpios, cree una preferencia sintética bajo A y repita bajo B. Escriba la expectativa como regla visible para el usuario.

Pruebe por separado los flujos de primera parte y embebido. La visita de primera parte debe verificar el recorrido normal de cuenta y configuración; la visita embebida debe cubrir la partición vacía, el acceso denegado y el retorno al servicio. Use datos sintéticos, nunca cuentas o documentos reales en un endpoint de prueba.

Cubra el ciclo de vida: contexto nuevo, reinicio del navegador, limpieza del estado del sitio, cambio de consentimiento, caducidad de sesión y actualización de la aplicación. Compruebe si el producto conserva lo introducido, solicita una elección o empieza de nuevo intencionadamente. Un reinicio del estado no debe dejar la interfaz afirmando que una operación anterior terminó.

Los frames pueden comunicarse, pero el protocolo debe ser explícito y limitarse a la tarea. Valide tanto el origen como el significado de cada mensaje en ambos lados; no use un canal de mensajes amplio para recrear una capa global de almacenamiento oculta. Si el usuario decide continuar en una página de primera parte, pase una referencia de transferencia de corta duración, con vida documentada y autorización del servidor.

Compare navegadores sin tratar un resultado como universal. Registre familia, versión, sitios, origen embebido, aplicación y resultado. Un cambio puede exigir una alternativa, no una conclusión sobre toda la plataforma.

Solucionar compatibilidad

Ante un componente desconectado, determine si es superior o embebido, limpio o existente, y quién lo posee. Revise después sesión, autorización, consentimiento y red. No empiece copiando cookies.

Distinga una partición vacía de un fallo de red. Ambos pueden parecer una preferencia ausente, pero requieren acciones distintas: configuración inicial, reintento o explicación de un permiso revocado. Los mensajes de estado claros reducen solicitudes repetidas y consultas de soporte.

El almacenamiento en caché puede hacer que un cambio parezca incoherente. Un service worker o la caché de la aplicación puede conservar una interfaz antigua mientras una partición nueva obtiene recursos actuales. Versione los recursos, gestione una actualización interrumpida y mantenga una ruta funcional mientras se descarga la sustitución. No elimine el único borrador local utilizable solo porque el nuevo contexto no tenga su caché.

Si la función embebida es opcional, el resto de la página debe seguir siendo utilizable sin acceso al almacenamiento. Ofrezca una ruta de primera parte, una alternativa local sin cuenta o una explicación clara de lo que no podrá continuar. Muestre cualquier alternativa remota antes de cargar datos y explique qué opción de retención se aplica.

Las pruebas de soporte deben ser reducidas: conserve la tarea afectada, el contexto superior, la categoría del origen integrado, la versión del navegador, la revisión de la aplicación y el resultado visible. Solicite datos subyacentes de almacenamiento o cuenta solo mediante un proceso autorizado y cuando el registro mínimo no baste para explicar el problema; elimine la evidencia temporal al cerrar el caso.

Revisión de versión y operación

Cuando cambien navegador, SDK, consentimiento, cuentas o schema, repita el mismo flujo sintético. Compare resultado visible y acción del usuario, no una suposición sobre la clave.

Mantenga una matriz de navegadores y recorridos embebidos con propietario y fecha. No convierta cada valor de almacenamiento de la prueba en un registro permanente.

Documente las reglas de migración para estados que antes estaban disponibles entre contextos. El usuario quizá tenga que elegir de nuevo una preferencia, iniciar sesión en la página del servicio o exportar un borrador antes de una actualización. Ofrezca una acción clara y mantenga la ruta anterior el tiempo suficiente para evitar pérdidas silenciosas; no combine registros de sitios superiores no relacionados.

La respuesta a incidentes debe preservar el trabajo. Mantenga los datos introducidos, ofrezca exportación o continuidad propia y explique cualquier carga. No desactive aislamiento de forma permanente.

Después de actualizar el navegador o la integración, repita un flujo con un borrador sintético en cada contexto incrustado admitido. Una partición nueva debe mostrar la configuración inicial en lugar de anunciar falsamente que se guardó el borrador anterior; conserve el borrador original hasta completar la exportación o la continuación en la página del propio servicio elegida por el usuario. Compare las revisiones de la aplicación y sus dependencias con la ejecución anterior que funcionó antes de atribuir el fallo al almacenamiento del navegador.

La operación también incluye la eliminación. Defina cómo el usuario limpia un borrador integrado, cómo soporte retira un registro de prueba temporal y cómo una integración retirada deja de recibir solicitudes. Verifique la confirmación visible y mantenga disponible la acción incluso si el servicio integrado no puede cargar su preferencia anterior.

Antes de ir a una página propia, muestre el límite de datos: si el borrador queda local, pasa a una cuenta o se carga al servicio. Conserve los datos introducidos hasta que el usuario confirme.

La analítica también debe tener en cuenta las particiones. Dos visitas al mismo servicio integrado desde dos sitios superiores pueden generar dos estados locales sin representar a dos personas. Defina los informes según los eventos de aplicación completados, el consentimiento y la relación que el servicio tiene permiso para observar. No una identificadores particionados para reconstruir una vista entre sitios. Si hace falta un informe agregado, documente el propósito de medición, limite la retención y compruebe que la exclusión y la eliminación funcionan en cada contexto compatible.

Pruebe la recuperación de cuenta por separado. La página propia debe permitir recuperar acceso sin perder el trabajo introducido en la aplicación superior. El handoff debe caducar, no exponer credenciales en la URL y devolver solo el resultado necesario. Cubra cancelación, expiración, otra cuenta activa y reinicio del navegador con un siguiente paso claro.

La accesibilidad incluye el cambio de contexto. Anuncie que el panel necesita configuración, mueva el foco a un título útil después de la continuidad propia y conserve la posición del teclado al volver. Distinga acceso denegado, estado caducado y servicio no disponible con mensajes y controles de recuperación accesibles.

Trate cada conclusión de compatibilidad como una observación fechada. Registre versión y flujo propio, y revise cuando cambien navegador, proveedor de identidad, SDK o modelo de consentimiento. La documentación pública debe describir la tarea y la alternativa compatibles sin especular sobre la implementación interna.

Fuentes públicas

• MDN: State Partitioning
• Privacy Sandbox: Storage Partitioning