Instrucciones para la prueba de conjuntos propios

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

Los comentarios sobre el ecosistema destacaron casos de uso entre sitios que se verán afectados cuando las cookies de terceros dejen de admitirse en 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 puede expresarse al navegador, de modo que este pueda realizar la acción adecuada en nombre del usuario o presentar esa información de manera efectiva.

La propuesta actualizada usa dos APIs (la API de Storage Access y una API nueva llamada requestStorageAccessForOrigin provisoriamente) para proporcionar a los sitios un método activo de solicitar acceso entre sitios para sus cookies en un conjunto propio. Las siguientes instrucciones deberían permitirte probar y validar los conjuntos que deseas crear para tus sitios, así como los puntos correctos para llamar a las dos APIs diferentes.

Descripción general de 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 el acceso limitado a cookies entre sitios con 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 cuando se encuentre en un contexto de terceros.

En términos generales, un conjunto propio es un conjunto de dominios para el cual existe un solo conjunto "principal" y quizás varios “miembros del conjunto”. Solo los autores de sitios pueden enviar sus dominios a un conjunto y deberán declarar la relación entre cada "miembro del conjunto" a su “establecer principal”. Los miembros del conjunto pueden incluir una variedad de tipos de dominios diferentes con subconjuntos según los casos de uso.

Para facilitar la administración de cada subconjunto por parte del navegador de acuerdo con las implicaciones de privacidad de cada uno, proponemos aprovechar la API de acceso a almacenamiento (SAA) y requestStorageAccessForOrigin para habilitar el acceso de cookies en un FPS.

Con el SAA, los sitios pueden solicitar activamente acceso de cookies entre sitios. Chrome otorgará automáticamente la solicitud si el sitio solicitante y el sitio web de nivel superior están 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 SAA.

Actualmente, 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 secuencias de comandos que requieren cookies. Para abordar algunos de estos desafíos, propusimos una nueva API, requestStorageAccessForOrigin, con el objetivo de que los desarrolladores puedan adoptar este cambio con mayor facilidad. Esta API también está disponible para pruebas.

Configurar entrega

La lista canónica de FPS será una lista visible públicamente en un formato de archivo JSON alojada en un nuevo repositorio de FPS de GitHub, que funcionará como fuente de información para todos los conjuntos. Chrome usará 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.

Dado que 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 a fin de realizar pruebas con marcas de función.

Cómo realizar pruebas locales

Requisitos previos

Para probar los FPS de forma local, usa Chrome 108 o una versión posterior iniciado 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 el FPS de forma local, debes usar la opción --enable-features de Chrome con una lista de marcas separadas por comas que se explican en esta sección y declarar un conjunto de sitios relacionados como un objeto JSON para pasar a --use-first-party-set.

Habilitar FPS

FirstPartySets habilita los FPSs en Chrome.

FirstPartySets

Habilita la API de Storage Access

StorageAccessAPI

Habilita la API de Storage Access (SAA) en Chrome, 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 llama a requestStorageAccess(), se requiere un gesto del usuario para resolver el problema. Es posible que las versiones futuras de Chrome impongan diferentes conjuntos de requisitos, ya que la especificación de SAA sigue evolucionando. Consulte aquí la lista de las mejoras planificadas para la implementación de la SAA 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 resulta útil para los sitios de nivel superior que utilizan imágenes entre sitios o etiquetas de secuencias de comandos que requieren cookies y aborda algunos de los desafíos en la adopción de SAA.

Declara un conjunto de manera local

Un conjunto propio es un conjunto de dominios para el que hay un solo conjunto "establecer principal" y quizás varios “miembros del conjunto”. Los miembros del conjunto pueden incluir una variedad de tipos de dominios diferentes con subconjuntos según los casos de uso.

Crea un objeto JSON que contenga las 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 realizar pruebas locales, solo puedes crear conjuntos en la línea de comandos y pasarlos directamente al navegador. Para fines de prueba local, no habrá una validación de conjuntos de FPS, pero cuando el FPS se envía en versiones estables, todos los conjuntos deben enviarse al repositorio de GitHub de FPS y estar sujetos a criterios de validación.

Habilitar 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 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).

Cómo verificar 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 "Bloquear cookies de terceros" esté habilitado.
  3. Comprueba que la subopción "Permitir que los sitios relacionados vean tu actividad en el grupo" también está habilitada.

Consideraciones de seguridad

Dado que la API de Storage Access permite que los sitios web recuperen el acceso a cookies de terceros en casos seleccionados, es posible que las aplicaciones web sean susceptibles de ataques entre sitios y filtraciones de información. Los sitios que dependen de cookies en contextos entre sitios deben estar al tanto 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 aceptación explícita de las incorporaciones. Las mejoras propuestas serían: solo otorgar acceso por fotograma, requerir CORS en solicitudes con credenciales y mantener el alcance de acceso solo al origen. Obtén más información en el análisis de seguridad reciente.

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

Ten en cuenta que Chrome solo envía cookies marcadas con SameSite=None en contextos incorporados entre sitios, que es donde es relevante la API de Storage Access. Sin embargo, no se puede suponer dónde se puede usar la cookie hasta que todos los navegadores dejen de estar disponibles el acceso predeterminado a esas cookies. No es seguro suponer que el acceso solo se permitirá dentro de un FPS, y los sitios deberían seguir usando las prácticas recomendadas de seguridad estándar.

Interactúa y comparte tus comentarios

Las pruebas locales son una oportunidad para probar el mecanismo de la API de Storage Access para habilitar el FPS y compartir comentarios o problemas que encuentres. Además, probar el proceso de envío de conjuntos 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: