Conjuntos de sitios web relacionados: guía para desarrolladores

Los conjuntos de sitios web relacionados (RWS) son un mecanismo de plataforma web que ayuda a los navegadores a comprender las relaciones entre un conjunto de dominios. Esto permite que los navegadores tomen decisiones clave para habilitar ciertas funciones del sitio (como permitir el acceso a cookies entre sitios) y presentar esta información a los usuarios.

A medida que Chrome da de baja las cookies de terceros, su objetivo es mantener los casos de uso clave en la Web y, al mismo tiempo, mejorar la privacidad de los usuarios. Por ejemplo, muchos sitios dependen de varios dominios para publicar una sola experiencia del usuario. Es posible que las organizaciones deseen mantener diferentes dominios de nivel superior para varios casos de uso, como dominios específicos de países o dominios de servicios para alojar imágenes o videos. Los conjuntos de sitios web relacionados permiten que los sitios compartan datos entre dominios con controles específicos.

¿Qué es un conjunto de sitios web relacionados?

En términos generales, un conjunto de sitios web relacionados es un conjunto de dominios para los que hay un solo "conjunto principal" y, potencialmente, varios "miembros del conjunto".

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"]
}

La lista canónica de conjuntos de sitios web relacionados es una lista visible para el público en formato de archivo JSON alojada en el repositorio de GitHub de conjuntos de sitios web relacionados, que sirve como fuente de información para todos los conjuntos. Chrome consume este archivo para aplicarlo a su comportamiento.

Solo las personas con control administrativo sobre un dominio pueden crear un conjunto con ese dominio. Los remitentes deben declarar la relación entre cada "miembro del conjunto" y su "conjunto principal". Los miembros del conjunto pueden incluir un rango de diferentes tipos de dominios y deben ser parte de un subconjunto basado en un caso de uso.

Si tu aplicación depende del acceso a cookies entre sitios (también llamadas cookies de terceros) en sitios del mismo conjunto de sitios web relacionados, puedes usar la API de acceso al almacenamiento (SAA) y la API de requestStorageAccessFor para solicitar acceso a esas cookies. Según el subconjunto del que forma parte cada sitio, el navegador puede controlar la solicitud de manera diferente.

Para obtener más información sobre el proceso y los requisitos para enviar conjuntos, consulta los lineamientos de envío. Los conjuntos enviados pasarán por varias verificaciones técnicas para validar los envíos.

Casos de uso de los Conjuntos de sitios web relacionados

Los conjuntos de sitios web relacionados son una buena opción para los casos en los que una organización necesita una forma de identidad compartida en diferentes sitios de nivel superior.

Estos son algunos de los casos de uso de los Conjuntos de sitios web relacionados:

• Personalización por país: Aprovechar los sitios localizados y, al mismo tiempo, depender de la infraestructura compartida (example.co.uk puede depender de un servicio alojado por example.ca)
• Integración de dominios de servicios. Aprovechar los dominios de servicio con los que los usuarios nunca interactúan directamente, pero que proporcionan servicios en los sitios de la misma organización (example-cdn.com)
• Separación del contenido del usuario: Acceder a datos en diferentes dominios que separan el contenido subido por el usuario del contenido de otros sitios por motivos de seguridad, a la vez que permite que el dominio en zona de pruebas acceda a cookies de autenticación (y otras) Si publicas contenido inactivo que subieron los usuarios, es posible que también puedas alojarlo de forma segura en el mismo dominio siguiendo las prácticas recomendadas.
• Contenido autenticado incorporado: Admite contenido incorporado de todas las propiedades afiliadas (videos, documentos o recursos restringidos al usuario que accedió en el sitio de nivel superior).
• Accede. Admite el acceso en propiedades afiliadas. La API de FedCM también puede ser adecuada para algunos casos de uso.
• Analytics. Implementación de análisis y medición de los recorridos de los usuarios en las propiedades afiliadas para mejorar la calidad de los servicios

Detalles de la integración de Conjuntos de sitios web relacionados

API de Storage Access

La API de Storage Access (SAA) proporciona una forma para que el contenido incorporado de varios orígenes acceda al almacenamiento al que, por lo general, solo tendría acceso en un contexto propio.

Los recursos incorporados pueden usar métodos de SAA para verificar si actualmente tienen acceso al almacenamiento y solicitar acceso al usuario-agente.

Cuando se bloquean las cookies de terceros, pero se habilitan los conjuntos de sitios web relacionados (RWS), Chrome otorgará automáticamente el permiso en contextos intra-RWS y, de lo contrario, mostrará un mensaje al usuario. (Un "contexto intra-RWS" es un contexto, como un iframe, cuyo sitio incorporado y el sitio de nivel superior se encuentran en el mismo RWS).

Cómo verificar y solicitar acceso al almacenamiento

