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 (por ejemplo, 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 mejorar la privacidad de los usuarios. Por ejemplo, muchos sitios dependen de varios dominios para ofrecer una única experiencia del usuario. Es posible que las organizaciones quieran mantener diferentes dominios de nivel superior para varios casos de uso, como dominios específicos de un país o dominios de servicio para alojar imágenes o videos. Los Conjuntos de sitios web relacionados permiten que los sitios compartan datos entre dominios, con controles específicos.

En un nivel superior, un conjunto de sitios web relacionados es una colección de dominios, para la que hay un solo "conjunto principal" y, posiblemente, 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 públicamente en un formato de archivo JSON alojado 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 aquellos con control administrativo sobre un dominio pueden crear un conjunto con ese dominio. Los remitentes deben declarar la relación entre cada “miembro establecido” y su “conjunto principal”. Los miembros del conjunto pueden incluir un rango de diferentes tipos de dominio 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 denominadas cookies de terceros) en sitios dentro del mismo conjunto de sitios web relacionados, puedes usar la API de Storage Access (SAA) y la API de requestStorageAccessFor para solicitar acceso a esas cookies. Según el subconjunto del que forme parte cada sitio, el navegador puede manejar 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 se someterán a varias verificaciones técnicas para validar las postulaciones.

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 del país. Aprovechar sitios localizados con una infraestructura compartida (example.co.uk puede depender de un servicio alojado por example.ca)
  • Integración de dominios de servicio. Se aprovechan los dominios de servicio con los que los usuarios nunca interactúan directamente, pero que ofrecen servicios en los sitios de la misma organización (example-cdn.com).
  • Separación del contenido del usuario. Acceder a datos de diferentes dominios que separan el contenido subido por los usuarios del contenido del sitio por motivos de seguridad y, al mismo tiempo, permiten que el dominio de la zona de pruebas acceda a cookies de autenticación (y otras). Si publicas contenido inactivo subido por usuarios, también puedes alojarlo de forma segura en el mismo dominio siguiendo las prácticas recomendadas.
  • Contenido autenticado incorporado. Admitir contenido incorporado de todas las propiedades afiliadas (videos, documentos o recursos restringidos al usuario que accedió en el sitio de nivel superior)
  • Acceso. Compatibilidad con el acceso en todas las propiedades afiliadas. La API de FedCM también puede ser apropiada para algunos casos de uso.
  • Analytics. Implementamos estadísticas y mediciones de los recorridos de los usuarios en las propiedades afiliadas para mejorar la calidad de los servicios.

API de Storage Access

Navegadores compatibles

  • 119
  • 85
  • 65
  • 11.1

Origen

La API de Storage Access (SAA) permite que el contenido incorporado de origen cruzado acceda al almacenamiento al que normalmente solo tendría acceso en un contexto propio.

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

Cuando se bloquean las cookies de terceros, pero los Conjuntos de sitios web relacionados (RWS) están habilitados, Chrome otorgará permiso automáticamente en contextos dentro de RWS y, de lo contrario, le mostrará un mensaje al usuario. (Un "contexto dentro del RWS" es un contexto, como un iframe, cuyo sitio incorporado y sitio de nivel superior están en el mismo RWS).

Verifica y solicita acceso al almacenamiento

Para comprobar 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 el valor "true" si el iframe tiene el mismo origen que el fotograma superior.

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

