Exploration de la Privacy Sandbox

La Privacy Sandbox est une série de propositions visant à répondre aux cas d'utilisation de tiers sans cookies tiers ni autres mécanismes de suivi.

Résumé

  • Cet article présente les API et les concepts des propositions de la Privacy Sandbox.
  • Les auteurs des propositions invitent la communauté, en particulier les acteurs du secteur de la publicité (éditeurs, annonceurs et entreprises de technologie publicitaire), à suggérer les cas d'utilisation manquants et à partager des informations sur la façon de soutenir vos cas d'utilisation commerciaux.
  • Vous pouvez commenter les propositions en signalant les problèmes dans les dépôts dont les liens sont indiqués ci-dessous.
  • Vous trouverez un glossaire pour les propositions à la fin de cet article.

L'état actuel de la confidentialité sur le Web

Les sites Web utilisent les services d'autres entreprises pour fournir des analyses, diffuser des vidéos et effectuer beaucoup d'autres choses utiles. La composabilité est l'un des superpouvoirs du Web. Les annonces sont notamment incluses dans les pages Web via des cadres iFrame et JavaScript tiers. Le suivi des visionnages d'annonces, des clics et des conversions est effectué à l'aide de cookies et de scripts tiers.

Toutefois, lorsque vous consultez un site Web, il est possible que vous ne soyez pas au courant des tiers impliqués ni de ce qu'ils font de vos données. Même les éditeurs et les développeurs Web peuvent ne pas comprendre l'ensemble de la chaîne d'approvisionnement tierce.

La sélection des annonces, la mesure des conversions et d'autres cas d'utilisation reposent actuellement sur la création d'une identité d'utilisateur stable sur plusieurs sites. Auparavant, cette opération s'effectuait avec des cookies tiers, mais les navigateurs ont commencé à limiter l'accès à ces cookies. Par ailleurs, d'autres mécanismes de suivi intersites des utilisateurs, tels que le stockage dissimulé dans le navigateur, le fingerprinting des appareils et les demandes d'informations personnelles telles que les adresses e-mail, ont été de plus en plus utilisés.

C'est un dilemme pour le Web. Comment soutenir les cas d'utilisation légitimes de tiers sans activer le suivi des utilisateurs d'un site à l'autre ?

Par exemple, comment les sites Web peuvent-ils financer le contenu en permettant à des tiers de diffuser des annonces et de mesurer leurs performances, sans pour autant permettre le profilage des utilisateurs individuels ? Comment les annonceurs et les propriétaires de sites peuvent-ils évaluer l'authenticité d'un utilisateur sans avoir recours à des schémas sombres, comme le fingerprinting de l'appareil ?

Le fonctionnement actuel peut être problématique pour l'ensemble de l'écosystème Web, et pas seulement pour les utilisateurs. Pour les éditeurs et les annonceurs, le suivi des identités et l'utilisation de diverses solutions tierces non standards peuvent augmenter la dette technique, la complexité du code et les risques liés aux données. Les utilisateurs, développeurs, éditeurs et annonceurs doivent avoir l'assurance que le Web protège les paramètres de confidentialité des utilisateurs.

La publicité est l'un des principaux modèles économiques du Web pour Internet, mais elle doit fonctionner pour tout le monde. Ce qui nous amène à la mission de la Privacy Sandbox: créer un écosystème Web florissant, respectueux des utilisateurs et respectueux de la confidentialité par défaut.

Présentation de la Privacy Sandbox

La Privacy Sandbox propose un ensemble d'API protégeant la confidentialité pour soutenir les modèles économiques qui financeront le Web ouvert en l'absence de mécanismes de suivi tels que les cookies tiers.

