Para evitar ciertos tipos de seguimiento entre sitios de canales laterales, Chrome particiona la mayoría de las APIs de almacenamiento y comunicaciones 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 un análisis más detallado.
Los sitios que no tuvieron tiempo de implementar compatibilidad con particiones de almacenamiento de terceros pueden participar en una prueba de baja para anular la partición de forma temporal (continuar con el aislamiento según la política del mismo origen, pero quitar el aislamiento por sitio de nivel superior) y restablecer el comportamiento anterior del almacenamiento, los service worker y las APIs de comunicación en el contenido incorporado en su sitio.
¿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 en diferentes sitios para rastrear al 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 Timing Attacks, XS-Leaks y COSI.
Históricamente, el almacenamiento ha sido clave únicamente por el origen. Eso significa que, si un iframe de example.com
está incorporado en a.com
y b.com
, podría aprender sobre tus hábitos de navegación para 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 otra para b.com
.
Por lo general, la partición significa que los datos almacenados mediante las APIs de almacenamiento, como el almacenamiento local e IndexedDB por iframe, ya no son accesibles para todos los contextos del mismo origen. En cambio, los datos solo están disponibles para contextos con el mismo origen y el mismo sitio de nivel superior.
Antes
Después
Partición de almacenamiento en iframes encadenados
Cuando un iframe contiene un iframe, comienza a complicarse. Esto se aplica en especial 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 tanto A1 como A2 están en el mismo sitio. Si solo consideramos los contextos de nivel superior y actual al realizar la partición, el iframe A2 podría considerarse de origen, ya que está en el mismo sitio que el de nivel superior (A1), a pesar del iframe de terceros (B) que interviene. Esto podría abrir a A2 a riesgos de seguridad como la captura de clics si A2 tuviera acceso al almacenamiento no particionado de forma predeterminada.
Para abordar este problema, Chrome incluye un “bit principal” adicional como parte de la clave de partición de almacenamiento, que se establece si algún documento entre el contexto actual y el de nivel superior coincide con el contexto actual. En este caso, el sitio B es entre sitios, por lo que el bit se configuraría para A2 y su almacenamiento se particionaría desde A1.
Cuando no hay un contexto de varios sitios en la cadena, el almacenamiento no está particionado. Por ejemplo, un sitio A1 que contenga un iframe para A2 y un iframe para A3 no se particionaría para A1, A2 ni A3, ya que todos están en el mismo sitio.
Para los sitios que necesitan acceso no particionado a través de iframes en cadena, 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 explícitamente la API, esto mitiga el riesgo de clickjacking.
APIs actualizadas
Las APIs afectadas por la partición se pueden dividir en las siguientes agrupaciones:
APIs de Storage
- Sistema de cuotas
- El sistema de cuotas se usa con el fin de 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, comowindow.webkitStorageInfo
ynavigator.webkitTemporaryStorage
, dejarán de estar disponibles.- IndexedDB y Cache Storage usan el nuevo sistema de cuotas particionado.
- API de Web Storage
- La API de Web Storage proporciona mecanismos mediante los cuales los navegadores pueden almacenar pares clave-valor. Existen dos mecanismos: Almacenamiento local y Almacenamiento de sesiones. Por el momento, no están administrados por cuotas, pero siguen particionados.
- Sistema de archivos privados de origen
- La API de Acceso al sistema de archivos permite que un sitio lea o guarde los cambios directamente en los archivos y las 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 pueda acceder con facilidad y que esté particionado.
- 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, a través de un concepto nuevo llamado buckets. Se particionan los datos almacenados en los buckets y los metadatos asociados a ellos.
- 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 del DOM. Cuando se usa el encabezado, solo se borra el almacenamiento en una partición.
- Almacén de URL de BLOB
- Un blob es un objeto que contiene datos sin procesar que se deben procesar y se puede generar una URL de BLOB para acceder al recurso. Los almacenes de URL de BLOB no están particionados. Para admitir un caso de uso destinado a navegar en un contexto de nivel superior a cualquier URL de BLOB (grupo de discusión), el clúster de agente puede particionar el almacén de URL de BLOB en lugar de hacerlo por el sitio de nivel superior. Esta función aún no está disponible para pruebas, y el mecanismo de partición podría 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 descubrir otros contextos a través de transmisiones o citas del mismo origen.
Para las siguientes APIs de comunicación, el iframe de terceros ya no puede comunicarse con su contexto del mismo 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 los trabajadores del mismo origen.
- No se propone cambiar el iframe
postMessage()
entre sitios, en el que la relación entre contextos está claramente definida.
- SharedWorker
- La API de SharedWorker proporciona un trabajador al que se puede acceder en distintos 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 trabajador del mismo origen adquiera un bloqueo para un recurso compartido mientras se realiza una parte del 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 contexto de trabajador nuevo para responder a los eventos, y ese trabajador puede comunicarse con cualquier contexto de mismo origen. Además, la API de Service Worker puede cambiar el tiempo de las solicitudes de navegación, lo que posibilita que se produzcan filtraciones de información entre sitios, como el análisis de historiales.
Por lo tanto, los Service Workers registrados en un contexto de terceros están particionados.
APIs de extensiones
Las extensiones son programas que permiten a los usuarios personalizar su experiencia de navegación.
Las páginas de extensiones (páginas con un esquema chrome-extension://
) se pueden incorporar en sitios de toda 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 las extensiones.
Demostración: Prueba de la partición de almacenamiento
Sitio de demostración: https://storage-partitioning-demo-site-a.glitch.me/
La demostración usa dos sitios: el sitio A y el sitio B.
- Cuando visitas el sitio A en el contexto de nivel superior, este establece datos mediante varios métodos de almacenamiento.
- El sitio B inserta una página del sitio A, y este 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 se particiona el almacenamiento, por lo que fallan las lecturas.
- La demostración utiliza el éxito o el fracaso de cada lectura para mostrar si los datos están particionados.
Por ahora, puedes desactivar la partición de almacenamiento en Chrome. Para ello, configura la función experimental chrome://flags/#third-party-storage-partitioning
de Chrome en disabled
a fin de confirmar que no pasa la prueba de partición.
También puedes probar otros navegadores de la misma manera para ver el estado de partición.
Interactúa y comparte comentarios
- GitHub: Lee la propuesta original, genera preguntas y participa en debates.
- Asistencia para desarrolladores: Haz preguntas y únete a debates en el repositorio de asistencia para desarrolladores de Privacy Sandbox.
- Informa errores: Informa un error en la herramienta de seguimiento de Chromium si crees que algo no funciona como se espera.