Гоогле Плаи ће ускоро приморати програмере да отпремају скупове апликација уместо АПК-ова, што ће покренути непријатна безбедносна питања у вези са захтевом.
Прошлог новембра, Гоогле је објавио да ће програмери морати да објављују нове апликације у Плаи продавници користећи Андроид Апп Бундле (ААБ) формат уместо АПК-а. Пре неки дан, Гугл је подсетио програмере на овај предстојећи захтев, изазвавши буру контроверзи од корисника који верују да Гоогле убија АПК-ове, елиминише бочно учитавање, омета продавнице апликација трећих страна и шта не.
Истина је да су Андроид Апп Бундлеови прилично велики одмак од класичног АПК формата на који сте можда навикли, и као корисник и као програмер. Иако постоји доста предности коришћења Апп Бундле-а, постоји један кључни аспект за њихово стварање за који су неки програмери и стручњаци за безбедност с правом забринути.
У овом чланку ћемо покрити критике које смо видели о преласку на Андроид Апп Бундле, као и нека предложена решења, а такође ћемо говорити о Гоогле-овом предложеном решењу за ове проблеме.
Позадина
Пре него што се то догоди, морамо мало да разговарамо о томе како дистрибуција апликација функционише на Андроид-у уопште. Ако већ знате како функционишу потписивање апликација и скупови апликација, можете прескочити овај део.
АПК-ови
Углавном, апликације на Андроиду се дистрибуирају унутар АПК датотека. АПК садржи сав код и ресурсе апликације, заједно са неким безбедносним функцијама као што је манифест за потписивање. Када се АПК инсталира, он се у суштини само копира у одређену фасциклу и додаје у интерну базу података инсталираних апликација.
Потписи
Током инсталације, потпис те апликације се такође верификује да би се уверило да је валидан. Ако је апликација већ инсталирана, Андроид проверава потпис нове апликације у односу на онај који је већ инсталиран. Ако потпис није важећи или се не подудара, Андроид ће одбити да инсталира апликацију.
Та провера потписа је важан део безбедности у Андроид-у. Обезбеђује да је апликација коју инсталирате важећа и барем из истог извора као и она коју сте већ инсталирали. На пример, ако инсталирате, рецимо, моја апликација Лоцксцреен Видгетс из Плаи продавнице, можете бити прилично сигурни да сам ја тај који га је потписао и да је аутентичан. Ако затим покушате да инсталирате ажурирање Лоцксцреен Видгетс-а са неког сумњивог сајта треће стране и то не успе, знаћете да је неко мењао тај АПК, вероватно да би додао малвер.
Кључ који се користи за потписивање апликације је (идеално) никад јавно објављен. Ово је познато као приватни кључ. Приватни кључ се затим користи за генерисање кључа приказаног у потпису апликације, познатог као јавни кључ. Ово је оно што Андроид и продавнице апликација користе за проверу ваљаности апликације. Нећу улазити у то како тачно можете да генеришете јавни кључ без откривања приватног кључа, пошто то укључује много математике за шифровање. Ако желите више детаља, погледајте Гоогле-ова документација о потписивању АПК-ова или урадите неко истраживање о једносмерним математичким функцијама.
Још једна карактеристика потписа апликација је могућност да се дозволе ограничи само на апликације са одговарајућим потписима. Андроид то ради интерно за многе функције, где само апликације потписане истим кључем као оквир могу приступити одређеним функцијама.
Пакети апликација
Сада када смо дали кратак преглед АПК-ова и потписа, хајде да причамо о пакетима апликација. Овде долазе АПК ресурси. Ресурси су ствари као што су распореди, слике, аудио итд. У суштини, они су све што није код. Да би боље подржали различите конфигурације екрана и различите језике, програмери могу направити више верзија истог ресурса које се користе у зависности од уређаја и језика.
Али у АПК-у, сви ти ресурси постоје, без обзира на то који користите. И заузимају простор. У зависности од сложености ваше апликације, може бити много неискоришћених ресурса за много уређаја. То је оно што су Апп Бундле-ови направљени да реше. Програмери могу да генеришу Апп Бундле баш као АПК, а тај Апп Бундле затим може да се отпреми у Плаи продавницу, баш као што АПК може.
Гоогле затим користи тај Апп Бундле да генерише читав низ различитих АПК-ова за различите конфигурације уређаја. Сваки Апп Бундле садржи само ресурсе потребне за ту конфигурацију. Када корисник оде да преузме ту апликацију, сервира му се генерисани АПК који одговара њиховој конфигурацији. Ово помаже да се смањи величина преузимања и инсталирања апликација, штедећи пропусни опсег и простор за складиштење.
Наравно, инсталирање АПК-а специфичног за ваш уређај значи да вам је теже да га једноставно копирате на други уређај и инсталирате без проблема. У зависности од ваше перспективе, ово може бити добра или лоша ствар. С једне стране, то отежава пиратерију, пошто корисници више немају целу апликацију. С друге стране, то отежава легитимно архивирање апликација из истог разлога.
Потписивање апликација
Пошто Андроид Апп Бундле-ови нису АПК-ови, не можете једноставно отворити ААБ датотеку и инсталирати је директно на уређај. Када отпремите једну у Плаи продавницу, Гоогле користи пакет да генерише различите (непотписане) АПК датотеке. Ти АПК-ови тада морају бити потписани пре него што се могу инсталирати.
Уместо да тражи од програмера да потпише и поново отпреми те генерисане АПК-ове, Гоогле управља самим потписивањем. Плаи продавница или користи нови кључ који креира или тражи од програмера кључ који користе за потписивање АПК-ови. Са било којом опцијом, Гоогле управља јавним потписивањем за програмера и обезбеђује отпремање кључ. Гоогле користи кључ за отпремање за интерну верификацију и осигурава да је Апп Бундле (или АПК у неким случајевима) који програмер отпрема прави.
Ако је кључ за отпремање угрожен или изгубљен, програмери могу да затраже нови, а кључ за потписивање који се користи за дистрибуцију апликације остаје непромењен.
Потписивање апликација има још много тога, али ово је оно што је релевантно за овај чланак. Ако желите, можете прочитати више о пакетима апликација и пријављивању апликација овај Медиум чланак Војтека Калицинског.
Критика
У теорији и пракси, пакети апликација су прилично сјајни. Они смањују употребу података и величину инсталације, а све то без потребе да корисник било шта ради. Али због начина на који се имплементира, неки програмери и истраживачи безбедности у последњих неколико месеци су изразили забринутост. Пре него што сумирам ове забринутости, желим да одвојим тренутак да кажем да је већина онога што је написано у наставку директно на основу серије чланака од програмера Марка Марфија од ЦоммонсВаре. Апсолутно би требало да погледате његове чланке, јер они пружају више детаља и критика из перспективе програмера.
Безбедност
У класичном моделу дистрибуције, програмер држи кључ који користи за потписивање АПК-а приватним. Никада се не дели јавности и само овлашћени људи треба да му имају приступ. Ово осигурава да само ти људи могу да генеришу важећи АПК.
Али ако користите Апп Бундле у Плаи продавници, Гоогле је тај који управља кључем који потписује АПК-ове које корисници добијају. Тхе Уобичајено понашање за нове апликације отпремљене на Гоогле Плаи почев од августа 2021 је да Гоогле креира сопствени кључ за дистрибуцију који чува приватно од програмера.
Програмери се шаљу нове апликације ће Гоогле подразумевано управљати њиховим приватним кључем за њих, иако програмери шаљу ажурирања на постојеће апликације може да настави да користи АПК-ове или могу да пређу на ААБ дистрибуцију генерисањем новог кључа који ће Гоогле користити за нове кориснике. Постојеће апликације нису обавезни да пређу са дистрибуције АПК-а на Андроид Апп Бундле-е, иако им је та опција доступна ако одаберу. После извесног одбијања, Гоогле чак ће то и омогућити да отпремите свој приватни кључ за Гоогле за потписивање, и за нове и за постојеће апликације. Ниједна од ових ситуација није идеална, јер без обзира на све, Гоогле ће имати приступ вашем приватном кључу ако то желите користите Андроид Апп Бундле (а програмери немају избора ако желе да пошаљу нову апликацију после августа 2021!)
Иако смо уверени да Гоогле безбедност схвата веома озбиљно, не постоји ниједна компанија на Земљи која је имуна на кршење података. Ако је кључ који Гоогле користи за потписивање ваше апликације за дистрибуцију у једној од тих повреда, онда свако може да потпише верзију ваше апликације и учини да изгледа као да сте је потписали ви. Неки програмери и стручњаци за безбедност нису задовољни овом могућношћу. То је врло, веома мала могућност, да, али чињеница да је то могућност уопште плаши неке у инфосец заједници.
Ако програмери потпишу Андроид АПК-ове значи да свако може да верификује АПК-ове са Гоогле Плаи-а, слепо поверење није потребно. То је елегантан дизајн који пружа проверљиву сигурност. Пакети апликација окрећу то наопако и изгледа да су структурирани да промовишу закључавање добављача. Постоји много алтернативних техничких приступа који би обезбедили мале АПК-ове које још увек потписују програмери, али они не би преферирали Плаи. На пример, програмер може да генерише и потпише све варијанте АПК-а, а затим да их отпреми у било коју продавницу апликација.
Сигурно постоје аргументи о томе да ли је боље препустити безбедно складиштење приватних кључева у руке Гоогле-а или појединачних програмера. Али ти програмери (вероватно) обично не користе централно спремиште за своје кључеве. Приморавајући програмере да користе потписивање Плаи апликација, злонамерни нападач треба само једном да пробије Гоогле-ову безбедност да би преузео хиљаде или милионе кључева.
Колико вреди, ево шта Гоогле каже о томе како штити ваш кључ за потписивање на својој инфраструктури:
[блоцккуоте аутхор="Војтек Калицински, Андроид Девелопер Адвоцате ат Гоогле"]Када користите потписивање Плаи апликација, ваши кључеви се чувају на истој инфраструктури коју Гоогле користи за складиштење сопствених кључева.
Кључни приступ је регулисан стриктним АЦЛ-овима и контролним траговима који су евидентни због неовлашћења за све операције.
Сви артефакти генерисани и потписани кључем програмера доступни су вам у Гоогле Плаи конзоли за преглед/потврђивање.
Штавише, да бисмо спречили губитак кључа, врло често правимо резервне копије нашег примарног складишта. Ове резервне копије су снажно шифроване и ми редовно тестирамо враћање из ових резервних копија.
Ако желите да сазнате више о Гоогле техничкој инфраструктури, прочитајте Гоогле Цлоуд Сецурити Вхитепаперс.[/блоцккуоте]
Колико год то било сјајно, губитак и крађа су и даље могући. А ревизорски трагови само помажу у спречавању будућих напада; неће добити назад покварене кључеве.
Потенцијал за неовлашћене модификације
Један велики проблем у вези са начином на који је Гоогле поставио пакете апликација је могућност додавања неовлашћених модификација у апликацију. Процес издвајања АПК-ова из Апп Бундле-а инхерентно укључује модификације, пошто Гоогле мора ручно да направи сваки АПК. Док Гугл је обећао да неће и да неће убацивати или мењати код, проблем са процесом Апп Бундле-а је у томе што он има моћ да то уради.
Ево неколико примера шта компанија на позицији Гугла има моћ да уради:
Рецимо да постоји безбедна апликација за размену порука коју људи користе за комуникацију без ризика од владиног надзора. Ово би могло бити невероватно корисно средство за људе који протестују против ауторитарне владе, или чак за људе који само желе да задрже своју приватност. Та влада, желећи могућност да види шта корисници апликације говоре, могла би да покуша да примора Гугл да дода бекдор за надзор у код апликације.
Овај пример је мало безазленији, али је и нешто што забрињава неке људе. Рецимо да постоји апликација која добија милионе преузимања дневно, али у њој нема огласа или аналитике. То је огроман извор података без начина да се приступи тим подацима. Гоогле, као компанија за оглашавање, можда жели да приступи тим подацима.
У класичном АПК моделу дистрибуције апликација, Гоогле не може да мења апликације без промене потписа. Ако Гоогле промени потпис, посебно на популарној апликацији, људи ће приметити јер се ажурирање неће инсталирати. Али са пакетима апликација и потписивањем апликација, Гоогле би могао тихо да убаци сопствени код у апликације пре него што их дистрибуира. Потпис се не би променио јер би Гоогле поседовао кључ за потписивање.
Да се разумемо, мало је вероватно да ће се ови примери десити. Гугл тежи једноставном потпуно повући са проблематичних тржишта, а не прилагођавати се. Али иако је мало вероватно, ипак је могуће. Само зато што компанија обећава да се нешто неће догодити, то не гарантује.
Транспарентност кода
Гоогле је, чувши ове забринутости, ове недеље представио нову функцију под називом Транспарентност кода за скупове апликација. Транспарентност кода омогућава програмеру да у суштини креира други потпис који се корисницима испоручује са апликацијом. Овај додатни потпис треба да буде креиран из засебног приватног кључа коме само програмер има приступ. Међутим, постоје нека ограничења за овај метод.
Транспарентност кода покрива само код. То може изгледати очигледно с обзиром на име, али то такође значи да не дозвољава корисницима да верификују ресурсе, манифест или било шта друго што није ДЕКС датотека или матична библиотека. Иако злонамерне модификације датотека које нису кодиране обично имају много мањи утицај, то је још увек рупа у безбедности апликације.
Још један проблем са транспарентношћу кода је да не постоји инхерентна верификација. За један, то је опциона функција, тако да програмери морају да упамте да га укључе за сваки нови АПК који отпреме. Тренутно то мора да се уради из командне линије и са верзијом bundletool то не долази уз Андроид Студио. Чак и када га програмер укључи, Андроид нема уграђену никакву врсту верификације да провери да ли манифест транспарентности кода одговара коду у апликацији.
На крајњем кориснику је да сам провери упоређивањем манифеста са јавним кључем који програмер може да обезбеди или слањем АПК програмеру на верификацију.
Иако Транспарентност кода омогућава потврду да ниједан код у апликацији није измењен, не укључује никакву врсту верификације за друге делове апликације. Такође нема инхерентног поверења у процес. Могли бисте да тврдите да ако не верујете Гоогле-у, вероватно сте спремни за независну верификацију, али зашто бисте то морали?
Постоје и други проблеми са функцијом Транспарентност кода, као истакао од Марка Марфија из ЦоммонсВаре. Препоручујем да прочитате његов чланак за детаљнију анализу ове функције.
Погодност и избор програмера
Трећи (и последњи за овај чланак) разлог зашто неки програмери имају проблема са скуповима апликација је смањена погодност и избор.
Ако програмер направи нову апликацију у Плаи продавници након што Гоогле почне да захтева пакете апликација и они изаберу подразумевана опција омогућавања Гоогле-у да управља кључем за потписивање, они никада неће имати приступ том потписивању кључ. Ако тај исти програмер тада жели да дистрибуира ту апликацију у другој продавници апликација, мораће да користи сопствени кључ, који се неће подударати са Гоогле-овим.
То значи да ће корисници морати да инсталирају и ажурирају са Гоогле Плаи-а или из извора треће стране. Ако желе да промене извор, морају потпуно да деинсталирају апликацију, потенцијално губећи податке, и поново инсталирају. АПК агрегатори воле АПКМиррор тада ће такође морати да ради са више званичних потписа за исту апликацију. (Технички, они то већ морају да ураде јер вам потписивање апликација омогућава да креирате нови, безбеднији кључ за нове кориснике, али биће горе за њих и друге сајтове када сви има урадити то.)
Гоогле-ов одговор на овај проблем је да користи истраживач скупова апликација или истраживач артефаката у Плаи конзоли да преузме резултујуће АПК-ове из отпремљеног скупа. Слично Транспарентности кода, ово није потпуно решење. АПК-ови преузети са Плаи конзоле биће подељени за различите профиле уређаја. Иако Плаи конзола подржава отпремање више АПК-ова за једну верзију једне апликације, многи други канали дистрибуције не подржавају.
Дакле, многе предности коришћења Апп Бундле-а нестају када програмери управљају више продавница, што отежава дистрибуцију. Уз вест да Виндовс 11 је добијање подршке за Андроид апликацију захваљујући Амазон Аппсторе-у, неки верују да ће захтев за пакете апликација дестимулисати програмере да дистрибуирају на Амазону. Наравно, Гоогле-ова примарна брига је сопствена продавница апликација, али то је управо оно што спустио их у топлу воду са конкурентима водећи их да направе мале, помирљиве промене како продавнице апликација независних произвођача раде на Андроид-у.
Неколико проблема везаних за више продавница су међусобна повезаност апликација и брзо тестирање.
Почнимо од међусобног повезивања апликација. Да ли сте икада преузели апликацију која закључава функције иза паивалл-а? Готово дефинитивно. Неки програмери стављају функције иза куповине у апликацији, али други могу изабрати да направе засебну, плаћену апликацију. Када се тај додатак инсталира, функције главне апликације се откључавају.
Али шта спречава некога да само инсталира додатак из пиратског извора? Па, постоји много опција за програмере, али барем једна укључује коришћење дозвола заштићених потписом. Рецимо да главна апликација декларише дозволу заштићену потписом. Додатна апликација затим изјављује да жели да користи ту дозволу. У идеалном случају, додатна апликација ће такође имати неку врсту функције верификације лиценце, која се повезује на интернет како би се уверила да је корисник легитиман.
Ако обе апликације имају исти потпис, Андроид ће доделити дозволу додатној апликацији и провере заштите од пиратерије ће проћи. Ако додатна апликација нема одговарајући потпис, дозвола неће бити дата и верификација неће успети.
Са класичним моделом дистрибуције АПК-а, корисник може да добије било коју апликацију из било ког легитимног извора и да заврши са њом. Са тренутним подразумеваним моделом Апп Бундле-а, потписи на главној и додатним апликацијама се неће подударати. Гоогле ће направити јединствени кључ за сваку апликацију. Програмер би увек могао да укине дозволу заштићену потписом и користи директну хеш верификацију потписа, али то је много мање безбедно.
А онда је тестирање брзом паљбом. Корисници стално шаљу е-поруке програмерима о проблемима у њиховим апликацијама. Понекад су ти проблеми једноставна решења: репродукујте проблем, пронађите проблем, поправите га и отпремите нову верзију. Али понекад нису. Понекад програмери не могу да репродукују проблем. Они могу да поправе оно што мисле да је проблем, али онда корисник то мора да тестира. Сада претпоставите да је корисник инсталирао апликацију преко Гоогле Плаи-а.
Са АПК моделом, програмер може да промени неки код, направи и потпише нови АПК и пошаље га кориснику на тестирање. Пошто се потпис тестног АПК-а поклапа са оним који је корисник инсталирао, једноставан је процес за ажурирање, тестирање и извештавање. Са пакетима апликација, ово се распада. Пошто Гоогле потписује АПК који је корисник првобитно инсталирао, он се неће подударати са потписом АПК-а који програмер шаље. Ако се ова апликација објави након истека рока за пакете апликација, програмер чак неће имати приступ кључним Гоогле-овим функцијама. Да би тестирао, корисник би морао да деинсталира тренутну апликацију пре инсталирања тест верзије.
Овде постоји гомила проблема. Прво, постоји непријатност, како на страни програмера тако и на страни корисника. Деинсталирање апликације само да бисте тестирали исправку није забавно. А шта ако проблем нестане? Да ли су то биле промене које је програмер направио или зато што је корисник ефикасно обрисао податке апликације? Плаи продавница има интерно тестирање, које би требало да омогући програмерима да раде брзе градње и дистрибуцију, али захтева од корисника да прво деинсталира верзију издања. То заправо ништа не поправља.
У случају да све ово звучи као гомила хипотетичких глупости, ево стварног примера програмера који ће имати ове проблеме ако допусти Гуглу да генерише приватни кључ за њих: Јоао Диас. Он је програмер Таскера, заједно са читавом гомилом додатних апликација, укључујући и АутоАппс пакет. Са новим захтевом за пакете апликација, Јоаов развојни циклус може постати много тежи, барем за нове апликације. Директно слање верзија за тестирање биће мање згодно. Верификација лиценци ће бити мање ефикасна.
Ово може звучати као ивични случај, али није да је Јоао неки мали програмер и вероватно није сам. У Плаи продавници постоји много апликација које се ослањају на верификацију потписа да би откриле нелегитимне кориснике.
Наравно, са новом опцијом за програмере да отпреме сопствене кључеве за потписивање на Гоогле, ови проблеми су бар донекле ублажени. Али програмери морају да се укључе да би омогућили опцију за сваку апликацију. Ако то не ураде, интерконекције неће успети и брза подршка ће захтевати отпремање пакета на Гоогле и чекање да се АПК-ови генеришу, пре него што се пошаље исправан кориснику. Осим тога, то и даље значи да морају да деле свој приватни кључ, што нас враћа на забринутост о којој смо раније разговарали.
Решења
Ово је старо питање с обзиром да су захтеви Апп Бундле-а објављени пре неколико месеци, тако да је у међувремену предложено доста решења.
Једно решење је избегавање потребе за потписивањем Плаи апликација. Уместо да генерише Апп Бундле који Гоогле затим обрађује у АПК-ове и знакове, ту обраду би могао да обави Андроид Студио. Затим, програмери могу само да отпреме ЗИП пун локално потписаних АПК-ова за сваку конфигурацију коју би Гоогле генерисао.
Са тим решењем, Гоогле-у уопште не би био потребан приступ кључевима програмера. Процес би био веома сличан класичном моделу дистрибуције АПК-а, али би укључивао више, мањих АПК-ова уместо само једног.
Друго решење је да једноставно не захтевате коришћење Апп Бундле-а и да наставите да дозвољавате програмерима да отпремају локално потписане АПК-ове. Док пакети апликација могу бити боље искуство за корисника у многим случајевима, неке апликације заправо немају користи од тога да буду подељене по конфигурацији, са минималном величином смањење.
Ако је Гоогле имплементирао оба ова решења, програмер који жели да користи Апп Бундле неће морати да преко потписивања на Гоогле, а програмер чија апликација неће имати много користи од формата неће морати да је користи на све.
Гоогле-ови одговори
Самопотписивање
Када су их први пут питали да дозволе програмерима да руководе потписивањем за Апп Бундлеове, Гоогле-ов одговор је био веома необавезујући:
[блоцккуоте аутхор=""]Дакле, укратко сам говорио о захтеву следеће године за нове апликације да користе скупове апликација, а једна ствар која долази са тим је да ће нам као проширење бити потребно потписивање Плаи апликација. Дакле, програмери ће морати или да генеришу кључ за потписивање апликације на Плаи-у или да отпреме сопствени кључ на Плаи... јер је то предуслов за скупове апликација. Чули смо од програмера да неки од њих једноставно не желе то да ураде. Не желе да им Плаи управља кључевима. А тренутно то није могуће ако желите да користите скупове апликација.
Али, чули смо ту повратну информацију и... Не могу тренутно ни о чему да причам, немамо шта да објавимо, али тражимо како бисмо могли да ублажимо неке од ових забринутости. Не мора нужно да дозвољава да задржите сопствени кључ док отпремате пакете. Тражимо различите опције. Једноставно тренутно немамо решење да објавимо. Али, имамо још око годину дана до захтева, тако да се заиста надам да ћемо имати одговор за програмере за ово.[/блоцккуоте]
То је било крајем новембра прошле године, а изгледа да се ништа није догодило. Остало је само неколико месеци до Захтеви за скупове апликација ступају на снагу, још увек не постоји начин да програмери управљају потписивањем сопствених апликација. Док је Гоогле сада омогућио да отпремити ваш сопствени кључ за нове и постојеће апликације, ово и даље преузима део потписивања из руку програмера.
Промене кода
Иако је Гоогле изричито обећао да Плаи продавница неће мењати код апликације, обећање није гаранција. Уз пакете апликација и потписивање апликација, не постоји техничко ограничење за које знамо да спречава Гоогле да измени отпремљене апликације пре дистрибуције.
Гоогле је представио Транспарентност кода као опциона функција, и иако ово донекле помаже, има доста проблема, као што смо раније расправљали.
Селф-Маде Бундлес
Када је Гоогле упитан да дозволи програмерима да праве сопствене „скупове“ апликација (ЗИП-ови који садрже подељене АПК-ове), одговор је у суштини био „нећемо то да радимо“:
Вероватно не као што је описано у питању, јер би то додатно отежало процес објављивања програмерима, а ми заправо желимо да га учинимо једноставнијим и сигурнијим. Међутим, опет смо чули ове повратне информације и тражићемо опције како да то омогућимо, али вероватно не на начин који је овде описан.
Занимљиво, чини се да је Гугл оправдање да би то учинило објављивање компликованијим. Међутим, Гоогле би и даље могао да аутоматизује процес као део дијалога за генерисање АПК-а у Андроид студију. Штавише, ако се дотична апликација дистрибуира у више продавница, то би заправо учинило процес објављивања је једноставнији, јер програмери не би морали да управљају вишеструким кључевима за потписивање и жалбама корисника.
А са увођењем транспарентности кода, чини се да компликација ипак није проблем. Транспарентност кода, барем за сада, захтева од програмера да користи алатку командне линије и да корисници експлицитно верификују валидност апликације коју користе. Ово је компликованије од процеса самосталног прављења пакета и није јасно зашто је ово решење које Гоогле преферира.
Иде напред
Пакети апликација ће бити обавезан формат дистрибуције за нове апликације послате на Гоогле Плаи од 1. августа. Иако је Гоогле бар донекле решио већину питања која су покренули програмери и стручњаци за безбедност, одговори остављају много да се пожеле. Постоје многе очигледне предности Апп Бундле-а као формата за дистрибуцију следеће генерације, али увек ће постојати забринутост око давања делимичне или потпуне контроле над потписивањем апликација Гоогле-у.
Гоогле-ови одговори и напори су свакако цењени, али неки, попут Марка Марфија, сматрају да нису отишли довољно далеко. Пошто решења као што су пакети који су сами направили нису имплементирани и рок за Андроид Апп Бундле је потребан брзо приближава се, не изгледа да ће програмери на Гоогле Плаи-у моћи дуго да задрже потпуну контролу над својим апликацијама дуже.
Причаћемо о импликацијама захтева Андроид Апп Бундле-а у Твиттер простору касније поподне, па нам се придружите!