Pour se préparer à l'abandon des cookies tiers, nous proposons des modes de test gérés par Chrome qui permettent aux sites de prévisualiser le comportement et les fonctionnalités des sites sans cookies tiers. Ce guide présente les modes de test que Chrome prévoit de proposer et explique comment accéder aux libellés des groupes de test.
Dans ce contexte, le navigateur Chrome fait référence à un client Chrome, c'est-à-dire une installation de Chrome sur un appareil. Chaque répertoire de données d'utilisateur constitue un client distinct.
Groupe de test: ensemble de navigateurs Chrome pour lesquels certaines fonctionnalités sont activées, désactivées ou configurées. Dans le contexte des tests gérés par Chrome, il s'agit d'un ensemble de navigateurs pour lesquels des libellés sont définis.
Étiquette: dans ce contexte, une valeur d'en-tête de requête définie pour un navigateur appartenant à un groupe de test. Chaque navigateur d'un groupe de test restera dans ce groupe pendant toute la durée des tests gérés par Chrome, ce qui garantit la cohérence du libellé d'un navigateur pour tous les testeurs.
Nous proposons deux modes distincts:
- Mode A:depuis novembre 2023, les organisations qui testent les API PS R&M peuvent choisir de recevoir des libellés cohérents sur un sous-ensemble de navigateurs Chrome afin de permettre un test coordonné entre différents testeurs.
- Mode B:à partir du 4 janvier 2024, Chrome a désactivé les cookies tiers dans le monde entier pour une partie des navigateurs Chrome.
Lorsque les cookies tiers sont désactivés en Mode B, ils le restent pendant toute la phase d'abandon des cookies tiers.
Nous avons collaboré avec la CMA pour nous assurer que ces modes de test s'alignent sur le framework de test (et le calendrier) pour les tiers, comme indiqué dans ses Consignes sur les tests sectoriels. Par conséquent, l'autorité britannique de la concurrence et des marchés estime que les résultats des tests effectués dans ces modes pourront être utilisés pour évaluer la Privacy Sandbox. La CMA indique qu'elle est susceptible d'accorder plus de poids aux résultats de la conception expérimentale 2, qui utilise les étiquettes du Mode B et du mode A de contrôle 1. Pour en savoir plus sur la conception expérimentale 2, consultez les conseils de la CMA le 26 octobre.
Vous pouvez accéder aux étiquettes à l'aide de la valeur temporaire Cookie-Deprecation disponible à partir d'un en-tête HTTP ou de l'API JavaScript. Pour en savoir plus sur l'implémentation, consultez la section suivante Accéder aux libellés à l'aide de la valeur d'abandon des cookies.
Nous vous enverrons également cette proposition via le processus de développement Blink habituel, au cours duquel la conception technique et la version majeure de Chrome seront finalisées. Bien qu'il s'agisse de l'implémentation que nous aimerions proposer, une discussion et une approbation plus poussées signifient que ces détails sont encore susceptibles d'être modifiés. Nous continuerons d'actualiser cette page au fur et à mesure de l'avancement des projets, et vous pouvez continuer à envoyer des commentaires ou des questions.
Mode A: groupes de navigateurs libellés
Les organisations participant aux tests pourront choisir de recevoir un ensemble persistant de libellés pour un sous-ensemble de navigateurs Chrome, ce qui permettra de mener des tests coordonnés entre différentes technologies publicitaires sur le même ensemble de navigateurs.
Par exemple, si un navigateur appartient au groupe de test label_only_3 (comme indiqué dans le tableau suivant), toutes les technologies publicitaires participantes pourront voir le même libellé label_only_3 et se coordonner en conséquence: utilisez les API PS R&M, mais abstenez-vous d'utiliser des cookies tiers. Nous attendons des utilisateurs de la page qu'ils s'assurent que les libellés sont transmis aux autres participants afin de permettre des tests cohérents tout au long du processus de sélection et de mesure des annonces.
Par exemple, cela permet à plusieurs participants d'exécuter des enchères Protected Audience sans cookies tiers sur un groupe cohérent de navigateurs. Les vendeurs participant aux enchères transmettaient l'étiquette observée aux acheteurs afin de faciliter les tests coordonnés.
Ils n'affectent aucun comportement dans les instances Chrome concernées, y compris la disponibilité des cookies tiers. Les étiquettes permettent de regrouper les tests indépendants et coordonnés, mais c'est aux parties participantes d'appliquer les paramètres pertinents pour le test. Si vous testez l'effet de la suppression des cookies tiers, chaque participant est tenu d'exclure les données des cookies tiers pour les navigateurs portant ce libellé.
L'objectif est de créer des groupes représentatifs du trafic Chrome normal. Cela signifie que les cookies tiers et les API PS R&M doivent être disponibles, même si une partie des utilisateurs peut avoir utilisé des paramètres ou des extensions pour modifier ou désactiver des fonctionnalités.
Les libellés sont généralement persistants tout au long d'une session de navigation dans Chrome et entre les sessions. Toutefois, cela n'est pas garanti, car dans de rares cas, la réinitialisation complète d'un navigateur peut également réinitialiser le libellé actuel.
Nous prévoyons d'inclure 8,5% des navigateurs Chrome stables pour le mode A, et notre proposition initiale divise cette population en neuf groupes. Les sous-groupes plus petits sont destinés à permettre aux technologies publicitaires de combiner les étiquettes de manière flexible afin de créer leurs propres tests de tailles variables. Les groupes ne se chevauchent pas.
Notez que les étiquettes control_1.* sont destinées à être utilisées comme "Contrôle 1" comme indiqué dans les conseils de la CMA sur les tests du secteur. Par conséquent, les participants aux tests ne doivent pas utiliser l'API Topics ni lancer des enchères Protected Audience pour ce trafic. Étant donné que les libellés n'affectent pas le comportement du navigateur, les participants ne doivent pas transmettre les thèmes observés ni lancer des enchères Protected Audience lorsqu'ils détectent les libellés de groupe control_1.*.
N'hésitez pas à nous envoyer des commentaires pour savoir si cette sélection de groupes répond aux besoins des organisations participantes.
| Libellé | % de trafic stable |
|---|---|
control_1.1 |
0,25 |
control_1.2 |
0,25 |
control_1.3 |
0,25 |
control_1.4 |
0,25 |
label_only_1 |
1,5 |
label_only_2 |
1,5 |
label_only_3 |
1,5 |
label_only_4 |
1,5 |
label_only_5 |
1,5 |
Les groupes de navigateur en mode A label_only_ sont disponibles depuis novembre 2023, tandis que les groupes de navigateur control_1_* en mode A sont disponibles depuis le 4 janvier 2024.
Mode B: désactiver 1% des cookies tiers
À partir du 4 janvier 2024, Chrome a désactivé les cookies tiers pour environ 1% des navigateurs stables de Chrome (ainsi que dans les navigateurs en développement, Canary et bêta au cours du 4e trimestre 2023). Les organisations qui testent les API PS R&M n'ont pas besoin d'activer ce mode, car il sera appliqué de manière uniforme à tous les navigateurs. Bien entendu, il est possible que certaines fonctionnalités du site soient affectées si le site n'a pas encore adopté de solution alternative, comme les CHIPS ou les ensembles de sites Web associés.
De plus, nous prévoyons de fournir une petite partie du trafic dans le mode B pour lequel les API PS R&M sont désactivées. Les autres API, telles que les ensembles de sites Web associés, les CHIPS et FedCM, ne seront pas désactivées. Cette combinaison devrait permettre d'établir une référence des performances pour les navigateurs sans cookies tiers et sans API PS R&M.
Dans le cadre du Mode B, nous fournissons également des libellés pour les navigateurs concernés. Les libellés sont disponibles en même temps que les API. Nous proposons de diviser la population en trois groupes treatment_1.* dans lesquels les cookies tiers sont désactivés, mais les API PS R&M sont disponibles, et un groupe control_2 dans lequel les cookies tiers et les API PS R&M sont désactivés à la fois.
Pour faciliter le débogage des intégrations de l'API Attribution Reporting et de l'API Private Aggregation, et pour aider les participants aux tests à mieux comprendre l'impact du bruit, les rapports de débogage ARA et les rapports de débogage Private Aggregation seront toujours disponibles pour les navigateurs en Mode B, à condition que l'utilisateur n'ait pas explicitement bloqué les cookies tiers. Les rapports de débogage ne seront pas disponibles dans control_2, car les API PS R&M ne sont pas disponibles dans ce segment. Les rapports de débogage seront supprimés, de même que l'abandon progressif des cookies tiers.
- Pour l'API Attribution Reporting, étant donné que les cookies tiers sont désactivés, l'origine du rapport ne pourra pas définir le cookie
ar_debuget doit s'appuyer sur les champsdebug_key(pour les rapports attribution-success) etdebug_reporting(pour les rapports de type verbose) pour activer ou désactiver la réception des rapports de débogage. - Pour l'API Private Aggregation, l'origine des rapports doit s'appuyer sur l'appel de
enableDebugMode()pour contrôler l'activation de la réception de rapports de débogage. Les entreprises doivent continuer à réfléchir à la façon dont les obligations réglementaires peuvent s'appliquer à l'utilisation de l'API Attribution Reporting et de l'API Private Aggregation, y compris les rapports de débogage.
Le mode A continue de s'exécuter et ces groupes sont différents des groupes du mode A, car un utilisateur est en mode A ou en mode B, ou aucun des deux. Les participants aux tests doivent utiliser le trafic control_1.* comme groupe de contrôle représentant le statu quo avec des cookies tiers.
| Libellé | % de trafic stable |
|---|---|
treatment_1.1 |
0,25 |
treatment_1.2 |
0,25 |
treatment_1.3 |
0,25 |
control_2 |
0,25 |
Chrome a également restreint les cookies pour 20% des clients Chrome Canary, en développement et bêta.
| Libellé | % de trafic pré-stable |
|---|---|
prestable_treatment_1 |
10 % |
prestable_control_2 |
10 % |
L'inclusion dans l'un de ces groupes de test aura le même effet que ses équivalents stables.
Comme pour le mode A, la disponibilité des API PS R&M n'est pas garantie, car les utilisateurs peuvent les désactiver dans les paramètres de confidentialité et de sécurité de Chrome. De même, il n'est pas garanti que les cookies tiers soient désactivés pour chaque membre du groupe control_2, car les utilisateurs peuvent accéder à l'interface utilisateur du navigateur pour autoriser les cookies tiers pour un site.
Surveillance des tests
Veillez à surveiller le volume de trafic relatif de chaque libellé de traitement et de contrôle. treatment_1.1 doit générer à peu près le même volume de trafic que treatment_1.2 et treatment_1.3.
Nous vous recommandons de faire preuve de discernement concernant le trafic contenant des libellés provenant de versions de Chrome antérieures à la version 120. Si votre équipe qui gère généralement le trafic incorrect identifie des user-agents qui présentent des caractéristiques de trafic incorrect, il est judicieux d'exclure ces user-agents des résultats de test.
Étiquettes de période antérieure
Jusqu'en janvier 2024, nous avions exécuté des périodes préalables à plusieurs groupes de test : une période permettant à Chrome de dimensionner avec précision et de sélectionner des groupes non biaisés d'un point de vue statistique. Ces périodes antérieures s'appliquaient à tous les groupes qui étaient censés commencer en janvier: les groupes en Mode B et Control_1.*. Aucune action n'est requise de la part du développeur ou du site dans ce cas. Ces groupes antérieurs ne constateront aucun changement de comportement ni de disponibilité de l'API. Toutefois, sachez qu'un libellé preperiod peut s'afficher dans certaines situations. Bien que les navigateurs qui reçoivent le libellé preperiod puissent passer à l'un des groupes de test, cela n'est pas garanti. Nous vous recommandons donc de ne pas partir du principe que les navigateurs associés à ce libellé peuvent être inclus dans le test.
Un groupe de test est un sous-ensemble de la population étudiée: dans ce cas, l'un des groupes étiquetés.
Accéder aux libellés à l'aide de la valeur d'abandon des cookies
Pendant la durée des modes A et B, nous avons introduit une valeur Cookie-Deprecation temporaire accessible à l'aide d'un en-tête HTTP d'acceptation et d'une API JavaScript, qui fournit le libellé du groupe de test Mode A ou B applicable du navigateur (tel que défini par les pourcentages ci-dessus), s'il appartient à l'un de ces critères.
L'accès aux libellés implique l'accès aux informations stockées sur l'appareil de l'utilisateur. Dans certaines juridictions (telles que l'UE et le Royaume-Uni), nous comprenons que cette activité est analogue à l'utilisation des cookies et que l'accès aux libellés nécessite donc probablement le consentement de l'utilisateur final. Avant de commencer à demander des libellés, nous vous recommandons de consulter un conseiller juridique pour savoir si cette obligation de consentement s'applique à votre cas.
Accéder à l'en-tête HTTP Sec-Cookie-Deprecation
Pour recevoir l'en-tête de requête Sec-Cookie-Deprecation, un site doit d'abord définir le cookie receive-cookie-deprecation. Ce cookie doit utiliser l'attribut Partitioned, ce qui signifie que l'activation de la réception de l'en-tête doit être effectuée pour chaque site de premier niveau.
Par exemple, si 3p-example.site souhaite recevoir l'en-tête Sec-Cookie-Deprecation sur ses ressources intégrées à example.com, 3p-example.site doit définir le cookie suivant dans ce contexte.
Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned; Max-Age=15552000
Les attributs de cookie Secure, HttpOnly, SameSite et Partitioned sont obligatoires. Les autres attributs Domain, Path, Expires et Max-Age peuvent être définis de la façon la plus adaptée à vos besoins, bien que Path=/ soit une valeur par défaut appropriée. Dans l'exemple présenté ici, Max-Age=15552000 est défini afin que le cookie n'expire pas avant 180 jours.
Vous pouvez commencer à définir le cookie receive-cookie-deprecation=1 avant le début de la période de test gérée par Chrome, afin de vous assurer que les navigateurs d'un groupe de test incluent l'en-tête de requête Sec-Cookie-Deprecation dès qu'il est disponible.
Par exemple, en supposant que le navigateur appartient au groupe example_label_1, les requêtes suivantes qui incluent ce cookie incluront également l'en-tête Sec-Cookie-Deprecation.
Sec-Cookie-Deprecation: example_label_1
Si le navigateur ne fait pas partie d'un groupe, aucun en-tête n'est envoyé.
Les libellés sont liés à la présence du cookie. Par conséquent, si le cookie est supprimé, entièrement bloqué ou bloqué pour le site spécifique, ils ne seront pas envoyés. L'attribut Partitioned étant destiné à continuer d'être utilisé une fois les cookies tiers complètement obsolètes, cela signifie que les cookies Partitioned peuvent être définis lorsque les cookies tiers sont bloqués.
Accéder à l'API JavaScript cookieDeprecationLabel
La valeur Cookie-Deprecation est également accessible à l'aide de l'API JavaScript navigator.cookieDeprecationLabel.getValue(). Cette action renvoie une promesse qui renvoie vers une chaîne contenant le libellé de groupe applicable. Par exemple, si le navigateur se trouvait dans le groupe example_label_1:
// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
// Request value and resolve promise
navigator.cookieDeprecationLabel.getValue().then((label) => {
console.log(label);
// Expected output: "example_label_1"
});
}
Si le navigateur ne fait pas partie d'un groupe, l'API ne sera pas disponible ou la valeur sera une chaîne vide. Assurez-vous donc d'effectuer la détection de caractéristiques.
L'API JavaScript peut être appelée, que le cookie receive-cookie-deprecation soit présent ou non. Toutefois, si les cookies sont bloqués complètement ou spécifiquement pour le site, l'API ne sera pas disponible ou renverra une chaîne vide.
Comme pour toute valeur fournie par le client, veillez à nettoyer et à valider la valeur de l'en-tête ou de l'API JavaScript avant utilisation.
Démonstration et tests
À partir de Chrome 120, des options sont disponibles pour permettre aux développeurs locaux de tester les demandes et les lectures des étiquettes.
L'option chrome://flags/#tpc-phase-out-facilitated-testing vous permet d'activer une sélection d'étiquettes de test. Ces étiquettes sont précédées de fake_ pour les différencier des étiquettes réelles. L'activation de cet indicateur n'entraîne l'inclusion du navigateur dans aucun des groupes de test.
Vous pouvez voir les libellés en action sur goo.gle/cft-demo.
Étant donné que l'inscription est obligatoire pour les API de mesure et de pertinence de la Privacy Sandbox, vous devrez peut-être ignorer cette mesure pour les tests en local en utilisant chrome://flags/#privacy-sandbox-enrollment-overrides et en fournissant l'origine de la démonstration. Vous pouvez également inclure l'indicateur de ligne de commande suivant si vous exécutez Chrome à partir d'un terminal : --args --disable-features=EnforcePrivacySandboxAttestations
Le menu déroulant de l'indicateur inclut plusieurs options. Les testeurs s'intéressent principalement aux entrées marquées "Force", car elles garantissent que le comportement du test est activé, quelles que soient les autres configurations d'appareil.
Pour ne tester que les libellés de groupe de test, sélectionnez "Enabled Force Control 1" ou "Enabled Force LabelOnly". Dans ce cas, le navigateur enverra les étiquettes "fake_control_1.1" ou "fake_label_only_1.1".
Dans Chrome M120 ou version ultérieure, vous pouvez également utiliser les entrées suivantes.
Pour tester le blocage des cookies tiers, sélectionnez "Activation du traitement forcé". Le libellé du groupe de test "fake_treatment_1.1" sera envoyé, mais la page des paramètres des cookies et le paramètre actuel des cookies seront également modifiés pour bloquer les cookies tiers.
Pour tester le blocage des cookies tiers sans API d'annonces privées, sélectionnez "Force Control 2". Cela entraînera l'envoi du libellé de groupe de test "fake_control_2", la mise à jour de la page des paramètres des cookies, le blocage des cookies tiers et la suppression des nouvelles API d'annonces privées.
Notez qu'il existe un problème : le navigateur conserve la nouvelle page de configuration des cookies et le nouveau paramètre qui bloque les cookies tiers, même si vous désactivez l'indicateur. Nous nous efforçons de résoudre ce problème. En attendant, vous pouvez tester ces valeurs d'indicateur dans un répertoire de données Chrome distinct en lançant Chrome avec l'indicateur de ligne de commande --user-data-dir=<new dir>.
Commentaires
Pour gérer les questions, nous utilisons le libellé "chrome-testing" dans le dépôt d'assistance aux développeurs sur GitHub. N'hésitez pas à nous faire part de vos commentaires et de vos discussions sur les questions initiales:
- Prévoyez-vous d'effectuer des tests en mode A, en mode B ou les deux ?
- Choisir la taille des libellés pour les tests gérés par Chrome
- Utiliser les hints client pour les tests gérés par Chrome
Vous pouvez également soumettre de nouvelles questions ou discussions dans le dépôt à l'aide du modèle "Tests gérés par Chrome".