Chrome abandonne progressivement la prise en charge des cookies tiers pour réduire le suivi intersites. Cela représente un défi pour les sites et services qui s'appuient sur des cookies dans des contextes intégrés, lors des parcours utilisateur tels que l'authentification. L'API Storage Access (SAA) permet à ces cas d'utilisation de continuer à fonctionner, tout en limitant le plus possible le suivi intersites.
État de l'implémentation
L'API Storage Access est disponible dans tous les principaux navigateurs, mais il existe de légères différences d'implémentation entre les navigateurs. Ces différences ont été mises en évidence dans les sections correspondantes de cet article.
Nous continuons de résoudre tous les problèmes bloquants restants avant de standardiser l'API.
Qu'est-ce que l'API Storage Access ?
L'API Storage Access est une API JavaScript qui permet aux iFrames de demander des autorisations d'accès à l'espace de stockage lorsque l'accès serait normalement refusé par les paramètres du navigateur. Les intégrations pour les cas d'utilisation qui dépendent du chargement de ressources intersites peuvent utiliser l'API pour demander l'autorisation d'accès à l'utilisateur, selon les besoins.
Si la demande de stockage est acceptée, l'iFrame aura accès à ses cookies intersites, qui sont également disponibles lorsque les utilisateurs le consultent en tant que site de premier niveau.
L'API Storage Access permet de fournir l'accès à des cookies intersites spécifiques en limitant au maximum la charge de l'utilisateur final, tout en empêchant l'accès à des cookies intersites génériques comme ils sont souvent utilisés pour le suivi des utilisateurs.
Cas d'utilisation
Certaines intégrations tierces nécessitent l'accès aux cookies intersites pour offrir une meilleure expérience utilisateur. Cette fonctionnalité ne sera plus disponible une fois les cookies tiers abandonnés.
Exemples de cas d'utilisation :
- Widgets de commentaires intégrés nécessitant des informations de connexion
- Boutons "J'aime" des réseaux sociaux nécessitant des informations de connexion
- Documents intégrés nécessitant des informations de connexion
- Expérience premium sans frais pour l'intégration d'une vidéo (par exemple, pour empêcher la diffusion d'annonces auprès des utilisateurs connectés, pour connaître les préférences des utilisateurs concernant les sous-titres ou pour restreindre certains types de vidéos).
- les systèmes de paiement intégrés ;
Bon nombre de ces cas d'utilisation impliquent la persistance de l'accès à la connexion dans des iFrames intégrés.
Quand utiliser l'API Storage Access plutôt que d'autres API
L'API Storage Access est l'une des alternatives aux cookies tiers. Il est donc important de savoir quand utiliser cette API par rapport aux autres. Il est destiné aux cas d'utilisation où les deux conditions suivantes sont remplies:
- L'utilisateur interagira avec le contenu intégré, c'est-à-dire qu'il ne s'agit pas d'un iFrame passif ni d'un iFrame masqué.
- L'utilisateur a visité l'origine intégrée dans un contexte de niveau supérieur, c'est-à-dire lorsque cette origine n'est pas intégrée à un autre site.
Il existe d'autres API pour divers cas d'utilisation:
- Les cookies ayant un état partitionné indépendant (CHIPS, Independent Partitioned State) permettent aux développeurs d'activer le stockage "partitionné" d'un cookie, avec un fichier de cookies séparé pour chaque site de premier niveau. Par exemple, un widget de chat en ligne tiers peut dépendre de la définition d'un cookie pour enregistrer les informations de session. Les informations de session sont enregistrées par site. Il n'est donc pas nécessaire d'accéder au cookie défini par le widget sur d'autres sites Web où il est également intégré. L'API Storage Access est utile lorsqu'un widget tiers intégré dépend du partage des mêmes informations sur différentes origines (par exemple, pour les détails ou les préférences d'une session de connexion).
- Les ensembles de sites Web associés (RWS) permettent à une organisation de déclarer des relations entre les sites, de sorte que les navigateurs autorisent un accès limité aux cookies tiers à des fins spécifiques. Les sites doivent toujours demander l'accès à l'aide de l'API Storage Access. Toutefois, pour les sites de l'ensemble, l'accès peut être accordé sans invite de l'utilisateur.
- La Federated Credential Management (FedCM) est une approche des services d'identité fédérée qui protège la confidentialité des utilisateurs. L'API Storage Access gère l'accès aux cookies après la connexion. Pour certains cas d'utilisation, FedCM propose une solution alternative à l'API Storage Access. Cette solution peut être préférable, car elle propose une invite de navigateur davantage axée sur la connexion. Cependant, l’adoption de FedCM nécessite généralement des modifications supplémentaires de votre code, par exemple pour prendre en charge ses points de terminaison HTTP.
- Il existe également des API de lutte contre la fraude, d'annonce et de mesure, et l'API Storage Access n'est pas destinée à répondre à ces préoccupations.
Utiliser l'API Storage Access
L'API Storage Access propose deux méthodes prometteuses:
De plus, il s'intègre à l'API Permissions. Cela vous permet de vérifier l'état de l'autorisation d'accès au stockage dans un contexte tiers, ce qui indique si un appel à document.requestStorageAccess() serait automatiquement accordé:
Utiliser la méthode hasStorageAccess()
Lors du premier chargement d'un site, il peut utiliser la méthode hasStorageAccess() pour vérifier si l'accès aux cookies tiers a déjà été autorisé.
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (!document.hasStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted via the Storage Access API.
// Note on page load this will always be false initially so we could be
// skipped in this example, but including for completeness for when this
// is not so obvious.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
L'accès à l'espace de stockage n'est accordé à un document iFrame qu'après avoir appelé requestStorageAccess(),. Par conséquent, hasStorageAccess() renvoie toujours la valeur "false" au départ, sauf si un autre document de même origine dans le même iFrame a déjà obtenu l'accès. L'autorisation est préservée dans les navigations de même origine à l'intérieur de l'iFrame, pour permettre spécifiquement les actualisations après avoir accordé l'accès aux pages nécessitant la présence de cookies dans la requête initiale du document HTML.
Utiliser la méthode requestStorageAccess()
Si l'iFrame n'y a pas accès, il devra peut-être en demander l'accès à l'aide de la méthode requestStorageAccess():
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
Lors de la première demande, l'utilisateur devra peut-être approuver cet accès à l'aide d'une invite du navigateur. La promesse sera résolue ou sera refusée, ce qui entraînera une exception si await est utilisé.
Pour éviter toute utilisation abusive, cette invite du navigateur ne s'affiche qu'après une interaction de l'utilisateur. C'est pourquoi requestStorageAccess() doit d'abord être appelé à partir d'un gestionnaire d'événements activé par l'utilisateur, plutôt que immédiatement lors du chargement de l'iFrame:
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if above did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
Invites d'autorisation
Lorsque l'utilisateur clique sur le bouton pour la première fois, l'invite du navigateur s'affiche automatiquement, généralement dans la barre d'adresse. Vous trouverez ci-dessous un exemple d'invite de Chrome, mais d'autres navigateurs ont une interface utilisateur similaire:
L'invite peut être ignorée par le navigateur et l'autorisation est accordée automatiquement dans certains cas:
- Si la page et l'iFrame ont été utilisés au cours des 30 derniers jours après avoir accepté l'invite.
- Si l'iFrame intégré fait partie d'un Ensemble de sites Web associés,
- Dans Firefox, l'invite est également ignorée pour les sites Web connus (ceux avec lesquels vous avez interagi au premier niveau) au cours des cinq premières tentatives.
Dans certains cas, la méthode peut également être rejetée automatiquement sans afficher l'invite:
- Si l'utilisateur n'a pas encore consulté et interagi avec le site auquel appartient l'iFrame en tant que document de premier niveau, et non dans un iFrame. Cela signifie que l'API Storage Access n'est utile que pour les sites intégrés que les utilisateurs ont déjà visités dans un contexte propriétaire.
- Si la méthode
requestStorageAccess()est appelée en dehors d'un événement d'interaction utilisateur sans approbation préalable de l'invite après une interaction.
Bien que l'utilisateur soit invité à l'utiliser lors de sa première utilisation, les visites suivantes peuvent résoudre le problème requestStorageAccess() sans invite ni intervention de l'utilisateur dans Chrome et Firefox. Notez que Safari nécessite toujours une interaction de l'utilisateur.
Étant donné que l'accès aux cookies peut être accordé sans invite ni interaction de l'utilisateur, il est souvent possible d'obtenir l'accès aux cookies tiers avant une interaction de l'utilisateur dans les navigateurs compatibles (Chrome et Firefox) en appelant requestStorageAccess() lors du chargement de la page. Cela peut vous permettre d'accéder immédiatement aux cookies tiers intersites et d'offrir une expérience plus complète, avant même que l'utilisateur n'interagisse avec l'iFrame. Dans certaines situations, cela peut être une meilleure expérience que d'attendre une interaction de l'utilisateur.
Utiliser la requête d'autorisation storage-access
Pour vérifier si l'accès peut être accordé sans interaction de l'utilisateur, vous pouvez vérifier l'état de l'autorisation storage-access et n'effectuer l'appel requestStoreAccess() de manière anticipée que si aucune action de l'utilisateur n'est requise, plutôt que de l'appeler et le faire échouer lorsqu'une interaction est requise.
Cela vous permet également de gérer potentiellement la nécessité d'une invite en amont en affichant différents contenus, par exemple un bouton de connexion.
Le code suivant ajoute la vérification d'autorisation storage-access à l'exemple précédent:
// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;
async function hasCookieAccess() {
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
return true;
}
// Check if access has already been granted
if (await document.hasStorageAccess()) {
return true;
}
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
// (e.g. Safari and older versions of Firefox).
let permission;
try {
permission = await navigator.permissions.query(
{name: 'storage-access'}
);
} catch (error) {
// storage-access permission not supported. Assume no cookie access.
return false;
}
if (permission) {
if (permission.state === 'granted') {
// Permission has previously been granted so can just call
// requestStorageAccess() without a user interaction and
// it will resolve automatically.
try {
await document.requestStorageAccess();
return true;
} catch (error) {
// This shouldn't really fail if access is granted, but return false
// if it does.
return false;
}
} else if (permission.state === 'prompt') {
// Need to call requestStorageAccess() after a user interaction
// (potentially with a prompt). Can't do anything further here,
// so handle this in the click handler.
return false;
} else if (permission.state === 'denied') {
// Currently not used. See:
// https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by one of above.
return false;
}
async function handleCookieAccessInit() {
hasAccess = await hasCookieAccess();
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
iFrames en bac à sable
Lorsque vous utilisez l'API Storage Access dans des iFrames en bac à sable, les autorisations de bac à sable suivantes sont requises:
allow-storage-access-by-user-activationest requis pour autoriser l'accès à l'API Storage Access.allow-scriptsest requis pour pouvoir appeler l'API à l'aide de JavaScript.allow-same-originest requis pour autoriser l'accès aux cookies de même origine et à d'autres stockages.
Exemple :
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
Exigences relatives aux cookies
Pour être accessibles avec l'API Storage Access dans Chrome, les cookies intersites doivent être définis avec les deux attributs suivants:
SameSite=None, qui est requis pour marquer le cookie comme intersiteSecure, qui garantit que seuls les cookies définis par des sites HTTPS sont accessibles.
Dans Firefox et Safari, les cookies sont définis par défaut sur SameSite=None et ne limitent pas les cookies SSA à Secure. Ces attributs ne sont donc pas obligatoires. Nous vous recommandons d'indiquer explicitement l'attribut SameSite et de toujours utiliser des cookies Secure.
Accès de premier niveau aux pages
L'API Storage Access est destinée à permettre l'accès aux cookies tiers dans des iFrames intégrés.
Il existe également d'autres cas d'utilisation pour lesquels la page de premier niveau nécessite l'accès à des cookies tiers. Il peut s'agir, par exemple, d'images ou de scripts limités par des cookies que les propriétaires de sites peuvent inclure directement dans le document de premier niveau plutôt que dans un iFrame. Pour répondre à ce cas d'utilisation, Chrome a proposé une extension de l'API Storage Access qui ajoute une méthode requestStorageAccessFor().
La méthode requestStorageAccessFor()
La méthode requestStorageAccessFor() fonctionne de manière semblable à requestStorageAccess(), mais pour les ressources de premier niveau. Elle ne peut être utilisée que pour les sites d'un ensemble de sites Web associés afin d'empêcher l'accès général aux cookies tiers.
Pour en savoir plus sur l'utilisation de requestStorageAccessFor(), consultez le Guide du développeur sur les Ensembles de sites Web associés.
Requête d'autorisation top-level-storage-access
Navigateurs pris en charge
- 119
- 119
- x
- x
Comme pour l'autorisation storage-access, il existe une autorisation top-level-storage-access permettant de vérifier si l'accès peut être accordé pour requestStorageAccessFor().
En quoi l'API Storage Access est-elle différente lorsqu'elle est utilisée avec RWS ?
Lorsque des Ensembles de sites Web associés sont utilisés avec l'API Storage Access, certaines fonctionnalités supplémentaires sont disponibles, comme indiqué dans le tableau suivant:
| Sans RWS | Avec RWS | |
|---|---|---|
| Nécessite un geste de l'utilisateur pour demander l'accès à l'espace de stockage | ||
| Oblige l'utilisateur à visiter l'origine de stockage demandée dans un contexte de premier niveau avant d'accorder l'accès | ||
| La première invite utilisateur peut être ignorée | ||
requestStorageAccess ne doit pas être appelé si l'accès a déjà été accordé |
||
| Accorde automatiquement l'accès à d'autres domaines sur un site Web associé | ||
Compatible avec requestStorageAccessFor pour l'accès de premier niveau à la page |
Démonstration: définir et accéder aux cookies
La démonstration suivante montre comment accéder à un cookie défini par vous-même sur le premier écran de la démo dans un frame intégré sur le deuxième site de la démo:
storage-access-api-demo.glitch.me
Cette démonstration nécessite un navigateur dans lequel les cookies tiers sont désactivés:
- Chrome 118 ou version ultérieure avec l'indicateur
chrome://flags/#test-third-party-cookie-phaseoutdéfini et le navigateur redémarré. - Firefox
- Safari
Ressources
- Lisez la spécification ou suivez et signalez les problèmes.
- Documentation et guide de l'API.
- Documentation Chrome sur l'utilisation de l'API Storage Access dans les ensembles de sites Web associés