Les ensembles de sites Web associés sont un mécanisme de plate-forme Web qui aide les navigateurs à comprendre les relations entre un ensemble de domaines. Les navigateurs peuvent ainsi prendre des décisions clés pour activer certaines fonctions du site (par exemple, autoriser l'accès aux cookies intersites) et présenter ces informations aux utilisateurs.
À mesure que Chrome abandonne les cookies tiers, son objectif est de conserver les principaux cas d'utilisation sur le Web tout en améliorant la confidentialité des utilisateurs. Par exemple, de nombreux sites s'appuient sur plusieurs domaines pour offrir une expérience utilisateur unique. Les organisations peuvent vouloir conserver différents domaines de premier niveau pour plusieurs cas d'utilisation, comme des domaines spécifiques à un pays ou des domaines de service pour l'hébergement d'images ou de vidéos. Les Ensembles de sites Web associés permettent aux sites de partager des données entre plusieurs domaines, avec des contrôles spécifiques.
Qu'est-ce qu'un ensemble de sites Web associés ?
De manière générale, un Ensemble de sites Web associés est un ensemble de domaines, pour lesquels il existe un seul "ensemble principal" et potentiellement plusieurs "membres de l'ensemble".
Dans l'exemple suivant, primary liste le domaine principal et associatedSites répertorie les domaines qui répondent aux exigences du sous-ensemble associé.
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}
La liste canonique d'ensembles de sites Web associés est une liste publique au format JSON, hébergée dans le dépôt GitHub d'ensembles de sites Web associés, qui sert de source de référence pour tous les ensembles. Chrome utilise ce fichier pour appliquer son comportement.
Seuls les utilisateurs disposant d'un contrôle administratif sur un domaine peuvent créer un ensemble avec ce domaine. Les contributeurs doivent déclarer la relation entre chaque "membre de l'ensemble" et son "membre principal". Les membres de l'ensemble peuvent inclure différents types de domaines et doivent faire partie d'un sous-ensemble basé sur un cas d'utilisation.
Si votre application dépend de l'accès à des cookies intersites (également appelés cookies tiers) sur plusieurs sites au sein du même Ensemble de sites Web associés, vous pouvez demander l'accès à ces cookies à l'aide de l'API Storage Access (SAA) et de l'API requestStorageAccessFor. En fonction du sous-ensemble auquel appartient chaque site, le navigateur peut traiter la requête différemment.
Pour en savoir plus sur la procédure et les exigences concernant l'envoi d'ensembles, consultez nos consignes d'envoi. Les ensembles envoyés font l'objet de différents contrôles techniques afin de valider les envois.
Cas d'utilisation des Ensembles de sites Web associés
Les Ensembles de sites Web associés conviennent parfaitement dans les cas où une organisation a besoin d'une forme d'identité partagée entre différents sites de premier niveau.
Voici quelques cas d'utilisation des Ensembles de sites Web associés:
- Personnalisation du pays. Exploiter des sites localisés tout en ayant recours à une infrastructure partagée (example.co.uk peut s'appuyer sur un service hébergé par example.ca).
- Intégration des domaines de service. Exploiter des domaines de service avec lesquels les utilisateurs n'interagissent jamais directement, mais qui fournissent des services sur les sites de la même organisation (example-cdn.com).
- Séparation des contenus utilisateur. Accès à des données sur différents domaines qui séparent le contenu envoyé par l'utilisateur des autres contenus du site pour des raisons de sécurité, tout en autorisant le domaine en bac à sable à accéder aux cookies d'authentification (et autres). Si vous diffusez du contenu inactif mis en ligne par des utilisateurs, vous pouvez également l'héberger en toute sécurité sur le même domaine en suivant les bonnes pratiques.
- Contenu authentifié intégré : Prise en charge du contenu intégré provenant de différentes propriétés affiliées (vidéos, documents ou ressources réservés à l'utilisateur connecté au site de premier niveau).
- Se connecter. Permettre la connexion sur toutes les propriétés affiliées L'API FedCM peut également convenir pour certains cas d'utilisation.
- Données analytiques : Déployer des analyses et des mesures du parcours utilisateur sur les propriétés affiliées pour améliorer la qualité des services.
Détails de l'intégration des Ensembles de sites Web associés
API Storage Access
L'API Storage Access (SAA) permet au contenu multi-origine intégré d'accéder à l'espace de stockage auquel il n'aurait normalement accès que dans un contexte propriétaire.
Les ressources intégrées peuvent utiliser les méthodes SAA pour vérifier si elles ont actuellement accès à l'espace de stockage et demander l'accès à l'user-agent.
Lorsque les cookies tiers sont bloqués, mais que les Ensembles de sites Web associés (RWS) sont activés, Chrome accorde automatiquement l'autorisation dans les contextes intra-RWS et affiche une invite dans le cas contraire. Un "contexte intra-RWS" est un contexte, tel qu'un iFrame, dont le site intégré et le site de premier niveau se trouvent dans le même RWS.
Vérifier et demander l'accès à l'espace de stockage
Pour vérifier s'ils ont actuellement accès à l'espace de stockage, les sites intégrés peuvent utiliser la méthode Document.hasStorageAccess().
La méthode renvoie une promesse qui se résout avec une valeur booléenne indiquant si le document a déjà accès à ses cookies ou non. Cette promesse renvoie également la valeur "true" si l'iFrame a la même origine que le frame supérieur.
Pour demander l'accès aux cookies dans un contexte intersites, les sites intégrés peuvent utiliser Document.requestStorageAccess() (rSA).
L'API requestStorageAccess() doit être appelée depuis un iFrame. Cet iFrame doit simplement avoir reçu une interaction de l'utilisateur (un geste de l'utilisateur, qui est requis par tous les navigateurs). Cependant, Chrome exige également qu'au cours des 30 derniers jours, l'utilisateur ait visité le site propriétaire de cet iFrame et ait interagi avec ce site en tant que document de premier niveau, et non dans un iFrame.
requestStorageAccess() renvoie une promesse qui se résout si l'accès à l'espace de stockage a été accordé. Si l'accès a été refusé pour quelque raison que ce soit, la promesse est rejetée et la raison est indiquée.
requestStorageAccessFor dans Chrome
L'API Storage Access n'autorise que les sites intégrés à demander l'accès à l'espace de stockage à partir d'éléments <iframe> ayant fait l'objet d'une interaction utilisateur.
Il est donc difficile d'adopter l'API Storage Access pour les sites de premier niveau qui utilisent des images intersites ou des tags de script nécessitant des cookies.
Pour résoudre ce problème, Chrome a mis en place un moyen pour les sites de premier niveau de demander l'accès à l'espace de stockage au nom d'origines spécifiques avec Document.requestStorageAccessFor() (rSAFor).
document.requestStorageAccessFor('https://target.site')
L'API requestStorageAccessFor() est destinée à être appelée par un document de niveau supérieur. Ce document doit également avoir reçu une interaction de l'utilisateur. Toutefois, contrairement à requestStorageAccess(), Chrome ne vérifie pas si une interaction a eu lieu dans un document de premier niveau au cours des 30 derniers jours, car l'utilisateur a déjà consulté la page.
Vérifier les autorisations d'accès à l'espace de stockage
L'accès à certaines fonctionnalités du navigateur, comme l'appareil photo ou la géolocalisation, dépend des autorisations accordées aux utilisateurs. L'API Permissions permet de vérifier l'état de l'autorisation d'accès à une API, qu'il ait été accordé ou refusé, ou s'il nécessite une interaction de l'utilisateur, comme un clic sur une invite ou une interaction avec la page.
Vous pouvez interroger l'état d'autorisation à l'aide de navigator.permissions.query().
Pour vérifier l'autorisation d'accès au stockage pour le contexte actuel, vous devez transmettre la chaîne 'storage-access':
navigator.permissions.query({name: 'storage-access'})
Pour vérifier l'autorisation d'accès au stockage pour une origine spécifiée, vous devez transmettre la chaîne 'top-level-storage-access':
navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
Notez que pour protéger l'intégrité de l'origine intégrée, seules les autorisations accordées par le document de premier niveau à l'aide de document.requestStorageAccessFor sont vérifiées.
Selon que l'autorisation peut être accordée automatiquement ou qu'elle nécessite un geste de l'utilisateur, elle renvoie prompt ou granted.
Par modèle d'image
Les autorisations rSA s'appliquent par frame. Les attributions rSA et rSAFor sont traitées comme des autorisations distinctes.
Chaque nouveau frame devra demander individuellement l'accès à l'espace de stockage, qui se verra accorder l'accès automatiquement. Seule la première requête nécessite un geste de l'utilisateur. Toute requête ultérieure lancée par l'iFrame, par exemple la navigation ou les sous-ressources, n'a pas besoin d'attendre un geste de l'utilisateur, car celui-ci sera accordé pour la session de navigation par la requête initiale.
Si vous actualisez ou recréez l'iFrame, vous devrez de nouveau demander l'accès.
Exigences relatives aux cookies
Les cookies doivent spécifier les attributs SameSite=None et Secure, car rSA ne fournit un accès qu'aux cookies déjà marqués pour être utilisés dans des contextes intersites.
Les cookies avec SameSite=Lax, SameSite=Strict ou sans attribut SameSite sont réservés à une utilisation propriétaire et ne seront jamais partagés dans un contexte intersites, indépendamment du rSA.
Sécurité
Pour rSAFor, les requêtes de sous-ressources nécessitent des en-têtes CORS (Cross-Origin Resource Sharing) ou l'attribut crossorigin sur les ressources, ce qui garantit une activation explicite.
Exemples d'intégration
Demander l'accès à l'espace de stockage à partir d'un iFrame multi-origine intégré
requestStorageAccess() dans une intégration sur un autre siteVérifier si vous avez accès à l'espace de stockage
Pour vérifier si vous avez déjà accès à l'espace de stockage, utilisez document.hasStorageAccess().
Si la promesse se résout, vous pouvez accéder au stockage dans un contexte intersites. Si la réponse est "false", vous devez demander l'accès à l'espace de stockage.
document.hasStorageAccess().then((hasAccess) => {
if (hasAccess) {
// You can access storage in this context
} else {
// You have to request storage access
}
});
Demander l'accès à l'espace de stockage
Si vous devez demander l'accès à l'espace de stockage, vérifiez d'abord l'autorisation d'accès à l'espace de stockage navigator.permissions.query({name: 'storage-access'}) pour voir si cela nécessite un geste de l'utilisateur ou si elle peut être accordée automatiquement.
Si l'autorisation est granted, vous pouvez appeler document.requestStorageAccess(). Cela devrait aboutir sans un geste de l'utilisateur.
Si l'état d'autorisation est prompt, vous devez lancer l'appel document.requestStorageAccess() après un geste de l'utilisateur, par exemple un clic sur un bouton.
Exemple :
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
}
);
}
}
Les requêtes ultérieures provenant du frame, des navigations ou des sous-ressources auront automatiquement l'autorisation d'accéder aux cookies intersites. hasStorageAccess() renvoie des cookies "true" et des cookies intersites du même Ensemble de sites Web associés seront envoyés à ces requêtes sans aucun appel JavaScript supplémentaire.
Sites de premier niveau demandant l'accès à des cookies au nom de sites multi-origines
requestStorageAccessFor() sur un site de premier niveau pour une origine différenteLes sites de premier niveau peuvent utiliser requestStorageAccessFor() pour demander l'accès à l'espace de stockage au nom d'origines spécifiques.
hasStorageAccess() vérifie uniquement si le site qui l'appelle dispose d'un accès à l'espace de stockage. Ainsi, un site de premier niveau peut vérifier les autorisations pour une autre origine.
Pour savoir si l'utilisateur sera invité à accéder à l'espace de stockage ou si l'accès à l'espace de stockage a déjà été accordé pour l'origine spécifiée, appelez navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}).
Si l'autorisation est granted, vous pouvez appeler document.requestStorageAccessFor('https://target.site'). Elle doit réussir sans intervention de l'utilisateur.
Si l'autorisation est prompt, vous devez ancrer l'appel document.requestStorageAccessFor('https://target.site') derrière le geste de l'utilisateur, par exemple un clic sur un bouton.
Exemple :
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
}
);
}
}
Après un appel requestStorageAccessFor() réussi, les requêtes intersites incluront des cookies si elles incluent CORS ou l'attribut crossorigin. Les sites peuvent donc vouloir attendre avant de déclencher une requête.
Les requêtes doivent utiliser l'option credentials: 'include' et les ressources doivent inclure l'attribut 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
});
}
Tester en local
Prérequis
Pour tester les Ensembles de sites Web associés en local, utilisez Chrome 119 ou une version ultérieure lancé à partir de la ligne de commande et activez l'indicateur Chrome test-third-party-cookie-phaseout.
Activer l'indicateur Chrome
Pour activer l'indicateur Chrome requis, accédez à chrome://flags#test-third-party-cookie-phaseout depuis la barre d'adresse et remplacez-le par Enabled. Veillez à redémarrer le navigateur une fois les indicateurs modifiés.
Lancer Chrome avec un ensemble de sites Web associés local
Pour lancer Chrome avec l'ensemble de sites Web associés déclaré localement, créez un objet JSON contenant les URL membres d'un ensemble et transmettez-le à --use-related-website-set.
Découvrez comment exécuter Chromium avec des indicateurs.
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
Exemple
Pour activer les Ensembles de sites Web associés localement, vous devez activer test-third-party-cookie-phaseout dans chrome://flags, puis lancer Chrome à partir de la ligne de commande avec l'indicateur --use-related-website-set et l'objet JSON contenant les URL qui font partie d'un ensemble.
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
Vérifier que vous avez accès aux cookies intersites
Appelez les API (rSA ou rSAFor) à partir des sites testés et validez l'accès aux cookies intersites.
Processus d'envoi des Ensembles de sites Web associés
Pour déclarer la relation entre les domaines et spécifier le sous-ensemble auquel ils appartiennent, procédez comme suit:
- Identifiez les domaines pertinents, y compris les membres de l'ensemble principal et les membres de l'ensemble, qui feront partie de l'ensemble de sites Web associés. Identifiez également le type de sous-ensemble auquel chaque membre de l'ensemble appartient.
- Assurez-vous que les exigences de configuration et les exigences de validation sont en place.
- Déclarez l'ensemble de sites Web associés dans le format JSON approprié.
- Envoyez l'ensemble de sites Web associés en créant une demande d'extraction dans
related_website_sets.JSON, où Chrome hébergera la liste canonique d'ensembles de sites Web associés. (Vous devez disposer d'un compte GitHub pour créer des demandes d'extraction, et vous devrez signer un contrat de licence du contributeur pour pouvoir contribuer à la liste.)
Une fois le PR créé, une série de vérifications sont effectuées pour vérifier que les exigences de l'étape 2 sont bien respectées.
En cas de succès, le PR indique que les vérifications ont été effectuées. Les PR approuvés seront fusionnées manuellement par lots dans la liste canonique des ensembles de sites Web associés une fois par semaine (les mardis à 12h, heure de l'Est).
Si l'une des vérifications échoue, le demandeur sera informé de l'échec de la demande d'extraction sur GitHub. Le demandeur peut corriger les erreurs et mettre à jour le message d'identification, en gardant à l'esprit les points suivants:
- En cas d'échec de la demande d'extraction, un message d'erreur fournit des informations supplémentaires expliquant pourquoi l'envoi peut avoir échoué (exemple).
- Toutes les vérifications techniques régissant l'envoi d'ensembles sont effectuées sur GitHub. Par conséquent, tous les échecs d'envoi résultant de vérifications techniques seront visibles sur GitHub.
Règles d'entreprise
Pour répondre aux besoins des utilisateurs professionnels, Chrome a mis en place deux règles d'entreprise:
- Les systèmes qui ne peuvent pas être intégrés aux Ensembles de sites Web associés peuvent désactiver cette fonctionnalité dans toutes les instances d'entreprise de Chrome avec la règle
RelatedWebsiteSetsEnabled. - Certains systèmes d'entreprise disposent de sites réservés à un usage interne (un intranet, par exemple) avec des domaines enregistrables différents des domaines de leur Ensemble de sites Web associés. S'ils doivent traiter ces sites comme faisant partie de leur Ensemble de sites Web associés sans les exposer publiquement (les domaines pouvant être confidentiels), ils peuvent enrichir ou remplacer leur liste d'Ensembles de sites Web associés publics par la règle
RelatedWebsiteSetsOverrides.
Résoudre les problèmes liés aux ensembles de sites Web associés
"Invite de l'utilisateur" et "geste de l'utilisateur"
Une « invite utilisateur » et un « geste utilisateur » sont des choses différentes. Chrome n'affichera pas d'invite d'autorisation pour les sites appartenant au même Ensemble de sites Web associés, mais Chrome exige toujours que l'utilisateur ait interagi avec la page. Avant d'accorder une autorisation, Chrome exige un geste utilisateur, également appelé "interaction utilisateur" ou "activation de l'utilisateur". En effet, l'utilisation de l'API Storage Access en dehors d'un contexte d'ensemble de sites Web associés (à savoir requestStorageAccess()) nécessite également un geste de l'utilisateur, en raison des principes de conception des plates-formes Web.
Accéder aux cookies ou à l'espace de stockage d'autres sites
La fonctionnalité d'ensembles de sites Web associés ne fusionne pas le stockage des différents sites: elle permet simplement des appels requestStorageAccess() plus faciles (sans invite). Les ensembles de sites Web associés ne font que simplifier l'utilisation de l'API Storage Access pour les utilisateurs, mais ils ne vous dictent pas la marche à suivre une fois l'accès restauré. Si A et B sont des sites différents dans le même Ensemble de sites Web associés et que A intègre B, B peut appeler requestStorageAccess() et accéder à l'espace de stockage propriétaire sans envoyer d'invite à l'utilisateur. La fonctionnalité d'ensembles de sites Web associés n'effectue aucune communication intersite. Par exemple, si vous configurez un Ensemble de sites Web associés, les cookies appartenant à B ne seront pas envoyés à A. Si vous souhaitez partager ces données, vous devez le faire vous-même, par exemple en envoyant un window.postMessage à partir d'un iFrame B vers un frame A.
Accès aux cookies non partitionnés par défaut
Les Ensembles de sites Web associés n'autorisent pas l'accès implicite aux cookies non partitionnés sans appeler d'API. Les cookies intersites ne sont pas disponibles par défaut dans l'ensemble. Les ensembles de sites Web associés permettent uniquement aux sites de l'ensemble d'ignorer l'invite d'autorisation de l'API Storage Access.
Un iFrame doit appeler document.requestStorageAccess() s'il souhaite accéder à ses cookies, ou la page de premier niveau peut appeler document.requestStorageAccessFor().
Envoyer des commentaires
En soumettant un ensemble sur GitHub et en utilisant l'API Storage Access et l'API requestStorageAccessFor, vous pouvez partager votre expérience du processus et les problèmes que vous rencontrez.
Pour participer à des discussions sur les Ensembles de sites Web associés:
- rejoindre la liste de diffusion publique des Ensembles de sites Web associés ;
- Signalez des problèmes et suivez la discussion sur le dépôt GitHub des ensembles de sites Web associés.