4 points par GN⁺ 2025-06-06 | 3 commentaires | Partager sur WhatsApp
  • Google a récemment mis en œuvre une politique de restriction du sideloading d’applications Android, relançant le débat sur l’autonomie numérique des utilisateurs et l’ouverture de l’écosystème mobile
  • Dans le cadre d’un projet pilote à Singapour, la régulation a été renforcée avec le blocage de l’installation d’applications reçues via le web, la messagerie ou un gestionnaire de fichiers lorsqu’elles demandent des autorisations sensibles (SMS, accessibilité, etc.)
  • Avec l’introduction de la Play Integrity API, les développeurs peuvent limiter certaines fonctionnalités des applications installées par sideloading, renforçant une structure de distribution fermée et centrée sur le Google Play Store
  • Si ces mesures peuvent contribuer à renforcer la sécurité, elles sont aussi critiquées pour leur impact potentiel sur l’innovation et la concurrence, ainsi que pour l’affaiblissement de l’ouverture d’Android
  • Purism présente des alternatives comme PureOS et le Librem 5, des solutions mobiles open source et axées sur la confidentialité, qui garantissent la souveraineté des données et un environnement d’installation d’applications libre pour les utilisateurs

Mise en place par Google de restrictions sur le sideloading Android

  • Google a récemment commencé à appliquer de nouvelles restrictions aux applications installées par sideloading sur Android, invoquant des problèmes de sécurité
  • La politique pilote mise en place à Singapour a été introduite en coopération avec une agence de cybersécurité et consiste notamment à restreindre, via le navigateur web, les applications de messagerie et les gestionnaires de fichiers, l’installation d’applications demandant des autorisations sensibles comme l’accès aux SMS ou les services d’accessibilité
  • Cette mesure vise à empêcher les crimes liés aux escroqueries et aux malwares

Play Integrity API et dépendance à l’app store

  • En introduisant la Play Integrity API, Google permet aux développeurs d’applications d’imposer des limitations sur certaines fonctionnalités lorsqu’une application a été installée par sideloading
  • Ces politiques poussent les utilisateurs à installer les applications uniquement par la voie officielle du Google Play Store
  • Officiellement, l’objectif affiché est le renforcement de la sécurité, mais dans les faits cela conduit à un renforcement du contrôle de Google sur l’écosystème Android
  • Cela ravive les inquiétudes concernant l’autonomie numérique, l’innovation et les droits des utilisateurs

Critiques et conséquences

  • Les critiques reconnaissent que cette politique peut être efficace pour bloquer les applications malveillantes, mais soulignent aussi les problèmes de restriction de la concurrence et de réduction du choix des utilisateurs
  • L’ouverture de la plateforme propre à Android et la liberté du sideloading s’en trouvent affaiblies, faisant évoluer la plateforme vers un modèle similaire à l’écosystème fermé d’Apple iOS
  • Cette tendance pourrait déboucher sur un frein à l’innovation et un monopole de la distribution d’applications

L’alternative de Purism : PureOS et Librem Phone

  • Face à l’intensification de la surveillance et de la domination des entreprises, Purism propose une solution axée sur la confidentialité
  • PureOS est un système d’exploitation Linux basé sur Debian, embarqué sur les Librem 5 et Liberty Phones, qui garantit une autonomie complète de l’utilisateur et la souveraineté sur ses données
  • Cet environnement ne prend en charge que des applications de sécurité open source n’utilisant ni publicité ciblée, ni data mining, ni algorithmes addictifs, ni manipulation comportementale
  • Les utilisateurs n’ont pas à dépendre d’app stores d’entreprise ou d’API intrusives, et bénéficient ainsi d’une expérience informatique plus transparente et plus sûre

Conclusion : l’importance des alternatives ouvertes

  • Alors que Google rend l’écosystème Android de plus en plus fermé, Purism défend un environnement informatique mobile éthique, sûr et ouvert
  • Des alternatives centrées sur la souveraineté des utilisateurs et la confidentialité s’imposent comme des options importantes pour le secteur technologique et les développeurs

