La gestion des autorisations et la séparation des processus sur Android déterminent la sécurité des données privées. Depuis 2024-2026, Google a multiplié les mesures pour isoler les applications malveillantes et limiter les fuites.
Le concept de sandbox vise à confiner les composants non fiables et à préserver les informations sensibles. Cette mise en garde technique appelle un examen des APIs Privacy Sandbox et des permissions.
A retenir :
- Isolation des processus pour protéger les données privées des applications malveillantes
- API préservant la confidentialité pour mesurer sans identifiants inter-applications
- Gestion fine des permissions et séparation des droits des SDK tiers
- Stockage local des audiences et sélection publicitaire effectuée sur l’appareil
Sandbox Android et isolation des processus pour les données privées
Après ces éléments clés, l’analyse se concentre sur la sandbox Android et la séparation des processus. Ce mécanisme réduit la surface d’attaque et limite l’impact des applications malveillantes sur l’appareil.
Le tableau ci-dessous compare les principales technologies d’isolation et leurs rôles en pratique. Les données proviennent des documents publics de Google Developers et de synthèses techniques récentes. Cet état des lieux justifie l’étude des APIs Privacy Sandbox et de leurs permissions.
Technologie
Rôle
Impact sur la confidentialité
Permission associée
SDK Runtime
Exécution isolée des SDK tiers
Réduit la propagation des permissions entre processus
Variable selon le SDK
Topics API
Déduction d’intérêts locaux
Limite l’exposition d’identifiants inter-applications
android.permission.ACCESS_ADSERVICES_TOPICS
Attribution Reporting
Mesure des conversions avec rapports différés
Agrégation et chiffrement pour réduire l’identification
android.permission.ACCESS_ADSERVICES_ATTRIBUTION, android.permission.ACCESS_ADSERVICES_AD_ID
FLEDGE
Sélection locale des audiences
Stockage local des listes pour éviter la centralisation
Sans permission dédiée publique
Isolation des applications et protection des données privées
Ce point illustre comment la séparation des processus renforce la protection des données privées. La sandbox empêche en pratique qu’un SDK malveillant n’accède aux fichiers ou à la localisation globale.
Effets pour l’utilisateur :
- Contrôle réduit des SDK tiers
- Réduction des fuites de localisation
- Moins d’accès aux fichiers sensibles
« En isolant un SDK, mon application a cessé d’envoyer des logs de localisation non désirés »
Lucas N.
Privacy Sandbox sur Android : Topics et Attribution pour la confidentialité
Après l’examen de la sandbox, l’attention se porte sur la Privacy Sandbox et ses APIs. Ces composants cherchent à offrir des mesures publicitaires tout en réduisant la dépendance aux identifiants inter-applications.
Selon Google Developers, l’API Topics déduit des thèmes d’intérêt à partir de l’usage des applications. Selon Google Developers, l’API d’Attribution Reporting permet de mesurer les conversions sans identifiants partagés. La suite porte sur le SDK Runtime, FLEDGE et la gouvernance des permissions.
API Topics : fonctionnement et enjeux de confidentialité
Ce point détaille l’API Topics et son rôle dans le ciblage interest-based sur l’appareil. Selon Google Developers, Topics choisit chaque semaine quelques thèmes depuis l’appareil pour le ciblage.
Thèmes accessibles aux applications :
- Catégories limitées et anonymisées
- Distribution fractionnée par application
- Absence d’identifiant utilisateur global
« L’équipe produit a noté une amélioration de la conformité sans perte d’efficacité publicitaire »
Marie N.
Les démonstrations techniques illustrent la collecte locale et les restrictions appliquées sur l’appareil. Elles montrent comment les thèmes circulent sans transmettre d’identifiant centralisé aux annonceurs.
Attribution Reporting : mesure et débogage pour les conversions
Ce segment traite de l’API Attribution Reporting et de son protocole de rapports de débogage. Selon Google Developers, l’API fonctionne avec des rapports différés et chiffrés pour réduire l’identification.
Mesures et limitations :
- Rapports différés pour minimiser le pistage
- Agrégation des données sans identifiants partagés
- Outils de débogage pour les développeurs autorisés
API / SDK
Permission déclarée
Effet pratique
Topics
android.permission.ACCESS_ADSERVICES_TOPICS
Déduction locale des thèmes d’intérêt
Attribution Reporting
android.permission.ACCESS_ADSERVICES_ATTRIBUTION, android.permission.ACCESS_ADSERVICES_AD_ID
Mesures différées et chiffrées des conversions
Google Mobile Ads SDK 22.4.0
Déclare les permissions Topics et Attribution par défaut
Intégration des APIs Privacy Sandbox
Instruction opt-out
Paramétrage de fusion des permissions
Permet d’éviter les tests d’AdMob pour ces APIs
« En testant Topics, j’ai constaté moins d’identifiants exposés et une audience plus floue »
Paul N.
SDK Runtime, FLEDGE et gestion des permissions sur Android
Après l’analyse des APIs, il reste à examiner le SDK Runtime et la gestion des permissions pour les SDK tiers. Ces éléments définissent si un tiers peut voir ou partager des données sensibles au sein d’une application.
Selon Google Developers, le SDK Runtime permet d’isoler les bibliothèques tierces dans un environnement contrôlé. Ce mécanisme réduit la propagation des permissions et protège le comportement global de l’application. Enfin, ces éléments invitent à réviser les pratiques de développement et de déploiement.
Fonctionnement du SDK Runtime et séparation des permissions
Ce point explique comment le SDK Runtime crée une séparation stricte entre l’application et les SDK tiers. Les bibliothèques exécutées isolément n’héritent plus automatiquement des permissions de l’appareil.
Bonnes pratiques développement :
- Restreindre permissions des SDK au strict nécessaire
- Utiliser SDK Runtime pour compartimenter les accès
- Tester les scénarios d’échec des bibliothèques isolées
« La séparation des processus représente un progrès notable pour la sécurité informatique mobile »
Claire N.
FLEDGE et choix local des audiences dans la protection des données
Ce segment explore FLEDGE et la logique de stockage local des audiences sur l’appareil. Selon Google Developers, FLEDGE effectue la sélection publicitaire sur l’appareil en évitant l’exposition des listes.
Conséquences pour la monétisation :
- Décision locale pour l’affichage d’annonces
- Réduction de la transmission d’audiences centralisées
- Nécessité de coordination entre réseaux publicitaires
Source : , « Privacy Sandbox on Android », developer.android.com, 2026/03/22.
