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. Cela permet aux navigateurs de prendre des décisions clés pour activer certaines fonctionnalités du site (par exemple, autoriser l'accès aux cookies intersites) et de présenter ces informations aux utilisateurs.
Chrome abandonne les cookies tiers, mais son objectif est de maintenir 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 proposer une expérience utilisateur unique. Les organisations peuvent souhaiter gérer différents domaines de premier niveau pour différents 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 les domaines, avec des commandes 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
liste 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 des ensembles de sites Web associés est une liste publique au format de fichier JSON hébergée dans le dépôt GitHub des ensembles de sites Web associés, qui sert de source de vérité pour tous les ensembles. Chrome utilise ce fichier pour appliquer son comportement.
Seuls les utilisateurs disposant d'un contrôle administrateur sur un domaine peuvent créer un ensemble avec ce domaine. Les soumissionnaires doivent déclarer la relation entre chaque "membre de l'ensemble" et son "ensemble 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 aux cookies intersites (également appelés cookies tiers) sur les sites d'un même ensemble de sites Web associés, vous pouvez utiliser l'API Storage Access Access (SAA) et l'API requestStorageAccessFor pour demander l'accès à ces cookies. Selon le sous-ensemble auquel chaque site appartient, le navigateur peut traiter la requête différemment.
Pour en savoir plus sur la procédure et les conditions à respecter pour envoyer des ensembles, consultez les consignes d'envoi. Les ensembles envoyés seront soumis à divers contrôles techniques pour valider les envois.
Cas d'utilisation des ensembles de sites Web associés
Les ensembles de sites Web associés sont adaptés lorsque votre organisation a besoin d'une forme d'identité partagée entre différents sites racine.
Voici quelques cas d'utilisation des ensembles de sites Web associés:
- Personnalisation par pays Exploiter des sites localisés tout en s'appuyant sur une infrastructure partagée (example.co.uk peut s'appuyer sur un service hébergé par example.ca).
- Intégration du domaine de service Utilisation de 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 du contenu utilisateur Accès aux données sur différents domaines qui séparent le contenu importé par l'utilisateur du reste du contenu du site pour des raisons de sécurité, tout en permettant au domaine en bac à sable d'accéder aux cookies d'authentification (et autres). Si vous diffusez du contenu inactif importé par les 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 plusieurs propriétés affiliées (vidéos, documents ou ressources réservés à l'utilisateur connecté sur le site racine).
- Connexion. Prise en charge de la connexion sur les propriétés affiliées. L'API FedCM peut également être adaptée à certains cas d'utilisation.
- Analytics. Déploiement d'analyses et de mesures des parcours utilisateur sur les propriétés affiliées afin d'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 aux contenus intersites intégrés d'accéder au stockage auquel ils n'auraient normalement accès que dans un contexte propriétaire.
Les ressources intégrées peuvent utiliser des méthodes SAA pour vérifier si elles ont actuellement accès au stockage et pour demander l'accès à l'agent utilisateur.
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 à l'utilisateur dans le cas contraire. (Un "contexte intra-RWS" est un contexte, tel qu'un iFrame, dont le site intégré et le site racine se trouvent dans le même RWS.)
Vérifier et demander l'accès au stockage
Pour vérifier s'ils ont actuellement accès au 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. La promesse renvoie également "true" si l'iFrame est de 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. Cette iFrame doit avoir reçu une interaction de l'utilisateur (un geste utilisateur, qui est requis par tous les navigateurs). Chrome exige également que l'utilisateur ait visité le site propriétaire de cette iFrame et interagi avec ce site spécifiquement au cours des 30 derniers jours (en tant que document de premier niveau, et non dans une iFrame).
requestStorageAccess()
renvoie une promesse qui se résout si l'accès au stockage a été accordé. La promesse est rejetée, en indiquant le motif, si l'accès a été refusé pour une raison quelconque.
requestStorageAccessFor dans Chrome
L'API Storage Access n'autorise que les sites intégrés à demander l'accès au stockage à partir d'éléments <iframe>
ayant reçu une interaction utilisateur.
Cela pose des difficultés pour adopter l'API Storage Access pour les sites de premier niveau qui utilisent des images intersites ou des balises de script nécessitant des cookies.
Pour y remédier, Chrome a implémenté un moyen pour les sites de premier niveau de demander l'accès au 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 premier niveau. Ce document doit également avoir reçu une interaction utilisateur. Cependant, contrairement à requestStorageAccess()
, Chrome ne vérifie pas d'interaction dans un document de niveau supérieur au cours des 30 derniers jours, car l'utilisateur se trouve déjà sur la page.
Vérifier les autorisations d'accès au stockage
L'accès à certaines fonctionnalités du navigateur, comme la caméra ou la géolocalisation, est basé sur les autorisations accordées par l'utilisateur. L'API Permissions permet de vérifier l'état des autorisations d'accès à une API, qu'elles aient été accordées, refusées ou qu'elles nécessitent une forme d'interaction de l'utilisateur, comme cliquer sur une invite ou interagir avec la page.
Vous pouvez interroger l'état des autorisations à 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, la valeur renvoyée est prompt
ou granted
.
Modèle par image
Les autorisations rSA s'appliquent par cadre. Les autorisations rSA et rSAFor sont traitées comme des autorisations distinctes.
Chaque nouvelle trame devra demander l'accès au stockage individuellement. L'accès lui sera automatiquement accordé. Seule la première requête nécessite un geste de l'utilisateur. Les requêtes ultérieures lancées par l'iFrame, telles que la navigation ou les sous-ressources, n'auront pas besoin d'attendre un geste de l'utilisateur, car celui-ci sera accordé à la session de navigation par la requête initiale.
Si vous actualisez, rechargez ou recréez l'iFrame, vous devrez demander à nouveau l'accès.
Exigences concernant les cookies
Les cookies doivent spécifier à la fois les attributs SameSite=None
et Secure
, car rSA n'autorise l'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 à l'utilisation par les propriétaires et ne seront jamais partagés dans un contexte intersites, quel que soit le 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 au stockage à partir d'un iFrame d'origine différente intégré

