De nombreuses API de la Privacy Sandbox passeront en disponibilité générale (DG) dans la version stable de Chrome en vue de l'abandon des cookies tiers à partir de 2024. Certaines de ces API contribueront à préserver les cas d'utilisation cruciaux des cookies intersites, tels que les CHIPS et l'API actuellement connue sous le nom d'ensembles internes (FPS). Dans cet article, nous présentons les Ensembles de sites Web associés (RWS), notre nouveau nom du lecteur d'empreinte digitale qui reflète mieux son objectif, et nous renvoyons un rappel sur les principaux cas d'utilisation ainsi que des informations sur la limite du sous-ensemble de domaines associé.
Préserver les parcours utilisateur critiques
RWS est conçu pour limiter les interruptions de certaines fonctionnalités utilisateur une fois que Chrome commencera à limiter l'accès aux cookies tiers par défaut. Notre objectif est de permettre aux utilisateurs de naviguer sur le Web avec le moins de perturbations possible, tout en respectant les objectifs de confidentialité de la Privacy Sandbox. Pour trouver cet équilibre, RWS cible des cas d'utilisation spécifiques liés aux fonctionnalités des sites Web:
- Le cas d'utilisation ccTLD traite de défaillances comme l'exemple de connexion enregistré dans notre outil de suivi public. Ces cas sont souvent traités dans l'écosystème au moyen d'exceptions basées sur des méthodes heuristiques (voir réf. 1).
- Le cas d'utilisation des domaines de service aborde une pratique courante des développeurs qui consiste à isoler les fonctions sensibles (comme la prise en charge d'un flux d'authentification) des domaines visibles par l'utilisateur. Ces cas peuvent être traités dans l'écosystème via des exceptions ciblées (voir la réf 2).
- Le cas d'utilisation de domaine associé offre plus de flexibilité pour les types de domaines pouvant nécessiter l'accès à des cookies tiers pour les parcours utilisateur critiques (voir la réf 3). Bien que les cas d'utilisation du ccTLD et du domaine de service appliquent des contrôles techniques stricts basés sur les caractéristiques du domaine pour minimiser les abus, le domaine associé utilise une limite numérique. Pour en savoir plus, consultez la section suivante.
Le nombre maximal de domaines associés est passé à 5
Chrome proposait auparavant une limite numérique de trois domaines pour le sous-ensemble associé (plus un domaine principal), conformément à notre objectif visant à empêcher le suivi généralisé des abus. Les participants aux normes Web nous ont signalé que la limite était trop faible pour différents types de cas d'utilisation.
Nous avons décidé d'augmenter la limite des domaines associés à cinq domaines (plus un domaine principal), ce qui correspond le mieux à l'implémentation la plus comparable proposée par un autre navigateur majeur (voir la réf. 4). Cette modification prendra effet à partir de Chrome 117.
RWS n'a pas vocation à être une solution publicitaire. Par conséquent, nous ne tenons pas compte des commentaires sur la façon d'améliorer RWS afin de mieux répondre aux cas d'utilisation des annonces. Pour les cas d'utilisation des annonces, les développeurs doivent envisager d'utiliser les API Topics, Protected Audience et Attribution Reporting, et fournir des commentaires à leur sujet en conséquence.
Les utilisateurs ont le choix entre des cas d'utilisation étendus au-delà de cinq domaines associés
Pour les expériences qui ont un impact sur les utilisateurs et qui ne sont pas concernées par cette limite, Chrome élabore un flux d'invite utilisateur qui exploite également l'API Storage Access (SAA), une norme adoptée par d'autres navigateurs. Pour les cas d'utilisation nécessitant plus de cinq domaines associés, nous encourageons les développeurs à évaluer la compatibilité des annonces SAA dans des contextes autres que RWS. Nous suivons le processus de lancement de Blink séparément pour cette fonctionnalité, qui sera déployé dans Chrome pour ordinateur à partir de Chrome 117.
Étapes suivantes
Nous vous sommes reconnaissants pour les commentaires de l'écosystème qui ont contribué à façonner l'API jusqu'à présent. Nous avons investi dans RWS afin d'offrir aux développeurs une plus grande prévisibilité, un contrôle et une influence sur la préservation de l'expérience utilisateur sur les sites Web qu'ils créent. Nous avons hâte de voir comment les développeurs adopteront et utiliseront RWS à mesure que nous progresserons. Le processus d'envoi est actuellement en ligne, et le générateur JSON RWS est un excellent point de départ pour vous aider.
Suivez le fil de discussion Intention d'expédition pour suivre la progression et consultez ces ressources pour obtenir des conseils d'implémentation.
Références
- Tous les navigateurs s'accordent à dire que ces cas d'utilisation de cookies intersites sont nécessaires, mais ils ont adopté des approches différentes pour les activer. Firefox (code) et Safari (code) ont tous deux implémenté la méthode heuristique de pop-up qui résout le problème observé, par exemple dans le flux de connexion Nintendo.
- Il existe également de nombreux exemples d'exceptions de code en dur dans les navigateurs afin de limiter les perturbations pour les utilisateurs. Firefox accorde un accès à l'espace de stockage lors des flux de redirection entre Microsoft Teams et login.microsoftonline.us.
- Firefox fournit un shim qui appelle requestStorageAccessForOrigin au nom de facebook.com lorsque l'utilisateur se connecte sur instagram.com. Les exceptions codées en dur de Safari permettent également de regrouper les invites d'accès au stockage pour plusieurs domaines.
- Firefox accorde automatiquement les cinq premiers appels requestStorageAccess effectués par un site tiers (code) que l'utilisateur a déjà consulté. Dans Chrome, l'accès aux cookies tiers sera automatiquement autorisé via RWS pour les cinq premiers domaines répertoriés dans le sous-ensemble associé, en plus du domaine principal du même ensemble.