La API de requestStorageAccess() está diseñada para que se llame desde un iframe. Ese iframe tiene que haber recibido recientemente interacción del usuario (un gesto del usuario, que todos los navegadores requieren), pero Chrome adicionalmente requiere que en algún momento de los últimos 30 días, el usuario haya visitado el sitio propietario de ese iframe y haya interactuado específicamente con ese sitio (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 menciona el motivo si se denegó el acceso por algún motivo.

requestStorageAccessFor en Chrome

Navegadores compatibles

  • 119
  • 119
  • x
  • x

Origen

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 a la hora de adoptar la API de Storage Access para sitios de nivel superior que usan imágenes entre sitios o etiquetas de secuencias de comandos que requieren cookies.

Para solucionar este problema, Chrome implementó una forma para que los sitios de nivel superior soliciten acceso al 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 recientemente interacción del usuario. Sin embargo, a diferencia de requestStorageAccess(), Chrome no verifica la interacción en un documento de nivel superior durante los últimos 30 días porque el usuario ya se encuentra 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 otorgados por el usuario. La API de Permissions proporciona una forma de verificar el estado del permiso para acceder a una API, ya sea que se haya otorgado, denegado o que requiera alguna forma de interacción del usuario, como hacer clic en un mensaje o interactuar con la página.

Puedes consultar el estado del permiso con navigator.permissions.query().

Para verificar el permiso de acceso al almacenamiento en el 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 si requiere un gesto del usuario, mostrará prompt o granted.

Modelo por fotograma

Los otorgamientos de rSA se aplican por marco. Los otorgamientos de rSA y rSAFor se tratan como permisos independientes.

Cada marco nuevo deberá solicitar acceso al almacenamiento de manera individual y se le otorgará acceso automáticamente. Solo la primera solicitud requiere gestos del usuario. Cualquier solicitud posterior iniciada por el iframe, como la navegación o los subrecursos, no necesitará esperar un gesto del usuario, ya que la solicitud inicial otorgará ese gesto para la sesión de navegación.

Para actualizar, volver a cargar o crear de cualquier otro modo el iframe, deberás volver a solicitar acceso.

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

Diagrama que muestra un sitio incorporado en un sitio de nivel superior
Cómo usar requestStorageAccess() en una incorporación en otro sitio

Cómo comprobar 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 de varios sitios. Si se resuelve como false, 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 correspondiente 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 funcionar 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 un 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 permiso automáticamente para acceder a las cookies entre sitios. hasStorageAccess() muestra cookies verdaderas y entre sitios del mismo conjunto de sitios web relacionados que se enviarán en esas solicitudes sin llamadas adicionales de JavaScript.

Diagrama que muestra el uso de requestStorageAccessFor() en un sitio de nivel superior y no dentro de una incorporación
Cómo usar requestStorageAccessFor() en un sitio de nivel superior para un origen diferente

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

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

Para descubrir si se le solicitará al usuario o si ya se otorgó acceso al 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 funcionar sin un gesto del usuario.

Si el permiso es prompt, deberás conectar la llamada a 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 a requestStorageAccessFor() exitosa, las solicitudes entre sitios incluirán cookies si incluyen CORS o el atributo de origen cruzado, por lo que es posible que los sitios quieran 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 versiones posteriores desde la línea de comandos y habilita la marca de Chrome test-third-party-cookie-phaseout.

Habilitar la función experimental de Chrome

Para habilitar la función experimental de Chrome necesaria, navega a chrome://flags#test-third-party-cookie-phaseout en la barra de direcciones y cámbiala a Enabled. Asegúrate de reiniciar el navegador después de que se hayan modificado las marcas.

Para iniciar Chrome con el conjunto de sitios web relacionados declarado localmente, crea un objeto JSON que contenga las 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 e iniciar Chrome desde la línea de comandos con la marca --use-related-website-set con 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/

Cómo verificar que tienes acceso a 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.

Para declarar la relación entre los dominios y especificar de qué subconjunto forman parte, sigue estos pasos:

  1. Identifica los dominios relevantes; esto incluye establecer principales y conjuntos miembros, que formarán parte del conjunto de sitios web relacionados. Identifica también a qué tipo de subconjunto pertenece cada miembro del conjunto.
  2. Asegúrate de que se hayan establecido los requisitos de creación y los requisitos de validación establecidos.
  3. Declara el conjunto de sitios web relacionados en el formato JSON correcto.
  4. Envía el conjunto de sitios web relacionados creando una solicitud de extracción (PR) al elemento related_website_sets.JSON donde Chrome alojará la lista canónica del conjunto de sitios web relacionados. (se requiere una cuenta de GitHub para crear PR y debes firmar un Contrato de Licencia para Colaboradores (CLC) para contribuir a la lista).

Una vez que se cree la RR.PP., se llevará a cabo una serie de verificaciones para validar que se cumplan los requisitos del paso 2.

Si la solicitud se realiza correctamente, la solicitud de extracción indicará que se aprobaron las verificaciones. Las relaciones públicas aprobadas se combinarán manualmente en lotes con la lista canónica del conjunto de sitios web relacionados una vez por semana (los martes a las 12 p.m., hora del este).

Si falla alguna de las verificaciones, el remitente recibirá una notificación con una falla de PR en GitHub. El remitente puede corregir los errores y actualizar el RR.PP., y ten en cuenta lo siguiente:

  • Cuando falla el comunicado de prensa, se muestra un mensaje de error que proporciona información adicional sobre los motivos por los que puede haber fallado el envío (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 resultantes de las verificaciones técnicas se podrán ver en GitHub.

Políticas empresariales

Para satisfacer las necesidades de los usuarios empresariales, Chrome cuenta con algunas políticas empresariales:

  • Los sistemas que tal vez 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 internos (como una intranet) con dominios registrables que difieren de los dominios en su conjunto de sitios web relacionados. Si necesitan tratar estos sitios como parte de su conjunto de sitios web relacionados sin exponerlos públicamente (ya que los dominios pueden ser confidenciales), pueden aumentar o anular su lista pública de conjuntos de sitios web relacionados con la política RelatedWebsiteSetsOverrides.

“Aviso del usuario” y “Gesto del usuario”

Un “mensaje del usuario” y un “gesto del usuario” son cosas diferentes. Chrome no mostrará un mensaje de permiso a los usuarios para sitios que estén en el mismo conjunto de sitios web relacionados, pero Chrome 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 del contexto de un 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.

Cómo acceder al almacenamiento o las cookies de otros sitios

La función Conjuntos de sitios web relacionados no combina el almacenamiento para diferentes sitios; solo permite llamar a requestStorageAccess() más fácilmente (sin solicitudes). La función Conjuntos de sitios web relacionados solo reduce la fricción del usuario a la hora de usar la API de Storage Access, pero no determina 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 preguntarle 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 deseas compartir esos datos, tendrás que compartirlos tú mismo, por ejemplo, enviando un window.postMessage de un iframe B a un marco A.

Los conjuntos de sitios web relacionados no permiten el acceso implícito no particionado de las cookies 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 omiten 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 los problemas con los que te encuentres.

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