Chrome et Android cesseront d'utiliser de nombreuses technologies créées par le projet Privacy Sandbox.

Le vice-président de Google en charge du projet Privacy Sandbox a annoncé l'arrêt du développement et l'exclusion de certaines technologies de Chrome et Android, développées pour trouver un compromis entre la nécessité des utilisateurs de préserver leur confidentialité et le désir des réseaux publicitaires et des sites de suivre les préférences des visiteurs. La plupart des API développées dans le cadre du projet Privacy Sandbox étaient destinées à remplacer les cookies tiers, dont la prise en charge était prévue pour être arrêtée dans Chrome.

Initialement, le blocage des cookies tiers par défaut était prévu pour être mis en œuvre d'ici 2022, mais sa mise en œuvre a été repoussée chaque année en raison de la résistance de l'industrie et du faible niveau d'adoption des technologies développées pour remplacer les méthodes de suivi des utilisateurs basées sur les cookies. Au printemps de cette année, Google a décidé d'abandonner cette initiative et de maintenir l'approche existante. Maintenant, six mois plus tard, il a également été décidé d'arrêter la promotion de nombreuses API et technologies développées pour améliorer la confidentialité et garantir la diffusion de publicités sans identification des utilisateurs basées sur des cookies tiers.

Les API et technologies dont le soutien sera interrompu :

• IP Protection — permet de cacher l'adresse IP de l'utilisateur aux propriétaires des sites, en envoyant le trafic non pas directement, mais à travers une chaîne de serveurs proxy. Lorsque IP Protection est activé, le serveur cible ne voit que l'adresse proxy comme adresse IP entrante, semblable à l'utilisation de VPN.
• l'API Topics (qui a remplacé l'API FLoC) — permet de déterminer les catégories d'intérêts de l'utilisateur, qui peuvent être utilisées pour identifier des groupes d'utilisateurs partageant des intérêts similaires sans identifier les utilisateurs individuels à l'aide de cookies de suivi. Les intérêts sont calculés sur la base de l'activité de l'utilisateur dans le navigateur et sont enregistrés sur le dispositif de l'utilisateur. Grâce à l'API Topics, le réseau publicitaire peut obtenir des informations générales sur les intérêts individuels sans avoir d'informations sur l'activité spécifique de l'utilisateur.
• Le reporting d'attribution API permet d'évaluer des caractéristiques telles que les clics et la conversion (achats sur le site après clic). Pour mesurer l'efficacité des publicités affichées sans compromettre la confidentialité des utilisateurs, l'organisation W3C, en collaboration avec les fabricants de divers navigateurs, développe une nouvelle API Ad Attribution, permettant de collecter des données statistiques agrégées sur la conversion des publicités affichées. Google utilisera cette API à la place de sa propre version.
• Agrégation privée — pour agréger et obtenir des informations sur les données utilisées par différents sites (cross-site). Par exemple, l'API permet de générer des rapports consolidés sur l'unicité des visiteurs (premières et récurrentes ouvertures du site) et la démographie des utilisateurs.
• API de stockage partagé — stockage de données au format clé-valeur, sans attache à un domaine et avec la possibilité d'accéder au stockage depuis différents sites.
• API de public ciblée — solution pour les tâches de reciblage et d'évaluation de son propre public (travail avec les utilisateurs ayant déjà visité le site).
• API de ensembles de sites web connexes — identification des interconnexions entre les sites, sur la base desquelles les navigateurs peuvent permettre un accès intersites limité aux données.
• requestStorageAccessFor — extension de l'API Storage Access pour demander des autorisations d'accès intersites aux données stockées.
• API de partition de sites web connexes — permet aux scripts externes de travailler avec un groupe de sites liés.
• API de sélection d'URL — permet de choisir l'URL affichée en fonction des données intersites dans le stockage Shared Storage, sans révéler ces données.
• API de signaux d'application protégés — conservation des informations sur l'activité de l'utilisateur lors de l'utilisation des applications, qui peuvent être utiles pour afficher des publicités tenant compte des intérêts de l'utilisateur. Par exemple, l'API permet de recueillir des informations sur le nombre d'installations, le premier lancement, le temps passé dans l'application, les achats effectués et les actions réalisées.
• SDK Runtime — permet d'exécuter des bibliothèques tierces dans un processus isolé, séparément du processus de l'application Android, ce qui empêche les fonctions de la bibliothèque d'accéder aux ressources et à la mémoire du processus.
• Personnalisation sur l'appareil — technologie de personnalisation de l'expérience utilisateur sur les appareils Android, utilisant des données stockées localement, sans les envoyer sur des serveurs externes.

Les API qui ont été décidés à être conservés, car ils sont déjà répandus et mis en œuvre dans d'autres navigateurs :

• FedCM (Gestion Fédérée des Identifiants) permet de créer des services d'identification combinés, garantissant la confidentialité et fonctionnant sans cookies tiers.
• CHIPS (Cookies Avec État Partiotionnés Indépendamment) — permet d'isoler les cookies liés à un domaine de premier niveau en utilisant l'attribut « Partitioned ». Si dans des conditions normales, un code tiers provenant du site « C », intégré sur les sites « A » et « B », peut traiter des cookies partagés entre ces sites, alors avec l'attribut « Partitioned », les cookies définis par le site « C », lors du chargement de code provenant des sites « A » et « B », seront complètement séparés.
• Le Private State Token — permet de distinguer différents utilisateurs sans utiliser d'identifiants inter-sites et de transmettre les informations d'authentification de l'utilisateur entre différents contextes. L'API est utile pour séparer les bots des visiteurs réels sans transmettre explicitement les données d'identification. Le fonctionnement de l'API repose sur le fait qu'un site donné, où l'utilisateur a suivi une authentification ou un contrôle CAPTCHA, peut générer un token, stocké du côté du navigateur. Ce token peut être utilisé par d'autres sites pour s'assurer que l'utilisateur est une personne et non un bot.

Source : opennet.ru