Les API Privacy Sandbox nécessitent que les navigateurs Web assument un nouveau rôle. Plutôt que d'utiliser des outils et des protections limités, les API permettent au navigateur de l'utilisateur d'agir en son nom (localement, sur son appareil) pour protéger ses informations d'identification lorsqu'il navigue sur le Web. Les API permettent des cas d'utilisation tels que la sélection des annonces et la mesure des conversions, sans révéler d'informations personnelles et privées individuelles. En termes d'ingénierie, un sandbox est un environnement protégé. L'un des principes fondamentaux de la Privacy Sandbox est que les informations personnelles d'un utilisateur doivent être protégées et ne pas être partagées de manière à permettre l'identification de l'utilisateur sur les sites.

C'est un changement de direction pour les navigateurs. La Privacy Sandbox envisage l'avenir en proposant des navigateurs offrant des outils spécifiques pour répondre à des cas d'utilisation spécifiques, tout en préservant la confidentialité des utilisateurs. Un modèle de confidentialité potentiel pour le Web définit les principes fondamentaux des API:

  • Définir l'éventail d'activités Web à travers lequel le navigateur d'un utilisateur peut permettre aux sites Web de considérer une personne comme ayant une identité unique.
  • Identifier les moyens par lesquels les informations peuvent circuler au-delà des limites de l'identité sans compromettre cette séparation.

Les propositions de la Privacy Sandbox

Pour abandonner l'utilisation des cookies tiers, l'initiative Privacy Sandbox a besoin de votre aide. Les explications des propositions ont besoin des commentaires des développeurs, des éditeurs, des annonceurs et des entreprises de technologie publicitaire pour suggérer les cas d'utilisation manquants et partager des informations sur la manière d'atteindre leurs objectifs tout en respectant la confidentialité.

Vous pouvez commenter les explications des propositions en signalant les problèmes liés à chaque référentiel:

  • Modèle de confidentialité pour le Web
    Définissez l'éventail d'activités sur le Web au sein duquel le navigateur d'un utilisateur peut permettre aux sites Web de considérer une personne comme ayant une seule identité. Identifiez les moyens par lesquels les informations peuvent circuler au-delà des limites de l'identité sans compromettre cette séparation.
  • Budget lié à la confidentialité
    Limitez la quantité totale de données potentiellement identifiables auxquelles les sites peuvent accéder. Mise à jour des API pour réduire la quantité de données potentiellement identifiables révélées. Rendez mesurable l'accès à des données potentiellement identifiables.
  • Gnatcatcher
    Limitez la capacité à identifier des utilisateurs individuels en accédant à leur adresse IP.
  • API Trust Token
    Activez une origine qui fait confiance à un utilisateur pour lui fournir des jetons cryptographiques stockés par le navigateur de l'utilisateur afin qu'ils puissent être utilisés dans d'autres contextes pour évaluer l'authenticité de l'utilisateur.
  • Ensembles propriétaires
    Autorisez les noms de domaine associés appartenant à la même entité à se déclarer comme appartenant au même propriétaire.
  • Rapports agrégés
    Fournissez des mécanismes de protection de la confidentialité afin de prendre en charge divers cas d'utilisation tels que la mesure des conversions après affichage, de la marque, de l'impact et de la couverture.
  • Attribution Reporting
    Mesurez les clics et les vues tout en protégeant la confidentialité grâce à des rapports globaux et au niveau des événements.
  • API Topics
    Activez la publicité ciblée par centres d'intérêt sans avoir à suivre les sites consultés par un utilisateur. La conception de l'API a été basée sur les commentaires de la communauté lors de nos précédents essais FLoC et remplace la proposition FLoC.
  • FLEDGE
    Fournit une solution pour les cas d'utilisation du remarketing, conçue pour ne pas être utilisée par des tiers pour suivre le comportement de navigation des utilisateurs sur les sites.

Vous pouvez accéder immédiatement aux explications sur les propositions d'API. Au cours des prochains mois, nous publierons des articles sur chaque proposition individuellement.

Nous allons également compléter notre playlist de vidéos de cinq minutes avec une explication simple de chaque API.

Cas d'utilisation et objectifs

Mesurer les conversions

Objectif:permettre aux annonceurs de mesurer les performances des annonces.

