Google Play obligera bientôt les développeurs à télécharger des App Bundles au lieu des APK, soulevant des questions de sécurité inconfortables concernant cette exigence.
Novembre dernier, Google a annoncé que les développeurs devront publier de nouvelles applications sur le Play Store en utilisant le format Android App Bundle (AAB) au lieu d'un APK. L'autre jour, Google a rappelé aux développeurs cette exigence à venir, déclenchant une tempête de controverses. des utilisateurs qui pensent que Google tue les APK, élimine le chargement latéral, gêne les magasins d'applications tiers et étagère.
Il est vrai qu’Android App Bundles s’écarte considérablement du format APK classique auquel vous êtes peut-être habitué, à la fois en tant qu’utilisateur et en tant que développeur. Bien que l'utilisation des App Bundles présente de nombreux avantages, leur création présente un aspect clé qui inquiète à juste titre certains développeurs et experts en sécurité.
Dans cet article, nous aborderons les critiques que nous avons vues concernant le passage à Android App Bundles ainsi que certaines solutions proposées, et nous parlerons également de la solution proposée par Google à ces problèmes.
Arrière-plan
Avant que cela n’arrive, nous devons parler un peu du fonctionnement général de la distribution d’applications sur Android. Si vous savez déjà comment fonctionnent la signature d’applications et les App Bundles, vous pouvez ignorer cette partie.
APK
Pour la plupart, les applications sur Android sont distribuées dans des fichiers APK. Un APK contient tout le code et les ressources d'une application, ainsi que certaines fonctionnalités de sécurité comme un manifeste de signature. Lorsqu'un APK est installé, il est simplement copié dans un dossier spécifique et ajouté à une base de données interne des applications installées.
Signature
Lors de l'installation, la signature de cette application est également vérifiée pour garantir sa validité. Si l'application est déjà installée, Android vérifie la signature de la nouvelle application par rapport à celle déjà installée. Si la signature n'est pas valide ou ne correspond pas, Android refusera d'installer l'application.
Cette vérification de signature est un élément important de la sécurité sous Android. Il garantit que l'application que vous installez est valide et provient au moins de la même source que celle que vous aviez déjà installée. Par exemple, si vous installez, disons: mon application Lockscreen Widgets depuis le Play Store, vous pouvez être raisonnablement sûr que c'est moi qui l'ai signé et qu'il est authentique. Si vous essayez ensuite d'installer une mise à jour de Lockscreen Widgets à partir d'un site tiers douteux et que cela échoue, vous saurez que quelqu'un a falsifié cet APK, éventuellement pour ajouter un logiciel malveillant.
La clé utilisée pour signer une application est (idéalement) jamais rendu public. C'est ce qu'on appelle la clé privée. La clé privée est ensuite utilisée pour générer la clé affichée dans la signature de l'application, appelée clé publique. C'est ce qu'Android et les magasins d'applications utilisent pour vérifier la validité d'une application. Je n'entrerai pas dans les détails de la manière exacte dont vous pouvez générer une clé publique sans exposer la clé privée, car cela implique beaucoup de calculs de chiffrement. Si vous voulez plus de détails, consultez Documentation de Google sur la signature des APK ou faites des recherches sur les fonctions mathématiques à sens unique.
Une autre fonctionnalité des signatures d'applications est la possibilité de restreindre les autorisations uniquement aux applications dont les signatures correspondent. Android le fait en interne pour de nombreuses fonctions, où seules les applications signées avec la même clé que le framework peuvent accéder à certaines fonctionnalités.
Offres groupées d'applications
Alors maintenant que nous avons donné un aperçu rapide des APK et des signatures, parlons des App Bundles. C'est là qu'interviennent les ressources APK. Les ressources sont des éléments tels que des mises en page, des images, du son, etc. Fondamentalement, il s’agit de tout ce qui n’est pas du code. Pour mieux prendre en charge différentes configurations d'affichage et différentes langues, les développeurs peuvent créer plusieurs versions de la même ressource qui sont utilisées en fonction de l'appareil et de la langue.
Mais dans un APK, toutes ces ressources existent, quelle que soit celle que vous utilisez. Et ils prennent de la place. En fonction de la complexité de votre application, de nombreuses ressources peuvent être inutilisées pour de nombreux appareils. C’est ce que les App Bundles sont conçus pour résoudre. Les développeurs peuvent générer un App Bundle tout comme un APK, et cet App Bundle peut ensuite être téléchargé sur le Play Store, tout comme un APK.
Google utilise ensuite cet App Bundle pour générer tout un tas d'APK différents pour différentes configurations d'appareils. Chaque App Bundle contient uniquement les ressources nécessaires à cette configuration. Lorsqu'un utilisateur télécharge cette application, il reçoit l'APK généré qui correspond à sa configuration. Cela permet de réduire à la fois la taille des téléchargements et des installations des applications, économisant ainsi de la bande passante et de l'espace de stockage.
Bien sûr, installer un APK spécifique à votre appareil signifie qu'il est plus difficile pour vous de simplement le copier sur un autre appareil et de l'installer sans problème. Selon votre point de vue, cela peut être une bonne ou une mauvaise chose. D'une part, cela rend le piratage plus difficile, puisque les utilisateurs ne disposent plus de l'intégralité de l'application. D’un autre côté, cela rend plus difficile l’archivage légitime des applications, pour la même raison.
Signature d'application
Étant donné que les Android App Bundles ne sont pas des APK, vous ne pouvez pas simplement ouvrir un fichier AAB et l'installer directement sur un appareil. Lorsque vous en téléchargez un sur le Play Store, Google utilise le bundle pour générer différents fichiers APK (non signés). Ces APK doivent ensuite être signés avant de pouvoir être installés.
Au lieu de demander au développeur de signer et de télécharger à nouveau les APK générés, Google gère lui-même la signature. Le Play Store utilise une nouvelle clé qu'il crée ou demande au développeur la clé qu'il utilise pour signer APK. Quelle que soit l'option choisie, Google gère la signature publique pour le développeur et propose un téléchargement clé. Google utilise la clé de téléchargement pour la vérification interne et s'assure que l'App Bundle (ou l'APK dans certains cas) que le développeur télécharge est le bon.
Si une clé de téléchargement est compromise ou perdue, les développeurs peuvent en demander une nouvelle et la clé de signature utilisée pour distribuer l'application reste inchangée.
Il y a bien plus à découvrir dans la signature d'application, mais c'est ce qui est pertinent pour cet article. Si vous le souhaitez, vous pouvez en savoir plus sur les App Bundles et la connexion aux applications sur cet article Medium de Wojtek Kaliciński.
Critique
En théorie et en pratique, les App Bundles sont plutôt géniaux. Ils réduisent l’utilisation des données et la taille de l’installation, le tout sans que l’utilisateur n’ait à faire quoi que ce soit. Mais en raison de la manière dont il est mis en œuvre, certains développeurs et chercheurs en sécurité ont exprimé leurs inquiétudes au cours des derniers mois. Avant de résumer ces préoccupations, je voudrais prendre un moment pour dire que la plupart de ce qui est écrit ci-dessous est directement basé sur une série d'articles par le développeur Mark Murphy de CommonsWare. Vous devez absolument consulter ses articles, car ils fournissent plus de détails et de critiques du point de vue d'un développeur.
Sécurité
Dans le modèle de distribution classique, un développeur garde privée la clé qu’il utilise pour signer un APK. Il n'est jamais partagé avec le public et seules les personnes autorisées devraient y avoir accès. Cela garantit que seules ces personnes peuvent générer un APK valide.
Mais si vous utilisez des App Bundles sur le Play Store, c'est Google qui gère la clé qui signe les APK que les utilisateurs reçoivent. Le défaut comportement des nouvelles applications téléchargées sur Google Play à partir d'août 2021 est pour Google de créer sa propre clé de distribution qu'il garde privée du développeur.
Développeurs soumettant nouvelles applications Google demandera par défaut de gérer leur clé privée pour eux, bien que les développeurs soumettent des mises à jour à applications existantes peut continuer à utiliser les APK ou ils peuvent passer à la distribution AAB en générant une nouvelle clé que Google pourra utiliser pour les nouveaux utilisateurs. Applications existantes ne sont pas obligatoires pour passer de la distribution APK aux Android App Bundles, bien que cette option leur soit disponible s'ils le souhaitent. Après quelques réticences, Google permettra même pour télécharger votre propre clé privée avec laquelle Google pourra se connecter, pour les applications nouvelles et existantes. Aucune de ces situations n'est idéale, car quoi qu'il arrive, Google aura accès à votre clé privée si vous le souhaitez. utiliser Android App Bundles (et les développeurs n'ont pas le choix s'ils souhaitent soumettre une nouvelle application après le mois d'août) 2021!)
Même si nous sommes convaincus que Google prend la sécurité très au sérieux, aucune entreprise sur Terre n'est à l'abri des violations de données. Si la clé que Google utilise pour signer votre application en vue de sa distribution se trouve dans l'une de ces violations, n'importe qui peut signer une version de votre application et donner l'impression qu'elle a été signée par vous. Et certains développeurs et experts en sécurité ne sont pas satisfaits de cette possibilité. C'est une possibilité très, très mince, oui, mais le fait que ce soit une possibilité effraie certains membres de la communauté de la sécurité informatique.
Demander aux développeurs de signer les APK Android signifie que n'importe qui peut vérifier les APK depuis Google Play, une confiance aveugle n'est pas requise. C'est un design élégant qui offre une sécurité vérifiable. Les App Bundles renversent la situation et semblent structurés pour promouvoir le verrouillage du fournisseur. Il existe de nombreuses approches techniques alternatives qui fourniraient de petits APK toujours signés par les développeurs, mais celles-ci ne privilégieraient pas Play. Par exemple, toutes les variantes d’APK pourraient être générées et signées par le développeur, puis téléchargées sur n’importe quelle boutique d’applications.
Il y a certainement des arguments à faire valoir pour savoir s'il est préférable de laisser le stockage sécurisé des clés privées entre les mains de Google ou de développeurs individuels. Mais ces développeurs n’utilisent (probablement) généralement pas de référentiel central pour leurs clés. En obligeant les développeurs à utiliser Play App Signing, un attaquant malveillant n'a qu'à violer la sécurité de Google une seule fois pour récupérer des milliers ou des millions de clés.
Pour ce que ça vaut, voici ce que dit Google sur la manière dont il protège votre clé de signature sur son infrastructure :
[blockquote author="Wojtek Kaliciński, Android Developer Advocate chez Google"]Lorsque vous utilisez Play App Signing, vos clés sont stockées sur la même infrastructure que celle que Google utilise pour stocker ses propres clés.
L'accès aux clés est régi par des ACL strictes et des pistes d'audit inviolables pour toutes les opérations.
Tous les artefacts générés et signés avec la clé du développeur sont mis à votre disposition dans la console Google Play pour inspection/attestation.
De plus, pour éviter la perte de clés, nous effectuons des sauvegardes très fréquentes de notre stockage principal. Ces sauvegardes sont fortement cryptées et nous testons régulièrement la restauration à partir de ces sauvegardes.
Si vous souhaitez en savoir plus sur l'infrastructure technique de Google, lisez le Livres blancs sur la sécurité du cloud Google.[/blockquote]
Aussi génial que cela, tous les bruits, pertes et vols restent possibles. Et les pistes d’audit ne font qu’aider à prévenir de futures attaques; ils ne récupéreront pas les clés violées.
Potentiel de modifications non autorisées
Un gros problème avec la façon dont Google a configuré les App Bundles est la possibilité que des modifications non autorisées soient ajoutées à une application. Le processus d’extraction des APK d’un App Bundle implique intrinsèquement des modifications, puisque Google doit créer manuellement chaque APK. Alors que Google a promis de ne pas injecter ni modifier de code., le problème avec le processus App Bundle est qu’il a le pouvoir de le faire.
Voici quelques exemples de ce qu’une entreprise dans la position de Google a le pouvoir de faire :
Supposons qu'il existe une application de messagerie sécurisée que les gens utilisent pour communiquer sans risque de surveillance gouvernementale. Cela pourrait être un outil incroyablement utile pour les personnes qui protestent contre un gouvernement autoritaire, ou même pour celles qui souhaitent simplement préserver leur vie privée. Ce gouvernement, souhaitant pouvoir voir ce que disent les utilisateurs de l'application, pourrait tenter de contraindre Google à ajouter une porte dérobée de surveillance dans le code de l'application.
Cet exemple est un peu plus anodin, mais c'est aussi quelque chose qui préoccupe certaines personnes. Supposons qu'il existe une application qui reçoit des millions de téléchargements par jour, mais qui ne contient aucune publicité ni analyse. C'est une énorme source de données sans aucun moyen d'accéder à ces données. Google, en tant que société de publicité, souhaiterait peut-être accéder à ces données.
Dans le modèle APK classique de distribution d'applications, Google ne peut pas modifier les applications sans changer la signature. Si Google modifie la signature, en particulier sur une application populaire, les gens le remarqueront car la mise à jour ne s'installera pas. Mais avec les App Bundles et App Signing, Google pourrait injecter silencieusement son propre code dans les applications avant de les distribuer. La signature ne changerait pas car Google serait propriétaire de la clé de signature.
Pour être clair, il est extrêmement improbable que ces exemples se produisent. Google a tendance à simplement se retirer complètement des marchés difficiles, plutôt que de s’adapter. Mais même si c’est peu probable, cela reste possible. Ce n’est pas parce qu’une entreprise promet que quelque chose n’arrivera pas qu’elle le garantit.
Transparence des codes
Google, entendant ces préoccupations, a introduit cette semaine une nouvelle fonctionnalité appelée Transparence du code pour les App Bundles. La transparence du code permet à un développeur de créer essentiellement une deuxième signature fournie avec l'application aux utilisateurs. Cette signature supplémentaire doit être créée à partir d'une clé privée distincte à laquelle seul le développeur a accès. Cependant, cette méthode présente certaines limites.
La transparence du code ne couvre que le code. Cela peut sembler évident étant donné son nom, mais cela signifie également que cela ne permet pas aux utilisateurs de vérifier les ressources, le manifeste ou tout autre élément qui n'est pas un fichier DEX ou une bibliothèque native. Bien que les modifications malveillantes apportées aux fichiers non codés aient généralement beaucoup moins d'impact, elles constituent toujours une faille dans la sécurité de l'application.
Un autre problème avec Code Transparency est qu’il n’y a pas de vérification inhérente. Pour un, c'est une fonctionnalité facultative, les développeurs doivent donc penser à l’inclure pour chaque nouvel APK qu’ils téléchargent. Pour le moment, cela doit être fait depuis la ligne de commande et avec une version de bundletool cela ne vient pas avec Android Studio. Même lorsqu'un développeur l'inclut, Android ne dispose d'aucune sorte de vérification intégrée pour vérifier que le manifeste Code Transparency correspond au code de l'application.
C'est à l'utilisateur final de vérifier par lui-même en comparant le manifeste à une clé publique que le développeur peut fournir, ou en envoyant l'APK au développeur pour vérification.
Bien que la transparence du code permette de confirmer qu'aucun code d'une application n'est modifié, elle n'inclut aucune sorte de vérification pour les autres parties d'une application. Il n’y a pas non plus de confiance inhérente dans le processus. On pourrait dire que si vous ne faites pas confiance à Google, vous êtes probablement à la hauteur de la tâche de vérification indépendante, mais pourquoi devriez-vous le faire ?
Il existe d'autres problèmes avec la fonctionnalité de transparence du code, comme souligné par Mark Murphy de CommonsWare. Je recommande de lire son article pour une analyse plus approfondie de la fonctionnalité.
Commodité et choix pour les développeurs
Une troisième (et dernière pour cet article) raison pour laquelle certains développeurs contestent les App Bundles est la commodité et le choix réduits.
Si un développeur crée une nouvelle application sur le Play Store après que Google commence à exiger des App Bundles et qu'il choisit l'option par défaut consistant à laisser Google gérer la clé de signature, ils n'auront jamais accès à cette signature clé. Si ce même développeur souhaite ensuite distribuer cette application sur une autre boutique d'applications, il devra utiliser sa propre clé, qui ne correspondra pas à celle de Google.
Cela signifie que les utilisateurs devront soit installer et mettre à jour depuis Google Play, soit à partir de sources tierces. S'ils souhaitent modifier la source, ils doivent désinstaller complètement l'application, ce qui risque de perdre des données, et la réinstaller. Les agrégateurs d'APK comme APKMiroir devra alors également gérer plusieurs signatures officielles pour une même application. (Techniquement, ils doivent déjà le faire car la signature d'application vous permet de créer une nouvelle clé plus sécurisée pour les nouveaux utilisateurs, mais ce sera pire pour eux et pour les autres sites lorsque tout le monde a pour le faire.)
La réponse de Google à ce problème consiste à utiliser l'explorateur App Bundle ou l'explorateur Artifact dans la Play Console pour télécharger les APK résultants à partir du bundle téléchargé. Tout comme pour Code Transparency, ce n’est pas une solution complète. Les APK téléchargés depuis la Play Console seront répartis pour différents profils d'appareil. Bien que la Play Console prenne en charge le téléchargement de plusieurs APK pour une version d'une application, ce n'est pas le cas de nombreux autres canaux de distribution.
Ainsi, de nombreux avantages de l’utilisation des App Bundles disparaissent lorsque les développeurs gèrent plusieurs magasins, ce qui rend la distribution plus difficile. Avec des nouvelles que Windows 11 est obtenir le support des applications Android grâce à l'Amazon Appstore, certains pensent que l'exigence des App Bundles dissuadera les développeurs de distribuer sur Amazon. Bien sûr, la principale préoccupation de Google concerne sa propre boutique d'applications, mais c'est exactement ce que les a mis dans l'eau chaude avec des concurrents les amenant à faire petits changements conciliants sur le fonctionnement des magasins d'applications tiers sur Android.
Quelques problèmes liés à plusieurs magasins sont l’interconnectivité des applications et les tests rapides.
Commençons par l'interconnectivité des applications. Avez-vous déjà téléchargé une application qui verrouille des fonctionnalités derrière un paywall? Presque certainement. Certains développeurs mettent les fonctionnalités derrière un achat intégré, mais d'autres peuvent choisir de créer une application distincte et payante. Lorsque cette application complémentaire est installée, les fonctionnalités de l'application principale sont déverrouillées.
Mais qu’est-ce qui empêche quelqu’un d’installer simplement le module complémentaire à partir d’une source pirate? Eh bien, il existe de nombreuses options pour les développeurs, mais au moins une implique l'utilisation d'autorisations protégées par signature. Supposons que l'application principale déclare une autorisation protégée par signature. L'application complémentaire déclare alors qu'elle souhaite utiliser cette autorisation. Idéalement, l'application complémentaire comportera également une sorte de fonctionnalité de vérification de licence, qui se connecte à Internet pour garantir la légitimité de l'utilisateur.
Si les deux applications ont la même signature, Android accordera l'autorisation à l'application complémentaire et les contrôles de protection contre le piratage seront réussis. Si l'application complémentaire n'a pas la bonne signature, l'autorisation ne sera pas accordée et la vérification échouera.
Avec le modèle de distribution APK classique, un utilisateur peut obtenir l’une ou l’autre application à partir de n’importe quelle source légitime et en finir avec elle. Avec le modèle App Bundle par défaut actuel, les signatures des applications principales et complémentaires ne correspondent pas. Google va créer une clé unique pour chaque application. Le développeur pourrait toujours supprimer l'autorisation protégée par signature et utiliser la vérification directe du hachage de signature, mais c'est beaucoup moins sécurisé.
Et puis il y a les tests de tir rapide. Les utilisateurs envoient régulièrement des e-mails aux développeurs concernant les problèmes liés à leurs applications. Parfois, ces problèmes sont de simples solutions: reproduisez le problème, recherchez le problème, corrigez-le et téléchargez une nouvelle version. Mais parfois, ce n’est pas le cas. Parfois, les développeurs ne parviennent pas à reproduire un problème. Ils peuvent résoudre ce qu’ils pensent être le problème, mais l’utilisateur doit ensuite le tester. Supposons maintenant que l'utilisateur ait installé l'application via Google Play.
Avec le modèle APK, un développeur peut modifier du code, créer et signer un nouvel APK, puis l'envoyer à l'utilisateur pour test. Étant donné que la signature de l'APK de test correspond à celle installée par l'utilisateur, le processus de mise à jour, de test et de rapport est simple. Avec les App Bundles, cela s’effondre. Étant donné que Google signe l’APK initialement installé par l’utilisateur, il ne correspondra pas à la signature de l’APK envoyé par le développeur. Si cette application est publiée après la date limite des App Bundles, le développeur n'aura même pas accès aux principales utilisations de Google. Pour tester, l'utilisateur devra désinstaller l'application actuelle avant d'installer la version de test.
Il y a un tas de problèmes ici. Premièrement, il y a des inconvénients, tant du côté des développeurs que des utilisateurs. Devoir désinstaller l'application juste pour tester un correctif n'est pas amusant. Et si le problème disparaissait? Était-ce les modifications apportées par le développeur, ou était-ce parce que l'utilisateur avait effectivement effacé les données de l'application? Le Play Store dispose de tests internes, qui sont censés permettre aux développeurs de créer et de distribuer rapidement, mais ils obligent l'utilisateur à désinstaller d'abord la version finale. Cela ne résout vraiment rien.
Au cas où tout cela ressemblerait à un tas d'absurdités hypothétiques, voici un exemple très réel d'un développeur qui rencontrera ces problèmes s'il laisse Google générer une clé privée pour lui: João Dias. Il est le développeur de Tasker, ainsi que de tout un tas d'applications plug-in, dont la suite AutoApps. Avec la nouvelle exigence des App Bundles, le cycle de développement de João pourrait devenir beaucoup plus délicat, du moins pour les nouvelles applications. Envoyer directement des versions de test sera moins pratique. La vérification des licences sera moins efficace.
Cela peut sembler un peu marginal, mais ce n'est pas comme si João était un petit développeur, et il est probable qu'il ne soit pas seul. Il existe de nombreuses applications sur le Play Store qui s'appuient sur la vérification des signatures pour détecter les utilisateurs illégitimes.
Bien entendu, avec la nouvelle option permettant aux développeurs de télécharger leurs propres clés de signature sur Google, ces problèmes sont au moins quelque peu atténués. Mais les développeurs doivent s’inscrire pour activer l’option pour chaque application. Si ce n’est pas le cas, les interconnexions échoueront et la prise en charge rapide nécessitera de télécharger un bundle sur Google et d’attendre que les APK soient générés avant d’envoyer le bon à l’utilisateur. De plus, cela signifie toujours qu’ils doivent partager leur clé privée, ce qui nous ramène aux préoccupations évoquées plus tôt.
Solutions
Il s'agit d'un vieux problème étant donné que les exigences de l'App Bundle ont été publiées il y a des mois, de nombreuses solutions ont donc été proposées entre-temps.
Une solution consiste à éviter d’avoir besoin de la signature d’application Play. Au lieu de générer un App Bundle que Google traite ensuite en APK et en signes, ce traitement pourrait être effectué par Android Studio. Ensuite, les développeurs peuvent simplement télécharger un ZIP rempli d'APK signés localement pour chaque configuration que Google aurait générée.
Avec cette solution, Google n'aurait pas du tout besoin d'accéder aux clés des développeurs. Le processus serait très similaire au modèle de distribution APK classique, mais impliquerait plusieurs APK plus petits au lieu d’un seul.
Une autre solution consiste simplement à ne pas exiger l’utilisation d’App Bundles et à continuer de permettre aux développeurs de télécharger des APK signés localement. Bien que les App Bundles puissent être une meilleure expérience pour l'utilisateur dans de nombreux cas, certaines applications ne bénéficient pas réellement d'une division par configuration, avec une taille minimale réduction.
Si Google implémentait ces deux solutions, alors un développeur souhaitant utiliser les App Bundles n'aurait pas à le faire. sur la signature à Google, et un développeur dont l'application ne bénéficiera pas beaucoup du format n'aura pas à l'utiliser à tous.
Les réponses de Google
Auto-signature
Lorsqu'on leur a demandé pour la première fois s'il était possible d'autoriser les développeurs à gérer la signature des App Bundles, la réponse de Google a été très évasive :
[blockquote author=""]J'ai donc brièvement parlé de l'obligation l'année prochaine pour les nouvelles applications d'utiliser des bundles d'applications, et une chose qui va avec est que, par extension, nous exigerons la signature d'application Play. Les développeurs devront donc soit générer la clé de signature d’application sur Play, soit télécharger leur propre clé sur Play… car c’est une condition préalable aux bundles d’applications. Les développeurs nous ont dit que certains d’entre eux ne voulaient tout simplement pas le faire. Ils ne veulent pas que les clés soient gérées par Play. Et actuellement, ce n’est pas possible si vous souhaitez utiliser des bundles d’applications.
Mais nous avons entendu ces retours, et… Je ne peux parler de rien pour le moment, nous n’avons rien à annoncer, mais nous étudions comment nous pourrions atténuer certaines de ces inquiétudes. Cela ne doit pas nécessairement permettre de conserver votre propre clé lors du téléchargement de bundles. Nous étudions différentes options. Nous n’avons tout simplement pas de solution à annoncer pour le moment. Mais il nous reste encore environ un an avant de répondre aux exigences, j'espère donc vraiment que nous aurons une réponse pour les développeurs à ce sujet.[/blockquote]
C'était à la fin novembre de l'année dernière et rien ne semble s'être produit. À quelques mois seulement du L'exigence relative aux App Bundles entre en vigueur, les développeurs n'ont toujours aucun moyen de gérer la signature de leurs propres applications. Même si Google permet désormais de télécharger votre propre clé pour les applications nouvelles et existantes, cela retire toujours la partie signature du développeur.
Modifications des codes
Bien que Google ait spécifiquement promis que le Play Store ne modifierait pas le code de l'application, une promesse ne constitue pas une garantie. Avec les App Bundles et la signature d'applications, nous ne connaissons aucune limitation technique empêchant Google de modifier les applications téléchargées avant leur distribution.
Google a introduit Transparence des codes en tant que fonctionnalité facultative, et bien que cela aide dans une certaine mesure, elle présente son lot de problèmes, comme nous l'avons évoqué plus tôt.
Offres groupées faites maison
Lorsqu'on a demandé à Google s'il était possible de permettre aux développeurs de créer leurs propres « bundles » d'applications (des ZIP contenant des APK divisés), la réponse a été essentiellement: « nous n'allons pas faire cela » :
Probablement pas comme cela est décrit dans la question, car cela rendrait le processus de publication encore plus difficile pour les développeurs, et nous voulons en fait le rendre plus simple et plus sûr. Cependant, encore une fois, nous avons entendu ces commentaires et nous examinerons les options permettant de rendre cela possible, mais probablement pas de la manière décrite ici.
Il est intéressant de noter que la justification de Google semble être que cela rendrait la publication plus compliquée. Cependant, Google pourrait toujours automatiser le processus dans le cadre de la boîte de dialogue de génération d'APK dans Android Studio. De plus, si l'application en question est distribuée sur plusieurs magasins, cela rendrait effectivement le processus de publication plus simple, puisque les développeurs n'auraient pas à gérer plusieurs clés de signature et les plaintes de utilisateurs.
Et avec l’introduction de Code Transparency, il semble que la complication ne soit pas vraiment un problème après tout. La transparence du code, du moins pour l'instant, nécessite que le développeur utilise un outil de ligne de commande et que les utilisateurs vérifient explicitement la validité de l'application qui leur est proposée. C'est plus compliqué qu'un processus de création groupée autonome, et on ne sait pas pourquoi c'est la solution préférée de Google.
Aller de l'avant
Les App Bundles seront le format de distribution requis pour les nouvelles applications soumises sur Google Play à partir du 1er août. Bien que Google ait au moins quelque peu résolu la plupart des problèmes soulevés par les développeurs et les experts en sécurité, les réponses laissent beaucoup à désirer. Les App Bundles présentent de nombreux avantages évidents en tant que format de distribution de nouvelle génération, mais il y aura toujours des préoccupations persistantes quant au fait de donner un contrôle partiel ou total à Google sur la signature des applications.
Les réponses et les efforts de Google sont certes appréciés, mais certains, comme Mark Murphy, estiment ne pas être allés assez loin. Avec des solutions telles que les bundles créés par vous-même qui ne sont pas mises en œuvre et la date limite pour les Android App Bundles est requise rapidement. À l'approche, il ne semble pas que les développeurs sur Google Play seront en mesure de conserver le contrôle total de leurs applications pendant longtemps. plus long.
Nous parlerons des implications de l'exigence d'Android App Bundle dans un espace Twitter plus tard cet après-midi, alors rejoignez-nous !