Mise à jour sur l'avancement de la Privacy Sandbox pour Android

Depuis l'annonce initiale en février 2022, nous avons reçu des commentaires de partenaires de l'écosystème Android. Nous vous remercions de vos retours et vous invitons à continuer à partager vos commentaires et questions.

Vous trouverez dans ce bilan sur l'avancement un résumé des nouveaux développements et des mises à jour des propositions de conception, les principales questions et commentaires que nous avons reçus, ainsi que les mises à jour sur les versions Preview développeur.

Nouveautés

Sortie de la version Preview développeur 7

Cette dernière version est une version majeure qui constitue la base des prochaines versions de la version bêta de la Privacy Sandbox. Elle inclut des fonctionnalités supplémentaires sur la prise en charge de la médiation en cascade de l'API Protected Audience, sur les redirections d'enregistrement d'événements Attribution Reporting et sur d'autres modifications de l'API.

Nous continuerons de mettre à jour les ressources de la version Preview développeur à mesure que de nouvelles fonctionnalités seront disponibles dans les mois à venir. Nous vous encourageons à envoyer vos commentaires ou questions, et à vous inscrire pour recevoir des informations sur cette initiative.

Sortie de la version bêta en mars 2023

Cette version représente la mise à disposition des API Privacy Sandbox sur les appareils publics. Du point de vue fonctionnel, elle équivaut à la version 6 du preview développeur. Les développeurs peuvent accéder aux API dans les versions bêta via le SDK Extension.

Informations sur le calendrier pour les versions Preview développeur

Toutes les dates et les détails sont susceptibles de changer

Chaque version bêta et version Preview développeur s'accompagne de notes de version détaillées et de guides décrivant les fonctionnalités disponibles et celles qui ne le sont pas pour une version spécifique.

Disponible maintenant :

  • Preview développeur 7 : inclut une fonctionnalité qui vous permet de concevoir l'intégration à l'aide d'API pertinentes comprenant le SDK Runtime et les API Topics, Protected Audience et les Attribution Reporting.
  • Programme bêta disponible pour effectuer des tests en production limités. La version bêta de mars 2023 représente la mise à disposition des API Privacy Sandbox sur les appareils publics. Du point de vue fonctionnel, elle équivaut à la version 6 du preview développeur.

Début 2023 :

  • Première version stable des API protégeant la confidentialité sur un faible pourcentage d'appareils Android 13.

Tout au long de 2023 :

  • Autres itérations des versions Preview développeur et des versions stables de l'API avec des fonctionnalités supplémentaires. Élargissement de l'accès à d'autres utilisateurs et appareils Android.

Rappel : Lorsque nous avons annoncé la Privacy Sandbox sur Android en février, nous avions insisté sur le fait que pendant la conception, la création et le test de ces solutions, nous prévoyions de prendre en charge les fonctionnalités existantes des plates-formes publicitaires pendant au moins deux ans et de vous informer suffisamment à l'avance de toute modification future.

Avancement des propositions de conception

Cette section décrit plusieurs modifications spécifiques apportées aux propositions de conception.

API Reflection

Dans notre proposition de conception du SDK Runtime d'origine, nous avions demandé des commentaires sur notre proposition d'empêcher l'accès à des API de réflexion et d'appel afin d'aider les développeurs de SDK à empêcher toute modification provenant d'autres SDK.

Nous avons reçu des commentaires utiles sur les cas d'utilisation concernés. Après une enquête plus approfondie sur l'utilité et les risques associés, nous allons autoriser l'utilisation d'API de réflexion et d'appel dans le SDK Runtime, et nous avons mis à jour notre conception en conséquence.

Toutefois, un SDK ne sera pas autorisé à utiliser les API de réflexion et d'appel sur un autre SDK pour lequel Runtime est activé. Pour la communication SDK vers SDK dans le SDK Runtime, nous concevons des API distinctes pour la découverte de SDK, qui seront détaillées dans une prochaine mise à jour ultérieure.

