- Le programme de certification des développeurs Android que Google mettra en place à partir de 2026 exigera que tous les développeurs d’applications vérifient leur identité, ce qui alimente la controverse sur l’équilibre entre protection de la vie privée et sécurité
- Le cas ICEBlock montre que, pour les développeurs ayant besoin d’anonymat, la divulgation de l’identité peut entraîner des préjudices personnels et professionnels
- La politique de confidentialité de Google précise que les informations des développeurs peuvent être partagées sans restriction avec des tiers, ce qui soulève des inquiétudes sur la fiabilité et la transparence
- Si l’usage des debug keystores et des noms de package en double est restreint après 2027, le développement et les tests d’applications dans les environnements éducatifs pourraient devenir plus difficiles
- Ce programme vise à empêcher les applications malveillantes, mais il faut débattre de l’anonymat, de l’accessibilité pédagogique et du manque de coopération avec les organisations de la société civile
Contexte et problématique
- Google exigera à partir de 2026 que tous les développeurs d’applications Android complètent une vérification d’identité, de sorte que seules les applications de développeurs certifiés puissent être installées
- Cette politique s’applique aussi aux applications distribuées en dehors de Google Play (sideloading)
- Accès anticipé à partir d’octobre 2025, ouverture à tous les développeurs en mars 2026, mise en œuvre en septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande
- Le cas de l’application ICEBlock souligne l’importance de l’anonymat
- ICEBlock est une plateforme permettant aux utilisateurs de signaler anonymement des activités de l’ICE (Immigration and Customs Enforcement), et après avoir révélé son identité, le développeur a subi des menaces juridiques ainsi que le licenciement de son épouse
- Le développeur d’une application similaire sur Android (provisoirement appelée « ICE Scream ») pourrait être exposé à des risques comparables en cas de divulgation de son identité
Question 1 : la prise en compte de l’anonymat
- On ne sait pas clairement comment Google prévoit de soutenir les développeurs qui doivent préserver leur anonymat pour des raisons légitimes
- Les développeurs d’applications comme ICE Scream peuvent craindre des menaces pour leur sécurité ou des représailles juridiques en cas d’exposition de leur identité
- Google n’a pas publié de mesures concrètes ni de politique d’exception pour ce type de scénario
Question 2 : la coopération avec les organisations de la société civile
- Rien ne confirme si Google a collaboré avec des organisations comme l’EFF ou AccessNow pour discuter de l’équilibre entre vie privée et sécurité dans ce programme de certification
- Ces organisations disposent d’une longue expérience sur les questions d’équilibre entre confidentialité et sécurité
- On manque d’informations sur l’utilisation éventuelle de leur expertise par Google et sur les résultats obtenus
Question 3 : l’ambiguïté de la politique de confidentialité
- La politique de confidentialité de Google indique que les données personnelles des développeurs peuvent être partagées avec des « entreprises ou personnes de confiance »
- Il n’existe pas d’explication claire sur les critères de « confiance » ni sur les limites d’utilisation des informations partagées
- Cela rend difficile, pour des personnes comme le développeur de ICE Scream, d’avoir confiance dans la manière dont Google traite ces informations
Question 4 : les debug keystores et l’environnement de développement
- Le développement d’applications Android utilise des debug keystores, qui sont temporaires et souvent remplacés
- Après 2027, si les debug keystores ne sont pas inclus dans le programme de certification, il pourrait devenir impossible de tester des applications sur du matériel certifié par Google
- Dans les environnements éducatifs (par exemple les salles de classe ou les serveurs CI), l’obligation d’enregistrer les keystores risque d’augmenter les barrières à l’apprentissage
Question 5 : le problème des noms de package en double
- Dans les environnements éducatifs, il est fréquent d’utiliser des noms de package en double, comme dans les projets d’exemple de Google
- Le programme de certification interdit les noms de package en double, ce qui empêcherait les développeurs débutants d’exécuter le code d’exemple
- Exemple : l’auteur, qui écrit des livres sur le développement d’applications Android, s’inquiète que ses lecteurs ne puissent plus lancer les exemples
- Google n’a présenté aucune solution à ce problème
Discussions supplémentaires et retours
- Google propose un formulaire en ligne pour recueillir les retours des développeurs, où il est possible de soumettre questions et préoccupations
- Lien vers le formulaire : https://docs.google.com/forms/d/…
- Les organisations de la société civile ou les personnes intéressées peuvent contacter dev.verification@commonsware.com
- Si Google souhaite lui aussi engager la discussion, il peut écrire à did.you.really.need.a.written.invitation@commonsware.com
Enjeux
- Le programme de certification des développeurs Android vise à renforcer la sécurité des utilisateurs, mais il ne prend pas suffisamment en compte l’impact des restrictions sur l’anonymat pour les développeurs
- Il risque de nuire à l’accessibilité pédagogique et à la protection de la vie privée, et appelle de la part de Google des explications politiques transparentes ainsi qu’une coopération avec les organisations de la société civile
- Cette politique pose un défi d’équilibre entre la prévention des applications malveillantes et le maintien d’un écosystème ouvert, ce qui rend essentiel le dialogue avec la communauté des développeurs
2 commentaires
S’il s’agit d’une application dont l’APK est distribué directement par le développeur, installez-la autant que possible avec Obtainium. Si elle est hébergée sur une plateforme de distribution connue comme GitHub ou GitLab, l’installation se fait en une ou deux manipulations et les mises à jour automatiques sont aussi prises en charge.
Le code lié à Google n’est pas inclus non plus, et c’est mieux sur tous les plans.
Si vous ne faites pas confiance au développeur, vous ne devriez de toute façon pas installer l’application.
Avis Hacker News
Il ne s’agit pas simplement de poser des questions, il faut afficher une opposition totale.
Au moindre compromis, on risque de se faire retirer tous ses droits en un instant.
Je n’arrête pas de repenser à l’avertissement de Stallman dans The Right to Read en 1997 : « en 2047, les débogueurs ne seront distribués qu’à des programmeurs numérotés et officiellement certifiés ».
Je ne comprends pas pourquoi il est si compliqué de disposer d’un vrai OS mobile open source.
J’utilise uniquement des PC Linux (portables, serveurs), pour le perso comme pour le travail.
J’ai bien besoin de MS365, Google Workspace, Zoom, etc. pour le travail, mais au moins j’y accède via le navigateur, ce qui permet d’éviter les écosystèmes fermés, et ça me convient.
Côté mobile, il existe PostmarketOS, Phosh et Ubuntu Touch, mais je ne les ai jamais vraiment utilisés au quotidien.
Je me dis parfois que c’est aussi de ma faute, mais même notre gouvernement ne prend en charge ses applis de vérification d’identité que sur iOS/Android.
En théorie il faudrait tenir uniquement avec le web, mais à cause de la commodité je finis moi aussi par utiliser des applis, et j’ai l’impression d’être faible.
Avec Ubuntu Touch et même un iPad, j’aurais peut-être au moins des appareils sur lesquels je peux encore contrôler mes données personnelles.
Au fond, il nous faut une véritable « plateforme informatique personnelle » qu’on peut emporter sans sac.
C’est triste de voir que même l’avenir de GrapheneOS dépend au final des mains d’un immense adversaire, cette entreprise qui déteste que les utilisateurs gardent le contrôle.
Je m’attends à ce que, dans un avenir proche, les smartphones et tablettes fermés deviennent plus nombreux que les desktops/portables classiques.
La plupart des gens n’auront même jamais la possibilité de posséder un appareil totalement ouvert.
Et il n’est pas impossible que les ordinateurs portables eux-mêmes deviennent fermés.
On peut déjà acheter des puces RISC-V entièrement ouvertes et les déboguer librement.
x86 est lui aussi presque totalement ouvert (à part quelques tentatives de fermeture comme sur Xbox ou PS5).
Donc j’ai l’impression que l’histoire du « droit de lire » chez Stallman est encore une exagération prématurée.
Le raisonnement manquant chez Stallman suppose que tous les systèmes sont parfaits, jamais compromis, et que les gens ont une compréhension parfaite des logiciels et des systèmes, qu’ils le veuillent ou non.
Si les débogueurs sont restreints, tout le monde finira simplement par utiliser des débogueurs pirates.
La grande majorité des gens (99,9 %) n’en a rien à faire de l’OSS.
Ce qui les intéresse, c’est juste de pouvoir utiliser leur téléphone comme ils le veulent, sans appli malveillante, inutile ou bourrée de pub.
Et par ailleurs, la publication et le développement sont deux activités distinctes.
Forcer une validation à chaque sideloading d’application, quelle qu’elle soit, relève d’un contrôle fascisant.
J’ai honte pour Google et Apple ; c’était leur objectif final depuis longtemps.
L’étape suivante sera de supprimer arbitrairement les applis qu’ils n’aiment pas, et nous ne pourrons pas les en empêcher.
L’avertissement de Stallman était juste.
Si le PC est resté ouvert, c’est uniquement parce qu’IBM n’avait pas vu venir les choses.
Quand IBM a essayé de reprendre le contrôle, il était déjà trop tard.
Je pense même que le mot « sideload » pose problème.
Pourquoi dire « sideload » au lieu de simplement « exécuter un programme » ?
Un OS qui m’empêche d’exécuter le programme que je veux n’a aucun sens.
J’ai demandé à un LLM ce que signifiait « Stallman was right » et j’en ai une vague idée, mais j’aimerais bien qu’on me l’explique directement.
Chaque fois que j’essaie de comprendre ce genre de sujet, ça me met mal à l’aise de n’écouter que la réponse d’un LLM, donc je préfère demander à des humains.
Je m’oppose fermement à ce type de mesure, et c’est pour ce genre de raison que je boycotte les produits Apple à vie, par conviction.
En revanche, qualifier tout de « fasciste » me semble être un abus de langage.
J’espère que cette décision provoquera un retour de bâton massif contre Google, et que des ROM comme LineageOS retrouveront leur popularité d’autrefois.
J’aimerais aussi que les contournements de détection de root progressent au point que les applis bancaires fonctionnent simplement sur des téléphones rootés.
Les exigences compliquées d’identité, comme la certification des développeurs, sont presque aussi mauvaises que chez Apple.
C’est aussi pour ça que les développeurs qui utilisent des produits Apple ne m’ont jamais vraiment semblé sérieux.
C’est absolument inacceptable.
Si on possède un appareil, on doit pouvoir y exécuter tout ce qu’on veut.
Limiter ou verrouiller l’accès à un produit qu’on a payé signifie qu’on n’en a pas vraiment la propriété.
Ce n’est guère différent d’une location.
Pas besoin d’imaginer longtemps la réaction si un constructeur automobile interdisait de rouler dans certaines zones.
Cela dit, VW limite déjà en pratique la puissance si l’abonnement annuel n’est plus payé.
À cause de l’avidité des entreprises et de l’ignorance des utilisateurs, ce phénomène existe déjà dans le monde réel.
Sur Steam, on achète des licences de jeux vidéo et on peut encore installer librement des mods.
Le modèle locatif est déjà discrètement présent à bien des endroits.
Avant, j’utilisais Shizuku sur mon téléphone pour faire tourner Hail (un outil de mise en pause d’applis).
Mais ma banque liée à ma carte de crédit a récemment commencé à vérifier la présence du débogage USB, donc j’ai dû arrêter de l’utiliser (même les OTP 3DS, je dois maintenant les recevoir par SMS).
En Thaïlande, seules deux banques environ ne font pas encore ce contrôle, mais j’ai l’impression que bientôt elles le feront toutes.
Je suis finalement passé à Dhizuku ; la configuration était un peu compliquée, mais une fois terminée, je n’ai plus besoin de relancer Shizuku à chaque fois, donc ça donne presque l’impression d’un jailbreak untethered complet.
Dhizuku fonctionne en gros comme un téléphone d’entreprise, sauf que le propriétaire, c’est moi.
Pour « gérer le profil principal », il faut supprimer tous les comptes du système de comptes Android et saisir une longue commande ADB, ce qui empêche tout usage malveillant.
À l’avenir, si on veut continuer à utiliser F-Droid, ce genre de méthode pourrait devenir la norme chez les ingénieurs.
Je me permets de suggérer l’utilisation du site web de la banque.
Je n’installe pas d’appli bancaire sur mon téléphone ; chaque fois que j’ai besoin de faire un virement, je m’assois devant mon ordinateur et je le fais depuis là.
Cet appareil est clairement à moi, et je devrais pouvoir l’utiliser comme je l’entends.
Cela dit, il faut aussi tenir compte du fait que l’usage d’outils comme ceux mentionnés (Shizuku, Dhizuku) peut réellement affecter la sécurité de l’appareil et faciliter certaines attaques.
Le fait de prêter temporairement les droits DeviceOwner à d’autres applis, par exemple, me paraît risqué en cas d’abus de privilèges.
Et si même des systèmes de sécurité comme GrapheneOS commencent à bloquer ce genre de configuration, le problème deviendra plus grave.
La détection du root, l’inspection de call stack, etc., restent de toute façon faciles à contourner, donc leur efficacité est limitée.
Un formulaire de retour a été mis en place pour celles et ceux qui veulent donner leur avis.
Lien vers le formulaire de feedback Google
Discussion associée
Je pense que cette politique ne s’appliquera pas aux OEM chinois.
Les appareils chinois sont livrés avec Google Mobile Services désactivé par défaut, et sans appli Play Store destinée aux utilisateurs.
Exiger une approbation de Google pour le développement d’applis internes n’aurait aucun sens.
Chaque OEM devrait alors mettre en place son propre service de licence de débogage, et déboguer des applis fondées sur l’écosystème Google pourrait devenir bien plus difficile.
Beaucoup d’OEM chinois ne cherchent déjà pas à obtenir la certification Google, donc je pense vraiment que cette politique ne les concernera pas.
Certains, comme Huawei, ont déjà leur propre app store et des solutions de remplacement aux services Google.
Ce sont en pratique des appareils de-googled, mais malheureusement souvent remplacés par le spyware du camp d’en face.
Le droit d’autoriser ou non l’installation d’applis (sideloading) doit appartenir au propriétaire de l’appareil.
De la même manière qu’on peut activer le déverrouillage du bootloader sur un téléphone, ce type de fonctionnalité essentielle devrait aussi être configurable par l’utilisateur.
C’est un principe de base, rien de moins.
Il y a certes des questions gênantes à poser, mais croire que cela pourrait mettre Google mal à l’aise me paraît bien optimiste.
Google se moque totalement de ce genre de problèmes.
Le service PR est précisément payé pour esquiver habilement ce type de questions embarrassantes.
Au contraire, ce genre de communication sert surtout à donner à Google l’image d’une entreprise « en dialogue ».
À cause de ça, l’une des principales raisons pour lesquelles j’utilisais Android plutôt qu’un iPhone est en train de disparaître.
À vrai dire, je trouve ça pire encore que les politiques d’Apple.
Les utilisateurs d’iPhone considèrent parfois l’impossibilité d’installer des applis tierces comme une fonctionnalité.
Je ne suis pas d’accord, mais Apple a au moins toujours été honnête sur le fait que les utilisateurs ne contrôlent pas réellement leur appareil.
Je trouve cette expérience désagréable, mais au moins elle est franche.
À l’inverse, Google attire les utilisateurs avec la promesse d’une plateforme ouverte avant de les trahir ensuite ; c’est un véritable appât.
Au début, quand Android et iPhone étaient en concurrence, le plus grand atout d’Android était justement qu’on pouvait installer les applis qu’on voulait sans avoir à demander l’autorisation de Google.
Je pense que cette fermeture des politiques Google finira peut-être par se retourner contre Google lui-même.
Si Android devient lui aussi fermé et strictement contrôlé comme iOS, on ne voit plus très bien pourquoi il faudrait continuer à utiliser Android.
Je me demande si cette mesure pourrait donner à une entreprise comme Epic des arguments supplémentaires pour poursuivre Google.
Explication de l’affaire liée
Si Google monopolise la procédure de validation, alors le pouvoir de distribution des applis Android diffusées via l’Epic Store ne sera plus entre les mains d’Epic, mais entre celles de Google.
C’est aussi pour ça que je pense qu’aux États-Unis (et, pour d’autres raisons, dans l’UE), Google ne pourra pas réellement mettre cette politique en œuvre.
Je n’aurais jamais imaginé qu’ils puissent même envisager une telle tentative, mais désormais j’ai l’impression que tout est possible, donc je ne sais plus quoi prédire.