Comment les SDK tiers des applications Android divulguent votre position aux annonceurs
Une récente enquête de l'Electronic Frontier Foundation (EFF), relayée par TechCrunch, révèle que de nombreuses applications Android partagent involontairement les données de localisation des utilisateurs avec des annonceurs, non pas parce que les développeurs de l'application ont volontairement intégré un traçage, mais parce que des kits de développement logiciel (SDK) tiers intégrés dans l'application collectent et transmettent des données de localisation pour leurs propres besoins une fois que l'utilisateur a accordé à l'application l'autorisation de localisation. Comprendre ce mécanisme suppose de comprendre comment les applications modernes sont réellement construites, car très peu sont entièrement composées du code d'une seule équipe.
Un kit de développement logiciel est un ensemble de code prêt à l'emploi qu'un développeur mobile intègre dans son application pour ajouter une fonctionnalité précise sans devoir l'écrire lui-même — l'analytique, le signalement de plantages, la publicité intégrée et les notifications push sont les catégories les plus courantes. Comme intégrer un SDK revient généralement à ajouter quelques lignes de code et à lui accorder les autorisations déjà détenues par l'application hôte, un développeur qui intègre un SDK publicitaire pour générer des revenus ne vérifie pas toujours précisément ce que ce SDK fait de l'autorisation de localisation que l'application demande pour sa propre fonctionnalité principale.
Le modèle d'autorisation d'Android demande à l'utilisateur d'approuver l'accès à la localisation au niveau de l'application, pas au niveau de chaque élément de code s'exécutant à l'intérieur de celle-ci. Une fois que l'utilisateur appuie sur « autoriser » pour une application météo ou un tracker de fitness, chaque SDK intégré dans cette application hérite du même accès à la localisation que celui accordé à l'application dans son ensemble, sans invite distincte précisant qu'un réseau publicitaire ou un fournisseur d'analytique spécifique recevra également ces données.
La recherche de l'EFF met en garde spécifiquement les développeurs d'applications, pas seulement les utilisateurs : une partie du code tiers qu'ils intègrent peut collecter et transmettre des données de localisation qu'ils n'avaient jamais l'intention de partager, et dans certains cas n'avaient jamais explicitement accepté de partager, car les conditions d'utilisation du SDK sont enfouies dans une documentation technique que la plupart des équipes ne lisent pas ligne par ligne avant d'intégrer une bibliothèque promettant des revenus publicitaires faciles ou une analytique gratuite.
Pour les annonceurs et les courtiers en données, cet arrangement est précieux précisément parce qu'il agrège des signaux de localisation à travers des milliers d'applications sans lien entre elles. Un seul SDK publicitaire intégré dans une application de shopping, un jeu et un lecteur d'actualités peut construire une image bien plus riche des déplacements d'un téléphone que ne le suggérerait la simple autorisation de localisation d'une application isolée, puisque la personne a accordé son autorisation à une application, pas au fournisseur du SDK opérant silencieusement à travers toutes ces applications.
Google a durci au fil des années la politique du Play Store, exigeant que les applications déclarent leurs pratiques de collecte de données dans une étiquette normalisée « Sécurité des données », et restreignant l'accès à la localisation en arrière-plan derrière une invite d'autorisation distincte et plus visible que l'accès en premier plan. Ces changements ont rendu la collecte globale et invisible au niveau des SDK plus difficile qu'autrefois, mais ils dépendent toujours largement de la déclaration exacte, par les développeurs, de ce que fait réellement chaque SDK intégré — ce que les conclusions de l'EFF suggèrent ne pas toujours se produire.
La pression réglementaire a poussé dans la même direction. Le RGPD européen et diverses lois étatiques américaines sur la vie privée traitent de plus en plus les données de localisation détaillées comme des informations sensibles nécessitant un consentement clair et des limites de conservation définies, et les régulateurs ont sanctionné des entreprises spécifiquement pour des données de localisation collectées via des SDK intégrés plutôt que via les fonctionnalités propriétaires de l'application, exposant ainsi les fournisseurs de SDK au même risque juridique que les applications qui les intègrent.
Pour les utilisateurs préoccupés par cette question, le contrôle le plus direct reste les paramètres d'autorisation du système lui-même : vérifier quelles applications disposent d'un accès « toujours » ou « uniquement lors de l'utilisation », basculer les applications non essentielles sur « demander chaque fois » ou refuser purement la localisation, et auditer périodiquement quelles applications demandent la localisation par rapport à ce que l'application est réellement censée faire, puisqu'une application de prise de notes ou un simple jeu a rarement une raison légitime de connaître la position précise d'un téléphone.
Pour les développeurs d'applications, le message de l'EFF revient à un appel à la diligence raisonnable plutôt qu'à un blâme : lire la documentation réelle sur le traitement des données d'un SDK avant de l'intégrer, utiliser des outils d'analyse du trafic réseau pour vérifier quelles données le SDK envoie et où, et déclarer les flux de données tiers intégrés aux utilisateurs avec la même transparence que leurs propres données, puisque les politiques des magasins d'applications et les régulateurs tiennent de plus en plus les développeurs responsables de ce que fait leur code intégré, qu'ils l'aient écrit eux-mêmes ou non.
Le schéma plus large que met en évidence la recherche de l'EFF est un décalage entre la façon dont le système d'autorisation des applications est conçu — une autorisation par application — et la façon dont les applications modernes sont réellement construites, comme un assemblage de code propriétaire et de composants tiers ayant leurs propres incitations commerciales à collecter des données. Combler cet écart nécessitera probablement à la fois de meilleurs outils de transparence au niveau de la plateforme et la poursuite de recherches externes tenant à la fois développeurs et fournisseurs de SDK responsables de ce qui se passe après qu'un utilisateur a appuyé sur « autoriser ».
À lire ensuite
Pourquoi le Texas suspend-il les nouveaux raccordements des data centers au réseau ?
Selon Ars Technica, le Texas a suspendu les nouveaux raccordements à grande échelle de data centers à son réseau électrique géré par ERCOT, après qu'une vague de demandes de raccordement liées à l'IA a menacé de dépasser la capacité du réseau. Cette décision est notable car le gouverneur de l'État a passé les deux dernières années à présenter le Texas comme un « épicentre » de l'infrastructure IA. Des files d'attente de raccordement tout aussi tendues sont aussi apparues en Virginie et dans la région de PJM Interconnection, à mesure que les data centers d'IA deviennent plus gourmands en électricité.
SpaceX double ses revenus grâce aux contrats de calcul IA avec Anthropic et Google
Le chiffre d'affaires de SpaceX a à peu près doublé en glissement annuel lors de son premier rapport de résultats trimestriels en tant qu'entreprise cotée, porté par de nouveaux contrats de calcul IA avec Anthropic et Google ainsi que par la croissance continue de Starlink. L'activité de calcul a triplé pour atteindre environ 2,6 milliards de dollars, mais la division IA a tout de même affiché une perte trimestrielle de 1,5 milliard de dollars. Ces résultats placent SpaceX en concurrence directe avec des fournisseurs « neocloud » dédiés comme CoreWeave sur le marché de l'infrastructure IA.
Fuite IP et DNS de WebKit : comment elle expose les utilisateurs d'iCloud Private Relay
Un nouveau rapport du blog de recherche en sécurité Mysk décrit une fuite d'IP et de DNS au sein de WebKit, le moteur de navigateur qu'Apple impose à tout navigateur iOS, capable de révéler la localisation réelle d'un utilisateur même en utilisant un navigateur proxy ou le Relais privé iCloud. Comme les navigateurs iOS ne peuvent pas remplacer la pile réseau de WebKit, la faille est difficile à contourner pour les applications tierces et nécessite en pratique un correctif d'Apple. Les chercheurs en sécurité recommandent de considérer tout outil de confidentialité isolé comme une seule couche de défense, non comme une garantie complète.
Zigbee contre Matter sur Thread : quel protocole domotique est le plus performant ?
Zigbee et Matter sur Thread sont les deux protocoles principaux qui rivalisent pour faire fonctionner les réseaux domotiques, et une nouvelle comparaison publiée sur arXiv teste lequel des deux performe réellement mieux en pratique. L'étude montre que Zigbee garde un avantage en latence brute et en autonomie des piles dans les déploiements maillés denses, tandis que Matter sur Thread sacrifie une partie de son efficacité pour l'interopérabilité entre marques. Le protocole gagnant dépend de si un foyer démarre de zéro ou a déjà investi dans un écosystème.
10 avancées majeures en mathématiques et en informatique théorique, expliquées simplement
D'un théorème vieux de 350 ans enfin démontré à un algorithme quantique qui menace le chiffrement moderne, voici dix résultats qui ont transformé les mathématiques et l'informatique théorique, et pourquoi chacun a compté au-delà des spécialistes qui les ont d'abord compris.