Sideloading Android : sécurité contre liberté

Google vient de rendre nettement plus difficile l'installation d'applications en dehors du Play Store. Leur nouveau processus impose un délai d'attente de 24 heures pour les applications installées en sideloading qui n'ont pas été vérifiées par Google Play Protect, pendant lequel l'APK est envoyé sur les serveurs de Google pour analyse. Vous installez une appli depuis une source tierce ? Il faudra attendre une journée entière avant de pouvoir l'utiliser. La justification sécuritaire est simple : les APK infectés par des logiciels malveillants sont un vrai problème, surtout dans les régions où le sideloading est courant. La réaction des développeurs et des utilisateurs avancés a été... nettement moins enthousiaste.

Ce dernier changement se situe au cœur d'une tension qui définit Android depuis sa création : comment donner aux utilisateurs la liberté d'installer ce qu'ils veulent tout en protégeant ceux qui ne savent pas ce qu'ils font ? Android itère sur cette question depuis 18 ans, et la réponse ne cesse de changer.

Brève histoire de l'installation d'applications sur Android

Les premiers Android ressemblaient à un far west. N'importe quelle application pouvait être installée depuis n'importe quelle source d'un simple toucher. L'interrupteur « Sources inconnues » dans les paramètres était un commutateur global : l'activer permettait à toutes les applications de l'appareil d'installer des APK. C'était simple, responsabilisant pour l'utilisateur, et un vrai cauchemar pour la sécurité.

Android 8 (Oreo, 2017) a introduit les permissions par source. Au lieu d'un interrupteur global, chaque application devait demander individuellement la permission « Installer des applis inconnues ». Votre navigateur pouvait avoir le droit d'installer des APK alors que votre client mail ne l'avait pas. C'était une vraie amélioration, qui limitait le rayon d'action d'une application compromise.

Android 13 a ajouté les paramètres restreints. Les applications installées en sideloading ne pouvaient plus accéder à certaines API sensibles (services d'accessibilité, écouteurs de notifications) sans que l'utilisateur passe par des boîtes de dialogue de confirmation supplémentaires. La logique : les applis venant de l'extérieur du Play Store n'ont pas été vérifiées, elles ne devraient donc pas avoir un accès facile aux permissions les plus puissantes.

Désormais, la période de vérification de 24 heures ajoute une couche de friction supplémentaire. Chaque itération rend le sideloading plus difficile, et chacune est justifiée par de vraies données de sécurité. La question est de savoir si la friction cumulée a franchi la ligne qui sépare « protéger les utilisateurs » de « les contraindre à passer par le Play Store ».

Pourquoi le sideloading est un vrai problème de sécurité

Avant de balayer les inquiétudes de Google d'un revers de main : les logiciels malveillants diffusés par sideloading sont un problème réel et à grande échelle. Les propres données de Google montrent que les applications installées hors du Play Store ont 50 fois plus de chances de contenir un logiciel malveillant que celles du Play Store. Sur des marchés comme l'Asie du Sud-Est, où les boutiques d'applications tierces sont populaires, les taux d'infection sont nettement plus élevés que dans les pays où le Play Store domine.

Le vecteur d'attaque est redoutablement efficace. Un utilisateur reçoit un message (WhatsApp, SMS, e-mail) contenant un lien pour télécharger une « mise à jour de sécurité bancaire », un « nettoyeur de téléphone » ou une « appli premium gratuite ». Il télécharge l'APK, ignore les avertissements de sécurité (parce qu'on l'a habitué à ignorer les avertissements) et l'installe. Le logiciel malveillant obtient l'accès aux services d'accessibilité (là encore, en convainquant l'utilisateur de les accorder) et se met à voler les identifiants bancaires, intercepter les codes de vérification par SMS ou chiffrer l'appareil pour exiger une rançon.

Ce ne sont pas des attaques sophistiquées. Elles fonctionnent parce que l'ingénierie sociale est efficace et que la plupart des utilisateurs ne comprennent pas le modèle de risque lié à l'installation de code arbitraire. La position de Google : la friction, qui rend le sideloading plus lent et plus compliqué, est la défense la plus efficace, car elle laisse à l'utilisateur le temps de réfléchir et à Google celui d'analyser l'APK.

Pourquoi les développeurs sont frustrés

La grogne des développeurs ne porte pas sur les logiciels malveillants. Elle porte sur le contrôle, la distribution et la friction croissante qui consiste à faire parvenir des applications aux utilisateurs en dehors de l'écosystème de Google.

Tests et développement. Les développeurs installent en sideloading en permanence pendant le développement. Attendre 24 heures pour chaque build de test est absurde. Google contourne le problème en exemptant les applis installées via ADB (Android Debug Bridge), mais tous les workflows de test n'utilisent pas ADB : les équipes QA, les bêta-testeurs et les démos clients passent souvent par des installations directes d'APK.
Distribution en entreprise. Les entreprises qui distribuent des applications internes hors du Play Store (gérées via des solutions MDM) subissent une friction supplémentaire. Si les MDM peuvent contourner certaines restrictions, les petites organisations sans infrastructure MDM sont, elles, touchées de plein fouet.
Boutiques d'applications alternatives. F-Droid, Amazon Appstore, Samsung Galaxy Store : ces canaux de distribution légitimes sont tous considérés comme du sideloading du point de vue de Google. Chaque restriction supplémentaire dégrade leur expérience utilisateur par rapport au Play Store, ce que les critiques reprochent précisément à Google de vouloir.
Conformité réglementaire. Le Digital Markets Act de l'UE impose aux contrôleurs d'accès (dont Google) de permettre le sideloading sans friction excessive. Rendre le sideloading nettement pire tout en le laissant techniquement possible relève exactement de la mise en scène de conformité que le DMA cherchait à empêcher.

