Particionamiento del almacenamiento

Para evitar ciertos tipos de seguimiento entre sitios de canales laterales, Chrome particionó la mayoría de las APIs de almacenamiento y comunicación en contextos de terceros.

Estado de implementación

La función se habilitó para todos los usuarios de Chrome 115 y versiones posteriores. La propuesta de partición de almacenamiento está abierta para que se siga analizando.

¿Qué es la partición de almacenamiento?

Para evitar ciertos tipos de seguimiento entre sitios de canales laterales, Chrome particiona las APIs de almacenamiento y comunicaciones en contextos de terceros.

Sin la partición de almacenamiento, un sitio puede unir datos de diferentes sitios para hacer un seguimiento del usuario en la Web. Además, permite que el sitio incorporado infiera estados específicos sobre el usuario en el sitio de nivel superior mediante técnicas de canal lateral, como ataques de sincronización, fugas de XS y COSI.

Históricamente, el almacenamiento se ha claveado solo por origen. Esto significa que, si un iframe de example.com está incorporado en a.com y b.com, podría obtener información sobre tus hábitos de navegación en esos dos sitios almacenando y recuperando correctamente un ID del almacenamiento. Con la partición de almacenamiento de terceros habilitada, el almacenamiento de example.com existe en dos particiones diferentes, una para a.com y la otra para b.com.

Por lo general, el particionamiento significa que los datos almacenados por las APIs de almacenamiento, como el almacenamiento local y IndexedDB a través de un iframe, ya no son accesibles para todos los contextos en el mismo origen. En cambio, los datos solo están disponibles para los contextos con el mismo origen y el mismo sitio de nivel superior.

Antes

Diagrama de APIs de almacenamiento sin particiones.
Antes de la partición de almacenamiento, example.com puede escribir datos cuando se incorpora en a.com y, luego, leerlos cuando se incorpora en b.com.

Después

Diagrama de las APIs de almacenamiento con particiones
Después de la partición del almacenamiento, example.com, cuando está incorporado en b.com, no puede acceder al almacenamiento de example.com cuando está incorporado en a.com.

Partición de almacenamiento en iframes encadenados

Cuando un iframe contiene un iframe, la situación se complica. Esto es así, en particular, cuando el mismo origen se encuentra en más de un lugar de la cadena.

Por ejemplo, A1 contiene un iframe para B que contiene un iframe para A2, y A1 y A2 están en el mismo sitio. Si solo consideramos los contextos de nivel superior y de nivel actual cuando se particiona, el iframe A2 se podría considerar propio, ya que se encuentra en el mismo sitio que el de nivel superior (A1), a pesar del iframe de terceros (B) que interviene. Esto podría exponer a A2 a riesgos de seguridad, como el robo de clics, si A2 tuviera acceso al almacenamiento sin particionar de forma predeterminada.

Para abordar este problema, Chrome incluye un "bit de ancestro" adicional como parte de la clave de partición de almacenamiento, que se establece si algún documento entre el contexto actual y el contexto de nivel superior es entre sitios. En este caso, el sitio B es multisitio, por lo que el bit se establecería para A2 y su almacenamiento se particionaría desde A1.

Cuando no hay contexto entre sitios en la cadena, el almacenamiento no se particiona. Por ejemplo, el sitio A1 que contiene un iframe para A2 que contiene un iframe para A3 no se particionaría para A1, A2 ni A3, ya que todos están en el mismo sitio.

En el caso de los sitios que necesitan acceso sin particiones en iframes encadenados, Chrome está experimentando con la extensión de la API de Storage Access para habilitar este caso de uso. Como la API de Storage Access requiere que el sitio enmarcado invoque la API de forma explícita, esto mitiga el riesgo de ataque de suplantación de clics.

APIs actualizadas

Las APIs afectadas por el particionamiento se pueden dividir en los siguientes grupos:

