Conjuntos de sitios web relacionados (RWS) es 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 las cookies entre sitios) y presentar esta información a los usuarios.
Dado que Chrome dará de baja las cookies de terceros, su objetivo es mantener 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 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.
¿Qué es un conjunto de sitios web relacionados?
En términos generales, un conjunto de sitios web relacionados es una colección de dominios para la cual existe un solo conjunto de sitios web principales. y posiblemente tener 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 alojada en el repositorio de GitHub de Conjuntos de sitios web relacionados, que funciona como fuente de información para todos los conjuntos. Chrome consume este archivo para aplicarlo a su comportamiento.
Solo quienes tienen control de administrador sobre un dominio pueden crear un conjunto con ese dominio. Los remitentes deben declarar la relación entre cada miembro establecido. a la opción “establecer principal”. Los miembros del conjunto pueden incluir un rango de diferentes tipos de dominios y deben ser parte de un subconjunto según un caso de uso.
Si tu aplicación depende del acceso a cookies entre sitios (también llamadas cookies de terceros) entre sitios dentro 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 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 los envíos.
Casos de uso de 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 del país. Aprovechar sitios localizados mientras se basa en una infraestructura compartida (example.co.uk puede depender de un servicio alojado por example.ca)
- Integración de dominios de servicio. Aprovechar dominios de servicios 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 de los usuarios. Acceder a datos de diferentes dominios que separan el contenido subido por el usuario de otro contenido del sitio por razones de seguridad, mientras se permite el acceso del dominio de zona de pruebas a cookies de autenticación (y otras) Si publicas contenido inactivo subido por usuarios, también puedes seguir las prácticas recomendadas para alojarlo de forma segura en el mismo dominio.
- Contenido autenticado autenticado: Compatibilidad con contenido incorporado de distintas 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. Implementar estadísticas y mediciones de los recorridos de los usuarios en las propiedades afiliadas para mejorar la calidad de los servicios
Detalles de integración de Conjuntos de sitios web relacionados
API de Storage Access
La API de Storage Access (SAA) permite que el contenido de origen cruzado incorporado acceda al almacenamiento al que normalmente solo tendría acceso en un contexto propio.
Los recursos incorporados pueden usar los 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á permiso automáticamente en contextos dentro de RWS y, de lo contrario, mostrará un mensaje al usuario. (Un "contexto dentro de 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 actualmente tienen acceso al almacenamiento, los sitios incorporados pueden usar el método Document.hasStorageAccess()
.
El método devuelve una promesa que se resuelve con un valor booleano, que indica si el documento ya tiene acceso o no a sus cookies. La promesa también muestra el valor true si el iframe tiene el mismo origen que el fotograma superior.
Para solicitar acceso a las cookies en un contexto de varios sitios, los sitios incorporados pueden usar Document.requestStorageAccess()
(rSA).
La API de requestStorageAccess()
se debe llamar desde un iframe. Ese iframe tiene que haber recibido la interacción del usuario (un gesto del usuario, que es necesario para todos los navegadores), pero Chrome además requiere que, en algún momento durante los últimos 30 días, el usuario haya visitado el sitio que posee ese iframe y ha interactuado con ese sitio específicamente, como documento de nivel superior, no en un iframe.
requestStorageAccess()
muestra una promesa que se resuelve si se otorgó el acceso al almacenamiento. Si se denegó el acceso por alguna razón, se rechaza la promesa citando esa razón.
requestStorageAccessFor en Chrome
La API de Storage Access solo permite que los sitios incorporados soliciten acceso al almacenamiento desde elementos <iframe>
que recibieron 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')
Un documento de nivel superior debe llamar a la API de requestStorageAccessFor()
. Ese documento también debe haber recibido la interacción del usuario recién. Sin embargo, a diferencia de requestStorageAccess()
, Chrome no verifica si hay interacciones 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 que otorga 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, rechazado o que requiera algún tipo de interacción del usuario, como hacer clic en un mensaje o interactuar con la página.
Puedes consultar el estado del permiso mediante navigator.permissions.query()
.
Para verificar el permiso de acceso al almacenamiento para 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 específico, 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, esto solo verifica los permisos otorgados por el documento de nivel superior con document.requestStorageAccessFor
.
Se mostrará prompt
o granted
en función de si el permiso se puede otorgar automáticamente o si se requiere un gesto del usuario.
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 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 tendrán que 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 volver a crear el iframe, deberás volver a solicitar acceso.
Requisitos para las cookies
Las cookies deben especificar los atributos SameSite=None
y Secure
, ya que solo el rSA proporciona acceso a las cookies que ya están marcadas para su uso 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 entre sitios, independientemente del rSA.
Seguridad
Para rSAFor, las solicitudes de subrecursos requieren encabezados de Uso compartido de recursos multiorigen (CORS) o el atributo crossorigin
en los recursos, lo que garantiza la habilitación explícita.
Ejemplos de implementación
Solicitar acceso al almacenamiento desde un iframe de origen cruzado incorporado
![Diagrama que muestra un sitio incorporado en un sitio level.site superior](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/SV7SXAQRcVnBZEgjgxYc.png?authuser=5&hl=es)
requestStorageAccess()
en una incorporación de otro sitio.Cómo comprobar si tienes acceso al almacenamiento
Para comprobar 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 falsa, deberás solicitar acceso al almacenamiento.
document.hasStorageAccess().then((hasAccess) => {
if (hasAccess) {
// You can access storage in this context
} else {
// You have to request storage access
}
});
Cómo solicitar 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 se 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 hacerlo correctamente 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 que se originen en 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 ninguna llamada adicional de JavaScript.
Sitios de nivel superior que solicitan acceso de cookies en nombre de sitios de origen cruzado
![Diagrama que muestra el uso de requestStorageAccessFor() en un sitio de nivel superior y no en una incorporación](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/jRgDgWl7yb1cEcwpcdMo.png?authuser=5&hl=es)
requestStorageAccessFor()
en un sitio de nivel superior para un origen diferenteLos 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, por lo 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 a un 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 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 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 locales
Requisitos previos
Para probar los Conjuntos de sitios web relacionados de forma local, usa la versión 119 de Chrome o una posterior iniciada 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 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.
Iniciar Chrome con un conjunto de sitios web relacionados locales
Para iniciar Chrome con el conjunto de sitios web relacionados declarado de forma local, 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/
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
Para declarar la relación entre dominios y especificar de qué subconjunto forman parte, sigue estos pasos:
- Identifica los dominios relevantes, incluidos el conjunto principal y los miembros del conjunto, que formarán parte del conjunto de sitios web relacionados. Además, identifica a qué tipo de subconjunto pertenece cada miembro del conjunto.
- Asegúrate de que se hayan establecido los requisitos de formación de los conjuntos y los requisitos de validación.
- Declara el conjunto de sitios web relacionados en el formato JSON correcto.
- Para enviar el Conjunto de sitios web relacionados, crea una solicitud de extracción (PR) a la
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 deberás firmar un Contrato de Licencia para Colaboradores (CLA) para contribuir a la lista).
Una vez creado el PR, se llevará a cabo una serie de verificaciones para validar que se hayan cumplido los requisitos del paso 2.
Si tiene éxito, el RR.PP. indicará que se aprobaron las verificaciones. Los PR aprobados 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 sobre el error de PR en GitHub. El remitente puede corregir los errores, actualizar el comunicado de prensa y tener en cuenta lo siguiente:
- Si falla la solicitud de extracción, aparecerá un mensaje de error con información adicional sobre el motivo del error en el envío (ejemplo).
- Todas las verificaciones técnicas que rigen los envíos de conjuntos se realizan en GitHub y, en consecuencia, todas las fallas de envío que resulten de las verificaciones técnicas serán visibles en GitHub.
Políticas empresariales
Chrome tiene dos políticas para satisfacer las necesidades de los usuarios empresariales:
- Los sistemas que tal vez no puedan integrarse con los conjuntos de sitios web relacionados pueden inhabilitar la función de conjuntos de sitios web relacionados 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 de
RelatedWebsiteSetsOverrides
.
Chrome resuelve cualquier intersección entre el público y los conjuntos Enterprise en uno de dos
dependiendo de si se especifican replacemements
o additions
.
Por ejemplo, para el conjunto público {primary: A, associated: [B, C]}
, usa lo siguiente:
replacements set: |
{primary: C, associated: [D, E]} |
El conjunto empresarial absorbe el sitio común para formar un conjunto nuevo. | |
Conjuntos resultantes: | {primary: A, associated: [B]} {primary: C, associated: [D, E]} |
additions set: |
{primary: C, associated: [D, E]} |
Se combinan los conjuntos Público y Empresarial. | |
Conjunto resultante: | {primary: C, associated: [A, B, D, E]} |
Solucionar problemas de Conjuntos de sitios web relacionados
"Instrucción del usuario" y "gesto del usuario"
Un "mensaje al usuario" y "gesto del usuario" son cosas diferentes. Chrome no mostrará un
mensaje de permiso
a los usuarios de sitios que están 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 de usuarios”. 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
principios de diseño para plataformas web.
Acceder a otros sitios cookies o almacenamiento
El Conjunto de sitios web relacionados no combina el almacenamiento de los distintos sitios, sino que solo permite
llamadas de requestStorageAccess()
más fáciles (sin mensaje) Sitio web relacionado
Los Sets solo reducen las dificultades que enfrentan los usuarios al usar la API de Storage Access, pero no
definir qué hacer una vez que el acceso se haya restablecido. Si A y B son sitios diferentes
en el mismo Conjunto de sitios web relacionados, y A incorpora B, B puede llamar
requestStorageAccess()
y obtén acceso al almacenamiento de origen sin solicitarlo
del usuario. Los Conjuntos de sitios web relacionados no realizan ninguna comunicación entre sitios. Para
ejemplo, configurar un conjunto de sitios web relacionados no provocará que las cookies que pertenezcan
a B para comenzar a enviarse a A. Si
y quieres compartir esos datos, tendrás que compartirlos tú mismo, por ejemplo,
enviar un objeto window.postMessage
desde un iframe B a un
Un marco.
Acceso a cookies no particionadas de forma predeterminada
Los conjuntos de sitios web relacionados no permiten el acceso implícito de cookies no particionadas
sin invocar ninguna API. Las cookies entre sitios no están disponibles
de forma predeterminada dentro del conjunto; El Conjunto de sitios web relacionados solo permite que los sitios del conjunto
omite el mensaje de permiso de la API de Storage Access.
Un iframe debe llamar a document.requestStorageAccess()
si desea acceder a su
cookies, o 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 que encuentres.
Para unirte a debates sobre 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 conjuntos de sitios web relacionados.