Confidentialité Sandbox pour le Web : l'évolution du paysage de la confidentialité et l'impact sur vos sites

Chrome apportera des modifications à la confidentialité via l'initiative Privacy Sandbox tout au long de 2023 tout en développant une nouvelle technologie pour garder les informations des utilisateurs privées. Simultanément, les éditeurs Web et les marques modifient leur stratégie numérique pour aider à préserver les revenus publicitaires et les précieuses analyses marketing qui reposent sur des cookies tiers.

Cette poussée vers une confidentialité accrue des navigateurs entraîne une demande accrue de personnalisation de sites Web.

Au cours de cette session, Sam Dutton, Google Developer Advocate, passe en revue les changements à venir, partage les objectifs de l'initiative Privacy Sandbox et vous aide à mieux comprendre comment vous pouvez pivoter pour vous assurer que vous disposez des données dont vous avez besoin pour maintenir votre entreprise et vos sites. avancer.

Diapositives de la session :

Transcription:

SAM DUTTON : Salut, je suis Sam Dutton. Je suis Developer Advocate au sein de l'équipe Chrome basée ici à Londres. Merci beaucoup de m'avoir rejoint aujourd'hui. Donc trois choses que je vais faire dans les 25 prochaines minutes. Je vais vous donner un aperçu des API Privacy Sandbox. Je vais vous expliquer ce que vous devez faire maintenant, et je vais vous montrer comment vous pouvez devenir testeur et participer à la discussion sur les API et fournir des commentaires.

Alors permettez-moi de commencer par vous expliquer pourquoi nous avons besoin de la Privacy Sandbox. Beaucoup d'entre vous ne connaissent que trop bien l'histoire, mais cela vaut la peine de rappeler rapidement pourquoi nous en avons besoin et comment nous en sommes arrivés là où nous en sommes aujourd'hui. Ainsi, la Privacy Sandbox est une initiative visant à aider à créer un ensemble d'API préservant la confidentialité pour prendre en charge les modèles commerciaux qui financent le Web ouvert pour un avenir sans mécanismes de suivi tels que les cookies tiers.

Maintenant, vous avez peut-être vu cet exemple de Google I/O. C'est un site typique avec des composants provenant de différentes sources. Et bien sûr, la composabilité est l'un des superpouvoirs du web. Vous avez une carte d'une origine, un script d'une autre et ainsi de suite et bien sûr, la publicité et que cela nous plaise ou non et quel que soit l'avenir, la publicité est devenue une source de revenus cruciale et un moteur pour les affaires sur le la toile.

À ce stade de l'histoire, je pense que les navigateurs et les CMS doivent prendre en charge les cas d'utilisation de la publicité. Donc quel est le problème? Eh bien, la sélection des publicités, la mesure des conversions, la détection des fraudes, la personnalisation des appareils, de nombreux autres cas d'utilisation se sont appuyés sur l'identité intersites en utilisant des mécanismes qui n'ont tout simplement pas été conçus avec la confidentialité à l'esprit.

Maintenant, pas seulement les cookies tiers, mais les empreintes digitales sont utilisées pour suivre le comportement des utilisateurs sur les sites ou bien les sites demandent des informations personnelles, telles que les adresses e-mail et en plus, les écosystèmes tiers sont vraiment complexes, en particulier pour la publicité. Même les développeurs, les annonceurs ou les éditeurs ne comprennent pas la chaîne d'approvisionnement des services tiers.

Donc, certainement, lorsque je visite un site Web, je ne suis pas au courant de tous les tiers impliqués et de ce qu'ils font avec mes données et ce n'est pas seulement moi, la recherche montre que les gens se soucient vraiment de contrôler leurs données. Les préoccupations en matière de confidentialité orientent de plus en plus les choix sur ce que les gens font en ligne et les régulateurs du monde entier renforcent les exigences en matière de confidentialité, et cela se produit très rapidement.