Nous cherchons en permanence à réduire le risque de falsification d'autres SDK. C'est pourquoi nous proposons toujours d'empêcher l'utilisation du code JNI dans le SDK Runtime, et nous envisageons sérieusement d'utiliser d'autres API. Nous partagerons une proposition complète d'API interdites dans une prochaine mise à jour.

API Attribution Reporting

  • Suite aux commentaires que nous avons reçus, nous avons ajouté un exemple qui montre comment les événements de vue, de clic et de conversion peuvent être enregistrés par plusieurs parties concernées. Nous avons ajouté de nouvelles considérations et questions ouvertes sur lesquelles nous souhaitons recueillir des commentaires.

API Topics

  • L'API Topics renvoie une liste comportant jusqu'à trois thèmes, un pour chacune des trois epochs précédentes (par exemple, au cours des trois dernières semaines). Nous avons mis à jour la proposition technique de l'API Topics pour préciser que les thèmes renvoyés représentent les centres d'intérêt de l'utilisateur, et que tout ou partie des thèmes renvoyés peuvent être utilisés pour personnaliser les annonces.

Récapitulatif des questions et des commentaires reçus

Cette section inclut certaines des questions et des commentaires que nous avons reçus, ainsi que nos réponses.

Questions générales

La Privacy Sandbox sur Android s'appliquera-t-elle aux appareils pour la télévision connectée ?
Nos propositions de conception actuelles visent à faciliter les cas d'utilisation des appareils mobiles et des applications. Nous prévoyons de partager plus d'informations sur d'autres facteurs de forme Android à l'avenir.
Comment la Privacy Sandbox sera-t-elle déployée sur les appareils en version bêta sur Android ?
Pour proposer des mises à jour plus librement aux utilisateurs, les composants clés seront distribués sous forme de modules principaux sur les appareils mobiles Android compatibles. Cela nous permettra d'apporter facilement des améliorations en continu aux appareils compatibles en dehors du cycle de publication normal de la plate-forme Android.
Que prévoyez-vous pour la prise en charge de Kotlin ?
Nous travaillons à itérer la conception de l'API Privacy Sandbox et nous souhaitons permettre aux développeurs d'écrire du code Kotlin idiomatique. Des ressources associées pour les développeurs, telles que des applications exemples dans le Preview développeur, sont disponibles en langage Kotlin (et Java).
Quels sont les contrôles au niveau de l'utilisateur pour la Privacy Sandbox et quels sont les délais prévus pour le déploiement de ces contrôles ?

Les versions finales sont toujours en cours de développement, mais pendant la phase bêta, nous prévoyons de fournir des commandes utilisateur dans les paramètres de l'appareil aux fins suivantes :

  1. Quitter ou réintégrer les solutions de la Privacy Sandbox
  2. Supprimer les thèmes déduits spécifiques de l'API Topics
Les écosystèmes de plates-formes de téléchargement d'applications autres que Google Play peuvent-ils utiliser la solution Privacy Sandbox ?

Toutes les solutions Privacy Sandbox font partie du projet Android Open Source (AOSP). Elles peuvent donc être adoptées par d'autres plates-formes de téléchargement d'applications. Contactez les plates-formes de téléchargement d'applications avec lesquelles vous travaillez pour mieux comprendre leurs plans.

SDK Runtime

Comment les versions des SDK seront-elles gérées dans le cadre de ces propositions ? Les applications pourront-elles contrôler les dépendances des versions du SDK si les fournisseurs peuvent les mettre à jour indépendamment ?

Ce processus est en cours de conception. Une approche envisagée est que les développeurs de SDK spécifient la version major.minor.patch du SDK qu'ils choisissent de distribuer via une plate-forme de téléchargement d'applications compatible avec le SDK Runtime.

Les développeurs d'applications peuvent ensuite choisir la version major.minor dont ils ont besoin en le déclarant dans le fichier manifeste de leur application. La dernière version du correctif pour cette version major.minor sera installée jusqu'à ce que le prochain correctif soit publié (qui sera installé automatiquement), ou jusqu'à ce que le développeur de l'application recompile l'application en spécifiant une autre dépendance de version major.minor.