Para verificar si tienen acceso al almacenamiento, los sitios incorporados pueden usar el método Document.hasStorageAccess().

El método muestra una promesa que se resuelve con un valor booleano que indica si el documento ya tiene acceso a sus cookies o no. La promesa también muestra un valor verdadero si el iframe tiene el mismo origen que el marco superior.

Para solicitar acceso a cookies en un contexto de varios sitios, los sitios incorporados pueden usar Document.requestStorageAccess() (rSA).

Se debe llamar a la API de requestStorageAccess() desde un iframe. Ese iframe debe haber recibido la interacción del usuario (un gesto del usuario, que es obligatorio para todos los navegadores), pero Chrome también requiere que, en algún momento de los últimos 30 días, el usuario haya visitado el sitio al que pertenece ese iframe y haya interactuado con él específicamente, como un documento de nivel superior, no en un iframe.

requestStorageAccess() muestra una promesa que se resuelve si se otorgó el acceso al almacenamiento. La promesa se rechaza y se indica el motivo si se denegó el acceso por algún motivo.

requestStorageAccessFor en Chrome

La API de Storage Access solo permite que los sitios incorporados soliciten acceso al almacenamiento desde elementos <iframe> que hayan recibido interacción del usuario.

Esto plantea desafíos para adoptar la API de Storage Access en sitios de nivel superior que usan imágenes entre sitios o etiquetas de secuencia de comandos que requieren cookies.

Para abordar este problema, Chrome implementó una forma para que los sitios de nivel superior soliciten acceso de almacenamiento en nombre de orígenes específicos con Document.requestStorageAccessFor() (rSAFor).

 document.requestStorageAccessFor('https://target.site')

La API de requestStorageAccessFor() está diseñada para que la llame un documento de nivel superior. Ese documento también debe haber recibido interacción del usuario. Sin embargo, a diferencia de requestStorageAccess(), Chrome no verifica si hubo una interacción en un documento de nivel superior durante los últimos 30 días porque el usuario ya está en la página.

Verifica los permisos de acceso al almacenamiento

El acceso a algunas funciones del navegador, como la cámara o la ubicación geográfica, se basa en los permisos que otorga el usuario. La API de Permissions proporciona una forma de verificar el estado de los permisos para acceder a una API, ya sea que se hayan otorgado, denegado o requieran algún tipo de interacción del usuario, como hacer clic en un mensaje o interactuar con la página.

Puedes consultar el estado de los permisos con navigator.permissions.query().

Para verificar el permiso de acceso al almacenamiento del contexto actual, debes pasar la cadena 'storage-access':

navigator.permissions.query({name: 'storage-access'})

Para verificar el permiso de acceso al almacenamiento de un origen especificado, debes pasar la cadena 'top-level-storage-access':

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

Ten en cuenta que, para proteger la integridad del origen incorporado, solo se verifican los permisos otorgados por el documento de nivel superior con document.requestStorageAccessFor.

Según si el permiso se puede otorgar automáticamente o requiere un gesto del usuario, se mostrará prompt o granted.

Modelo por fotograma

Las concesiones de rSA se aplican por marco. Las concesiones de rSA y rSAFor se tratan como permisos independientes.

Cada marco nuevo deberá solicitar acceso al almacenamiento de forma individual y se le otorgará acceso automáticamente. Solo la primera solicitud requiere un gesto del usuario. Las solicitudes posteriores que inicie el iframe, como la navegación o los subrecursos, no necesitarán esperar un gesto del usuario, ya que la solicitud inicial lo otorgará para la sesión de navegación.

Si actualizas, vuelves a cargar o vuelves a crear el iframe, deberás volver a solicitar acceso.

Requisitos de las cookies

Las cookies deben especificar los atributos SameSite=None y Secure, ya que la rSA solo proporciona acceso a las cookies que ya están marcadas para usarse en contextos de varios sitios.

Las cookies con SameSite=Lax, SameSite=Strict o sin un atributo SameSite son solo para uso propio y nunca se compartirán en un contexto de varios sitios, independientemente de la RSA.

Seguridad

Para rSAFor, las solicitudes de subrecursos requieren encabezados de uso compartido de recursos entre dominios (CORS) o el atributo crossorigin en los recursos, lo que garantiza la habilitación explícita.

Ejemplos de implementación

Solicita acceso al almacenamiento desde un iframe de origen cruzado incorporado

Cómo verificar si tienes acceso al almacenamiento

Para verificar si ya tienes acceso al almacenamiento, usa document.hasStorageAccess().

Si la promesa se resuelve como verdadera, puedes acceder al almacenamiento en el contexto entre sitios. Si se resuelve como falso, debes solicitar acceso al almacenamiento.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

Solicita acceso al almacenamiento