APIs de Storage

  • Sistema de cuotas
    El sistema de cuotas se usa para determinar cuánto espacio en disco se asigna para el almacenamiento. El sistema de cuotas administra cada partición como un bucket independiente para determinar cuánto espacio se permite y cuándo se borra.
    navigator.storage.estimate() muestra la información de la partición. Las APIs exclusivas de Chrome, como window.webkitStorageInfo y navigator.webkitTemporaryStorage, dejarán de estar disponibles.
    IndexedDB y el almacenamiento en caché usan el nuevo sistema de cuotas particionadas.
  • API de Web Storage
    La API de Web Storage proporciona mecanismos a través de los cuales los navegadores pueden almacenar pares clave-valor. Existen dos mecanismos: el almacenamiento local y el almacenamiento de la sesión. Actualmente, no se administran con cuotas, pero aún se particionan.
  • Sistema de archivos privados de Origin
    La API de acceso al sistema de archivos permite que un sitio lea o guarde cambios directamente en archivos y carpetas del dispositivo después de que el usuario otorga acceso. El sistema de archivos privados de origen permite que un origen almacene contenido privado en el disco al que el usuario puede acceder fácilmente y que se particiona.
  • API de Storage Bucket
    La API de Storage Bucket se está desarrollando para Storage Standard, que consolida varias APIs de almacenamiento, como IndexedDB y localStorage, con un nuevo concepto llamado buckets. Los datos almacenados en los buckets y los metadatos asociados con ellos se particionan.
  • Encabezado Clear-Site-Data
    Incluir el encabezado Clear-Site-Data en la respuesta permite que un servidor solicite borrar los datos almacenados en el navegador del usuario. Se pueden borrar la caché, las cookies y el almacenamiento DOM. El uso del encabezado solo borra el almacenamiento dentro de una partición.
  • Almacenamiento de URL de BLOB
    Un blob es un objeto que contiene datos sin procesar que se procesarán, y se puede generar una URL de blob para acceder al recurso. Los almacenes de URLs de BLOB no se particionan. Para admitir un caso de uso de navegación en un contexto de nivel superior a cualquier URL de blob (discusión), el clúster de agentes puede particionar el almacén de URLs de blob en lugar del sitio de nivel superior. Esta función aún no está disponible para pruebas, y el mecanismo de partición puede cambiar en el futuro.

APIs de comunicación

Junto con las APIs de almacenamiento, también se particionan las APIs de comunicación que permiten que un contexto se comunique a través de los límites de origen. Los cambios afectan principalmente a las APIs que permiten el descubrimiento de otros contextos a través de la transmisión o la reunión del mismo origen.

En el caso de las siguientes APIs de comunicación, los iframes de terceros ya no pueden comunicarse con su contexto de origen:

  • Canal de transmisión
    La API de
    Broadcast Channel permite la comunicación entre contextos de navegación (ventanas, pestañas o iframes) y trabajadores del mismo origen.
    No se propone cambiar el iframe entre sitios postMessage() en el que la relación entre los con textos está claramente definida.
  • SharedWorker
    La API de
    SharedWorker proporciona un trabajador al que se puede acceder en todos los contextos de navegación del mismo origen.
  • Bloqueos web
    La API de Web Locks permite que el código que se ejecuta en una pestaña o un trabajador del mismo origen adquiera un bloqueo para un recurso compartido mientras se realiza algún trabajo.

API de Service Worker

La API de Service Worker proporciona la interfaz para realizar tareas en segundo plano. Los sitios crean registros persistentes que crean un nuevo contexto de trabajador para responder a eventos, y ese trabajador puede comunicarse con cualquier contexto de origen. Además, la API de Service Worker puede cambiar el tiempo de las solicitudes de navegación, lo que puede generar filtraciones de información entre sitios, como el análisis de historial.

Por lo tanto, los trabajadores de servicio registrados desde un contexto de terceros se particionan.

APIs de Extension

Las extensiones son programas que permiten a los usuarios personalizar su experiencia de navegación.

Las páginas de extensión (páginas con un esquema chrome-extension://) se pueden incorporar en sitios de la Web y, en estos casos, seguirán teniendo acceso a su partición de nivel superior. Estas páginas también pueden incorporar otros sitios, en cuyo caso esos sitios tendrán acceso a su partición de nivel superior, siempre y cuando la extensión tenga permisos de host para ese sitio.

Para obtener más información, consulta los documentos de la extensión.

Demostración: Prueba la partición de almacenamiento

Sitio de demostración: https://storage-partitioning-demo-site-a.glitch.me/

Captura de pantalla del sitio de demostración que muestra todas las marcas verdes a la izquierda y las cruces rojas a la derecha para cada prueba.
Captura de pantalla de la demostración, que muestra el resultado de un navegador con particiones de almacenamiento a la izquierda y sin particiones de almacenamiento a la derecha.

En la demostración, se usan dos sitios: el sitio A y el sitio B.

  • Cuando visitas el sitio A en el contexto de nivel superior, se establecen datos con varios métodos de almacenamiento.
  • El sitio B incorpora una página del sitio A y esa incorporación intenta leer las opciones de almacenamiento establecidas anteriormente.
  • Cuando el sitio A está incorporado en el sitio B, no tiene acceso a esos datos cuando el almacenamiento está particionado, por lo que las operaciones de lectura fallan.
  • La demostración usa el éxito o el error de cada operación de lectura para mostrar si los datos están particionados.

Por ahora, puedes desactivar la partición de almacenamiento en Chrome con el interruptor de línea de comandos --disable-features=ThirdPartyStoragePartitioning.

También puedes probar otros navegadores de la misma manera para ver su estado de partición.

Interactúa y comparte comentarios