Donc, étant donné le nombre d'entreprises qui comptent sur une publicité en ligne efficace et le nombre d'éditeurs qui comptent sur la publicité pour monétiser leurs sites, et tout un tas d'autres cas d'utilisation, c'est un problème pour l'ensemble de l'écosystème Web et pas seulement pour les entreprises technologiques et les plateformes publicitaires. Mais bien sûr, comme le Web est une plate-forme ouverte, les propositions de changement nécessitent une adhésion et des commentaires, et les navigateurs tels que Chrome ne peuvent pas et ne veulent pas agir unilatéralement.

Les navigateurs ne sont pas des produits pour lesquels les fournisseurs de navigateurs peuvent prendre des décisions de manière isolée et la réalité est que le Web n'a pas été conçu pour la plupart des exigences qui sont au cœur de la plate-forme aujourd'hui pour la détection des fraudes publicitaires, la gestion de l'identité et toutes ces autres exigences cas d'utilisation et bientôt. Nous avons donc besoin de technologies spécialement conçues pour ce Web axé sur la confidentialité, et c'est là qu'intervient la Privacy Sandbox.

Chrome a donc travaillé avec la communauté Web aux côtés des parties prenantes de l'industrie et des régulateurs pour développer de nouvelles technologies de préservation de la vie privée qui peuvent soutenir un écosystème sain et durable. Maintenant, une fois que ces nouvelles API spécialement conçues sont disponibles, nous devons nous assurer que les entreprises ont le temps de les adopter afin que nous puissions éliminer en toute sécurité la prise en charge des cookies tiers dans Chrome et poursuivre notre travail pour atténuer d'autres types de suivi.

Maintenant, l'ensemble de principes de base de cette initiative est le modèle de confidentialité potentiel pour le Web, et cela a été développé par des experts en confidentialité et des informaticiens de Google. Ce modèle de confidentialité établit un ensemble de règles de base pour la conception de technologies qui répondent aux cas d'utilisation de la plate-forme Web dont j'ai parlé, tout en respectant nos besoins changeants en matière de confidentialité.

En particulier, la proposition couvre la question difficile de savoir comment activer les connexions entre les sites sans compromettre la confidentialité. Désormais, l'une des innovations majeures des API Privacy Sandbox est de permettre au navigateur d'agir au nom de l'utilisateur, en revenant en quelque sorte au rôle principal du navigateur en tant que ce que nous appelons l'agent utilisateur.

Avec les technologies actuelles, les données sont collectées, agrégées et partagées par des tiers pour suivre la navigation des utilisateurs sur les sites. Les API Privacy Sandbox peuvent permettre à la mesure de la conversion des enchères publicitaires et à ces autres tâches d'être exécutées par le navigateur de l'utilisateur sur l'appareil de l'utilisateur.

Nous devons donc reconstruire les plates-formes publicitaires et le Web en collaborant entre les fournisseurs de navigateurs, les plates-formes, les annonceurs, les éditeurs adtech, les utilisateurs, les régulateurs et la communauté de la confidentialité, sans oublier les développeurs comme vous qui travaillent avec les plates-formes CMS.

Donc, avec tout cela à l'esprit, je veux juste vous donner un coup d'œil sur les API Privacy Sandbox elles-mêmes. Chez Google, il s'agit donc d'une initiative partagée sur le Web et Android. Privacy Sandbox sur Android se concentre sur l'introduction de nouvelles solutions publicitaires plus privées sans identifiants inter-applications.

Le Web et Android, bien sûr, partagent les mêmes principes et plusieurs des propositions Web sont également en cours de développement pour Android. Cependant, bien sûr, les plates-formes mobiles Web et Android reposent sur des technologies fondamentalement différentes.

C'est donc sur Android une initiative distincte, mais c'est une initiative que ceux d'entre vous qui créent des applications Android et travaillent sur le Web, vous voudrez garder un œil sur cela. Google a donc testé les nouvelles API en collaboration avec un éventail de partenaires dans le monde.

Des centaines d'entreprises participent à des forums publics, soit le W3C, expliquent les enjeux sur GitHub, etc., publient des perspectives et des analyses et rejoignent des tables rondes de l'industrie, partagent des commentaires avec Chrome et Android et bien sûr, participent à des tests.

