Google Play zal ontwikkelaars binnenkort dwingen app-bundels te uploaden in plaats van APK's, wat ongemakkelijke beveiligingsvragen over de vereiste doet rijzen.
Vorige november, Google heeft aangekondigd dat ontwikkelaars verplicht zullen zijn nieuwe apps in de Play Store te publiceren met behulp van het Android App Bundle-formaat (AAB) in plaats van een APK. Onlangs herinnerde Google ontwikkelaars aan deze aankomende vereiste, wat een storm van controverse veroorzaakte van gebruikers die geloven dat Google APK's doodt, sideloading elimineert, app-winkels van derden hindert, en wat dan ook.
Het is waar dat Android App Bundles behoorlijk afwijken van het klassieke APK-formaat waar je misschien aan gewend bent, zowel als gebruiker als als ontwikkelaar. Hoewel er nogal wat voordelen kleven aan het gebruik van app-bundels, is er één belangrijk aspect bij het maken ervan waar sommige ontwikkelaars en beveiligingsexperts zich terecht zorgen over maken.
In dit artikel bespreken we de kritiek die we hebben gezien op de overstap naar Android App Bundles, evenals enkele voorgestelde oplossingen, en we zullen ook praten over de door Google voorgestelde oplossing voor deze problemen.
Achtergrond
Voordat dat echter gebeurt, moeten we eerst even praten over hoe app-distributie in het algemeen op Android werkt. Als u al weet hoe app-ondertekening en app-bundels werken, kunt u dit gedeelte overslaan.
APK's
Voor het grootste deel worden apps op Android gedistribueerd in APK-bestanden. Een APK bevat alle code en bronnen van een app, samen met enkele beveiligingsfuncties zoals een ondertekeningsmanifest. Wanneer een APK is geïnstalleerd, wordt deze in principe gewoon naar een specifieke map gekopieerd en toegevoegd aan een interne database met geïnstalleerde apps.
Handtekeningen
Tijdens de installatie wordt de handtekening van die app ook geverifieerd om er zeker van te zijn dat deze geldig is. Als de app al is geïnstalleerd, controleert Android de handtekening van de nieuwe app met de handtekening die al is geïnstalleerd. Als de handtekening niet geldig is of niet overeenkomt, weigert Android de app te installeren.
Die handtekeningcontrole is een belangrijk onderdeel van de beveiliging in Android. Het zorgt ervoor dat de app die u installeert geldig is en op zijn minst afkomstig is van dezelfde bron als degene die u al had geïnstalleerd. Als u bijvoorbeeld installeert mijn Lockscreen Widgets-app uit de Play Store, kunt u er redelijk zeker van zijn dat ik degene ben die het heeft ondertekend en dat het authentiek is. Als u vervolgens probeert een update voor Lockscreen Widgets te installeren vanaf een duistere site van derden en dit mislukt, weet u dat iemand met die APK heeft geknoeid, mogelijk om malware toe te voegen.
De sleutel die wordt gebruikt om een app te ondertekenen is (idealiter) nooit publiekelijk vrijgegeven. Dit staat bekend als de privésleutel. De privésleutel wordt vervolgens gebruikt om de sleutel te genereren die wordt weergegeven in de handtekening van de app, ook wel de openbare sleutel genoemd. Dit is wat Android en appstores gebruiken om de geldigheid van een app te verifiëren. Ik zal niet ingaan op hoe je precies een publieke sleutel kunt genereren zonder de privésleutel vrij te geven, omdat dit veel encryptiewiskunde met zich meebrengt. Als je meer details wilt, kijk dan eens Documentatie van Google over het ondertekenen van APK's of doe wat onderzoek naar eenrichtingswiskundige functies.
Een ander kenmerk van app-handtekeningen is de mogelijkheid om machtigingen alleen te beperken tot apps met overeenkomende handtekeningen. Android doet dit intern voor veel functies, waarbij alleen apps die zijn ondertekend met dezelfde sleutel als het framework toegang hebben tot bepaalde functies.
App-bundels
Nu we een kort overzicht hebben gegeven van APK's en handtekeningen, gaan we het hebben over app-bundels. Dit is waar APK-bronnen binnenkomen. Hulpbronnen zijn zaken als lay-outs, afbeeldingen, audio, enz. Kortom, het is alles dat geen code is. Om verschillende weergaveconfiguraties en verschillende talen beter te ondersteunen, kunnen ontwikkelaars meerdere versies van dezelfde bron maken die worden gebruikt, afhankelijk van het apparaat en de taal.
Maar in een APK bestaan al deze bronnen, ongeacht welke u gebruikt. En ze nemen ruimte in beslag. Afhankelijk van de complexiteit van uw app kunnen er voor veel apparaten veel ongebruikte bronnen zijn. Dit is waar App Bundles voor gemaakt zijn. Ontwikkelaars kunnen een app-bundel genereren, net als een APK, en die app-bundel kan vervolgens worden geüpload naar de Play Store, net zoals een APK dat kan.
Google gebruikt die app-bundel vervolgens om een hele reeks verschillende APK's te genereren voor verschillende apparaatconfiguraties. Elke App Bundle bevat alleen de bronnen die nodig zijn voor die configuratie. Wanneer een gebruiker die app gaat downloaden, krijgt hij de gegenereerde APK te zien die overeenkomt met zijn configuratie. Dit helpt de download- en installatiegrootte van apps te verkleinen, waardoor bandbreedte en opslagruimte worden bespaard.
Als u een APK installeert die specifiek is voor uw apparaat, betekent dit natuurlijk dat het moeilijker voor u is om deze gewoon naar een ander apparaat te kopiëren en zonder problemen te installeren. Afhankelijk van uw perspectief kan dit een goede of een slechte zaak zijn. Aan de ene kant maakt het piraterij moeilijker, omdat gebruikers niet meer over de hele app beschikken. Aan de andere kant maakt het het legitiem archiveren van apps moeilijker, om dezelfde reden.
App-ondertekening
Omdat Android App Bundles geen APK's zijn, kunt u niet zomaar een AAB-bestand openen en dit rechtstreeks op een apparaat installeren. Wanneer je er één uploadt naar de Play Store, gebruikt Google de bundel om verschillende (niet-ondertekende) APK-bestanden te genereren. Deze APK's moeten vervolgens worden ondertekend voordat ze kunnen worden geïnstalleerd.
In plaats van de ontwikkelaar te vragen de gegenereerde APK's te ondertekenen en opnieuw te uploaden, beheert Google de ondertekening zelf. De Play Store gebruikt een nieuwe sleutel die wordt aangemaakt of vraagt de ontwikkelaar om de sleutel die hij gebruikt om te ondertekenen APK's. Bij beide opties verzorgt Google de openbare ondertekening voor de ontwikkelaar en zorgt voor een upload sleutel. Google gebruikt de uploadsleutel voor interne verificatie en zorgt ervoor dat de app-bundel (of in sommige gevallen APK) die de ontwikkelaar uploadt de juiste is.
Als een uploadsleutel gecompromitteerd of verloren gaat, kunnen ontwikkelaars een nieuwe aanvragen, en de ondertekeningssleutel die wordt gebruikt om de app te distribueren blijft ongewijzigd.
App-ondertekening omvat nog veel meer, maar dit is wat relevant is voor dit artikel. Als je wilt, kun je meer lezen over app-bundels en app-aanmelding dit mediumartikel van Wojtek Kaliciński.
Kritiek
In theorie en in de praktijk zijn app-bundels behoorlijk goed. Ze verminderen het datagebruik en de installatiegrootte, allemaal zonder dat de gebruiker iets hoeft te doen. Maar vanwege de manier waarop het is geïmplementeerd, hebben sommige ontwikkelaars en beveiligingsonderzoekers de afgelopen maanden hun zorgen geuit. Voordat ik deze zorgen samenvat, wil ik even de tijd nemen om te zeggen dat het meeste van wat hieronder staat rechtstreeks is gebaseerd op een reeks artikelen door ontwikkelaar Mark Murphy van CommonsWare. Je moet absoluut zijn artikelen lezen, omdat ze meer details en kritiek geven vanuit het perspectief van een ontwikkelaar.
Beveiliging
In het klassieke distributiemodel houdt een ontwikkelaar de sleutel die hij gebruikt om een APK te ondertekenen privé. Het wordt nooit gedeeld met het publiek en alleen geautoriseerde mensen mogen er toegang toe hebben. Dit zorgt ervoor dat alleen die mensen een geldige APK kunnen genereren.
Maar als u app-bundels in de Play Store gebruikt, is Google degene die de sleutel beheert die de APK's tekent die gebruikers ontvangen. De standaard gedrag voor nieuwe apps die zijn geüpload naar Google Play vanaf augustus 2021 Het is de bedoeling dat Google zijn eigen distributiesleutel maakt, die hij privé houdt voor de ontwikkelaar.
Ontwikkelaars die indienen nieuwe apps zal Google standaard hun privésleutel voor hen laten beheren, hoewel ontwikkelaars updates indienen bestaande apps kunt APK's blijven gebruiken of ze kunnen overstappen op AAB-distributie door een nieuwe sleutel te genereren die Google voor nieuwe gebruikers kan gebruiken. Bestaande apps zijn niet vereist om over te schakelen van APK-distributie naar Android App Bundles, hoewel die optie voor hen beschikbaar is als ze daarvoor kiezen. Na enige tegenwerking, Google zal het zelfs mogelijk maken om uw eigen privésleutel te uploaden waarmee Google kan ondertekenen, voor zowel nieuwe als bestaande apps. Geen van deze situaties is ideaal, want wat er ook gebeurt, Google heeft toegang tot uw privésleutel als u dat wilt gebruiken Android App Bundles (en ontwikkelaars hebben geen keuze als ze na augustus een nieuwe app willen indienen 2021!)
Hoewel we ervan overtuigd zijn dat Google beveiliging zeer serieus neemt, is er geen enkel bedrijf ter wereld dat immuun is voor datalekken. Als de sleutel die Google gebruikt om uw app te ondertekenen voor distributie zich in een van deze inbreuken bevindt, kan iedereen een versie van uw app ondertekenen en deze laten lijken alsof deze door u is ondertekend. En sommige ontwikkelaars en beveiligingsexperts zijn niet blij met deze mogelijkheid. Het is een heel, heel kleine mogelijkheid, ja, maar het feit dat het überhaupt een mogelijkheid is, maakt sommigen in de infosec-gemeenschap bang.
Als ontwikkelaars Android APK's ondertekenen, kan iedereen APK's van Google Play verifiëren. Blind vertrouwen is niet vereist. Het is een elegant ontwerp dat verifieerbare veiligheid biedt. App-bundels zetten dat op zijn kop en lijken gestructureerd om de lock-in van leveranciers te bevorderen. Er zijn veel alternatieve technische benaderingen die kleine APK's opleveren die nog steeds door ontwikkelaars zijn ondertekend, maar deze geven niet de voorkeur aan Play. Alle APK-varianten kunnen bijvoorbeeld door de ontwikkelaar worden gegenereerd en ondertekend en vervolgens naar een app store worden geüpload.
Er zijn zeker argumenten te bedenken over de vraag of het beter is om de veilige opslag van privésleutels over te laten aan Google of aan individuele ontwikkelaars. Maar die ontwikkelaars gebruiken (waarschijnlijk) meestal geen centrale opslagplaats voor hun sleutels. Door ontwikkelaars te dwingen Play App Signing te gebruiken, hoeft een kwaadwillende aanvaller slechts één keer de beveiliging van Google te doorbreken om duizenden of miljoenen sleutels op te halen.
Voor wat het waard is, hier is wat Google zegt over hoe het uw ondertekeningssleutel op zijn infrastructuur beschermt:
[blockquoteauthor="Wojtek Kaliciński, Android Developer Advocate bij Google"]Wanneer u Play App Signing gebruikt, worden uw sleutels opgeslagen op dezelfde infrastructuur die Google gebruikt om zijn eigen sleutels op te slaan.
Sleuteltoegang wordt geregeld door strikte ACL's en fraudebestendige audittrails voor alle activiteiten.
Alle artefacten die zijn gegenereerd en ondertekend met de sleutel van de ontwikkelaar, worden voor u beschikbaar gesteld in de Google Play Console voor inspectie/attestering.
Om sleutelverlies te voorkomen, maken we bovendien zeer frequent back-ups van onze primaire opslag. Deze back-ups zijn sterk gecodeerd en we testen regelmatig het herstel vanaf deze back-ups.
Als je meer wilt weten over de technische infrastructuur van Google, lees dan de Whitepapers over Google Cloud-beveiliging.[/blokquote]
Hoe geweldig ook, alle geluiden, verlies en diefstal zijn nog steeds mogelijk. En audittrails helpen alleen maar toekomstige aanvallen te voorkomen; ze krijgen geen gehackte sleutels terug.
Potentieel voor ongeoorloofde wijzigingen
Een groot probleem met de manier waarop Google App Bundles heeft opgezet, is de mogelijkheid dat er ongeautoriseerde wijzigingen aan een app worden toegevoegd. Het proces van het extraheren van APK's uit een app-bundel brengt inherent wijzigingen met zich mee, aangezien Google elke APK handmatig moet bouwen. Terwijl Google heeft beloofd dat het geen code zal injecteren of wijzigen, is het probleem met het App Bundle-proces dat het daartoe de macht heeft.
Hier zijn een paar voorbeelden van waartoe een bedrijf in de positie van Google de macht heeft:
Stel dat er een beveiligde berichten-app is die mensen gebruiken om te communiceren zonder het risico van overheidstoezicht. Dit zou een ongelooflijk nuttig instrument kunnen zijn voor mensen die protesteren tegen een autoritaire regering, of zelfs voor mensen die gewoon hun privacy willen behouden. Die regering, die wil kunnen zien wat app-gebruikers zeggen, zou kunnen proberen Google te dwingen een surveillance-achterdeur in de code van de app toe te voegen.
Dit voorbeeld is wat onschuldiger, maar het is ook iets dat sommige mensen zorgen baart. Stel dat er een app is die miljoenen downloads per dag krijgt, maar die geen advertenties of analyses bevat. Dat is een enorme gegevensbron zonder toegang tot die gegevens. Google wil als advertentiebedrijf mogelijk toegang krijgen tot die gegevens.
In het klassieke APK-model van app-distributie kan Google de apps niet wijzigen zonder de handtekening te wijzigen. Als Google de handtekening verandert, vooral bij een populaire app, zullen mensen het merken omdat de update niet kan worden geïnstalleerd. Maar met App Bundles en App Signing kon Google in stilte zijn eigen code in apps injecteren voordat deze werd gedistribueerd. De handtekening zou niet veranderen omdat Google eigenaar zou zijn van de ondertekeningssleutel.
Om duidelijk te zijn, Het is ongelooflijk onwaarschijnlijk dat deze voorbeelden zullen plaatsvinden. Google heeft de neiging om eenvoudig te zijn zich geheel uit de lastige markten terug te trekken, in plaats van zich aan te passen. Maar ook al is het onwaarschijnlijk, het is nog steeds mogelijk. Alleen omdat een bedrijf belooft dat iets niet zal gebeuren, garandeert het dit niet.
Codetransparantie
Google hoorde deze zorgen en introduceerde deze week een nieuwe functie genaamd Codetransparantie voor appbundels. Met Codetransparantie kan een ontwikkelaar in wezen een tweede handtekening maken die met de app naar gebruikers wordt verzonden. Deze extra handtekening moet worden gemaakt op basis van een afzonderlijke privésleutel waar alleen de ontwikkelaar toegang toe heeft. Er zijn echter enkele beperkingen aan deze methode.
Codetransparantie heeft alleen betrekking op code. Dat lijkt misschien voor de hand liggend gezien de naam, maar het betekent ook dat gebruikers geen bronnen, het manifest of iets anders kunnen verifiëren dat geen DEX-bestand of een eigen bibliotheek is. Hoewel kwaadwillige wijzigingen aan niet-codebestanden meestal veel minder impact hebben, is het nog steeds een gat in de beveiliging van de app.
Een ander probleem met Codetransparantie is dat er geen inherente verificatie is. Voor een, het is een optionele functie, dus ontwikkelaars moeten eraan denken dit op te nemen voor elke nieuwe APK die ze uploaden. Op dit moment moet dit worden gedaan vanaf de opdrachtregel en met een versie van bundletool dat wordt niet meegeleverd met Android Studio. Zelfs als een ontwikkelaar het toevoegt, heeft Android geen enkele vorm van verificatie ingebouwd om te controleren of het Code Transparency-manifest overeenkomt met de code in de app.
Het is aan een eindgebruiker om dit zelf te controleren door het manifest te vergelijken met een openbare sleutel die de ontwikkelaar kan verstrekken, of door de APK ter verificatie naar de ontwikkelaar te sturen.
Hoewel Codetransparantie de bevestiging mogelijk maakt dat er geen code in een app is gewijzigd, omvat deze geen enkele vorm van verificatie voor andere delen van een app. Er is ook geen inherent vertrouwen in het proces. Je zou kunnen zeggen dat als je Google niet vertrouwt, je waarschijnlijk de taak hebt om onafhankelijk te verifiëren, maar waarom zou je dat moeten doen?
Er zijn nog andere problemen met de functie Codetransparantie, zoals gewezen door Mark Murphy uit CommonsWare. Ik raad aan zijn artikel te lezen voor een meer diepgaande analyse van de functie.
Gemak en keuze voor ontwikkelaars
Een derde (en laatste voor dit artikel) reden waarom sommige ontwikkelaars problemen hebben met app-bundels is het verminderde gemak en de keuze.
Als een ontwikkelaar een nieuwe app in de Play Store maakt nadat Google app-bundels begint te eisen en hij of zij kiest de standaardoptie om Google de ondertekeningssleutel te laten beheren, hebben ze nooit toegang tot die ondertekening sleutel. Als diezelfde ontwikkelaar die app vervolgens in een andere app store wil distribueren, moet hij zijn eigen sleutel gebruiken, die niet overeenkomt met die van Google.
Dat betekent dat gebruikers moeten installeren en updaten vanaf Google Play of vanaf bronnen van derden. Als ze de bron willen wijzigen, moeten ze de app volledig verwijderen, waarbij mogelijk gegevens verloren gaan, en opnieuw installeren. APK-aggregators zoals APKMirror krijgt dan ook te maken met meerdere officiële handtekeningen voor dezelfde app. (Technisch gezien moeten ze dit al doen omdat je met app-ondertekening een nieuwe, veiligere sleutel kunt maken voor nieuwe gebruikers, maar het zal voor hen en voor andere sites nog erger zijn als iedereen heeft om het te doen.)
De reactie van Google op dit probleem is om de App Bundle-verkenner of Artefact-verkenner in de Play Console te gebruiken om de resulterende APK's uit de geüploade bundel te downloaden. Net als bij Codetransparantie is dit geen volledige oplossing. De APK's die zijn gedownload van de Play Console worden opgesplitst voor verschillende apparaatprofielen. Hoewel de Play Console het uploaden van meerdere APK's voor één versie van één app ondersteunt, doen veel andere distributiekanalen dat niet.
Veel van de voordelen van het gebruik van app-bundels verdwijnen dus als ontwikkelaars meerdere winkels beheren, wat de distributie moeilijker maakt. Met nieuws dat Windows 11 is ondersteuning voor Android-apps verkrijgen Dankzij de Amazon Appstore zijn sommigen van mening dat de eis voor app-bundels ontwikkelaars ervan zal weerhouden om op Amazon te distribueren. De voornaamste zorg van Google is natuurlijk de eigen app store, maar dat is precies wat bracht hen in heet water met concurrenten waardoor ze leiden kleine, verzoenende veranderingen over hoe appstores van derden werken op Android.
Een paar gerelateerde problemen met meerdere winkels zijn app-interconnectiviteit en snelle tests.
Laten we beginnen met app-interconnectiviteit. Heeft u ooit een app gedownload die functies achter een betaalmuur vergrendelt? Bijna zeker. Sommige ontwikkelaars plaatsen de functies achter een in-app-aankoop, maar anderen kiezen er misschien voor om een aparte, betaalde app te maken. Wanneer die add-on-app wordt geïnstalleerd, zijn de functies van de hoofdapp ontgrendeld.
Maar wat weerhoudt iemand ervan om zomaar de add-on van een piratenbron te installeren? Welnu, er zijn veel opties voor ontwikkelaars, maar in ieder geval één betreft het gebruik van door handtekeningen beveiligde machtigingen. Stel dat de hoofdapp een door handtekeningen beschermde toestemming declareert. De add-on-app geeft vervolgens aan van die toestemming gebruik te willen maken. Idealiter heeft de add-on-app ook een soort licentieverificatiefunctionaliteit, die verbinding maakt met internet om er zeker van te zijn dat de gebruiker legitiem is.
Als beide apps dezelfde handtekening hebben, verleent Android toestemming aan de add-on-app en worden de controles op piraterijbeveiliging doorstaan. Als de add-on-app niet de juiste handtekening heeft, wordt de toestemming niet verleend en mislukt de verificatie.
Met het klassieke APK-distributiemodel kan een gebruiker beide apps van elke legitieme bron verkrijgen en ermee klaar zijn. Met het huidige standaard App Bundle-model komen de handtekeningen van de hoofd- en add-on-apps niet overeen. Google gaat voor elke app een unieke sleutel maken. De ontwikkelaar kan altijd de door handtekeningen beveiligde toestemming afschaffen en directe hash-verificatie van handtekeningen gebruiken, maar dat is een stuk minder veilig.
En dan zijn er nog de snelvuurtesten. Gebruikers e-mailen ontwikkelaars voortdurend over problemen in hun apps. Soms zijn deze problemen eenvoudige oplossingen: reproduceer het probleem, zoek het probleem, los het op en upload een nieuwe versie. Maar soms zijn ze dat niet. Soms kunnen ontwikkelaars een probleem niet reproduceren. Ze kunnen repareren wat zij denken dat het probleem is, maar dan moet de gebruiker het testen. Stel nu dat de gebruiker de app via Google Play heeft geïnstalleerd.
Met het APK-model kan een ontwikkelaar code wijzigen, een nieuwe APK bouwen en ondertekenen, en deze ter test naar de gebruiker sturen. Omdat de handtekening van de test-APK overeenkomt met de handtekening die de gebruiker heeft geïnstalleerd, is het een eenvoudig proces om bij te werken, te testen en terug te rapporteren. Bij appbundels valt dit uit elkaar. Omdat Google de APK ondertekent die de gebruiker oorspronkelijk heeft geïnstalleerd, komt deze niet overeen met de handtekening van de APK die de ontwikkelaar verzendt. Als deze app na de deadline voor app-bundels wordt gepubliceerd, heeft de ontwikkelaar niet eens toegang tot de belangrijkste toepassingen van Google. Om te testen moet de gebruiker de huidige app verwijderen voordat hij de testversie installeert.
Er zijn hier een heleboel problemen. Ten eerste is er ongemak, zowel aan de kant van de ontwikkelaar als aan de gebruikerskant. Het is niet leuk om de app te moeten verwijderen alleen maar om een oplossing te testen. En wat als het probleem verdwijnt? Waren het de wijzigingen die de ontwikkelaar had aangebracht, of kwam dit doordat de gebruiker de gegevens van de app effectief had gewist? De Play Store beschikt over interne tests, waarmee ontwikkelaars snelle builds en distributie kunnen uitvoeren, maar hiervoor moet de gebruiker eerst de releaseversie verwijderen. Het lost niet echt iets op.
Mocht dit allemaal klinken als een hoop hypothetische onzin, dan is hier een heel reëel voorbeeld van een ontwikkelaar die deze problemen zal krijgen als hij Google een privésleutel voor hem laat genereren: João Dias. Hij is de ontwikkelaar van Tasker, samen met een hele reeks plug-in-apps, waaronder de AutoApps-suite. Met de nieuwe App Bundles-vereiste kan de ontwikkelingscyclus van João een stuk lastiger worden, tenminste voor nieuwe apps. Het direct versturen van testversies zal minder handig zijn. Het verifiëren van licenties zal minder effectief zijn.
Dit klinkt misschien als een randgeval, maar het is niet zo dat João een kleine ontwikkelaar is, en het is waarschijnlijk dat hij niet de enige is. Er zijn veel apps in de Play Store die afhankelijk zijn van handtekeningverificatie om onwettige gebruikers te detecteren.
Met de nieuwe optie voor ontwikkelaars om hun eigen ondertekeningssleutels naar Google te uploaden, zijn deze problemen uiteraard enigszins verlicht. Maar ontwikkelaars moeten zich aanmelden om de optie voor elke app in te schakelen. Als dit niet het geval is, zullen de verbindingen mislukken en zal snelle ondersteuning vereisen dat een bundel naar Google wordt geüpload en wordt gewacht tot APK's zijn gegenereerd voordat de juiste APK naar de gebruiker wordt verzonden. Bovendien betekent het nog steeds dat ze hun privésleutel moeten delen, wat ons terugbrengt bij de zorgen die we eerder bespraken.
Oplossingen
Dit is een oud probleem, aangezien de App Bundle-vereisten maanden geleden bekend zijn gemaakt, dus er zijn in de tussentijd nogal wat oplossingen voorgesteld.
Eén oplossing is om de noodzaak van Play App Signing te vermijden. In plaats van een appbundel te genereren die Google vervolgens verwerkt tot APK's en borden, zou die verwerking door Android Studio kunnen worden gedaan. Vervolgens kunnen ontwikkelaars gewoon een ZIP vol met lokaal ondertekende APK's uploaden voor elke configuratie die Google zou hebben gegenereerd.
Met die oplossing zou Google helemaal geen toegang meer nodig hebben tot de sleutels van ontwikkelaars. Het proces zou sterk lijken op het klassieke APK-distributiemodel, maar zou meerdere, kleinere APK's omvatten in plaats van slechts één.
Een andere oplossing is om het gebruik van app-bundels niet langer te vereisen en ontwikkelaars toe te staan lokaal ondertekende APK's te uploaden. Terwijl app-bundels dat wel kunnen in veel gevallen een betere ervaring voor de gebruiker zijn, hebben sommige apps er feitelijk geen baat bij om per configuratie te worden opgesplitst, met een minimale grootte afname.
Als Google beide oplossingen implementeert, hoeft een ontwikkelaar die App Bundles wil gebruiken, niet bij de hand te hebben over het ondertekenen bij Google, en een ontwikkelaar wiens app niet veel profijt heeft van het formaat, hoeft het niet te gebruiken alle.
Google's reacties
Zelfondertekenend
Toen hen voor het eerst werd gevraagd of ontwikkelaars toestemming kregen om de ondertekening voor app-bundels af te handelen, was het antwoord van Google zeer vrijblijvend:
[blockquoteauthor=""]Ik heb het dus kort gehad over de vereiste dat nieuwe apps volgend jaar appbundels moeten gebruiken, en één ding dat daarmee gepaard gaat is dat we bij uitbreiding Play App Signing nodig zullen hebben. Ontwikkelaars zullen dus de App Signing-sleutel op Play moeten genereren of hun eigen sleutel naar Play moeten uploaden... omdat dat een vereiste is voor app-bundels. We hebben van ontwikkelaars gehoord dat sommigen van hen het gewoon niet willen doen. Ze willen niet dat sleutels door Play worden beheerd. En dat kan momenteel niet als je gebruik wilt maken van appbundels.
Maar we hebben die feedback gehoord, en... ik kan nu nergens over praten, we hebben niets aan te kondigen, maar we onderzoeken hoe we een aantal van deze zorgen kunnen wegnemen. Het hoeft niet noodzakelijkerwijs mogelijk te zijn om uw eigen sleutel te behouden tijdens het uploaden van bundels. We onderzoeken verschillende opties. We hebben op dit moment gewoon geen oplossing om aan te kondigen. Maar we hebben nog ongeveer een jaar tot de vereiste, dus ik heb goede hoop dat we hiervoor een antwoord voor ontwikkelaars hebben.[/blockquote]
Dat was eind november vorig jaar en er lijkt niets te zijn gebeurd. Met nog maar een paar maanden te gaan voordat de De vereiste voor app-bundels wordt van kracht, is er nog steeds geen manier voor ontwikkelaars om het ondertekenen van hun eigen apps aan te pakken. Terwijl Google het nu mogelijk heeft gemaakt uploaden je eigen sleutel voor zowel nieuwe als bestaande apps, dit neemt het ondertekeningsgedeelte nog steeds uit handen van de ontwikkelaar.
Codewijzigingen
Hoewel Google specifiek heeft beloofd dat de Play Store de app-code niet zal wijzigen, is een belofte geen garantie. Met app-bundels en app-ondertekening zijn er voor zover wij weten geen technische beperkingen die voorkomen dat Google geüploade apps wijzigt vóór distributie.
Google heeft geïntroduceerd Codetransparantie als een optionele functie, en hoewel dit enigszins helpt, brengt het een behoorlijk aantal problemen met zich mee, zoals we eerder hebben besproken.
Zelfgemaakte bundels
Toen Google werd gevraagd of ontwikkelaars hun eigen app-"bundels" (ZIP's met gesplitste APK's) konden maken, was het antwoord feitelijk "dat gaan we niet doen":
Waarschijnlijk niet zoals beschreven in de vraag, omdat dit het publicatieproces nog moeilijker zou maken voor ontwikkelaars, en we het eigenlijk eenvoudiger en veiliger willen maken. Maar nogmaals, we hebben deze feedback gehoord en we zullen opties onderzoeken om dit mogelijk te maken, maar waarschijnlijk niet op de manier die hier is beschreven.
Interessant genoeg lijkt de rechtvaardiging van Google te zijn dat dit het publiceren ingewikkelder zou maken. Google zou het proces echter nog steeds kunnen automatiseren als onderdeel van het dialoogvenster voor het genereren van APK's in Android Studio. Bovendien, als de app in kwestie in meerdere winkels wordt gedistribueerd, zou deze feitelijk de publicatieproces eenvoudiger, omdat ontwikkelaars niet meerdere ondertekeningssleutels en klachten hoeven te beheren gebruikers.
En met de introductie van Code Transparency lijkt het erop dat complicaties toch niet bepaald een probleem zijn. Codetransparantie vereist, althans voorlopig, dat de ontwikkelaar een opdrachtregelprogramma gebruikt en dat gebruikers expliciet de geldigheid verifiëren van de app die ze krijgen. Dit is ingewikkelder dan een proces om zelf bundels te maken, en het is onduidelijk waarom dit de oplossing is waar Google de voorkeur aan geeft.
Vooruit gaan
App-bundels zijn vanaf 1 augustus het vereiste distributieformaat voor nieuwe apps die bij Google Play worden ingediend. Hoewel Google de meeste problemen die door ontwikkelaars en beveiligingsexperts naar voren zijn gebracht op zijn minst enigszins heeft aangepakt, laten de reacties veel te wensen over. Er zijn veel duidelijke voordelen aan App Bundles als distributieformaat van de volgende generatie, maar er zullen altijd zorgen blijven bestaan over het geven van gedeeltelijke of volledige controle over app-ondertekening aan Google.
De reacties en inspanningen van Google worden zeker op prijs gesteld, maar sommigen, zoals Mark Murphy, vinden dat ze niet ver genoeg zijn gegaan. Omdat oplossingen zoals zelfgemaakte bundels niet worden geïmplementeerd en de deadline voor Android App Bundles snel vereist is nadert, lijkt het er niet op dat ontwikkelaars op Google Play lang de volledige controle over hun apps zullen kunnen behouden langer.
We zullen later vanmiddag in een Twitter Space praten over de implicaties van de Android App Bundle-vereiste, dus doe mee!