L'API Attribution Reporting permet de mesurer deux événements qui sont associés : 1. Événement sur le site Web d'un éditeur (par exemple, lorsqu'un utilisateur voit une annonce ou clique dessus). 1. Une conversion ultérieure sur le site d'un annonceur

Cette API permet de mesurer les clics et les conversions après affichage.

Cette API comprend également d'autres fonctionnalités telles que les rapports sur l'attribution multi-appareil et sur l'attribution Application/Web.

L'API propose également deux types de rapports sur l'attribution:

  • Les rapports au niveau des événements associent une vue ou un clic sur une annonce spécifique (côté annonce) aux données concernant les conversions. Pour préserver la confidentialité des utilisateurs, en empêchant la jointure de l'identité de l'utilisateur entre les sites, les données côté conversion sont très limitées et elles sont "bruites" (ce qui signifie que pour un faible pourcentage de cas, des données aléatoires sont envoyées). Pour renforcer la protection de la confidentialité, les rapports ne sont pas envoyés immédiatement.

  • Les rapports globaux ne sont pas liés à un événement spécifique côté annonce. Ces rapports fournissent des données de conversion plus riches et plus précises que les rapports au niveau des événements. L'utilisation combinée de techniques de cryptographie, de distribution de la confiance et de confidentialité différentielle permet de réduire le risque de jonction d'identité entre les sites.

Les deux types de rapports peuvent être utilisés simultanément: ils sont complémentaires.

La page de présentation d'Attribution Reporting vous explique l'état de ces fonctionnalités et la façon d'essayer cette API.

Sélectionner les annonces

Objectif:permettre aux annonceurs de diffuser des annonces pertinentes pour les utilisateurs.

Les annonces pertinentes sont plus favorables aux internautes et plus rentables pour les éditeurs (ceux qui gèrent des sites Web financés par la publicité). Les outils tiers de sélection d'annonces augmentent la valeur des espaces publicitaires pour les annonceurs (les personnes qui en achètent sur les sites Web). Ils permettent ainsi d'augmenter les revenus générés par les sites Web financés par la publicité, tout en permettant la création et la publication de contenu.

Il existe de nombreuses façons de rendre des annonces pertinentes pour l'utilisateur, y compris les suivantes:

  • Données first party: diffusez des annonces en rapport avec les sujets qu'un utilisateur a déclarés à un site Web qui l'intéressent ou le contenu qu'il a précédemment consulté sur le site Web actuel.
  • Contextuel: choisissez où diffuser les annonces en fonction du contenu du site. Par exemple, "Place cette annonce à côté d'articles sur le tricot".
  • Remarketing: diffusez vos annonces auprès des personnes qui ont déjà visité votre site, alors qu'elles ne le sont pas. Par exemple, vous pouvez choisir "Diffuser cette annonce pour des laines à prix réduit auprès des personnes qui se sont rendues dans votre magasin et ont laissé des articles en tricot dans leur panier, lorsqu'ils visitent des sites d'artisanat".
  • Par centres d'intérêt: les annonces sont sélectionnées en fonction de l'historique de navigation de l'utilisateur. Par exemple, "Diffuser cette annonce auprès des internautes dont le comportement de navigation indique qu'ils pourraient être intéressés par le tricot".

Il est possible d'obtenir des données first party et de sélectionner des annonces contextuelles sans avoir d'autres informations sur l'utilisateur que son activité sur un site. Ces techniques ne nécessitent pas de suivi intersites.

Le remarketing utilise généralement des cookies ou une autre méthode permettant d'identifier les internautes sur les sites Web: il suffit d'ajouter des utilisateurs à des listes, puis de sélectionner les annonces spécifiques à leur présenter.

La sélection d'annonces par centres d'intérêt utilise actuellement des cookies pour suivre le comportement des internautes sur un maximum de sites. De nombreux utilisateurs s'inquiètent des conséquences du choix des annonces sur la confidentialité. La Privacy Sandbox propose deux alternatives, pour le remarketing et pour la sélection par centres d'intérêt:

  • FLEDGE: pour les cas d'utilisation de remarketing.
    L'API est conçue pour ne pas être utilisée par des tiers pour suivre le comportement de navigation de l'utilisateur: le navigateur de l'utilisateur, et non l'annonceur ou la plate-forme ad tech, stocke les groupes de centres d'intérêt définis par l'annonceur auxquels le navigateur est associé. Le navigateur de l'utilisateur combine les données d'un groupe de centres d'intérêt avec les données de l'acheteur/du vendeur d'annonces et la logique métier pour effectuer une "mise aux enchères" localement sur l'appareil de l'utilisateur afin de sélectionner une annonce, au lieu de partager les données avec un tiers.

  • API Topics: pour les audiences basées sur les centres d'intérêt.
    Activez la publicité ciblée par centres d'intérêt sans avoir à effectuer le suivi des sites consultés par un utilisateur. L'API propose d'utiliser le machine learning pour déduire les thèmes à partir des noms d'hôte, et une API JavaScript qui renvoie des thèmes précis susceptibles d'intéresser un utilisateur, en fonction des noms d'hôte des sites récemment visités.

Lutter contre le fingerprinting

Objectif:Réduire la quantité de données potentiellement identifiables révélées par les API, et permettre aux utilisateurs de contrôler l'accès à ces données et de les mesurer.

Les navigateurs ont pris des mesures pour abandonner les cookies tiers, mais les techniques permettant d'identifier et de suivre le comportement des utilisateurs individuels, connues sous le nom de fingerprinting, continuent d'évoluer. Le fingerprinting utilise des mécanismes que les utilisateurs ne connaissent pas et que les utilisateurs ne peuvent pas contrôler.

  • La proposition Privacy Budget vise à limiter le potentiel du fingerprinting en identifiant la quantité de données liées aux empreintes digitales exposées par les API JavaScript ou d'autres "surfaces" (telles que les en-têtes de requêtes HTTP) et en définissant une limite quant à la quantité de ces données accessible.

  • Le champ d'application des surfaces d'empreinte digitale, telles que l'en-tête User-Agent, sera réduit, et les données mises à disposition par d'autres mécanismes tels que les indications client seront soumises aux limites du budget lié à la confidentialité. D'autres surfaces, telles que les API d'orientation de l'appareil et de niveau de la batterie, seront mises à jour afin de limiter au maximum les informations.

Sécurité des adresses IP

Objectif:Contrôler l'accès aux adresses IP pour réduire le fingerprinting dissimulé, et permettre aux sites de désactiver l'affichage des adresses IP afin de ne pas consommer de budget dédié à la confidentialité.

L'adresse IP d'un utilisateur est l'"adresse" publique de son ordinateur sur Internet, qui, dans la plupart des cas, est attribuée de manière dynamique par le réseau par lequel il se connecte à Internet. Cependant, même les adresses IP dynamiques peuvent rester stables sur une période prolongée. Cela signifie sans surprise que les adresses IP constituent une source importante de données relatives aux empreintes digitales.

La proposition Gnatcatcher vise à fournir une approche protégeant la confidentialité qui évite de consommer le budget dédié à la confidentialité, tout en garantissant que les sites nécessitant un accès à des adresses IP à des fins légitimes (par exemple, pour prévenir les abus) peuvent le faire, sous réserve de certification et d'audit.

Cette proposition se compose de deux parties : * L'aveuglement volontaire des adresses IP permet aux sites Web d'informer les navigateurs qu'ils ne connectent pas les adresses IP aux utilisateurs. * La NAT en cas de proximité permet à des groupes d'utilisateurs d'envoyer leur trafic via le même serveur de privatisation, masquant ainsi leurs adresses IP à l'hôte d'un site.

Lutter contre le spam, la fraude et les attaques par déni de service

Objectif:Vérifier l'authenticité des utilisateurs sans utiliser le fingerprinting.

La protection contre la fraude est essentielle pour assurer la sécurité des utilisateurs, et pour permettre aux annonceurs et aux propriétaires de sites d'obtenir des mesures précises des performances des annonces. Les annonceurs et les propriétaires de sites doivent être en mesure de faire la distinction entre les robots malveillants et les utilisateurs authentiques. Si les annonceurs ne sont pas en mesure d'identifier de manière fiable les clics sur les annonces effectués par des utilisateurs réels, ils dépensent moins, ce qui signifie que les éditeurs de sites perçoivent moins de revenus. De nombreux services tiers ont actuellement recours à des techniques telles que le fingerprinting des appareils pour lutter contre la fraude.

Malheureusement, les techniques utilisées pour identifier les utilisateurs légitimes et bloquer les spammeurs, les fraudeurs et les robots fonctionnent de la même manière que les techniques de empreinte digitale qui portent atteinte à la confidentialité.

  • L'API Trust Tokens propose une approche alternative, qui permet de transmettre l'authenticité établie pour un utilisateur dans un contexte (par exemple, sur un site de réseau social) à un autre contexte, comme une annonce diffusée sur un site d'actualités, sans identifier l'utilisateur ni associer les deux identités.

Permettre à des domaines d'appartenir au même propriétaire

Objectif:permettre aux entités de déclarer que des noms de domaine associés appartiennent au même propriétaire.

De nombreuses organisations possèdent des sites dans plusieurs domaines. Cela peut poser problème si des restrictions sont imposées au suivi de l'identité des utilisateurs sur des sites considérés comme "tiers", mais appartenant en réalité à la même organisation.

  • Les ensembles propriétaires visent à harmoniser le concept Web de tiers et de propriétaires avec celui du monde réel en permettant à plusieurs domaines de se déclarer comme appartenant au même propriétaire.

En savoir plus

Explications sur les propositions de la Privacy Sandbox

L'initiative Privacy Sandbox a besoin de votre aide. Les explications des propositions d'API ont besoin de retours, en particulier pour suggérer les cas d'utilisation manquants et des moyens plus privés d'atteindre leurs objectifs.

Un modèle de confidentialité potentiel pour le Web définit les principes fondamentaux sur lesquels reposent les API.

Privacy Sandbox

Discussion et participation

Cas d'utilisation, règles et exigences


Annexe: Glossaire des termes utilisés dans les explications de la proposition

Taux de clics (CTR)

Nombre d'utilisateurs qui ont cliqué sur une annonce après l'avoir vue. Voir aussi impression.

Conversion après clic (CTC)

Conversion attribuée à une annonce sur laquelle l'utilisateur a cliqué.

Conversion

L'exécution d'une action sur le site Web d'un annonceur par un utilisateur ayant déjà interagi avec une annonce de cet annonceur. Il peut s'agir, par exemple, de l'achat d'un produit ou de l'inscription à une newsletter après avoir cliqué sur une annonce qui redirige vers le site de l'annonceur.

Confidentialité différentielle

Partagez des informations sur un ensemble de données pour mettre en évidence des modèles de comportement sans révéler d'informations privées sur les individus ni leur appartenance à l'ensemble de données.

Domaine

Voir Domaine de premier niveau et eTLD.

eTLD, eTLD+1

Les domaines de premier niveau "Effective" sont définis par la liste des suffixes publics. Exemple :

co.uk
appspot.com
glitch.me

Les domaines de premier niveau efficaces permettent à foo.appspot.com d'être un site différent de bar.appspot.com. Dans ce cas, le domaine de premier niveau effectif (eTLD) est appspot.com, et le nom complet du site (foo.appspot.com, bar.appspot.com) est connu sous le nom de eTLD+1.

Consultez également Domaine de premier niveau.

Entropie

Mesure de la mesure dans laquelle un élément de données révèle l'identité individuelle.

L'entropie des données se mesure en bits. Plus les données révèlent l'identité, plus leur valeur d'entropie est élevée.

Les données peuvent être combinées pour identifier un individu, mais il peut être difficile de déterminer si les nouvelles données ajoutent à l'entropie. Par exemple, savoir qu'une personne est originaire d'Australie ne réduit pas l'entropie si vous savez déjà qu'elle est originaire de l'île Kangourou.

Empreinte digitale

Techniques permettant d'identifier et de suivre le comportement de chaque utilisateur. Le fingerprinting utilise des mécanismes que les utilisateurs ne connaissent pas et que les utilisateurs ne peuvent pas contrôler. Des sites tels que Panopticlick et amiunique.org montrent comment combiner les données relatives à vos empreintes digitales pour vous identifier en tant qu'individu.

Surface d'empreinte

Élément pouvant être utilisé (probablement en association avec d'autres surfaces) pour identifier un utilisateur ou un appareil spécifique. Par exemple, la méthode JavaScript navigator.userAgent() et l'en-tête de requête HTTP User-Agent permettent d'accéder à une surface de fingerprinting (la chaîne user-agent).

Audience propriétaire

Ressources du site que vous consultez. Par exemple, la page que vous lisez se trouve sur le site web.dev et inclut des ressources de ce site. Consultez également l'article Tierce.

Impression

Vue d'une annonce. Consultez également l'article Taux de clics.

k-anonymat

Mesure de l'anonymat dans un ensemble de données. Avec la propriété k anonymat, vous ne pouvez pas vous distinguer des autres individus de l'ensemble de données k-1. En d'autres termes, k personnes ont les mêmes informations (vous y compris).

Nonce

Numéro arbitraire utilisé une seule fois dans la communication cryptographique.

Origine

Origine d'une requête, y compris le nom du serveur, mais pas les informations sur le chemin d'accès. Exemple : https://web.dev.

Surface passive

Certaines surfaces de fingerprinting, telles que les chaînes user-agent, les adresses IP et les en-têtes dans une langue acceptée, sont disponibles sur chaque site Web, que le site les demande ou non. Cela signifie que les surfaces passives peuvent facilement consommer le budget consacré à la confidentialité d'un site.

L'initiative Privacy Sandbox propose de remplacer les surfaces passives par des moyens actifs d'obtenir des informations spécifiques, par exemple en utilisant des indicateurs client une seule fois pour obtenir la langue de l'utilisateur au lieu d'avoir un en-tête "accepte-language" pour chaque réponse à chaque serveur.

Diffuseur

Les explications de la proposition Privacy Sandbox concernent principalement les annonces. Les types d'éditeurs mentionnés sont donc ceux qui diffusent des annonces sur leurs sites Web.

Couverture

Nombre total de personnes qui voient une annonce.

Remarketing

En ciblant les internautes qui ont déjà visité votre site Par exemple, une boutique en ligne peut diffuser des annonces pour une vente de jouets auprès des personnes qui ont déjà consulté des jouets sur son site.

Site

Voir Domaine de premier niveau et eTLD.

Surface

Consultez Surface de fingerprinting et Surface passive.

Tiers

Ressources diffusées à partir d'un domaine différent du site Web que vous consultez. Par exemple, le site Web foo.com peut utiliser du code d'analyse de google-analytics.com (via JavaScript), des polices use.typekit.net (via un élément link) et une vidéo de vimeo.com (dans un iFrame). Consultez également l'article Propriétaires.

Domaine de premier niveau

Les domaines de premier niveau tels que .com et .org sont répertoriés dans la base de données de la zone racine.

Notez que certains "sites" ne sont en fait que des sous-domaines. Par exemple, translation.google.com et maps.google.com ne sont que des sous-domaines de google.com (l'eTLD + 1).

.well-known

Il peut être utile d'accéder à une stratégie d'accès ou à d'autres informations sur un hôte avant d'envoyer une demande. Par exemple, il indique aux robots d'exploration les pages à consulter et celles à ignorer. Le document RFC8615 de l'IETF offre une méthode standardisée pour rendre les métadonnées de l'ensemble du site accessibles à des emplacements standards, dans un sous-répertoire /.well-known/. Vous pouvez consulter la liste de ces régions à l'adresse suivante : iana.org/assignments/well-known-uris/well-known-uris.xhtml.


Merci à tous ceux qui nous ont aidés à rédiger et à commenter ce message.

Photo de Pierre Bamin sur Unsplash.