Maintenant, ne vous y trompez pas, Privacy Sandbox a de nombreuses exigences à couvrir et cela va être difficile en cours de route. Je veux dire, je pense que la bonne nouvelle est que la fin de tout cela aura des plateformes plus sûres et plus privées pour les utilisateurs et meilleures pour les annonceurs, les éditeurs, les développeurs et bien sûr, pour des plateformes comme WordPress.

Je ne vais donc pas décrire toutes les API Privacy Sandbox. Au lieu de cela, je voudrais me concentrer sur les trois principales API publicitaires de la Privacy Sandbox. Il s'agit des sujets, de FLEDGE et des rapports d'attribution. Nos sujets et FLEDGE sont connus sous le nom d'API de pertinence.

Now Topics fournit des signaux de haut niveau sur l'intérêt d'un utilisateur en fonction de son historique de navigation récent. Et les sujets peuvent être combinés avec des signaux contextuels et des données de première partie pour sélectionner des publicités pertinentes.

Et FLEDGE prend en charge un remarketing plus granulaire et des cas d'utilisation d'audience personnalisée où les spécialistes du marketing souhaitent atteindre des publics qui ont manifesté de l'intérêt pour des sites Web ou des produits spécifiques, mais bien sûr, pour rendre cela possible dans le respect de la vie privée.

Enfin, Attribution Reporting est la proposition de Chrome pour la mesure des campagnes en préservant la confidentialité, en fournissant des rapports de performances anonymes et lorsque les internautes voient ou cliquent sur une annonce, puis effectuent ensuite un achat ou un autre type de conversion.

Ces API ont donc traversé une période de test sous Android et dans Chrome sur ordinateur et mobile. Si vous travaillez avec des plates-formes de technologie publicitaire, vous devez vous assurer que vous comprenez les plans de ces plates-formes pour traiter ces cas d'utilisation et les cas d'utilisation qui sont rencontrés par ces API pour cet avenir sans cookies tiers ni autres mécanismes de suivi.

Nous avons donc maintenant eu une période de tests techniques avec les API activées à l'aide des indicateurs Chrome, et maintenant dans l'essai d'origine initialement activé pour seulement un petit pourcentage d'utilisateurs de Chrome au départ. Nous en sommes donc maintenant à ce stade des tests d'utilité, 50 % des utilisateurs de développement et bêta de Chrome Canary ont les API d'essai d'origine des annonces activées sur les pages qui fournissent un jeton valide et 5 % des utilisateurs stables.

Maintenant, c'est bien sûr un petit pourcentage du trafic global de Chrome, mais c'est suffisant pour des tests limités des API avec de vrais utilisateurs. Et nous nous dirigeons maintenant vers le lancement dans Chrome Stable où les API seront disponibles pour tous les utilisateurs par défaut et je reviendrai sur les délais pour cela plus tard.

Donc, juste pour réitérer, pour un seul utilisateur, vous pouvez activer les API à l'aide des indicateurs Chrome, mais pour tester à grande échelle, vous devez participer à l'essai d'origine de Privacy Sandbox, et je partagerai des liens plus tard pour savoir comment faire tout cela. .

Soit dit en passant, Chrome met également à jour les contrôles de confidentialité des utilisateurs, tels que l'interface utilisateur pour cela. Les gens pourront voir et gérer les intérêts associés à leur navigation ou désactiver complètement les API.

Il existe donc en fait trois autres technologies Privacy Sandbox que je pense que vous voudrez peut-être également tester ou certainement signaler à l'un de vos fournisseurs tiers. Tout d'abord, CHIPS. C'est-à-dire que les cookies ayant un état de partition indépendant permettent aux développeurs d'activer un cookie pour un stockage partitionné avec une boîte à cookies séparée par site de niveau supérieur.

Les ensembles de première partie permettent aux noms de domaine associés détenus et exploités par la même entité de se déclarer comme appartenant à la même première partie, et aux jetons d'état privés. Vous avez peut-être entendu parler de ce nom initial sous le nom de Trust Tokens. Il s'agit d'une API permettant de véhiculer une quantité limitée d'informations d'un contexte de navigation à un autre par exemple, à travers des sites pour aider à lutter contre la fraude mais sans utiliser de techniques de suivi passif.

