Tests facilités par Chrome

Pour préparer l'abandon des cookies tiers, nous proposerons des modes de test gérés par Chrome qui permettront aux sites de prévisualiser le comportement et le fonctionnement 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: une installation de Chrome sur un appareil. Chaque répertoire de données d'un utilisateur individuel 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 cadre des tests gérés par Chrome, un ensemble de navigateurs pour lesquels des libellés sont définis.

Étiquette: dans ce contexte, 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 période des tests gérés par Chrome, garantissant ainsi que le libellé d'un navigateur reste le même 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 pour permettre des tests coordonnés entre différents testeurs.
  • Mode B:depuis le 4 janvier 2024, Chrome a désactivé les cookies tiers dans le monde entier sur une partie des navigateurs Chrome.

Les deux modes seront maintenus au moins jusqu'au 2e trimestre 2024. Lorsque les cookies tiers sont désactivés en Mode B, ils le resteront pendant toute la phase d'abandon des cookies tiers.

Nous avons collaboré avec la CMA pour nous assurer que ces modes de test sont conformes au framework (et au calendrier) de test pour les tiers, tel que défini dans ses conseils sur les tests du secteur. Par conséquent, la CMA prévoit que les résultats des tests effectués dans ces modes pourront être utilisés pour évaluer la Privacy Sandbox. La CMA a indiqué qu'elle serait susceptible d'accorder plus d'importance aux résultats de la conception expérimentale 2, qui utilise les étiquettes Mode B et celles de la commande 1 du mode A. Pour en savoir plus sur la version expérimentale de la version 2, consultez les conseils de la CMA du 26 octobre.

Nous enverrons également cette proposition via le processus de développement Blink habituel, au cours duquel la conception technique et le jalon de version de Chrome seront finalisés. Bien qu'il s'agisse de l'implémentation que nous aimerions proposer, une discussion et une approbation supplémentaires signifient que ces détails sont encore susceptibles de changer. Nous continuerons de mettre à jour cette page au fur et à mesure de l'avancement du plan, et vous pouvez continuer à envoyer des commentaires ou des questions.

Mode A: groupes de navigateurs libellés

Les organisations participant aux tests peuvent choisir de recevoir un ensemble persistant de libellés pour un sous-ensemble de navigateurs Chrome, ce qui permet d'effectuer des tests coordonnés sur 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: utiliser les API PS R&M, mais pas les cookies tiers. Les participants à la page doivent s'assurer que les libellés sont transmis à d'autres participants afin de permettre des tests cohérents tout au long du processus de sélection et de mesure des annonces.

Par exemple, plusieurs participants peuvent participer à des enchères Protected Audience sans cookies tiers sur un groupe cohérent de navigateurs. Les vendeurs participant aux enchères transmettraient l'étiquette observée aux acheteurs afin de faciliter les tests coordonnés.

Les libellés n'affectent aucune fonctionnalité dans ces instances de Chrome, y compris la disponibilité des cookies tiers. Les libellés permettent de regrouper les tests indépendants et coordonnés, mais l'application des paramètres pertinents au test revient aux participants. Si vous testez l'effet de la suppression des cookies tiers, chaque participant est responsable de l'exclusion des données des cookies tiers pour les navigateurs associés à 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 modifié ou désactivé des fonctionnalités via des paramètres ou des extensions.

Les libellés sont généralement persistants tout au long d'une session de navigation dans Chrome, ainsi que d'une session à l'autre. Toutefois, cela n'est pas garanti, car dans de rares cas, la réinitialisation complète d'un navigateur peut entraîner la réinitialisation du libellé actuel.

Nous prévoyons d'inclure 8, 5% des navigateurs stables de Chrome pour le mode A.Notre proposition initiale divise cette population en neuf groupes. Les sous-groupes plus petits sont destinés à permettre aux technologies publicitaires de combiner des libellés de manière flexible pour créer leurs propres tests de tailles différentes. Les groupes ne se chevauchent pas.

Notez que les étiquettes control_1.* sont destinées à être utilisées en tant que "Contrôle 1", comme décrit dans les conseils de la CMA sur les tests sectoriels. Par conséquent, les participants aux tests ne doivent pas utiliser l'API Topics ni lancer d'enchères Protected Audience pour ce trafic. Comme les étiquettes n'affectent pas les fonctionnalités, les participants ne doivent pas transmettre les thèmes observés ni exécuter des enchères Protected Audience lorsqu'ils détectent les libellés de groupe control_1.*.

N'hésitez pas à nous faire part de vos commentaires pour nous demander si cette sélection de groupes répond aux besoins des organisations participantes.

Libellé % du 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 navigateurs label_only_ du mode A sont disponibles depuis novembre 2023, tandis que les groupes de navigateurs control_1_* du mode A sont disponibles depuis le 4 janvier 2024. Nous continuerons à envoyer tous les libellés des modes A et B jusqu'à l'abandon progressif des cookies tiers début 2025.

Mode B: désactiver 1% des cookies tiers