À quels types de SDK l'environnement d'exécution est-il destiné ?

La version initiale du SDK Runtime est conçue pour prendre en charge des cas d'utilisation de SDK liés à la publicité, y compris les SDK permettant la diffusion d'annonces, la mesure des annonces, la fraude publicitaire et la détection des abus.

Bien que l'objectif premier soit destiné aux SDK publicitaires, les développeurs de SDK non publicitaires qui cherchent à protéger la confidentialité et qui pensent pouvoir fonctionner dans les conditions décrites ci-dessus peuvent partager des commentaires sur leur SDK s'exécutant dans le SDK Runtime

Nous utilisons actuellement des autorisations autres que celles spécifiées dans la proposition pour nos cas d'utilisation. Pouvons-nous demander d'autres autorisations ?

Nous voulons comprendre les cas d'utilisation liés à la publicité qui nécessitent des autorisations d'accès spécifiques en plus de ceux de notre proposition de conception initiale. Vous êtes invité à envoyer vos commentaires sur les fonctionnalités impactées.

Le déplacement des SDK dans le SDK Runtime permet-il de réduire la taille du téléchargement ou d'économiser de l'espace ?

Si plusieurs applications sont intégrées à des SDK de même version compatibles avec l'environnement d'exécution, cela permet de réduire la taille de téléchargement et l'espace disque.

L'autorisation du SDK d'accéder à l'AAID, ou identifiant publicitaire Android (AD_ID), dépend-elle des autorisations de l'application ?

La capacité du SDK RE à accéder à l'AAID dépend à la fois de l'application et du SDK qui déclarent l'autorisation dans le fichier manifeste de leur application. Dans une prochaine mise à jour des propositions, nous détaillerons l'API que les SDK pourront utiliser pour obtenir l'AAID s'ils disposent de l'autorisation.

Adresses IP, versions d'OS et autres données : seront-elles disponibles pour les SDK publicitaires ?

Nous travaillons actuellement sur les propriétés système auxquelles les SDK publicitaires auront accès. Nos avancées seront partagées dans une future mise à jour des propositions de conception. Nous n'avons publié aucune règle concernant l'utilisation de ces propriétés.

L'ID du groupe d'applications collecté par notre SDK est-il identique dans de nombreuses applications, même lorsque celles-ci appartiennent à des comptes de développeur Google Play différents ? Comment bloquer des utilisateurs frauduleux dans plusieurs applications sans l'AAID ?

Une application ou l'un de ses SDK peut n'avoir accès qu'à la valeur ID du groupe d'applications associée au compte de développeur Google Play de l'application hôte. Privacy Sandbox sur Android n'offrira pas d'identifiant multiéditeur afin d'éviter les fraudes. Pour l'instant, les développeurs peuvent envisager d'utiliser l'adresse IP comme alternative.

Rubriques

Pourrais-je afficher la liste de tous les thèmes que l'API peut renvoyer ?
À des fins de test, Preview développeur 1 utilise des thèmes de cette taxonomie, qui est susceptible de changer. Nous prévoyons de faire évoluer ceci au fil du temps en fonction des commentaires de l'écosystème.
Si la classification des thèmes est susceptible d'être modifiée, comment pouvons-nous en tenir compte dans les modèles côté achat en aval ?
La réponse de l'API Topics inclura un numéro de version pour le classificateur et la taxonomie.

Protected Audience sur Android

Le ciblage par exclusion sera-t-il compatible avec l'API Protected Audience ?

La proposition de conception actuelle ne prend pas en charge le ciblage par exclusion basé sur une audience personnalisée dans l'API Protected Audience.

Pour les campagnes d'installation d'applications, nous allons proposer une fonctionnalité de filtrage des annonces qui permettra aux fournisseurs de technologies publicitaires de filtrer les applications déjà installées. Nous cherchons une solution pour prendre en charge les besoins de filtrage négatif des campagnes basés sur la limitation de la fréquence d'exposition. Nous vous fournirons plus de détails dans les prochaines mises à jour de la proposition de conception.