Alors tout d'abord, examinons de plus près l'API Topics. L'API Topics fournit un mécanisme permettant d'activer la publicité basée sur les centres d'intérêt, mais sans permettre à des tiers de suivre l'activité de navigation des utilisateurs. Ainsi, l'API a en un sens trois composants principaux, et d'abord la publicité basée sur les intérêts a besoin d'une taxonomie de sujets d'intérêt.

La taxonomie de l'API Topics ressemble à ceci. Il s'agit d'une liste publique de sujets lisibles par l'homme qui évite les sujets sensibles. Et maintenant, cela est susceptible de changer et de se développer au fil du temps en consultation avec l'écosystème Web et cela signifie que des gens comme vous, nous avons besoin de vos commentaires à ce sujet ainsi que sur tout le reste.

Ainsi, l'API Topics doit déduire les intérêts d'un utilisateur en fonction de son activité de navigation, mais comme je l'ai dit, de le faire d'une manière qui préserve sa vie privée. Ainsi, les principaux sujets d'intérêt sont enregistrés pour un utilisateur dans son navigateur sur son appareil en fonction de son activité de navigation récente, par son navigateur sur son appareil.

À l'heure actuelle, Topics le fait en utilisant l'apprentissage automatique pour mapper les noms d'hôte des pages que l'utilisateur visite vers Topics à partir de la taxonomie. Maintenant, comme pour la taxonomie Topics elle-même, cette approche se développera au fil du temps. Mais déduire les intérêts de l'activité de navigation doit trouver le bon équilibre.

Si vous avez trop de détails sur la navigation des utilisateurs, c'est mauvais pour la confidentialité, mais trop peu de granularité signifie que l'API n'est pas utile. Je pense que dans un sens, la principale chose à comprendre ici est que les sujets d'intérêt ne sont qu'un signal pour trouver ce qui est pertinent pour les utilisateurs.

Ainsi, une fois que les sujets d'intérêt ont été déduits par le navigateur pour un utilisateur, Topics doit fournir aux appelants de l'API un accès aux sujets d'intérêt qu'ils ont observés pour l'utilisateur.

Ainsi, lorsque l'utilisateur navigue sur le Web, l'API comporte deux étapes. Un appelant API, qui peut être une plate-forme adtech par exemple, appelle l'API sur une page pour signaler qu'il souhaite observer les sujets de la page actuelle et de l'utilisateur actuel.

Plus tard, l'appelant de l'API peut accéder aux rubriques qu'il a observées pour l'utilisateur. Maintenant, tout cela doit être fait sans rien révéler de plus sur l'activité de navigation de l'utilisateur autre que les sujets d'intérêt qui ont été observés.

Ainsi, l'API Topics fournit deux façons d'observer les sujets d'intérêt pour un utilisateur, puis d'accéder aux sujets qui ont été observés, d'abord avec une API JavaScript ou en utilisant les en-têtes de requête et de réponse sur une requête de récupération.

La première façon pour un appelant de l'API Topics de signaler au navigateur qu'il a observé des sujets pour un utilisateur consiste à appeler document.browsingTopics à partir d'un iframe intégré aux sites visités par l'utilisateur.

Maintenant, plus tard, l'appelant de l'API peut appeler la même méthode document.browsingTopics pour accéder aux rubriques qu'il a observées pour l'utilisateur actuel. Et la raison pour laquelle cette méthode a besoin d'un iframe, c'est que le contexte d'observation des sujets doit être le même que le contexte d'accès aux sujets.

L'autre façon d'observer et d'accéder aux sujets consiste à utiliser les en-têtes de recherche, de demande et de réponse. L'appelant de l'API doit d'abord effectuer une requête de récupération vers une URL sur son origine, y compris l'objet true des rubriques de navigation dans le paramètre options.