Chrome a désactivé les cookies tiers pour environ 1% des navigateurs stables du navigateur à partir du 4 janvier 2024 (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 à l'ensemble des navigateurs. Bien entendu, il est possible que certaines fonctionnalités du site soient affectées si le site n'a pas encore adopté une solution alternative, telle que CHIPS ou les ensembles de sites Web associés.

De plus, nous prévoyons de fournir une petite partie du trafic en Mode B pour lequel les API PS R&M sont désactivées. D'autres API, telles que les ensembles de sites Web associés, CHIPS et FedCM, ne seront pas désactivées. Cette combinaison devrait être utile pour établir une référence de performances pour les navigateurs sans cookies tiers et sans les API PS R&M.

Dans le cadre du Mode B, nous fournissons également des libellés pour les navigateurs concernés. Ils seront disponibles au moment où les API seront désactivées. 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.

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 de l'ARA et les rapports de débogage de l'agrégation privée seront toujours disponibles pour les navigateurs en mode B, à condition que l'utilisateur n'ait pas bloqué explicitement 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 encore supprimés, tout comme les cookies tiers.

Le mode A continue de fonctionner et ces groupes sont différents des groupes en mode A, car un utilisateur sera soit en mode A, soit 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é % du trafic stable
treatment_1.1 0.25
treatment_1.2 0.25
treatment_1.3 0.25
control_2 0.25

Chrome a également limité 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 %

Le fait d'être inclus dans l'un de ces groupes de test aura les mêmes effets que dans leurs é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 à partir des paramètres Confidentialité et 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 étiquette 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 les user-agents qui présentent des caractéristiques de trafic incorrect, il est judicieux de les exclure des résultats de test.

Libellés précédant la période

Jusqu'en janvier 2024, nous avons effectué des périodes préalables pour plusieurs groupes de test : une période de temps pour permettre à Chrome de dimensionner et de sélectionner avec précision des groupes non biaisés d'un point de vue statistique. Ces périodes préalables ont été appliquées à tous les groupes dont le démarrage était prévu en janvier: les groupes en mode B et en contrôle_1.*. Aucune action n'est requise de la part du développeur ou du site. Ces groupes antérieurs ne constateront aucun changement du comportement ni de la disponibilité de l'API, mais vous devez savoir que le libellé preperiod peut s'afficher dans certaines situations. Bien que les navigateurs recevant 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é sont inclus dans le test.

Un groupe de test est un sous-ensemble de la population étudiée. Dans ce cas, il s'agit de l'un des groupes étiquetés.

Pour toute la durée des modes A et B, nous introduirons une valeur Cookie-Deprecation temporaire, accessible via un en-tête HTTP et une API JavaScript, qui fourniront le libellé pour le groupe de test Mode A ou B applicable du navigateur (tel que défini par les pourcentages ci-dessus), s'il n'y en a qu'un.

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. L'accès aux libellés nécessite donc probablement le consentement de l'utilisateur final. Avant de commencer à demander des étiquettes, nous vous recommandons de consulter un conseiller juridique pour savoir si cette obligation de consentement s'applique à votre cas.

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 comme étant les mieux adaptés à vos besoins, bien que Path=/ constitue une bonne valeur par défaut. Dans cet exemple, la valeur Max-Age=15552000 est définie de sorte que le cookie n'expire qu'au bout de 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, pour 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 fait partie du groupe example_label_1, les requêtes ultérieures incluant 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, les libellés ne seront pas envoyés. Comme l'attribut Partitioned est destiné à être utilisé de façon continue après l'abandon des cookies tiers, 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 via l'API JavaScript navigator.cookieDeprecationLabel.getValue(). Cela renverra une promesse qui se résout en une chaîne contenant le libellé de groupe applicable. Par exemple, si le navigateur se trouve 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 une détection des fonctionnalités.

L'API JavaScript peut être appelée indépendamment de la présence du cookie receive-cookie-deprecation. Toutefois, si les cookies sont complètement bloqués ou spécifiquement pour le site, l'API sera à nouveau indisponible 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 de l'utiliser.

Démonstration et tests

À partir de Chrome 120, des indicateurs sont disponibles pour permettre aux développeurs locaux de tester la demande et la lecture des libellés.

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 pas l'inscription du navigateur à aucun des groupes de test.

Vous pouvez voir les libellés en action via goo.gle/cft-demo.

Étant donné que l'inscription est appliquée pour les API de mesure et de pertinence de la Privacy Sandbox, vous devrez peut-être ignorer cette règle pour les tests en local en utilisant chrome://flags/#privacy-sandbox-enrollment-overrides et en indiquant l'origine de démonstration. Vous pouvez également inclure l'option de ligne de commande suivante si vous exécutez Chrome à partir d'un terminal : --args --disable-features=EnforcePrivacySandboxAttestations

chrome://flags/#tpc-phase-out-facilitated-testing

Le menu déroulant des indicateurs comprend plusieurs options. Les testeurs seront principalement intéressés par les entrées marquées "Force", car elles garantissent que le comportement du test est activé quelles que soient les autres configurations d'appareil.

Pour tester uniquement les libellés des groupes de test, sélectionnez "Enabled Force Control 1" ou "Enabled Force LabelOnly". Ainsi, le navigateur enverra les libellés "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 "Enabled Force Treatment" (Traitement forcé activé). Le libellé du groupe de test "fake_process_1.1" sera alors envoyé, mais la page des paramètres des cookies et les paramètres actuels seront 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". Le libellé du groupe de test "fake_control_2" sera envoyé, la page des paramètres des cookies sera mise à jour, les cookies tiers seront bloqués et les nouvelles API d'annonces privées seront supprimées.

Notez qu'actuellement, le navigateur continue à utiliser 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, mais 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

Nous utilisons le libellé "chrome-testing" du dépôt d'assistance pour les développeurs sur GitHub pour gérer les questions. N'hésitez pas à nous faire part de vos commentaires et de vos discussions sur les questions initiales:

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".