Privacy sandbox sur Android : qu'est-ce que c'est et quoi faire avec

AdGuard suit attentivement les nouvelles de la tech qui concernent la confidentialité des données.Google a récemment introduit le Privacy Sandbox qui déterminera en grande partie l'avenir de la vie privée des utilisateurs d'Android. Et nous devons certainement faire commentaire à ce sujet. Cet article est un bref aperçu de la situation, fait par Andrey Meshkov, directeur technique et cofondateur d'AdGuard. Nous continuerons à explorer le sujet ci-dessous, et un grand article de recherche sera bientôt publié. Suivez notre blog et nos médias sociaux afin de ne pas manquer sa publication.

Google a annoncé nouvelle gamme de technologies nommée Privacy Sandbox qui devrait (du moins en théorie) rendre les appareils Android plus performants en termes de confidentialité. Mais dans le même temps, Google indique clairement qu'il souhaite que les annonceurs conservent le plus d'options possibles, ce qui constitue un équilibre difficile à trouver. Y sont-ils parvenus ?

Privacy Sandbox comprend plusieurs technologies séparées. Vous pouvez creuser la matière vous-même, mais je vais essayer de décrire ici les points clés de chacune des nouvelles initiatives.

SDK Runtime

Il s'agit d'une technologie extrêmement utile qui aura certainement un effet positif. Ce SDK — qui signifie Software Development Kit — crée un environnement dédié dans lequel les SDK de tiers peuvent fonctionner.

Comment c'était avant

C'était autrefois une sorte de terre sans loi. Les développeurs inséraient des bibliothèques tierces dans leurs applications (pensez à Facebook, Google), et ces bibliothèques héritaient de toutes les autorisations accordées à l'application elle-même. Par exemple, disons que l'application a accès à la localisation de l'appareil — la bibliothèque l'a aussi maintenant. Inutile de dire que les fournisseurs des bibliothèques ont abusé de ce système à gauche et à droite, en collectant toutes sortes de données. Et ce n'était pas le seul problème : si un problème survenait avec la bibliothèque, l'application risquait également en subir les conséquences. ([1], [2] ).

Ce schéma montre que le code qui appelle le SDK, ainsi que les SDK qui reçoivent les appels de ce code, sont tous intégrés dans le processus de l'application.

Ce que propose Google

Avec l'introduction du SDK Runtime, les bibliothèques tierces fonctionneront dans un "bac à sable" virtuel distinct, contrôlé et réglementé de manière approfondie, d'où son nom. Le développeur pourra gérer les droits d'accès de chacune de ces bibliothèques, y compris les restreindre.

Ce schéma montre que dans les processus d'avant-plan de l'application, le code d'appel du SDK communique avec les interfaces du SDK. Ces interfaces traversent ensuite une frontière de processus et entrent dans le processus d'exécution du SDK pour appeler les SDK eux-mêmes.

Étant donné que toutes ces bibliothèques seront exécutées dans un " sandbox " détaché du reste des processus de l'application, cette dernière ne plantera pas si l'une d'entre elles présente un problème.

Enfin, ces bibliothèques seront distribuées par l'intermédiaire d'un magasin spécial qui disposera (probablement) de ses propres directives de révision.

Lisez plus sur SDK Runtime :
https://developer.android.com/design-for-safety/ads/sdk-runtime

Topics

Il s'agit de la même technologie que celle que Google va introduire dans Chrome. L'idée principale de Topics est que l'appareil lui-même surveille les applications utilisées par son propriétaire. Sur la base de ces données, l'appareil calculera chaque semaine cinq sujets qui présenteront le plus d'intérêt pour l'utilisateur au cours de la semaine.

Les applications pourront avoir accès à certaines de ces données, et les différentes applications recevront des données différentes. Selon Google, cela permettra de minimiser le risque d'utiliser les sujets pour prendre les empreintes digitales des utilisateurs.

Mais illustrons-le par un exemple :

  1. Vous avez plusieurs applications installées sur votre téléphone que vous utilisez régulièrement: Facebook, WhatsApp, Instagram, etc.
  2. Chacune d'entre eux reçoit une partie de vos sujets de la semaine.
  3. Les applications collectent ces informations et les utilisent pour compléter votre profil en ligne.
  4. Semaine après semaine, votre profil grandit et s'enrichit de données.

Je ne comprends pas pourquoi Google a décidé que c'était normal de partager mes intérêts sans mon consentement. Ne vous méprenez pas, les grands éditeurs comme Facebook/Meta ne se contenteront pas d'utiliser ces informations une fois pour toutes. Ils les regrouperont, les combineront avec d'autres données, etc.

Et ce n'est pas tout. De nombreuses applications utilisent des SDK développés par un petit groupe d'entreprises (vous l'avez deviné, Meta est l'une d'entre elles). Ces entreprises recevront des flux d'informations vous concernant provenant de dizaines d'applications différentes. À partir de là, il ne faut pas grand-chose pour construire un profil atrocement détaillé contenant toutes les données imaginables sur vous.

Lisez plus sur Topics pour Android :
https://developer.android.com/design-for-safety/ads/topics

FLEDGE sur Android

FLEDGE est un mécanisme destiné à être utilisé localement sur votre appareil. Vous verrez bientôt que, du point de vue de la sécurité des données, il se distingue avantageusement des autres solutions existantes.

Comment c'était avant

Currently, ad retargeting is mostly based on the lists of "audiences" that publishers upload. They are often made up of user IDs, or sometimes even straight up emails. This allows publishers to reach these users with ads that they consider relevant to the people from that list.

Ce que propose Google

Lorsque FLEDGE entrera pleinement en vigueur, les applications créeront elles-mêmes ces listes à l'aide d'une API (interface de programmation d'applications) spéciale. La principale différence est que ces listes seront stockées localement sur l'appareil. Les réseaux publicitaires connaîtront les noms de ces listes et téléchargeront des publicités ciblant des listes spécifiques. Le processus de sélection de la publicité à afficher à l'utilisateur se fera entièrement dans l'appareil, sur la base des listes (stockées sur le même appareil) et des publicités téléchargées par les réseaux publicitaires.

Lisez plus sur FLEDGE :
https://developer.android.com/design-for-safety/ads/fledge

Les Rapports d'attribution

Il s'agit d'une technologie permettant de compter les clics et de mesurer les conversions. Les annonceurs veulent connaître les performances de leurs publicités, et Google propose de réaliser toutes les mesures directement sur l'appareil. Les SDK des réseaux publicitaires pourront demander un rapport agrégé, qui sera toutefois présenté avec un certain retard. Ce délai est très important car il complique grandement les éventuelles tentatives d'identification de l'utilisateur. Et l'ensemble du mécanisme est généreusement saupoudré de cryptage et de vérifications supplémentaires.

La conception générale du fonctionnement de l'API de rapport d'attribution semble assez compliquée. Pour mieux comprendre le sujet, ouvrez le lien ci-dessous.

Lisez plus sur les Rapports d'attribution :
https://developer.android.com/design-for-safety/ads/attribution

Conclusions

En général, toutes ces initiatives (à l'exception de Topics) peuvent être considérées comme améliorant la protection de la confidentialité des utilisateurs dans le contexte du marché publicitaire. Mais avec une condition très importante — ces mécanismes sont les SEULS à être utilisés çà ces fins.

Quant à Topics, il reflète le désir (tout à fait compréhensible) de conserver la possibilité d'utiliser les informations sur les intérêts des utilisateurs à des fins de ciblage. Mais cette technologie élargit encore la portée de ces informations au lieu de la réduire.

Mais même les bonnes nouvelles laissent un arrière-goût amer : de facto, Google deviendra la seule entité à contrôler les publicités que les utilisateurs voient sur leurs appareils Android. C'était partiellement le cas auparavant, mais uniquement au sein du propre réseau publicitaire de Google. Maintenant, ils cherchent à influencer directement tous les autres réseaux publicitaires aussi, et nous savons que les monopoles sont rarement bons pour le consommateur. Nous savons plus ou moins ce qui va se passer sur nos smartphones maintenant, et il n'y a aucune garantie que cela reste ainsi.

C'est la tendance que nous observons depuis un certain temps déjà : les réseaux publicitaires s'installent lentement mais sûrement sur nos appareils. Vous envisagez d'acheter un nouveau téléphone ? Préparez-vous à mettre la main sur un outil hautement spécialisé dans la diffusion de publicités.

En téléchargeant les commentaires, vous conformez aux termes et politiques
L'Europe contre les géants de la tech, les assistants vocaux trompent encore les utilisateurs : le condensé d'AdGuard
Google Analytics est interdit dans les pays européens, Siri a été surprise en train d'écouter aux portes et promet d'arrêter, et il existe un moyen d'empêcher le suivi de votre téléphone par les fonds d'écran. Voici les nouvelles dans notre condensé.
Le DNS personnel AdGuard devient public : bienvenue à la Bêta ouverte à tous
La bêta ouverte du DNS privé AdGuard est disponible dès maintenant ! Prenez part au test bêta et profitez de tous les avantages de notre service : voyez toutes les requêtes DNS, bloquez seulement ce dont vous avez besoin, ajoutez vos propres règles !
Téléchargement de AdGuard To install AdGuard, click the file indicated by the arrow Sélectionnez « Ouvrir » et cliquez sur « OK », puis attendez que le fichier soit téléchargé. Dans la fenêtre ouverte, faites glisser l'icône AdGuard dans le dossier « Applications ». Merci d'avoir choisi AdGuard! Sélectionnez « Ouvrir » et cliquez sur « OK », puis attendez que le fichier soit téléchargé. Dans la fenêtre ouverte, cliquez sur « Installer ». Merci d'avoir choisi AdGuard!
Installer AdGuard sur votre appareil mobile