Les problèmes plus profonds du modèle de permissions

Les restrictions sur le sideloading ne sont qu'un pansement sur un problème plus profond : le modèle de permissions d'Android demande aux utilisateurs de prendre des décisions de sécurité pour lesquelles ils ne sont pas équipés. « Autoriser cette application à accéder à vos contacts ? » « Autoriser cette application à lire vos SMS ? » « Autoriser cette application à utiliser les services d'accessibilité ? » La plupart des utilisateurs ne mesurent pas les implications et acceptent tout ou refusent tout.

Le problème central : les permissions sont présentées comme des choix binaires sur des capacités, alors que les utilisateurs raisonnent en termes de finalités. Un utilisateur ne veut pas décider si une application peut lire les SMS. Il veut décider si l'application peut vérifier son numéro de téléphone (raisonnable) ou intercepter les codes à deux facteurs de sa banque (pas raisonnable). Les deux nécessitent exactement la même permission.

<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->

iOS a « résolu » le problème en n'autorisant tout simplement pas le sideloading (jusqu'à ce que la pression réglementaire impose des alternatives limitées). C'est une approche légitime, qui retire la décision aux utilisateurs, mais elle a ses propres coûts : enfermement des développeurs, rente de l'App Store et impossibilité d'exécuter des logiciels qu'Apple n'a pas approuvés.

À quoi pourrait ressembler un meilleur système

Ni l'approche « pas de sideloading » d'iOS, ni le « sideloading avec friction croissante » d'Android ne sont idéales. Un meilleur système devrait traiter plusieurs aspects simultanément.

Friction proportionnelle au risque. Une application qui ne demande aucune permission dangereuse et qui est signée par un développeur connu devrait s'installer instantanément. Une application qui demande les services d'accessibilité, l'accès aux SMS et les droits d'administrateur de l'appareil devrait subir un contrôle plus poussé. Le système actuel applique la même friction à une calculatrice open source inoffensive et à une application gourmande qui demande tout.
Permissions liées à une finalité. Au lieu d'accorder largement « lire les SMS », on accorderait « lire les SMS pour le remplissage automatique des codes de vérification », une permission restreinte qui ne peut être utilisée que dans des contextes d'API précis. Android a amorcé ce mouvement avec la SMS Retriever API, mais la plupart des permissions restent largement définies.
Analyse transparente sans attente. Le principe d'envoi puis d'analyse est raisonnable. Un délai de 24 heures ne l'est pas, d'autant que la plupart des analyses se terminent en quelques minutes. Il suffirait d'afficher le résultat à l'utilisateur, de le laisser continuer immédiatement si tout est propre, et de signaler les problèmes détectés.
Parité entre le store officiel et les stores tiers. Si le Play Store peut installer des applications instantanément, les boutiques alternatives devraient pouvoir en faire autant, à condition d'appliquer des contrôles de sécurité équivalents. L'argument sécuritaire ne tient que si les restrictions visent la sécurité et non l'avantage concurrentiel.

Ce que les développeurs devraient faire dès maintenant

Quel que soit votre avis sur l'approche de Google, la réalité pratique est que la friction du sideloading augmente et qu'elle a peu de chances de diminuer. Si vous distribuez des applications hors du Play Store, prévoyez-le.

Utilisez le programme Play App Signing. Les applications signées via le programme de Google peuvent subir moins de friction lors de la vérification du sideloading, car Google peut vérifier la signature par rapport à des clés connues.
Pour le développement, utilisez ADB. Les applications installées via ADB échappent à l'attente de 24 heures. Assurez-vous que vos pipelines CI/CD et vos workflows de test utilisent ADB plutôt que l'installation directe d'APK.
Envisagez les Progressive Web Apps. Pour les applications qui n'ont pas besoin d'une intégration profonde avec la plateforme, les PWA contournent totalement la question du store et du sideloading. Elles s'installent depuis le navigateur, se mettent à jour automatiquement et ne demandent aucune permission particulière pour être installées.
Si vous exploitez une boutique alternative, mettez en place une analyse robuste. Les stores qui démontrent de bonnes pratiques de sécurité pourraient à terme obtenir des exemptions ou une friction réduite, l'environnement réglementaire allant dans ce sens.
Prévenez les utilisateurs des délais. Si votre distribution repose sur le sideloading, informez les utilisateurs de l'attente de 24 heures dès le départ. Un délai annoncé frustre moins qu'une mauvaise surprise.

L'ouverture d'Android a toujours été un spectre, pas un absolu. Chaque version a déplacé ce curseur un peu plus vers le contrôle, justifié par de vraies préoccupations de sécurité, mais critiqué pour coïncider de manière bien commode avec des intérêts commerciaux. Le délai de 24 heures pour le sideloading est le dernier point de cette trajectoire, et probablement pas le dernier. Que vous y voyiez une protection raisonnable ou une friction artificielle dépend surtout de l'endroit où vous placez l'équilibre entre sécurité et liberté. Mais la réalité technique est claire : l'époque du sideloading sans friction sur Android est révolue, et les développeurs doivent adapter leur stratégie de distribution en conséquence.