Plus tôt cette année, Google a confirmé ce que beaucoup pensaient inévitable lorsqu’il a confirmé qu’il introduirait ses concepts Privacy Sandbox dans le système d’exploitation mobile Android – une décision qui, en quelque sorte, singe les limitations de données sur iOS d’Apple.

Sans surprise, tous les niveaux de l’industrie qui ont ressenti la brûlure d’iOS 14 d’Apple – une décision qui aurait effacé un total de 16 milliards de dollars de revenus provenant de Meta, Twitter et YouTube en moins de 12 mois – craignent que les plans de Google n’aient un impact similaire.

Cependant, la dépendance de Google à l’égard des revenus publicitaires, sans parler des difficultés réglementaires auxquelles il est confronté, signifie qu’il doit emprunter une voie plus délicate avec son Les propositions de bac à sable de confidentialité pour Chrome font souvent l’objet d’un examen par les pairs meurtri au fur et à mesure qu’ils avancent.

Les piliers de Privacy Sandbox sur Android

Les plans naissants pour Privacy Sandbox sur Android ont été déployés pour la première fois en février 2022 avec beaucoup d’aplomb, mais peu de détails, et depuis lors, ceux qui gèrent le système de confidentialité du système d’exploitation mobile ont mieux étoffé leurs propositions, selon des sources familières avec leurs conversations.

À l’heure actuelle, Privacy Sandbox sur Android contient un certain nombre de points de discussion qui reflètent en grande partie les propositions de ciblage et de suivi de l’audience dans Google Chrome après le retrait des cookies tiers. Il s’agit notamment de recommandations pour le ciblage continu basé sur les intérêts connu sous le nom d’API Topics, une proposition de reciblage des utilisateurs d’appareils Android baptisée FLEDGE, ainsi qu’un moyen proposé de mesurer les performances des campagnes avec des signaux de données limités appelé Attribution Reporting.

Les propositions privacy Sandbox de Google dans Chrome ont été ont reçu des commentaires mitigés, sa première proposition FLoC est maintenant KO’d, le résultat de ces discussions continues étant loin d’être certain.

Propositions de code de tiers de police

Cependant, les délégués au Sommet sur la croissance des applications de cette semaine à New York se sont enthousiasmés sur les premières propositions visant à contrôler le code tiers sur les applications soumises aux points de vente d’applications Android, surnommés Exécution du SDK, certains spéculant qu’Apple pourrait chercher à l’imiter.

Actuellement, la politique de Google permet effectivement aux développeurs de SDK tiers, tels que les sociétés de mesure intégrées à l’application, de partager les mêmes autorisations que leurs éditeurs d’applications Android. Une telle politique permet aux développeurs de services tiers de mieux intégrer leurs SDK avec le code de l’application Android de leur client. À partir de là, le développeur hôte soumet l’application empaquetée pour distribution via un magasin d’applications.

Cependant, cela ouvre également la porte à de mauvais acteurs pour infecter l’écosystème plus large, car cela crée le potentiel de collecte de données utilisateur non divulguées par des fournisseurs de SDK tiers à l’insu d’un éditeur hôte. En effet, les éditeurs s’appuient souvent sur l’auto-déclaration de leurs fournisseurs de SDK, car ils ne disposent pas toujours des ressources nécessaires pour vérifier régulièrement les données collectées par leurs partenaires.

« Dans Android 13, nous prévoyons d’ajouter une nouvelle fonctionnalité de plate-forme qui permet aux SDK tiers de s’exécuter dans un environnement d’exécution dédié appelé SDK Runtime », selon documentation de Google. Il détaille ensuite comment la version initiale de SDK Runtime se concentrera sur la prise en charge des SDK liés à la publicité, y compris la diffusion d’annonces, la mesure, ainsi que la détection des fraudes et des abus.

