Privacy Sandbox est disponible dans Android Preview développeur. Découvrez comment faire vos premiers pas et continuez à envoyer des commentaires.

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

Stay organized with collections Save and categorize content based on your preferences.

Depuis l'annonce initiale en février, 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éveloppeurs.

Dernière mise à jour : 9 septembre 2022

Nouveautés

Sortie du Preview développeur 5

Cette dernière version est une version majeure qui deviendra la base des prochaines versions de la version bêta de Privacy Sandbox. Cette version apporte des fonctionnalités supplémentaires, des améliorations liées à la validation des données et des évolutions de la signature d'e lAPI dans FLEDGE sur Android, Topics et Reporting Attribution. et le SDK Runtime.

Nous continuerons de mettre à jour les ressources du 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.

Informations sur le calendrier pour les versions Preview développeur

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

Chaque Preview développeur s'accompagne de notes de version détaillées et de guides décrivant les fonctionnalités disponibles et non disponibles pour chaque version.

Disponible maintenant :

  • Preview développeur 5 : inclut une fonctionnalité qui vous permet de concevoir l'intégration à l'aide d'API pertinentes comprenant le SDK Runtime, Topics, FLEDGE et les API Attribution Reporting.

À partir de septembre 2022 :

  • Mises à jour régulières des Previews développeurs pour toutes les API et le SDK Runtime.

D'ici fin 2022 :

  • Version bêta 1 de la Privacy Sandbox sur Android sur les appareils mobiles grand public.

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 plutôt 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'améliorer facilement les appareils compatibles de façon continue, en dehors du cycle de publication normal de la plate-forme Android.
Quel est votre plan quant à la prise en charge de Kotlin ?
Nous travaillons à itérer la conception de l'API Privacy Sandbox et nous entendons 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 pour lesquels Runtime est activé et de la même version, 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 n'importe lequel 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 à des fins de fraude. Pour l'instant, les développeurs peuvent envisager d'utiliser l'adresse IP comme une alternative légèrement moins cohérente.

Thèmes

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.

FLEDGE sur Android

Le ciblage par exclusion sera-t-il compatible avec FLEDGE ?

La proposition de conception actuelle ne prend pas en charge le ciblage par exclusion basé sur une audience personnalisée dans FLEDGE.

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 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. C'est pourquoi il est courant de faire appel à un partenaire de mesure de mesures sur mobile (Mobile Measurement Partner, MMP, en anglais). 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 des vues ?

La proposition d'API actuelle prend en charge la validation de base des clics via InputEvent. Nous étudions des formes plus robustes de validation des clics et des 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.