Chrome 130 presenta cambios en la API de Shared Storage para permitir el uso de secuencias de comandos de worklet de origen cruzado con createWorklet() y addModule(). También presentamos actualizaciones de la API de Select URL con Shared Storage en Chrome 132 con compatibilidad con consultas guardadas.
Worklets entre dominios con la API de Shared Storage en Chrome 130
Realizamos cambios en la API de Shared Storage en Chrome 130 para brindarte más flexibilidad cuando trabajes con secuencias de comandos de worklet entre orígenes.
Qué cambió
Quitamos la restricción de mismo origen para addModule(), por lo que ahora puedes cargar secuencias de comandos de worklet desde cualquier origen. Las secuencias de comandos de worklet multiorigen habilitan casos de uso clave, como alojar secuencias de comandos de worklet en CDN. Cuando la secuencia de comandos de worklet es de origen cruzado con el contexto de navegación de invocación, el origen del contexto de invocación se usa como el origen de la partición de datos para acceder al almacenamiento compartido.
Para que coincida con el nuevo comportamiento de addModule() y reducir la posible confusión, se agregó la propiedad dataOrigin a la llamada createWorklet() para permitir la lectura y escritura en una partición de datos de almacenamiento compartido que sea diferente del contexto de navegación de invocación. Esto te brinda un control más detallado sobre el almacenamiento compartido de cada origen al que accede cada worklet, incluso cuando se usan secuencias de comandos de worklet de varios orígenes.
Cómo cambió
A partir de Chrome 125, una secuencia de comandos de terceros de origen cruzado en una página puede invocar createWorklet(url) para crear worklets de origen cruzado sin necesidad de iframes de origen cruzado. Anteriormente, createWorklet(url) usaba el origen de la URL de la secuencia de comandos (url) como el origen de la partición de datos, independientemente del contexto de invocación.
En Chrome 130, para alinearse con el nuevo comportamiento de addModule(), createWorklet() también usa el contexto de invocación como el origen predeterminado de la partición de datos. Para seguir usando el origen de la URL de la secuencia de comandos como el origen de la partición de datos, se presenta una nueva propiedad dataOrigin que te permite establecer explícitamente el origen de la partición de datos.
La nueva propiedad dataOrigin acepta "script-origin", que establece el origen de la partición de datos como el origen de la secuencia de comandos, y "context-origin", que establece el origen de la partición de datos como el origen del contexto de navegación de invocación. En una versión futura, también planeamos admitir orígenes de particiones de datos personalizados, en los que una secuencia de comandos de worklet puede acceder a datos de almacenamiento compartidos desde un origen arbitrario de forma opcional.
Cuando se carga una secuencia de comandos de varios orígenes con el origen de datos establecido en "script-origin", la solicitud de la secuencia de comandos que se envía desde el navegador incluirá un encabezado "Sec-Shared-Storage-Data-Origin: <origin>". Para habilitar esto, la secuencia de comandos también debe incluir el encabezado de respuesta de habilitación "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1".
How to use
Si ya usas createWorklet() con el origen de la secuencia de comandos como el origen de la partición de datos del worklet, puedes configurar dataOrigin de la siguiente manera:
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
Dado que createWorklet() permite la creación de una partición de datos de varios orígenes y la creación de varios worklets, te recomendamos que realices la transición a createWorklet() en lugar de usar addModule().
Actualizamos la documentación para desarrolladores para reflejar estos cambios y brindar más orientación.
Búsquedas guardadas con la API de Select URL en Chrome 132
Presentamos actualizaciones de la API de Select URL con Shared Storage en Chrome 132 con compatibilidad con consultas guardadas.
Qué cambiará
Actualmente, la API de Select URL tiene dos presupuestos por carga de página que restringen la cantidad de llamadas que se realizan a la API en cada carga de página. Presentamos la capacidad de guardar y volver a usar consultas por página. Cuando usas una consulta guardada, los presupuestos por carga de página se cobran la primera vez que se ejecuta una consulta guardada, pero no para las ejecuciones posteriores de la consulta guardada durante la misma carga de página.
Cómo implementar las consultas guardadas
A partir de la versión 132 de Chrome, puedes usar el parámetro savedQuery en las opciones de selectURL() con el nombre de la consulta:
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
Usa el mismo nombre de savedQuery para cada llamada a selectURL() para asegurarte de que las consultas de seguimiento se carguen al mismo presupuesto.
Actualizamos la documentación para reflejar estos cambios y proporcionar detalles adicionales sobre el presupuesto de selectURL().
Interactúa y comparte comentarios
Ten en cuenta que la propuesta de la API de Shared Storage está en discusión y desarrollo activo y, por lo tanto, está sujeta a cambios.
Nos encantaría conocer tu opinión sobre la API de Shared Storage.
- Propuesta: Revisa la propuesta detallada.
- Debate: Únete al debate en curso para hacer preguntas y compartir tus estadísticas.
Mantente al tanto
- Lista de distribución: Suscríbete a nuestra lista de distribución para recibir las actualizaciones y los anuncios más recientes relacionados con la API de Shared Storage.
¿Necesitas ayuda?
- Asistencia para desarrolladores: Conéctate con otros desarrolladores y obtén respuestas a tus preguntas en el repositorio de asistencia para desarrolladores de Privacy Sandbox.