Les réseaux publicitaires des vendeurs permettent-ils de créer des audiences personnalisées ? Ou sont-elles limitées aux réseaux publicitaires des acheteurs ?

Notre proposition actuelle pour les audiences personnalisées se concentre sur le cas d'utilisation côté acheteur, car elles sont destinées à créer des enchères côté acheteur pour le cas d'utilisation du remarketing respectueux de la confidentialité.

Attribution Reporting

Les API Privacy Sandbox fonctionneront-elles ensemble pour prendre en charge les cas d'utilisation entre le Web et les applications et inversement ?
Nous parcourons les cas d'utilisation dans lesquels une application de navigateur mobile appelle l'API Attribution Reporting d'Android pour activer l'attribution dans l'application et sur le Web sur le même appareil. Si vous choisissez d'activer le Web vers l'application, la Privacy Sandbox pour les API Android sera utilisée pour le stockage et l'attribution. Elle supprimera l'attribution entre l'application et le Web (mais vous pourriez recevoir des rapports distincts de l'API pour l'application et pour le Web, qui devront être combinés).
L'API est-elle compatible avec d'autres modèles d'attribution que celui au dernier clic ?
L'API est compatible avec un modèle d'attribution au dernier contact avec priorité à la source. De plus, la proposition accepte une logique d'attribution facultative pour les conversions post-installation à attribuer au clic ou à la vue à l'origine de l'installation.
La Privacy Sandbox aura-t-elle un impact sur le Play Install Referrer ?

Sur la base de la conception et des plans actuels, les API Privacy Sandbox n'auront pas d'incidence sur les fonctionnalités fournies par le Play Install Referrer.

Certains développeurs ont identifié des formats d'annonces grâce auxquels les utilisateurs peuvent être "récompensés" pour avoir réalisé des événements post-clic spécifiques. Sans attribution au niveau de l'utilisateur, cela constituerait un défi pour les propositions actuelles.

Il s'agit d'une zone en cours d'examen pour déterminer les solutions possibles. Nous vous invitons à nous envoyer encore plus de commentaires pour ce cas d'utilisation et tous ceux susceptibles d'exister.

Pourquoi l'attribution est-elle indépendante pour chaque plate-forme de technologie publicitaire ?

Aujourd'hui, de nombreux annonceurs pensent qu'il est important d'obtenir une vue dédupliquée de leurs événements de conversion sur les différents réseaux. Il est donc courant de faire appel à un partenaire de mesure sur mobile (Mobile Measurement Partner, MMP). Les nouvelles API permettront toujours d'obtenir une vue dédupliquée, et faciliteront la mesure directe des performances pour les plates-formes technologiques et les annonceurs qui souhaiteraient le faire.

L'utilisation des redirections signifie que vous n'avez pas besoin d'une présence physique d'un SDK dans chaque application, mais d'une relation avec les SDK de technologie publicitaire pour être impliqué dans le processus de redirection.

L'un des principaux avantages de cette approche est que chaque utilisateur peut disposer de ses propres métadonnées et clés d'agrégation pour sa logique métier personnelle, et définir sa propre priorité.

Y a-t-il une validation ou une vérification des installations à partir du Play Store ?

Les installations validées ne sont utilisées que pour la logique d'attribution facultative des conversions post-installation. Ces installations validées ne seront pas envoyées par l'API. L'API n'enverra que les rapports sur les conversions enregistrées et ne renverra aucun signal indiquant si l'utilisateur a déjà installé l'application auparavant.

Effectuez-vous une validation par clic ou par vue ? Y a-t-il une durée minimale pour la validation par vue ?

La proposition d'API actuelle prend en charge la validation de base des clics via InputEvent. Nous étudions des formes plus robustes de validation par clics et par vues. Nous vous invitons à nous faire part de commentaires supplémentaires pour ces cas d'utilisation, en particulier ceux portant sur les types de définitions de vues qui pourraient être utiles à l'écosystème.