3 commentaires

 
spp00 2025-06-07

En réalité, pour le sideloading, il suffirait d’intégrer uniquement un « système de signataires de confiance » et d’ouvrir cela à des autorités de certification tierces comme DigiCert, ce qui permettrait au minimum de vérifier si un APK est digne de confiance. Le problème, c’est que Google a conçu ça de façon à en déléguer la responsabilité au Play Store. Mais si on se demande si le Google Play Store détecte vraiment bien les applications malveillantes, eh bien… quant aux applications qui ne respectent pas les règles de Google Play, ………

 
ndrgrd 2025-06-06

L’article lui-même semble avoir une intention discutable, mais il est vrai qu’à l’usage, cela devient de plus en plus pénible.
Sur les appareils Galaxy, ils ont déjà mis en place des fonctions comme le blocage des applications suspectées d’être malveillantes, au point qu’on ne peut même plus les désactiver. Il existe des moyens de contournement, mais ils ajoutent progressivement ce genre de restrictions.
Pour les utilisateurs occasionnels, qui utilisent rarement le sideloading, cela peut être une bonne fonctionnalité puisqu’elle peut empêcher l’exécution de malware, mais ne devrait-on pas au moins pouvoir la désactiver ?

J’espérais une sortie officielle du Pixel, mais si Google fait aussi la même chose...

 
GN⁺ 2025-06-06
Réactions sur Hacker News
  • Quelqu’un trouve très étrange le timing de cette publication de blog, se demandant si l’article n’avait pas été préparé il y a plusieurs mois avant d’être publié seulement maintenant, et rappelle que ce programme pilote a été annoncé à Singapour il y a 1 an et 4 mois ; il ne concerne que Singapour et les applications nécessitant certaines autorisations spécifiques (par ex. RECEIVE_SMS, READ_SMS, BIND_NOTIFICATIONS, autorisations d’accessibilité), et seulement celles téléchargées directement en dehors d’un app store ; l’installation via F-Droid ou adb semble aller dans le bon sens ; il serait possible d’essayer de contourner la mesure en désactivant Play Protect, mais la personne ne sait pas si cela fonctionne réellement à Singapour ; de façon originale, Google empêche de désactiver Play Protect pendant un appel, ce qui est salué comme une décision judicieuse ; citation à l’appui d’une annonce de la police de Singapour indiquant que cette approche n’a pas eu d’effet réellement probant en pratique, avec des exemples où les victimes sont incitées à désactiver Google Play Protect avant d’installer un fichier APK, puis à installer même une application VPN, permettant aux escrocs de contourner les protections bancaires (https://police.gov.sg/media-room/news/…)

    • Mention de données montrant que les habitants de Singapour sont particulièrement vulnérables aux arnaques : des dizaines de milliers de personnes ont été touchées l’an dernier, pour un total de 1,1 milliard de dollars singapouriens perdus, soit une hausse de 70 % sur un an ; selon les statistiques de la Global Anti-Scam Alliance, l’expérience de terrain suggère que les pertes réelles dépassent encore les chiffres déclarés ; explication du fait que Singapour soit ciblée par sa richesse, sa numérisation et sa culture de conformité réglementaire (https://archive.is/fCmW1)

    • Avis selon lequel on ne comprend pas pourquoi le billet de blog de Purism sort maintenant, et qu’il ne s’agit probablement que de FUD marketing ; mention directe de Librem 5 et Liberty Phones basés sur PureOS, avec doute sur leur capacité réelle à exécuter des APK ; Sailfish serait le seul à offrir ce type de fonction, mais comme exception liée à des questions de licence ; reconnaissance que Purism a beaucoup investi dans le développement Linux tactile, notamment Phosh, tout en soulignant que l’environnement tactile Linux reste encore très médiocre ; l’idée serait ici de dépeindre les alternatives grand public sous un jour défavorable afin de promouvoir ses propres produits, alors même que l’article ne traite pas d’une situation qui l’affecte directement

    • Quelqu’un estime qu’il est important de distinguer la période avant et après la décision défavorable à Google dans le procès lié à l’App Store ; insistance sur la difficulté à trouver un équilibre entre protection de l’utilisateur et liberté ; rappel que les utilisateurs finissent par ignorer les avertissements de sécurité à force d’y être habitués ; le Play Store lui-même n’est pas totalement sûr, et même des données GPS publiques d’utilisateurs Android montreraient des comportements malveillants de la part d’apps officielles ; au final, la solution serait selon cette personne de confier les droits d’administration de l’appareil à un tiers intelligent et digne de confiance pour protéger les utilisateurs vulnérables

  • Impression générale que l’article ressemble davantage à une publicité pour Purism qu’à un contenu vraiment substantiel

    • Dès qu’une personne a compris qu’il s’agissait de publicité, elle a jugé le contenu sans intérêt et a demandé un meilleur lien

    • À en juger par le nombre d’upvotes, beaucoup semblent inquiets de la direction prise par Android et intéressés par des alternatives

  • Quelqu’un demande si cette affaire ne date pas en fait de 2024 (https://techcrunch.com/2024/02/…)

  • À propos du programme pilote d’abord déployé à Singapour, explication qu’il ne bloque que les applications demandant certaines autorisations (SMS, accessibilité) lorsqu’elles sont installées via navigateur web, messagerie ou gestionnaire de fichiers ; avec autant de conditions, les utilisateurs avancés pourraient sans doute encore installer ce qu’ils veulent ; la mesure viserait surtout à empêcher les utilisateurs moyens de sideloader trop facilement des applications risquées demandant des autorisations SMS ou d’accessibilité ; rappel qu’il s’agit d’un dispositif mis en place avec la Cyber Security Agency de Singapour pour prévenir les arnaques et les malwares, ce qui expliquerait aussi pourquoi il est limité à Singapour

    • Remarque selon laquelle ce type de restriction peut en pratique devenir anticoncurrentiel sur le marché grand public : même si une minorité techniquement compétente peut encore installer ces apps, la majorité restera enfermée dans l’« enclos » contrôlé par Google ; Google ou Apple recourent même à un langage destiné à effrayer les utilisateurs au sujet des apps tierces, constituant une barrière psychologique supplémentaire ; ce type de « contrôle mental » devrait selon cette personne être éliminé par la régulation

    • Insistance sur le fait que « limité à Singapour » n’a rien de vraiment rassurant, et que navigateur et gestionnaire de fichiers étant des moyens tout à fait ordinaires de déplacer des fichiers, ces conditions n’inspirent pas spécialement confiance

    • Analyse selon laquelle parler de « blocage du sideloading » n’est pas vraiment exact tant que ADB n’est pas aussi bloqué ; quoi qu’il en soit, il faut trouver un équilibre entre la protection contre les malwares et la liberté d’installer les apps de son choix

    • Souvenir partagé d’une intégration obligatoire avec SingPass (le système national d’identité numérique) exigée par des clients singapouriens ; la personne n’est plus cliente aujourd’hui, mais le code doit encore traîner quelque part dans la base de code

    • Point de vue selon lequel d’autres régions pourraient être ajoutées à tout moment, et qu’il ne faut donc pas se rassurer avec la limitation à Singapour ; il vaudrait même mieux que Google avance vers une technologie de « fausses autorisations » accordées aux apps, sinon les criminels trouveront simplement d’autres moyens de contourner le système

  • En évoquant le commentaire devenu populaire selon lequel « le sideloading se résout en installant GrapheneOS », quelqu’un note à quel point cette réponse est déconnectée de la plupart des utilisateurs ordinaires ; les utilisateurs de HN savent peut-être faire du débogage matériel, mais les gens normaux ne peuvent pas manipuler ce genre de réglages système

    • Souvenir d’avoir été déconcerté sur des forums Linux par des réponses considérant comme normales des procédures CLI complexes ; pour des débutants qui veulent une solution simple et concise, le biais propre aux communautés d’experts peut au contraire freiner l’adoption et la diffusion

    • Diagnostic selon lequel la plupart des gens connaissent mal ce qu’est une expérience « moyenne » ; dans les communautés d’experts, cette déformation de perspective devient encore plus forte, produisant des avis très éloignés de la réalité de la majorité des utilisateurs

    • Analyse selon laquelle les gens ordinaires ne font généralement pas de sideloading et, une fois une app nécessaire installée, ont tendance à réutiliser encore et encore les mêmes applications

    • Mise en avant du fait que le grand public n’est généralement pas capable de distinguer si une application sideloadée demandant des autorisations SMS ou d’accessibilité est légitime, ce qui montre que le véritable objectif de ce blocage est d’empêcher les usages dangereux par les non-spécialistes

    • Inquiétude que, à mesure que Google ajoute des technologies DRM et des API, même l’installation de GrapheneOS cesse de devenir une alternative réaliste ; à ce moment-là, il faudra quitter tout l’écosystème Android pour utiliser un OS alternatif

  • Une personne raconte qu’elle défendait jusque-là l’idée « c’est mon téléphone, je veux être libre d’en faire ce que je veux », mais a été choquée de constater que les drones DJI et les Air Units poussent à installer leur app par sideloading ; explication que DJI ne peut pas publier l’application sur le Play Store parce qu’elle est capable de s’auto-modifier ; avertissement qu’en cas de conflit politique, cela pourrait permettre à un malware contrôlé par un État de prendre le contrôle du drone ; insistance sur le fait que des millions de personnes ont installé l’application sans vraiment prendre conscience de la situation

    • Selon cette personne, la réponse au problème n’est pas que Google fasse semblant d’analyser les malwares, mais qu’il existe des moyens bien plus stricts de contrôler les permissions et capacités réelles de l’app DJI ; le principal moteur de Google serait en réalité moins la « sécurité » que l’extension de son contrôle

    • Dans ce contexte, la vraie liberté de « faire ce que je veux » devrait aussi s’appliquer au logiciel ; l’idée défendue par Richard Stallman en 1988 — la liberté de récupérer le code source et de le modifier soi-même — resterait pleinement actuelle ; en pratique, on assisterait au contraire à une évolution où le logiciel contrôle l’utilisateur, ce qui est dénoncé ; si les gouvernements prennent le contrôle du code logiciel, les risques vont bien au-delà de la simple atteinte aux droits des consommateurs

    • Analyse selon laquelle les gouvernements ont déjà inséré ce type de fonction via les OEM ; le blocage du sideloading ne ferait alors qu’empêcher les hackers de désactiver ces malwares intégrés

    • Observation selon laquelle le fait qu’une application s’auto-modifie n’a pas grande importance, puisqu’il suffit d’embarquer un moteur V8 dans une app pour obtenir de toute façon des changements de code ; ironie sur le fait que Google ne considère pourtant pas cela comme un problème

    • Incompréhension face au fait que le commentaire initial mettant en garde contre le danger des apps de drones DJI ait été downvoté ; comme exemple, la personne cite la découverte récente de véritables kill switches dans des panneaux solaires chinois, pour soutenir l’idée que des entreprises chinoises étroitement liées au gouvernement peuvent intégrer des fonctions douteuses dans leur matériel ou leurs logiciels (https://reuters.com/sustainability/climate-energy/…, https://rickscott.senate.gov/2025/6/…)

  • Il est possible de contourner les restrictions de sideloading en installant GrapheneOS, mais Google tend de plus en plus à limiter via la Play Integrity API certaines fonctions applicatives aux seules installations depuis le Play Store ; même sur GrapheneOS avec bootloader verrouillé et Play Store utilisé normalement, Google bloquerait l’usage des API d’attestation matérielle, ce qui désactive des fonctions dans des apps bancaires, Google Wallet, etc. ; critique du fait que Google tolère des vendors médiocres qui retardent les mises à jour de sécurité, tout en excluant des OS open source pourtant très sûrs ; l’argument du travail conjoint avec la Cyber Security Agency de Singapour ne serait qu’un habillage ; question posée sur l’absence de blocage d’apps comme Facebook ou Instagram, qui devraient aussi être concernées (https://localmess.github.io, https://grapheneos.social/@GrapheneOS/112878070618462132)

    • Quelqu’un pense que Google tolère des pratiques de sécurité laxistes chez des tiers, et que sa véritable cible n’est pas la sécurité mais le contrôle en lui-même

    • Le principal problème de GrapheneOS serait le faible nombre d’appareils pris en charge ; il faudrait une alternative moins dépendante d’un matériel précis tout en maintenant un niveau de sécurité raisonnable

    • L’API Android d’attestation des clés est aussi prise en charge sur GrapheneOS, et peut être intégrée par les développeurs (https://grapheneos.org/articles/attestation-compatibility-guide)

    • Un lien de référence est donné vers une réponse déjà apportée au point sur l’installation de GrapheneOS comme solution (https://news.ycombinator.com/item?id=32496220)

  • Inquiétude que cette mesure porte un coup sévère à la communauté des personnes malvoyantes ; dans les pays où Android est populaire et où l’iPhone est cher, le lecteur d’écran Commentary (Jieshuo) constitue une meilleure alternative à TalkBack, mais il s’agit d’une app chinoise développée individuellement, absente du Play Store ; ce type d’app demande des autorisations extrêmement larges pour lire tout l’écran et contrôler l’interface système ; si l’accès aux apps sensibles est bloqué, sa raison d’être même comme lecteur d’écran devient vide de sens ; des employés de Google diront peut-être que ce n’est pas un problème au vu de la faible part d’usage dans les statistiques Webaim, mais Webaim repose surtout sur des échantillons anglophones à hauts revenus et ne représente pas les usages mondiaux (https://webaim.org/projects/screenreadersurvey10/)

  • Quelqu’un juge au contraire que cette intention de conception est plutôt rationnelle et de bon sens : il reste possible d’installer des malwares via ADB, mais la barrière d’entrée devient suffisamment élevée pour jouer le rôle de ralentisseur pour le grand public ; la personne dit ne pas connaître d’application sideloadée emblématique qui soit injustement discriminée

    • Rappel qu’il existe malgré tout des app stores alternatifs notables (par ex. Epic v. Google), et qu’Android mettait historiquement en avant son ouverture et la liberté de choix ; critique selon laquelle passer par ADB restreint finalement davantage la liberté utilisateur que la solution de sideloading proposée par Apple ; Apple a été critiqué pour cela, et cette mesure poserait un problème comparable
  • Explication du fait qu’il est fondamental de bloquer les demandes d’autorisations touchant aux données personnelles (SMS, accessibilité, etc.) : avec la seule autorisation SMS, il est possible de voler les OTP et donc les accès à pratiquement tous les services ; avec l’accessibilité, on peut aussi manipuler des fonctions critiques comme les apps bancaires ; à Singapour, le trafic de données d’identité serait si grave qu’il existe des avertissements du type « si un inconnu vous propose d’acheter votre numéro de téléphone ou d’autres données d’identité, vous risquez 5 ans de prison » ; même chose pour les comptes bancaires et cartes de crédit ; au final, comme les informations d’identité utilisées dans ces crimes restent liées aux individus, la coopération est punie plus sévèrement