Si necesitas solicitar acceso al almacenamiento, primero verifica el permiso de acceso al almacenamiento navigator.permissions.query({name: 'storage-access'}) para ver si requiere un gesto del usuario o si se puede otorgar automáticamente.

Si el permiso es granted, puedes llamar a document.requestStorageAccess() y debería tener éxito sin un gesto del usuario.

Si el estado del permiso es prompt, debes iniciar la llamada a document.requestStorageAccess() después de un gesto del usuario, como hacer clic en un botón.

Ejemplo:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Las solicitudes posteriores desde el marco, las navegaciones o los subrecursos tendrán automáticamente permiso para acceder a las cookies entre sitios. hasStorageAccess() muestra un valor verdadero y las cookies entre sitios del mismo conjunto de sitios web relacionados se enviarán en esas solicitudes sin ninguna llamada adicional a JavaScript.

Sitios de nivel superior que solicitan acceso a cookies en nombre de sitios de origen cruzado

Los sitios de nivel superior pueden usar requestStorageAccessFor() para solicitar acceso de almacenamiento en nombre de orígenes específicos.

hasStorageAccess() solo verifica si el sitio que lo llama tiene acceso de almacenamiento, de modo que un sitio de nivel superior pueda verificar los permisos de otro origen.

Para descubrir si se le pedirá al usuario o si ya se otorgó acceso de almacenamiento al origen especificado, llama a navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}).

Si el permiso es granted, puedes llamar a document.requestStorageAccessFor('https://target.site'). Debería tener éxito sin un gesto del usuario.

Si el permiso es prompt, deberás conectar la llamada document.requestStorageAccessFor('https://target.site') detrás del gesto del usuario, como un clic en un botón.

Ejemplo:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Después de una llamada requestStorageAccessFor() correcta, las solicitudes entre sitios incluirán cookies si incluyen CORS o el atributo crossorigin, por lo que los sitios pueden esperar antes de activar una solicitud.

Las solicitudes deben usar la opción credentials: 'include' y los recursos deben incluir el atributo crossorigin="use-credentials".

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

Cómo realizar pruebas de forma local

Requisitos previos

Para probar los conjuntos de sitios web relacionados de forma local, usa Chrome 119 o una versión posterior desde la línea de comandos y habilita la marca de Chrome test-third-party-cookie-phaseout.

Habilita la marca de Chrome

Para habilitar la marca de Chrome necesaria, navega a chrome://flags#test-third-party-cookie-phaseout desde la barra de direcciones y cambia la marca a Enabled. Asegúrate de reiniciar el navegador después de cambiar las marcas.

Cómo iniciar Chrome con un conjunto de sitios web relacionados locales

Para iniciar Chrome con un conjunto de sitios web relacionados declarado de forma local, crea un objeto JSON que contenga URLs que sean miembros de un conjunto y pásalo a --use-related-website-set.

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

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Ejemplo

Para habilitar los conjuntos de sitios web relacionados de forma local, debes habilitar test-third-party-cookie-phaseout en chrome://flags y, luego, iniciar Chrome desde la línea de comandos con la marca --use-related-website-set y el objeto JSON que contiene las URLs que son miembros de un conjunto.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Verifica que tienes acceso a las cookies entre sitios

Llama a las APIs (rSA o rSAFor) desde los sitios que se están probando y valida el acceso a las cookies entre sitios.

Proceso de envío de Conjuntos de sitios web relacionados

Sigue estos pasos para declarar la relación entre los dominios y especificar de qué subconjunto forman parte.

1. Identifica tus RWS

Identifica los dominios relevantes, incluidos los sitios web principales y los miembros del sitio web que formarán parte del conjunto de sitios web relacionados. También identifica a qué tipo de subconjunto pertenece cada miembro del conjunto.

2. Crea tu envío de RWS

Crea una copia local (clon o bifurcación) del repositorio de GitHub. En una rama nueva, realiza los cambios en el archivo related_website_sets.JSON para que refleje tu conjunto. Para asegurarte de que tu conjunto tenga el formato y la estructura JSON correctos, puedes usar la herramienta Generador de JSON.

3. Asegúrate de que tu RWS cumpla con los requisitos técnicos

Asegúrate de que se cumplan los requisitos de formación del conjunto y los requisitos de validación del conjunto.

4. Prueba tu RWS de forma local

Antes de crear una solicitud de extracción (PR) para enviar tu conjunto, prueba el envío de forma local para asegurarte de que apruebe todas las verificaciones requeridas.

5. Envía tu RWS

Para enviar el conjunto de sitios web relacionados, crea una PR en el archivo related_website_sets.JSON, en el que Chrome aloja la lista canónica de conjuntos de sitios web relacionados. (Se requiere una cuenta de GitHub para crear solicitudes de extracción, y deberás firmar un Contrato de Licencia para Colaboradores (CLA) antes de poder contribuir a la lista).