Et si la réponse à la requête de récupération inclut un en-tête Observe-Browsing-Topics ?1, eh bien, cela signale au navigateur que l'appelant veut que le navigateur enregistre que l'appelant a observé les sujets d'intérêt pour l'utilisateur actuel pour le courant page. J'espère que cela à du sens.

Désormais, les sujets observés pour un utilisateur peuvent être récupérés à partir de la demande de récupération d'un appelant en accédant à l'en-tête de demande sec-browsing-topics. Voici donc tout le processus du début à la fin. Je suis conscient du temps, donc je ne vais pas le parcourir maintenant, mais nous partagerons cela plus tard afin que vous puissiez voir comment cela fonctionne, l'ensemble du processus et nous l'aurons pour chacune des API.

Et vous pouvez essayer la démo Topics qui utilise la méthode JavaScript iframe pour observer et accéder aux sujets ou vous pouvez essayer notre démo qui utilise l'approche d'en-tête de requête de récupération. chrome://topics-internals affiche les sujets pour l'utilisateur actuel, les sujets conférés pour les noms d'hôte et les informations techniques sur la mise en œuvre de l'API.

Vous pouvez également exécuter le laboratoire Topics co pour tester l'inférence de sujets à l'aide du modèle de classificateur Topics. Maintenant, trois grandes questions ouvertes pour vous avant de quitter Topics, comment pourrions-nous faire un meilleur travail pour déduire les sujets d'intérêt pour un utilisateur en fonction de son activité de navigation ? Comment pouvons-nous améliorer le contenu et la structure de la taxonomie pour la rendre plus utile tout en préservant la confidentialité des utilisateurs ? Et comment pouvons-nous améliorer l'architecture globale de l'API ?

Je pense qu'une chose à garder à l'esprit ici est que nous ayons des sujets ou quelque chose de différent, nous devons toujours répondre à ses cas d'utilisation. Ensuite, FLEDGE. Il s'agit donc d'une API pour les options publicitaires sur l'appareil afin de servir le remarketing et les cas d'utilisation d'audience personnalisée sans avoir besoin d'un suivi tiers intersite.

Je pense que c'est un peu plus de détails de code avec FLEDGE car il a un travail plus compliqué à faire que Topics. Il y a donc trois parties dans le processus FLEDGE. Tout d'abord, l'acheteur d'annonces ajoute des utilisateurs ou plutôt des navigateurs individuels à ce qu'on appelle des groupes d'intérêt. Ce sont comme des audiences personnalisées, mais l'appartenance à un groupe d'intérêt est stockée sur le navigateur de l'appareil de l'utilisateur.

Désormais, à un moment donné, lorsqu'un utilisateur visite un site qui affiche des annonces, tel qu'un site d'éditeur, un vendeur d'annonces peut lancer une enchère publicitaire pour sélectionner une annonce pour lui, et avec FLEDGE, cette enchère peut être exécutée sur l'appareil de l'utilisateur.

Pour sélectionner une annonce, le code d'enchères exécute la logique d'enchères des acheteurs et la logique d'enchères du vendeur. Et enfin, le navigateur publie des rapports d'enchères aux points finaux fournis par les vendeurs et les acheteurs.

Je passe donc très brièvement en revue FLEDGE étape par étape. Imaginez tout d'abord qu'un utilisateur visite un magasin de chaussures en ligne, fait quelques recherches. Une plate-forme adtech ou peut-être un annonceur lui-même effectue un appel JavaScript pour dire au navigateur de rejoindre un groupe d'intérêt. Et ce groupe pourrait être nommé quelque chose comme Trail Running Shoes.

L'objet de configuration d'un groupe d'intérêt peut ressembler à ceci. Dans cet exemple, la technologie publicitaire du magasin de chaussures peut avoir un groupe d'intérêt pour le remarketing auquel elle aimerait ajouter l'utilisateur, et elle a bien appelé ce groupe, Trail Running Shoes. Et la plate-forme adtech du magasin de chaussures appelle rejoindre le groupe d'intérêt publicitaire pour demander au navigateur de l'utilisateur de rejoindre son groupe d'intérêt Trail Running Shoes en utilisant la configuration que je viens de vous montrer.

