Chrome 115 introdujo cambios en el almacenamiento, los service workers y las APIs de comunicación mediante la partición en contextos de terceros. Además de estar aisladas por la política del mismo origen, las APIs afectadas que se usan en contextos de terceros también están aisladas por el sitio del contexto de nivel superior.
Los sitios que no tuvieron tiempo de implementar la compatibilidad con la partición 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 según el sitio de nivel superior) y restablecer el comportamiento anterior del almacenamiento, los service workers y las APIs de comunicación en el contenido incorporado en su sitio. Esta prueba de baja vencerá con el lanzamiento de Chrome 127 el 3 de septiembre de 2024. Ten en cuenta que esta acción es independiente de la prueba de baja para acceder a cookies de terceros, ya que es solo para acceder al almacenamiento.
Como solución a largo plazo para abordar ciertos casos de uso interrumpidos por la partición de almacenamiento de terceros sin cookies, Chrome propone la posibilidad de que terceros soliciten acceso al almacenamiento o a las comunicaciones (tanto con cookies como sin cookies) a través de la API de Storage Access (envío a partir de la versión 117 de Chrome), que ya permite que los terceros soliciten acceso a las cookies.
A partir de Chrome 120, esta propuesta estará disponible para la experimentación a través de una prueba de origen. Los desarrolladores deben participar en esta prueba de origen para evaluar cómo la solución propuesta aborda sus casos de uso y asegurarse de que estén preparados antes de que finalice la prueba de baja.
Detalles de la prueba de origen
A partir de Chrome 120, Chrome admitirá una prueba de origen, StorageAccessAPIBeyondCookies, para habilitar la extensión propuesta de la API de Storage Access (compatible con versiones anteriores) para permitir el acceso al almacenamiento no particionado (con cookies y no cookies) en un contexto de terceros.
mecánica
La API se puede utilizar de la siguiente manera (JavaScript que se ejecuta en un iframe incorporado):
// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);
Si solo deseas obtener acceso a la API específica en lugar del acceso a all, puedes pasar los nombres solo de los controladores de API que necesitas. Por ejemplo, puedes pasar {sessionStorage: true} para solo obtener acceso al almacenamiento de sesiones, o bien {indexedDB: true, locks:true} para obtener acceso a IndexedDB y Web Locks.
Más allá de llamar a esta extensión adicional, el acceso al almacenamiento sin cookies coincidiría con los requisitos actuales para el acceso de cookies a través de la API de Storage Access. Por ejemplo, en Chrome, no se muestra ningún mensaje cuando los orígenes se encuentran en el mismo Conjunto de sitios web relacionados (RWS, el nuevo nombre de los Conjuntos propios). Los orígenes que no forman parte del mismo RWS están sujetos a los requisitos de solicitudes de la API de Storage Access en Chrome.
Duración
La prueba de origen estará disponible desde Chrome 120 hasta Chrome 125 (o después del 6 de agosto de 2024 en cualquier versión importante).
Alcance
Solo el almacenamiento del DOM (almacenamiento local y de sesión), la base de datos indexada y los bloqueos web están disponibles en Chrome 120.
En Chrome 121, se agregaron el almacenamiento en caché, el sistema de archivos privados de origen, la cuota, el almacenamiento de BLOB y el canal de transmisión.
En Chrome 123, se agregaron los trabajadores compartidos y el control sobre la inclusión de cookies.
Los trabajadores dedicados heredan el acceso a cookies no particionadas si se llamó a requestStorageAccess antes de que se creara el trabajador a partir de Chrome 120 (esto no requiere el uso del controlador de la API de Storage Access).
Participación
- Evalúa cómo usas el almacenamiento con cookies y sin cookies en un contexto de terceros. Los casos de uso de ejemplo pueden ayudar a comprender si esta propuesta se adapta a tus necesidades.
- Inicia Chrome 120 (o una versión posterior) y asegúrate de que la marca test-third-party-cookie-phaseout esté habilitada.
- Si deseas probar la función localmente sin configurar primero un token de prueba de origen, puedes habilitar #enable-experimental-web-platform-features en tu navegador.
- Una vez que termines de realizar las pruebas a nivel local, puedes register para la prueba de origen StorageAccessAPIBeyondCookies y obtener un token para tus dominios. Para obtener instrucciones más detalladas, consulta Cómo comenzar a usar las pruebas de origen. La guía para solucionar problemas de las pruebas de origen de Chrome incluye una lista de tareas completa para garantizar que el token se haya configurado correctamente.
- Incorpora ese token de prueba de origen en el iframe en el que necesites usar el controlador de la API de Storage Access, mediante un encabezado HTTP, una metaetiqueta HTML o de manera programática. Ten en cuenta que el token debe estar incorporado en cualquier marco que desee usar esta API; incorporarlo en el marco superior no habilitará la API en los marcos secundarios.
- Llama a
document.requestStorageAccess(...)para obtener el controlador de la API de Storage Access en el iframe entre sitios. Consulta la documentación de la API de Storage Access a fin de conocer los requisitos para que esta llamada se ejecute correctamente. - Migra el almacenamiento relacionado en tu iframe para usar el controlador de la API de Storage Access si está disponible. Por ejemplo, las llamadas a
window.sessionStorage.setItem(...)se convierten enhandle.sessionStorage.setItem(...). - Abre tu sitio web y verifica que el identificador de acceso al almacenamiento funcione según lo previsto.
- Para dejar de participar en la prueba de origen, quita el token que agregaste en el paso 3.
- Envía comentarios o informa cualquier problema que encuentres en el repositorio de GitHub de almacenamiento sin cookies de la API de Storage Access.
Demostración: Cómo usar la API de Storage Access para acceder al almacenamiento local no particionado
La siguiente demostración muestra cómo acceder a canales de transmisión no particionados desde un iframe de terceros mediante la API de Storage Access:
https://saa-beyond-cookies.glitch.me/
La demostración requiere Chrome 121 o una versión posterior con la marca test-third-party-cookie-phaseout habilitada.