requestStorageAccess()
dans une intégration sur un autre site.Vérifier si vous avez accès au stockage
Pour vérifier si vous disposez déjà d'un accès au stockage, utilisez document.hasStorageAccess()
.
Si la promesse renvoie la valeur "true", vous pouvez accéder au stockage dans le contexte intersites. Si la valeur 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 au stockage, vérifiez d'abord l'autorisation d'accès au stockage navigator.permissions.query({name: 'storage-access'})
pour voir si elle 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()
, et l'opération devrait réussir sans geste de l'utilisateur.
Si l'état de l'autorisation est prompt
, vous devez lancer l'appel document.requestStorageAccess()
après un geste de l'utilisateur, tel qu'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 seront automatiquement autorisées à accéder aux cookies intersites. hasStorageAccess()
renvoie la valeur "true", et les cookies intersites du même ensemble de sites Web associés sont envoyés sur ces requêtes sans aucun appel JavaScript supplémentaire.
Sites de premier niveau demandant l'accès aux cookies au nom de sites inter-origines

requestStorageAccessFor()
sur un site de premier niveau pour une autre origineLes sites de premier niveau peuvent utiliser requestStorageAccessFor()
pour demander l'accès au stockage au nom d'origines spécifiques.
hasStorageAccess()
ne vérifie que si le site qui l'appelle dispose d'un accès au stockage. Un site de premier niveau peut donc vérifier les autorisations d'une autre origine.
Pour savoir si l'utilisateur sera invité ou si l'accès à l'espace de stockage a déjà été accordé à 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')
. L'opération doit réussir sans geste de l'utilisateur.
Si l'autorisation est prompt
, vous devez connecter l'appel document.requestStorageAccessFor('https://target.site')
au geste de l'utilisateur, tel qu'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 incluent des cookies si elles incluent CORS ou l'attribut crossorigin. Les sites peuvent donc 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ée à 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 nécessaire, accédez à chrome://flags#test-third-party-cookie-phaseout
dans la barre d'adresse et remplacez l'indicateur par Enabled
. Veillez à redémarrer le navigateur après avoir modifié les indicateurs.
Lancer Chrome avec un ensemble de sites Web associés local
Pour lancer Chrome avec un ensemble de sites Web associés déclaré localement, créez un objet JSON contenant des 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
et lancer Chrome à partir de la ligne de commande avec l'indicateur --use-related-website-set
avec l'objet JSON contenant les URL membres 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
Suivez les étapes suivantes pour déclarer la relation entre les domaines et spécifier le sous-ensemble auquel ils appartiennent.
1. Identifier votre RWS
Identifiez les domaines pertinents, y compris le site principal et les sites membres 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.
2. Créer votre envoi de données de recherche sur le Web
Créez une copie locale (clone ou fork) du dépôt GitHub. Dans une nouvelle branche, apportez les modifications au fichier related_website_sets.JSON pour refléter votre ensemble. Pour vous assurer que votre ensemble dispose du format et de la structure JSON appropriés, vous pouvez utiliser l'outil de génération de code JSON.
3. Vérifier que votre RWS répond aux exigences techniques
Assurez-vous que les exigences de formation des ensembles et les exigences de validation des ensembles sont en place.
4. Tester votre RWS en local
Avant de créer une pull request (PR) pour envoyer votre ensemble, testez votre envoi localement pour vous assurer qu'il passe toutes les vérifications requises.
5. Envoyer votre RWS
Envoyez l'ensemble de sites Web associés en créant une demande de publication pour le fichier related_website_sets.JSON, où Chrome héberge la liste canonique des ensembles de sites Web associés. (Un compte GitHub est nécessaire pour créer des demandes d'extraction, et vous devrez signer un contrat de licence du contributeur avant de pouvoir contribuer à la liste.)
Une fois la demande de pull créée, une série de vérifications est effectuée pour vous assurer que les exigences de l'étape 3 sont en place, par exemple pour vous assurer que vous avez signé la CLA et que le fichier .well-known
est valide.
Si la requête est acceptée, la PR indique que les vérifications ont réussi. Les demandes de publication approuvées seront fusionnées manuellement par lot dans la liste canonique des ensembles de sites Web associés une fois par semaine (les mardis à midi, heure de l'Est). Si l'une des vérifications échoue, l'utilisateur qui a envoyé la demande de publication est informé par un échec de la demande de publication sur GitHub. L'auteur peut corriger les erreurs et mettre à jour la demande de pull. Gardez à l'esprit les points suivants:
- Si la demande échoue, un message d'erreur fournit des informations supplémentaires sur la raison pour laquelle l'envoi a échoué. (exemple).
- Toutes les vérifications techniques régissant les envois de jeux sont effectuées sur GitHub. Par conséquent, tous les échecs d'envoi dus à des vérifications techniques seront visibles sur GitHub.
Règles d'entreprise
Chrome applique deux règles pour répondre aux besoins des utilisateurs professionnels:
- 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 à l'aide de la règle
RelatedWebsiteSetsEnabled
. - Certains systèmes d'entreprise comportent des sites internes (comme un intranet) avec des domaines enregistrables qui diffèrent des domaines de leur ensemble de sites Web associés. S'il doit traiter ces sites comme faisant partie de son ensemble de sites Web associés sans les exposer publiquement (car les domaines peuvent être confidentiels), il peut compléter ou remplacer sa liste publique d'ensembles de sites Web associés à l'aide de la règle
RelatedWebsiteSetsOverrides
.
Chrome résout toute intersection des ensembles public et Enterprise de deux manières, selon que replacemements
ou additions
sont spécifiés.
Par exemple, pour l'ensemble public {primary: A, associated: [B, C]}
:
replacements set : |
{primary: C, associated: [D, E]} |
L'ensemble d'entreprise absorbe le site commun pour former un nouvel ensemble. | |
Ensembles obtenus: | {primary: A, associated: [B]} {primary: C, associated: [D, E]} |
additions set : |
{primary: C, associated: [D, E]} |
Les ensembles publics et Enterprise sont combinés. | |
Ensemble obtenu: | {primary: C, associated: [A, B, D, E]} |
Résoudre les problèmes liés aux ensembles de sites Web associés
"Invite utilisateur" et "geste utilisateur"
Une "invite utilisateur" et un "geste utilisateur" sont deux choses différentes. Chrome n'affiche pas d'invite d'autorisation aux utilisateurs 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 l'autorisation, Chrome nécessite un geste de l'utilisateur, également appelé "interaction de l'utilisateur" ou "activation de l'utilisateur". En effet, l'utilisation de l'API Storage Access en dehors d'un contexte de site Web associé (à savoir requestStorageAccess()
) nécessite également un geste de l'utilisateur, en raison des principes de conception de la plate-forme Web.
Accéder aux cookies ou au stockage d'autres sites
Les ensembles de sites Web associés ne fusionnent pas l'espace de stockage pour différents sites. Ils permettent simplement d'effectuer des appels requestStorageAccess()
plus faciles (sans invite). Les ensembles de sites Web associés ne réduisent que les difficultés rencontrées par l'utilisateur lors de l'utilisation de l'API Storage Access, mais ne dictent pas ce qu'il doit faire une fois l'accès rétabli. Si A et B sont des sites différents appartenant au même ensemble de sites Web associés, et que A intègre B, B peut appeler requestStorageAccess()
et accéder au stockage propriétaire sans demander à l'utilisateur. Les ensembles de sites Web associés n'effectuent aucune communication intersites. Par exemple, la configuration d'un ensemble de sites Web associés n'entraîne pas l'envoi des cookies appartenant à B à A. Si vous souhaitez partager ces données, vous devrez 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 simplement aux sites de l'ensemble de 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
Envoyer un ensemble sur GitHub et utiliser l'API Storage Access et l'API requestStorageAccessFor
sont des occasions de partager votre expérience du processus et les problèmes que vous rencontrez.
Pour participer aux discussions sur les ensembles de sites Web associés:
- Inscrivez-vous à la liste de diffusion publique des Ensembles de sites Web associés.
- Signalez les problèmes et suivez la discussion dans le dépôt GitHub des ensembles de sites Web associés.