Et le deuxième paramètre précise la durée du groupe d'intérêt qui est plafonnée à 30 jours. Maintenant, l'utilisateur visite un site qui publie des annonces. Dans cet exemple, un site Web d'actualités. Une enchère pour sélectionner une annonce à afficher pour l'utilisateur est exécutée en JavaScript sur l'appareil de l'utilisateur par le vendeur à l'aide de l'exécution d'enchères publicitaires, et le vendeur est probablement une plate-forme de technologie publicitaire, mais peut-être l'éditeur lui-même, dans ce cas, le site d'actualités.

Désormais, cette enchère sélectionne l'annonce la plus appropriée en fonction des enchères pour chacun des groupes d'intérêt auxquels appartient le navigateur de l'utilisateur, ainsi que d'autres facteurs du vendeur et du navigateur lui-même.

En regardant maintenant le code, l'éditeur ou une plate-forme vendant de l'espace publicitaire sur le site de l'éditeur crée des données de configuration pour l'enchère publicitaire. Le vendeur demande ensuite au navigateur d'exécuter une enchère publicitaire pour sélectionner une annonce dans le navigateur, et la valeur renvoyée par l'enchère publicitaire est transmise à un élément appelé cadre clôturé afin que le site puisse afficher l'annonce gagnante.

Désormais, un cadre clôturé peut être utilisé pour afficher une annonce, mais il ne peut pas interagir avec la page qui l'entoure. Et puis le vendeur et l'acheteur gagnant ont chacun la possibilité d'effectuer une journalisation et un rapport, et cela se fait en appelant navigator.reportresult.

Enfin, l'utilisateur, si tout se passe bien, appuie ou clique sur l'annonce et maintenant l'API Attribution Reporting prend le relais. Et encore une fois, nous avons un diagramme montrant l'ensemble du processus du début à la fin, que nous partagerons avec vous après le discours d'ouverture.

Maintenant, pour finir, j'aimerais vous parler un peu de l'API Privacy Sandbox pour la mesure des publicités, qui est Attribution Reporting. Le rapport d'attribution est utilisé pour mesurer à quel moment un clic sur une annonce ou une impression d'annonce entraîne une conversion. Par exemple, lorsque la vue d'une annonce sur un site d'actualités conduit à un achat dans un magasin de chaussures en ligne.

Désormais, comme pour Topics et FLEDGE, cette API est conçue pour éviter le suivi intersite. Ainsi, l'API permet deux types de résultats de mesure, des rapports au niveau des événements et des rapports récapitulatifs. Alors permettez-moi de décrire brièvement comment cela fonctionne.

Examinons d'abord les rapports au niveau des événements. Ainsi, les liens publicitaires peuvent être configurés avec des attributs spécifiques à l'API Attribution Reporting, ce qui permet de comptabiliser les vues et les clics avec une demande côté conversion.

Désormais, lorsqu'un utilisateur clique sur une publicité ou voit une publicité, puis effectue une conversion, le navigateur génère un rapport, et dans ce rapport, la société de publicité ou la technologie publicitaire inclut deux éléments de données. Premièrement, toutes les données qu'ils veulent sur le clic ou l'impression de l'annonce et cela peut être très détaillé, par exemple un ID de création, des informations sur l'éditeur, l'horodatage, etc. Et deuxièmement, un petit élément de données sur la conversion des annonces.

Maintenant, pour protéger la confidentialité des utilisateurs, cela ne peut pas être trop détaillé. Plus tard, le navigateur envoie ce rapport sur… Eh bien, ce rapport avec les données que je viens d'expliquer à la technologie publicitaire ou à l'annonceur, et cela inclut un délai pour éviter le suivi des utilisateurs.

Le rapport contient deux éléments de données, des données détaillées sur le clic ou l'impression sur l'annonce, l'événement et des données de haut niveau sur la conversion. Il s'agit donc d'un rapport au niveau des événements. Examinons maintenant les rapports de synthèse.