Un porte-parole de Google a informé Digiday que le nouvel ensemble de technologies est facultatif pour les développeurs de SDK à mesure que les propositions de Privacy Sandbox progressent.

Supprimer les maux de tête des éditeurs ?

Au cours de la semaine Sommet sur la croissance des applications, le conférencier principal Mike Brooks, vice-président des revenus chez WeatherBug, a décrit la proposition comme établissant un référentiel de SDK conformes à la confidentialité » qui assume efficacement la responsabilité de la gestion du SDK comme potentiellement « révolutionnaire ».

Il a ajouté: « Donc, c’est essentiellement un [proposed] bibliothèque où chaque partenaire soumet son SDK et Google le passe au peigne fin et doit l’approuver, donc il n’y a pas de mauvais code dedans … alors tout ce que l’éditeur a à faire est d’appuyer sur un commutateur et le SDK est intégré.

Les intégrations SDK sont dedix tâches compliquées pour les éditeurs d’applications avec le processus de vérification du code tiers retardant souvent les mises à jour d’applications indispensables. « Vous constatez souvent qu’il y a un retard de deux à trois mois en raison de la file d’attente des intégrations SDK, puis vous constatez qu’il y a tellement d’affaires que vous n’avez pas été en mesure de faire », a déclaré Brooks à Digiday.

Trevor Hamilton, directeur général, Amériques, Kochava, a décrit les propositions de Privacy Sandbox comme une proposition à grande échelle conviviale pour les développeurs, ajoutant qu’il est essentiel que les éditeurs comprennent les capacités de surveillance de leurs partenaires avant d’être commercialisées, car les utilisateurs ne filtrent pas souvent les termes et conditions auxquels ils consentent.

« Il y a un petit pourcentage de personnes qui creusent vraiment dans les détails et les comprennent vraiment », a-t-il déclaré aux participants à la conférence. « Tout comme avec les politiques de cookies, je pense que les gens vont simplement atteindre ce ‘X’ aussi vite que possible pour continuer leurs expériences de contenu de la manière la plus fluide possible. »

Apple va-t-il imiter ?

Parler séparément Lors du Sommet mondial sur la protection de la vie privée de l’IAPP de cette semaine, le PDG d’Apple, Tim Cook, a préconisé un contrôle centralisé des partenaires des développeurs d’applications, affirmant que des contrôles moins stricts signifiaient « que les entreprises avides de données seraient en mesure d’éviter nos règles de confidentialité » et de suivre les utilisateurs d’iPhone contre leur volonté.

Brooks de WeatherBug, ainsi que plusieurs autres participants à la conférence qui ont demandé l’anonymat en raison des politiques de relations publiques de leurs employeurs, pensent qu’Apple pourrait potentiellement reproduire l’approche de Google, d’autant plus que la quantité de données que les développeurs d’applications collectent auprès des utilisateurs de téléphones est examinée à la loupe.

Bien que Kevin Susman, vice-président de la marque et des communications chez Logiciel MATRIXX, a déclaré qu’il est difficile de comparer la façon dont Apple et Google traitent la vie privée. Il a observé qu’il semble que Google essaie d’appliquer une stratégie de confidentialité décentralisée par opposition à l’approche du jardin clos d’Apple.

« Apple gagne de l’argent avec les développeurs, maintenant, il fait aussi d’énormes publicités en monétisant la vie privée », a-t-il ajouté dans un communiqué envoyé par courrier électronique. « Cela va au cœur de la question: Apple suivra-t-il l’approche de confidentialité de Google pour les développeurs? [sic] qui se retirent de l’écosystème d’Apple et poursuivent le chargement latéral ou un magasin d’applications alternatif? Je ne pense pas, du moins pas avant un moment car Apple a un jardin clos dans son ADN… Ce que je pense qu’ils vont faire, c’est essentiellement isoler les développeurs tiers [sic] qui se retirent de l’App Store d’Apple au nom de la sécurité.

https://digiday.com/?p=444961