Instrucciones para la prueba de conjuntos propios

La iteración más reciente de First-Party Sets está lista para que los desarrolladores realicen pruebas de marcas de función a partir de la versión 108 de Chrome. Estamos trabajando activamente en los conjuntos propios con el objetivo de avanzar hacia el envío, por lo que consideraremos los comentarios de esta fase de pruebas para desarrolladores hasta el lanzamiento de Chrome 111 a principios de marzo (7 de marzo de 2023).

Los comentarios del ecosistema destacaron los casos de uso entre sitios que se verán afectados cuando las cookies de terceros ya no sean compatibles con Chrome. La propuesta de conjuntos propios examina y aborda una clase de casos de uso entre sitios en los que los sitios interdependientes comparten una relación que se puede expresar al navegador para que este pueda tomar la acción adecuada en nombre del usuario o presentarle esa información de manera eficaz.

La propuesta actualizada usa dos APIs (la API de Storage Access y una nueva API llamada de forma provisional requestStorageAccessForOrigin) para proporcionar a los sitios un método activo de solicitud de acceso entre sitios para sus cookies dentro de un conjunto propio. Las instrucciones que se indican a continuación deberían permitirte probar y validar los conjuntos que podrías crear para tus sitios y los puntos correctos para llamar a las dos APIs diferentes.

Descripción general de los conjuntos propios

Los conjuntos propios (FPS) son un mecanismo de plataforma web para que los desarrolladores declaren relaciones entre sitios, de modo que los navegadores puedan usar esta información para habilitar un acceso limitado a las cookies entre sitios para fines específicos para el usuario. Chrome usará estas relaciones declaradas para decidir cuándo permitir o denegar el acceso de un sitio a sus cookies en un contexto de terceros.

En un nivel alto, un conjunto propio es una colección de dominios, para los cuales hay un solo "conjunto principal" y, potencialmente, varios "miembros del conjunto". Solo los autores del sitio pueden enviar sus dominios a un conjunto y deberán declarar la relación entre cada "miembro del conjunto" y su "conjunto principal". Los miembros del conjunto pueden incluir una variedad de diferentes tipos de dominios con subconjuntos basados en casos de uso.

Para facilitar el manejo de cada subconjunto por parte del navegador según las implicaciones de privacidad de cada uno, proponemos aprovechar la API de acceso a almacenamiento (SAA) y requestStorageAccessForOrigin para habilitar el acceso a cookies dentro de un FPS.

Con el SAA, los sitios pueden solicitar acceso a cookies de varios sitios de forma activa. Chrome otorgará automáticamente la solicitud si el sitio solicitante y el sitio web de nivel superior se encuentran en el mismo FPS. Consulta la documentación de la API de Storage Access (SAA) para obtener información sobre cómo otros navegadores procesan las llamadas a la SAA.

Actualmente, la SAA requiere que el documento obtenga la activación del usuario antes de llamar a los métodos de la API.

Esto puede hacer que la adopción de FPS sea un desafío para los sitios de nivel superior que usan imágenes entre sitios o etiquetas de secuencia de comandos que requieren cookies. Para abordar algunos de estos desafíos, propusimos una nueva API, requestStorageAccessForOrigin, para que los desarrolladores puedan adoptar este cambio con mayor facilidad. Esta API también está disponible para pruebas.

Cómo configurar el envío

La lista canónica de FPS será una lista visible para el público en formato de archivo JSON alojada en un nuevo repositorio de GitHub de FPS, que servirá como fuente de información de todos los conjuntos. Chrome consumirá este archivo para aplicarlo a su comportamiento.

Para obtener más información sobre el proceso propuesto y los requisitos para enviar conjuntos, consulta los lineamientos de envío. También puedes enviar un conjunto para probar las diversas verificaciones técnicas que validarán los envíos. Ten en cuenta que se borrarán todos los envíos antes de que los FPS estén disponibles en las versiones estables de Chrome.

Como el proceso de envío de conjuntos aún está en desarrollo activo, para las pruebas locales, solo puedes crear conjuntos en la línea de comandos y pasarlos directamente al navegador. Para las pruebas locales, no es necesario enviar un conjunto al repositorio de GitHub para probar con marcas de funciones.

Cómo realizar pruebas de forma local

Requisitos previos

Para probar los FPS de forma local, usa Chrome 108 o una versión posterior desde la línea de comandos.

Para obtener una vista previa de las próximas funciones de Chrome antes de su lanzamiento, descarga la versión beta o Canary de Chrome.

Ejemplo

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Obtén más información para ejecutar Chromium con marcas.

Pasos

Para habilitar los FPS de forma local, debes usar la opción --enable-features de Chrome con una lista de marcas separadas por comas que se explica en esta sección y declarar un conjunto de sitios relacionados como un objeto JSON para pasar a --use-first-party-set.