Maintenant, l'API du navigateur pour générer un rapport de synthèse est similaire, mais les résultats et le mécanisme sont un peu différents. Donc, encore une fois, lorsqu'un utilisateur clique sur une annonce ou voit une annonce, puis effectue une conversion ultérieure, le navigateur génère un rapport, et dans ce rapport, la société de publicité ou la technologie publicitaire peut inclure toutes les données qu'elle souhaite sur le clic ou l'impression de l'annonce et toutes les données qu'elles souhaitez connaître la conversion des annonces, mais ce rapport est crypté.

Et c'est une protection de la vie privée car ce rapport contient des données détaillées sur la conversion et l'impression. Ainsi, le rapport pourrait être utilisé pour le suivi intersite s'il n'était pas crypté. Puis plus tard, le navigateur renverra ce rapport crypté, avec un petit délai.

Et de cette façon, une plate-forme adtech collectera de nombreux rapports de nombreux utilisateurs, puis enverra tous les rapports à un service d'agrégation comme on l'appelle et ce service agrégera tous ces rapports, les déchiffrera, ajoutera du bruit pour protéger la confidentialité des utilisateurs, puis renvoie le résultat final et le résultat final est appelé un rapport de synthèse. Il contient des données de mesure pour de nombreux utilisateurs.

C'est donc la mesure d'attribution. J'espère que cela à du sens. Je créerai un lien vers de nombreuses autres ressources pour vous aider à comprendre et à tester plus en détail les API Privacy Sandbox. Mais une dernière chose que je voudrais mentionner, Privacy Sandcastle.

Il s'agit d'une démo qui combine toutes les principales API Privacy Sandbox. Il a été construit par notre équipe à Tokyo. C'est encore très nouveau. Mais vous pouvez obtenir le code de GitHub et l'exécuter localement, et il est conçu pour vous aider à comprendre comment toutes ces API s'imbriquent.

Avant de terminer, j'aimerais juste faire un récapitulatif et regarder la chronologie de Privacy Sandbox. Comme vous pouvez le voir, nous approchons du trimestre où nous commencerons à expédier les API, ce qui signifie qu'elles seront disponibles par défaut dans Chrome Stable et prêtes à être testées à l'échelle de la production. Maintenant, ce n'est que peu de temps sur le calendrier, et je peux me voir. Je suis proche du temps ici.

Donc, quelques choses que je pense que vous devez faire maintenant. Tout d'abord, comprenez les délais pour le Web et Android. Assurez-vous que vous et vos fournisseurs tiers êtes prêts pour les changements qui sont maintenant imminents. Deuxièmement, auditez vos sites pour comprendre où ils s'appuient sur des cookies tiers et d'autres mécanismes qui sont obsolètes. Nous partagerons des liens vers des outils et des instructions sur la façon de le faire après l'événement d'aujourd'hui.

Ensuite, demandez à vos fournisseurs tiers, tels que les plates-formes adtech, etc., comment ils se préparent à répondre à leurs principaux cas d'utilisation en l'absence de cookies tiers ou d'autres mécanismes de suivi intersites et enfin, testez les API Privacy Sandbox et fournissez des commentaires. et demandez à vos fournisseurs tiers de faire de même.

Et s'ils ne vont pas bien, demandez-leur pourquoi et dites-nous quelle est la réponse à cette question. Ainsi, privacysandbox.com fournit des délais, des FAQ et plus d'informations sur les efforts multiplateformes. Je partagerai les URL après cet événement, mais vous pouvez trouver une grande partie du contenu auquel j'ai fait référence ici dans la section Privacy Sandbox sur developer.chrome.com.

En particulier, cela contient des ressources qui expliquent comment poser des questions pour nous et comment fournir des commentaires, et vous pouvez en savoir plus sur les essais d'origine sur developer.chrome.com. Nous avons également créé une série de courtes vidéos et d'articles pour vous aider à expliquer les concepts de Chrome tels que les essais d'origine, les drapeaux Chrome, le contenu clignotant, etc.

Alors merci pour votre écoute. C'est tout de ma part. Comme je l'ai dit, si vous avez besoin d'aide, veuillez consulter ces ressources ou vous pouvez simplement m'envoyer un message direct SW12 sur Twitter. Merci beaucoup.