Una vez que se crea la PR, se completa una serie de verificaciones para asegurarnos de que se cumplan los requisitos del paso 3, como verificar que hayas firmado la CLA y que el archivo .well-known sea válido.

Si se realiza correctamente, la PR indicará que se aprobaron las verificaciones. Las PR aprobadas se combinarán manualmente en lotes con la lista canónica de conjuntos de sitios web relacionados una vez por semana (los martes a las 12 p.m., hora del este). Si alguna de las verificaciones falla, se notificará al remitente a través de una falla de PR en GitHub. El remitente puede corregir los errores y actualizar la PR. Además, debe tener en cuenta lo siguiente:

• Si la PR falla, un mensaje de error proporcionará información adicional sobre el motivo del error. (ejemplo).
• Todas las verificaciones técnicas que rigen los envíos de conjuntos se realizan en GitHub y, por lo tanto, todos los errores de envío que resulten de las verificaciones técnicas se podrán ver en GitHub.

Políticas empresariales

Chrome tiene dos políticas para satisfacer las necesidades de los usuarios empresariales:

• Los sistemas que no puedan integrarse con los conjuntos de sitios web relacionados pueden inhabilitar la función en todas las instancias empresariales de Chrome con la política RelatedWebsiteSetsEnabled.
• Algunos sistemas empresariales tienen sitios solo para uso interno (como una intranet) con dominios registrables que difieren de los dominios de su conjunto de sitios web relacionados. Si necesita tratar estos sitios como parte de su conjunto de sitios web relacionados sin exponerlos públicamente (ya que los dominios pueden ser confidenciales), puede aumentar o anular su lista pública de conjuntos de sitios web relacionados con la política de RelatedWebsiteSetsOverrides.

Chrome resuelve cualquier intersección de los conjuntos públicos y empresariales de una de las siguientes maneras, según si se especifica replacemements o additions.

Por ejemplo, para el conjunto público {primary: A, associated: [B, C]}:

Cómo solucionar problemas relacionados con los conjuntos de sitios web relacionados

"Consigna del usuario" y "gesto del usuario"

Una "sugerencia del usuario" y un "gesto del usuario" son diferentes. Chrome no mostrará una solicitud de permiso a los usuarios para los sitios que se encuentran en el mismo conjunto de sitios web relacionados, pero Chrome aún requiere que el usuario haya interactuado con la página. Antes de otorgar el permiso, Chrome requiere un gesto del usuario, también llamado "interacción del usuario" o "activación del usuario". Esto se debe a que el uso de la API de Storage Access fuera de un contexto de conjunto de sitios web relacionados (es decir, requestStorageAccess()) también requiere un gesto del usuario debido a los principios de diseño de la plataforma web.

Acceder a las cookies o al almacenamiento de otros sitios

Los conjuntos de sitios web relacionados no combinan el almacenamiento de diferentes sitios: solo permiten llamadas requestStorageAccess() más fáciles (sin indicaciones). Los conjuntos de sitios web relacionados solo reducen la fricción del usuario cuando usa la API de Acceso al almacenamiento, pero no indican qué hacer una vez que se restablece el acceso. Si A y B son sitios diferentes en el mismo conjunto de sitios web relacionados, y A incorpora B, B puede llamar a requestStorageAccess() y obtener acceso al almacenamiento propio sin solicitarle permiso al usuario. Los conjuntos de sitios web relacionados no realizan ninguna comunicación entre sitios. Por ejemplo, configurar un conjunto de sitios web relacionados no hará que las cookies que pertenecen a B comiencen a enviarse a A. Si quieres compartir esos datos, deberás hacerlo por tu cuenta, por ejemplo, enviando un window.postMessage de un iframe B a un marco A.

Acceso a cookies no particionadas de forma predeterminada

Los Conjuntos de sitios web relacionados no permiten el acceso implícito a cookies sin particionar sin invocar ninguna API. Las cookies entre sitios no están disponibles de forma predeterminada dentro del conjunto. Los conjuntos de sitios web relacionados solo permiten que los sitios dentro del conjunto omitan el mensaje de permiso de la API de Storage Access. Un iframe debe llamar a document.requestStorageAccess() si desea acceder a sus cookies, o bien la página de nivel superior puede llamar a document.requestStorageAccessFor().

Compartir comentarios

Enviar un conjunto en GitHub y trabajar con la API de Storage Access y la API de requestStorageAccessFor son oportunidades para compartir tu experiencia con el proceso y cualquier problema que encuentres.

Para unirte a debates sobre los Conjuntos de sitios web relacionados, sigue estos pasos:

• Únete a la lista de distribución pública de los conjuntos de sitios web relacionados.
• Informa los problemas y sigue el debate en el repositorio de GitHub de Related Website Sets.