Habilita FPS

FirstPartySets habilita los FPS en Chrome.

FirstPartySets

Habilita la API de Storage Access

StorageAccessAPI

Habilita la API de Storage Access (SAA) en Chrome, lo que permite que los iframes incorporados usen requestStorageAccess() para solicitar acceso a las cookies en un contexto de varios sitios, incluso cuando el navegador bloquea las cookies de terceros.

Ten en cuenta que, cuando se lo llama, requestStorageAccess() requiere un gesto del usuario para resolverse. Es posible que las versiones futuras de Chrome impongan diferentes conjuntos de requisitos, ya que la especificación de la SAA aún está en evolución. Consulta aquí para obtener una lista de las mejoras planificadas en la implementación del SAA por parte de Chrome.

StorageAccessAPIForOriginExtension

Permite que los sitios de nivel superior usen requestStorageAccessForOrigin() para solicitar acceso al almacenamiento en nombre de orígenes específicos. Esto es útil para los sitios de nivel superior que usan imágenes o etiquetas de secuencias de comandos entre sitios que requieren cookies y aborda algunos de los desafíos de la adopción de la SAA.

Cómo declarar un conjunto de forma local

Un conjunto propio es una colección de dominios para los que hay un solo "conjunto principal" y, potencialmente, varios "miembros del conjunto". Los miembros del conjunto pueden incluir una variedad de tipos de dominios diferentes con subconjuntos basados en casos de uso.

Crea un objeto JSON que contenga URLs que sean miembros de un conjunto y pásalo a --use-first-party-set.

En el siguiente ejemplo, primary enumera el dominio principal y associatedSites enumera los dominios que cumplen con los requisitos del subconjunto asociado.

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Ejemplo:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

Para las pruebas locales, solo puedes crear conjuntos en la línea de comandos y pasarlos directamente al navegador. Para las pruebas locales, no habrá validación de conjuntos, pero cuando los FPS se envíen en versiones estables, todos los conjuntos deberán enviarse al repositorio de GitHub de FPS y estarán sujetos a criterios de validación.

Habilita la IU de FPS

PageInfoCookiesSubpage

Permite mostrar los FPS en la sección PageInfo a la que se puede acceder desde la barra de URL.

PrivacySandboxFirstPartySetsUI

Habilita la opción de la IU de FPS "Permitir que los sitios relacionados vean tu actividad en el grupo" en la configuración de Chrome, en Privacidad y seguridad → Cookies y otros datos de sitios (chrome://settings/cookies).

Verifica que las cookies de terceros estén bloqueadas

  1. En la configuración de Chrome, ve a Privacidad y seguridad → Cookies y otros datos de sitios o chrome://settings/cookies.
  2. En Configuración general, asegúrate de que la opción "Bloquear cookies de terceros" esté habilitada.
  3. Verifica que también esté habilitada la opción secundaria "Permitir que los sitios relacionados vean tu actividad en el grupo".

Consideraciones de seguridad

Dado que la API de Storage Access permite que los sitios web recuperen el acceso a las cookies de terceros en casos específicos, es posible que las aplicaciones web sean vulnerables a ataques entre sitios y filtraciones de información. Los sitios que dependen de cookies en contextos de varios sitios deben ser conscientes de los riesgos de CSRF y otros ataques.

Mejoras planificadas

Para mejorar esto, las próximas versiones de Chrome requerirán controles de seguridad adicionales, con el objetivo de garantizar la habilitación explícita de los elementos incorporados. Las mejoras propuestas solo otorgarían acceso por fotograma, requerirían CORS en las solicitudes con credenciales y mantendrían el alcance de acceso solo al origen. Puedes obtener más información en el análisis de seguridad reciente.

Consulta la lista de mejoras planificadas para la implementación del SAA en Chrome.

Ten en cuenta que Chrome solo envía cookies marcadas como SameSite=None en contextos incorporados en varios sitios, que es donde la API de Storage Access es relevante. Sin embargo, hasta que todos los navegadores dejen de admitir el acceso predeterminado a esas cookies, no se pueden hacer suposiciones sobre dónde se podría usar la cookie. No es seguro suponer que el acceso solo se permitiría dentro de un FPS, y los sitios deben seguir usando las prácticas recomendadas de seguridad estándar.

Interactúa y comparte comentarios

Las pruebas locales son una oportunidad para probar el mecanismo de la API de Storage Access para habilitar los FPS y compartir comentarios o cualquier problema que encuentres. Además, probar el proceso de envío establecido en GitHub es una oportunidad para compartir tu experiencia con el proceso y los pasos de validación. Para interactuar y compartir comentarios sobre la propuesta actualizada, sigue estos pasos: