Bienvenue dans l'édition de novembre de Progress in the Privacy Sandbox, qui suit les étapes de la suppression progressive des cookies tiers dans Chrome et vise un Web plus respectueux de la confidentialité. Chaque mois, nous vous présenterons les modifications apportées au calendrier Privacy Sandbox, ainsi que les actualités du projet. Nous avons également fait des mises à jour sur nos engagements concernant la Privacy Sandbox, car nous nous assurons que les propositions sont conçues, développées et mises en œuvre avec le contrôle et la contribution réglementaires de la Competition and Markets Authority (CMA) et de l'Information Commissioner's Office (ICO) du Royaume-Uni.
Événements
Au début du mois de novembre, nous avons organisé le Chrome Developer Summit, au cours duquel le discours d'ouverture comprenait à la fois un segment de la Privacy Sandbox et quelques questions connexes lors de la session de questions-réponses "Ask Me Anything". Nous avons ajouté un résumé à lire ou à regarder, qui couvre les activités et les exemples de ce à quoi s'attendre à mesure que les propositions progressent au cours des phases de discussion, de test et d'adoption à grande échelle.
Renforcez les limites de confidentialité intersites
Les cookies tiers constituent un mécanisme essentiel qui permet le suivi intersites. Leur abandon progressif est une étape importante, mais nous devons également nous attaquer à d'autres formes de stockage ou de communication intersites.
API Federated Credentials Management
Federated Credentials Management (FedCM) est le nouveau nom plus significatif de la proposition WebID. Nous avons pris en compte ce changement dans le calendrier de la Privacy Sandbox. L'identité fédérée est un service essentiel pour le Web. Cependant, étant donné qu'elle est explicitement utilisée pour partager certains aspects de l'identité sur d'autres sites, certains détails de mise en œuvre chevauchent le suivi intersites.
La proposition Federated Credentials Management explore un large éventail d'options: des chemins de migration simples pour des solutions existantes aux méthodes plus privées de connexion aux services avec le strict minimum d'informations partagées.
Le mois de novembre incluait également la conférence semestrielle BlinkOn. Blink est le moteur de rendu utilisé par Chromium, tandis que BlinkOn permet aux contributeurs de se réunir pour participer à des présentations techniques et discuter des projets en cours. Le BlinkOn de novembre comprenait une session de présentation et de questions-réponses sur FedCM: vous pouvez regarder l'enregistrement sur YouTube.
Empêcher le suivi dissimulé
À mesure que nous réduisons les options de suivi intersite explicite, nous devons également aborder les zones de la plate-forme Web qui divulguent des informations d'identification permettant le fingerprinting ou le suivi dissimulé des utilisateurs.
Réduction de chaîne user-agent et indicateurs client user-agent
Nous continuons de réduire le nombre d'informations disponibles par défaut dans la chaîne user-agent de Chrome et de fournir une méthode active et améliorée pour demander ces données via les indicateurs client user-agent. Nous avons ajouté une nouvelle présentation de la réduction user-agent pour regrouper toutes les recommandations et mises à jour actuelles.
Nous avons publié de nouvelles ressources de test pour vous aider à vous préparer à ces changements. Les extraits de code de réduction user-agent fournissent une sélection d'exemples de transformation de la chaîne user-agent Chrome actuelle en un format réduit. Il existe également la nouvelle entrée chrome://flags/#force-major-version-to-100, qui vous permettra de vérifier si le passage à une version majeure à trois chiffres entraîne le dysfonctionnement ou le dysfonctionnement de votre site.
Nous avons publié l'Intent to Ship for Sec-CH-UA-Full-Version-List. Cela répond aux commentaires de l'écosystème selon lesquels la version Sec-CH-UA-Full-Version existante était trop étroitement liée à la marque du navigateur principal, car elle ne fournissait qu'une seule valeur. Par exemple, l'implémentation actuelle indique:
⬇️ En-tête de réponse du serveur
Accept-CH: Sec-CH-UA-Full-Version
⬆️ En-tête des demandes de navigateur
Sec-CH-UA: "Chromium";v="94", "Google Chrome";v="94", ";Not A Brand";v="99"
Sec-CH-UA-Full-Version: "94.0.4606.124"
La version mise à jour fournit les éléments suivants:
⬇️ En-tête de réponse du serveur
Accept-CH: Sec-CH-UA-Full-Version-List
⬆️ En-tête des demandes de navigateur
Sec-CH-UA: "Chromium";v="94", "Google Chrome";v="94", "Other browser";v="99"
Sec-CH-UA-Full-Version-List: "Chromium";v="94.0.4606.124", "Google Chrome";v="94.0.4606.124", "Other browser";v="99.88.77.66"
Aveuglement des adresses IP
De par leur nature, les adresses IP fournissent souvent un identifiant unique à un client, permettant la communication nécessaire entre le navigateur et le serveur. Toutefois, cela signifie également qu'une adresse IP stable au fil du temps fournit de manière passive une grande quantité d'informations pouvant être utilisées pour le suivi intersites.
La proposition d'aveuglement des adresses IP (également appelée "traduction d'adresse réseau globale" combinée avec un CDN ou un proxy HTTP éliminant la réidentification ou Gnatcatcher) détaille une approche en deux temps pour résoudre ce problème. La première est le NAT en chemin proche, qui transfère efficacement la connexion du navigateur via un service de privatisation d'adresses IP qui masque l'adresse IP du navigateur au site consulté. La deuxième option repose sur la nature multicouche d'Internet, dans laquelle l'infrastructure qui repose sur l'adresse IP peut être complètement distincte de l'application qui s'exécute sur celle-ci. La proposition Aveuglement des adresses IP volontaires explore les méthodes permettant de définir des stratégies vérifiables pour créer et maintenir cette séparation.
Ces deux idées en sont au début de la phase de discussion avec une progression active dans le dépôt, comme les principes concernant le cas d'aveuglement délibéré, récemment publiés. La discussion devrait se poursuivre sur cette page. Si vous êtes intéressé par les détails au niveau du réseau, vous pouvez suivre le groupe de travail MASQUE (Multiplexed Application Substrate over QUIC Encryption) de l'IETF.
Mesurer les annonces numériques
En plus de la diffusion d'annonces sans suivi intersites, nous avons besoin de mécanismes protégeant la confidentialité pour permettre de mesurer l'efficacité des annonces.
API Attribution Reporting
L'API Attribution Reporting crée une fonctionnalité permettant de mesurer les événements sur un site, comme l'affichage d'une annonce ou le clic sur une annonce, qui entraînent une conversion sur un autre site, sans activer le suivi intersites.
Nous continuons de tester l'API et la phase d'évaluation a été étendue jusqu'à Chrome 97. Les jetons d'évaluation actuels ont expiré le 12 octobre. Les testeurs existants doivent donc demander des jetons mis à jour pour continuer les tests.
Deux nouveaux articles de blog contiennent les dernières informations sur la création de rapports au niveau des événements dans l'API. Les rapports au niveau des événements dans l'API Attribution Reporting présentent les concepts et le processus. Quant à l'article Utiliser les rapports au niveau des événements dans l'API Attribution Reporting, ils détaillent l'implémentation avec la démo et le code de démonstration associés.
Commentaires
Alors que nous continuons à publier ces mises à jour mensuelles et à progresser dans l'ensemble de la Privacy Sandbox, nous voulons nous assurer que les développeurs reçoivent les informations et l'assistance dont ils ont besoin. N'hésitez pas à nous contacter sur @ChromiumDev Twitter si vous souhaitez améliorer cette série. Vos réponses nous permettront de continuer à améliorer le format.
Consultez les questions fréquentes sur la Privacy Sandbox, que nous continuons à développer en fonction des problèmes que vous envoyez au dépôt de l'assistance pour les développeurs. Si vous avez des questions sur les tests ou l'implémentation de l'une des propositions, n'hésitez pas à nous contacter.