Google détaille la proposition de conception du SDK Runtime pour Android Privacy Sandbox

Récemment, nous avons vu Apple et Google s'efforcer de créer un écosystème plus soucieux de la confidentialité en matière de publicités. Avec Apple, c'était avec l'introduction d'un bouton pour empêcher les applications de vous suivre, et avec Google, c'est devenu le Initiative Android Privacy Sandbox. Même si les informations étaient rares lors de son annonce, davantage de détails ont été révélés concernant le « SDK Runtime » qui englobe une partie de la solution de Google en matière de publicité et de confidentialité.

Android Privacy Sandbox est composé de deux composants principaux: le SDK Runtime et les API de préservation de la confidentialité - qui seront distribués en tant que composants système modulaires, dont vous vous souviendrez peut-être comme Ligne principale du projet. Google a depuis publié une documentation pour les développeurs concernant le SDK Runtime et la manière dont il améliorera encore la confidentialité des utilisateurs. La société affirme que le SDK Runtime permettra aux SDK tiers de s'exécuter dans un environnement d'exécution dédié dans

Android 13, loin du code d'une application.

Sous Android, chaque application s'exécute dans un bac à sable avec ses propres autorisations et un accès variable au système en fonction de l'accès accordé. Comme le dit Google, "si l'application A tente de faire quelque chose de malveillant, comme lire les données de l'application B ou composer un numéro de téléphone sans autorisation, elle ne peut pas le faire car elle n'a pas l'autorisation privilèges utilisateur par défaut appropriés. " Le SDK Runtime étend davantage ce bac à sable pour exécuter des SDK tiers dans un environnement d'exécution dédié, loin de tout environnement d'exécution particulier. application.

Pourquoi le SDK Runtime existe

Google souhaite empêcher les SDK des annonceurs de collecter des données auxquelles il ne devrait pas avoir accès de manière malveillante (ou même par inadvertance) suite au partage du bac à sable de l'application hôte. Lorsqu'un SDK publicitaire est exécuté dans une application, il a également accès à tout ce que fait l'application, et un développeur d'application peut ne pas être complètement conscient du niveau d'accès réel. En supprimant ce code d'annonceur et en l'exécutant dans son propre environnement d'exécution, il ne peut alors accéder qu'aux données que le développeur partage explicitement avec lui.

En conséquence, Google affirme que le SDK Runtime offre les protections et garanties renforcées suivantes concernant la collecte et le partage des données utilisateur :

• Un environnement d'exécution modifié
• Autorisations et droits d'accès aux données bien définis pour les SDK

La première version du SDK Runtime se concentre uniquement sur les SDK liés à la publicité, y compris les SDK qui permettent la diffusion d'annonces, la mesure des annonces, la fraude publicitaire et la détection des abus.

Comment fonctionne le runtime du SDK

Actuellement, sans le runtime du SDK, un processus d'application appellera un SDK et ce SDK s'exécutera dans le même bac à sable que le reste du code de l'application. Google souhaite que les développeurs disposent plutôt d'une interface pour un SDK qui fonctionne au premier plan d'une application, et cette interface peut ensuite se connecter et partager des données spécifiques avec le SDK en cours d'exécution. utilisé.

Avant

Après

Le diagramme « avant » (premier) montre que le code appelant le SDK, ainsi que les SDK qui reçoivent les appels de ce code, résident tous dans le processus de l'application. Cela signifie que le SDK peut accéder à toutes les données accessibles par l'application. Le diagramme « après » (deuxième) montre que, dans le processus de premier plan de l’application, le code appelant du SDK communique avec les interfaces du SDK. Ces interfaces traversent ensuite une frontière de processus dans le processus SDK Runtime pour appeler les SDK eux-mêmes. Cela signifie que le SDK utilisé ne peut pas simplement accéder à ce qu'il veut, il ne peut recevoir que les informations de l'application avec laquelle il s'exécute.

Nouveau modèle de distribution fiable pour les SDK

Actuellement, lorsque vous téléchargez une application avec des SDK tiers, ceux-ci sont inclus par le développeur dans l'application téléchargée et distribuée sur le Google Play Store. Google souhaite plutôt que lorsque vous installez sur votre téléphone une application qui utilise ces SDK, ceux-ci soient téléchargés. séparément depuis l'application elle-même. Cela signifie que les développeurs de SDK peuvent apporter des modifications ininterrompues (c'est-à-dire qu'aucune modification n'est apportée aux API ou aux API). leur sémantique) à leurs SDK et les distribuer aux appareils sans aucune implication de l'application développeurs.

À leur tour, les modifications ininterrompues du SDK pourraient être déployées ou annulées, sans nécessairement avoir besoin d'attendre. pour les développeurs d'applications de reconstruire leurs applications avec les nouveaux SDK, ou d'attendre que les utilisateurs finaux mettent à jour leurs applications. Les modifications majeures qui modifient les API et leur sémantique devraient toujours être mises à jour par les développeurs d'applications, mais les développeurs de SDK pourraient obtenir leur dernière version ininterrompue. modifie et corrige plus rapidement et plus uniformément pour un plus grand nombre de personnes à la fois, sans compter sur un développeur d'application pour mettre à jour son application et son package dans la nouvelle version. SDK.

Avant

Après

Le diagramme « avant » montre exactement comment les applications sont désormais distribuées avec les SDK. Ils sont regroupés dans une application et l'application est ce qui est soumis au Google Play Store. Dans le diagramme « après », les développeurs de SDK ne placeraient plus leurs SDK directement dans les applications; au lieu de cela, les développeurs du SDK téléchargeraient un SDK et le publieraient sur le Google Play Store. Le Google Play Store gérerait ensuite la distribution des applications, ainsi que toutes les dépendances du SDK, sur les appareils des utilisateurs finaux. Google utilise également intentionnellement l'expression « App Store » dans ses diagrammes, car il s'agit d'une solution ouverte et générale qui peut fonctionner sur d'autres magasins.

Modifications apportées à la façon dont les SDK et les applications sont créés, exécutés et distribués

La proposition initiale pour le SDK Runtime propose une série de changements dans cinq domaines clés :

• Accéder
• Exécution
• Communications
• Développement
• Distribution

Google souhaite définir l'ensemble d'autorisations suivant pour le SDK Runtime :

• INTERNET: Accès à internet pour pouvoir communiquer avec un service web.
• ACCESS_NETWORK_STATE: accéder aux informations sur les réseaux.
• Autorisations d'accéder au API préservant la confidentialité, qui fournissent des fonctionnalités publicitaires de base sans avoir besoin d'accéder à des identifiants multi-applications. Les noms des autorisations n'ont pas été finalisés, mais ces API seraient limitées par l'accès de l'application à ces autorisations.
• AD_ID: Possibilité de demander l'identifiant publicitaire. Cela serait également limité par l'accès de l'application à cette autorisation.
• BIND_GET_INSTALL_REFERRER_SERVICE: Possibilité d'utiliser le API de référence d'installation de Google Play pour attribuer la source de l'installation d'une application.

La société souhaite également limiter l'accès des SDK à la mémoire d'une application en cours d'exécution, mais également empêcher une application d'accéder aux propres données d'un SDK. Une application ne pourrait pas accéder directement au stockage de ses SDK, et vice versa, le stockage externe ne le serait pas. ouvert aux SDK, et il y aurait à la fois un stockage accessible à tous les SDK et un stockage privé pour un SDK.

Quant à la façon dont les SDK fonctionneront, ils fonctionneront avec une priorité légèrement inférieure à celle de l'application elle-même. C'est-à-dire qu'il est très probable qu'une application soit fermée peu de temps après la fin d'un runtime du SDK si la situation se présentait et qu'elle devait être fermée par le système. Dans le cas où il n'est pas terminé en même temps, ou dans le cas où il y a une autre raison, la proposition propose des méthodes de rappel du cycle de vie associées aux développeurs d'applications pour leur permettre de gérer cette exception et de réinitialiser le SDK Durée. Les SDK d'exécution ne pourront à aucun moment utiliser les API de notifications pour envoyer des notifications aux utilisateurs.

Enfin, Google note qu'il s'agit d'une proposition générale qui n'est pas propre à une boutique d'applications en particulier. Bien qu'il soit vraisemblablement intégré au Google Play Store, il n'y a aucune raison pour que d'autres magasins d'applications ne puissent pas intégrer une structure similaire. Google affirme que les avantages suivants sont clairs :

• Assurer la qualité et la cohérence des SDK.
• Rationalisez la publication pour les développeurs de SDK.
• Accélérez le déploiement des mises à jour des versions mineures du SDK sur les applications installées.

Le bac à sable de confidentialité Android semble prometteur

Le calendrier de publication de Google est que le premier trimestre 2022 implique les propositions de conception initiales, les commentaires et les itérations de conception. Les aperçus des développeurs arriveront plus tard dans l’année, avec une version bêta à la fin de l’année. Enfin, 2023 verra le début des tests à grande échelle. Ces aperçus et versions bêta seront indépendants de la cadence de sortie d’Android 13. Il y aura également des contrôles destinés à l'utilisateur dans l'application des paramètres, une fois déployée.

À mon avis, le bac à sable de confidentialité Android regards prometteur, mais nous devrons attendre de voir comment l'entreprise le mettra en œuvre. Il est tout à fait possible que les développeurs ne l'apprécient pas ou que cela cause plus de problèmes qu'il n'en résout. Les développeurs sont encouragés à lire la documentation publiée par Google pour avoir une meilleure idée de l'avenir de la confidentialité sur Android.

Il s'agit pour l'instant d'une proposition et non d'une vision définitive de ce que exactement cela se produira dans une future version d'Android, mais il est probable que cela se terminera assez près. Nous resterons attentifs à tout développement ultérieur !

---

Source: Documentation pour les développeurs Android