Google Play wkrótce zmusi programistów do przesyłania pakietów aplikacji zamiast plików APK, co rodzi niewygodne pytania dotyczące bezpieczeństwa dotyczące tego wymogu.
Ostatni listopad, Google ogłosiło że programiści będą musieli publikować nowe aplikacje w Sklepie Play w formacie pakietu Android App Bundle (AAB) zamiast pliku APK. Któregoś dnia Google przypomniał programistom o tym nadchodzącym wymogu, wywołując burzę kontrowersji od użytkowników, którzy uważają, że Google niszczy pliki APK, eliminując sideloading i utrudniając działanie zewnętrznych sklepów z aplikacjami oraz etażerka.
To prawda, że pakiety aplikacji na Androida znacznie odbiegają od klasycznego formatu pliku APK, do którego możesz być przyzwyczajony zarówno jako użytkownik, jak i programista. Chociaż korzystanie z pakietów aplikacji ma wiele zalet, istnieje jeden kluczowy aspekt ich tworzenia, który słusznie niepokoi niektórych programistów i ekspertów ds. bezpieczeństwa.
W tym artykule omówimy krytykę przejścia na pakiety aplikacji na Androida, a także niektóre proponowane rozwiązania, a także omówimy proponowane przez Google rozwiązanie tych problemów.
Tło
Zanim to jednak nastąpi, musimy porozmawiać trochę o tym, jak ogólnie działa dystrybucja aplikacji na Androidzie. Jeśli wiesz już, jak działa podpisywanie aplikacji i pakiety aplikacji, możesz pominąć tę część.
APK
W większości aplikacje na Androida są dystrybuowane w plikach APK. Plik APK zawiera cały kod i zasoby aplikacji, a także niektóre funkcje zabezpieczeń, takie jak manifest podpisywania. Po zainstalowaniu pakietu APK jest on po prostu kopiowany do określonego folderu i dodawany do wewnętrznej bazy danych zainstalowanych aplikacji.
Podpisy
Podczas instalacji podpis tej aplikacji jest również weryfikowany, aby upewnić się, że jest prawidłowy. Jeśli aplikacja jest już zainstalowana, Android sprawdza podpis nowej aplikacji z podpisem już zainstalowanym. Jeśli podpis jest nieprawidłowy lub nie pasuje, Android odmówi zainstalowania aplikacji.
Sprawdzanie podpisów jest ważną częścią bezpieczeństwa systemu Android. Daje pewność, że instalowana aplikacja jest ważna i pochodzi przynajmniej z tego samego źródła, co ta, którą już zainstalowałeś. Na przykład, jeśli zainstalujesz, powiedzmy, moja aplikacja Lockscreen Widgets ze Sklepu Play, możesz być pewien, że to ja go podpisałem i że jest on autentyczny. Jeśli następnie spróbujesz zainstalować aktualizację Lockscreen Widgets z jakiejś podejrzanej witryny strony trzeciej i zakończy się to niepowodzeniem, będziesz wiedzieć, że ktoś majstrował przy tym pliku APK, prawdopodobnie w celu dodania złośliwego oprogramowania.
Klucz używany do podpisywania aplikacji to (idealnie) nigdy publicznie wydany. Nazywa się to kluczem prywatnym. Klucz prywatny jest następnie używany do generowania klucza widocznego w podpisie aplikacji, zwanego kluczem publicznym. W ten sposób sklepy z Androidem i aplikacjami sprawdzają ważność aplikacji. Nie będę wnikał w to, jak dokładnie można wygenerować klucz publiczny bez ujawniania klucza prywatnego, ponieważ wiąże się to z dużą ilością operacji matematycznych związanych z szyfrowaniem. Jeśli chcesz więcej szczegółów, sprawdź Dokumentacja Google dotycząca podpisywania plików APK lub przeprowadź badania dotyczące jednokierunkowych funkcji matematycznych.
Inną funkcją podpisów aplikacji jest możliwość ograniczenia uprawnień tylko do aplikacji z pasującymi podpisami. Android robi to wewnętrznie w przypadku wielu funkcji, w przypadku których tylko aplikacje podpisane tym samym kluczem co framework mogą uzyskać dostęp do niektórych funkcji.
Pakiety aplikacji
Skoro już omówiliśmy pliki APK i podpisy, porozmawiajmy o pakietach aplikacji. Tutaj pojawiają się zasoby APK. Zasoby to takie elementy, jak układy, obrazy, dźwięk itp. Zasadniczo jest to wszystko, co nie jest kodem. Aby lepiej obsługiwać różne konfiguracje wyświetlania i różne języki, programiści mogą tworzyć wiele wersji tego samego zasobu, używanych w zależności od urządzenia i języka.
Ale w pliku APK wszystkie te zasoby istnieją, niezależnie od tego, z którego korzystasz. I zajmują miejsce. W zależności od złożoności aplikacji może istnieć wiele niewykorzystanych zasobów na wielu urządzeniach. Właśnie po to stworzono pakiety aplikacji, aby rozwiązać ten problem. Programiści mogą wygenerować pakiet aplikacji podobnie jak plik APK, a następnie przesłać ten pakiet aplikacji do Sklepu Play, tak samo jak plik APK.
Następnie Google używa tego pakietu aplikacji do generowania całej gamy różnych plików APK dla różnych konfiguracji urządzeń. Każdy pakiet aplikacji zawiera tylko zasoby potrzebne do tej konfiguracji. Gdy użytkownik pobiera tę aplikację, wyświetlany jest wygenerowany plik APK pasujący do jego konfiguracji. Pomaga to zmniejszyć rozmiar pobieranych i instalowanych aplikacji, oszczędzając przepustowość i miejsce na dysku.
Oczywiście zainstalowanie pakietu APK specyficznego dla Twojego urządzenia oznacza, że trudniej będzie go po prostu skopiować na inne urządzenie i zainstalować bez problemu. W zależności od punktu widzenia może to być dobra lub zła rzecz. Z jednej strony utrudnia to piractwo, ponieważ użytkownicy nie mają już całej aplikacji. Z drugiej strony, z tego samego powodu utrudnia to legalne archiwizowanie aplikacji.
Podpisywanie aplikacji
Ponieważ pakiety aplikacji na Androida nie są plikami APK, nie można po prostu otworzyć pliku AAB i zainstalować go bezpośrednio na urządzeniu. Gdy przesyłasz go do Sklepu Play, Google używa pakietu do generowania różnych (niepodpisanych) plików APK. Te pliki APK muszą następnie zostać podpisane, zanim będzie można je zainstalować.
Zamiast prosić programistę o podpisanie i ponowne przesłanie wygenerowanych plików APK, Google samodzielnie zarządza podpisywaniem. Sklep Play albo używa nowego, utworzonego przez siebie klucza, albo prosi programistę o klucz, którego używa do podpisania APK. W przypadku obu opcji Google zajmuje się publicznym podpisywaniem programisty i udostępnia przesyłanie klucz. Google używa klucza przesyłania do wewnętrznej weryfikacji i sprawdza, czy pakiet aplikacji (lub w niektórych przypadkach plik APK), który programista przesyła, jest właściwy.
Jeśli klucz przesyłania zostanie naruszony lub utracony, programiści mogą poprosić o nowy, a klucz podpisywania używany do dystrybucji aplikacji pozostaje niezmieniony.
Podpisywanie aplikacji to znacznie więcej, ale to właśnie dotyczy tego artykułu. Jeśli chcesz, możesz przeczytać więcej o pakietach aplikacji i logowaniu się do aplikacji ten artykuł na Medium autorstwa Wojtka Kalicińskiego.
Krytyka
W teorii i praktyce pakiety aplikacji są całkiem niezłe. Zmniejszają zużycie danych i rozmiar instalacji, a wszystko to bez konieczności wykonywania jakichkolwiek czynności przez użytkownika. Jednak ze względu na sposób jego wdrożenia niektórzy programiści i badacze bezpieczeństwa wyrazili w ciągu ostatnich kilku miesięcy obawy. Zanim podsumuję te obawy, chcę poświęcić chwilę i powiedzieć, że większość tego, co napisano poniżej, dotyczy bezpośrednio na podstawie szeregu artykułów przez dewelopera Marka Murphy'ego z CommonsWare. Powinieneś koniecznie sprawdzić jego artykuły, ponieważ zawierają więcej szczegółów i uwag krytycznych z punktu widzenia programisty.
Bezpieczeństwo
W klasycznym modelu dystrybucji programista przechowuje klucz, którego używa do podpisywania pliku APK jako prywatny. Nigdy nie są one udostępniane publicznie i tylko upoważnione osoby powinny mieć do nich dostęp. Dzięki temu tylko te osoby będą mogły wygenerować prawidłowy plik APK.
Jeśli jednak korzystasz z pakietów aplikacji w Sklepie Play, Google zarządza kluczem podpisującym pliki APK otrzymywane przez użytkowników. The domyślny zachowanie nowych aplikacji przesłanych do Google Play od sierpnia 2021 r zadaniem Google jest utworzenie własnego klucza dystrybucyjnego, który przechowuje w tajemnicy przed programistą.
Deweloperzy przesyłają nowe aplikacje domyślnie Google będzie zarządzać dla nich kluczem prywatnym, chociaż programiści przesyłają aktualizacje do istniejące aplikacje możesz nadal korzystać z plików APK Lub mogą przejść na dystrybucję AAB, generując nowy klucz, którego Google będzie mógł używać dla nowych użytkowników. Istniejące aplikacje nie są wymagane aby przejść z dystrybucji plików APK na pakiety aplikacji na Androida, chociaż ta opcja jest dla nich dostępna, jeśli tak zdecydują. Po pewnym sprzeciwie Google nawet to umożliwi aby przesłać do Google własny klucz prywatny, za pomocą którego będzie mógł się podpisywać, zarówno w przypadku nowych, jak i istniejących aplikacji. Żadna z tych sytuacji nie jest idealna, ponieważ bez względu na wszystko Google będzie mieć dostęp do Twojego klucza prywatnego, jeśli chcesz korzystaj z pakietów aplikacji na Androida (a programiści nie mają w tej kwestii wyboru, jeśli chcą przesłać nową aplikację po sierpniu). 2021!)
Choć mamy pewność, że Google bardzo poważnie podchodzi do bezpieczeństwa, nie ma na świecie firmy, która byłaby odporna na naruszenia bezpieczeństwa danych. Jeśli klucz, którego Google używa do podpisywania Twojej aplikacji do dystrybucji, podlega jednemu z tych naruszeń, każdy może podpisać wersję Twojej aplikacji i sprawić, by wyglądała tak, jakby była podpisana przez Ciebie. Niektórzy programiści i eksperci ds. bezpieczeństwa nie są zadowoleni z tej możliwości. To prawda, bardzo nikła możliwość, ale fakt, że w ogóle istnieje, przeraża niektórych członków społeczności informatycznej.
Dzięki podpisaniu przez programistów plików APK na Androida każdy może zweryfikować pliki APK z Google Play i nie jest wymagane ślepe zaufanie. Jest to elegancki projekt zapewniający weryfikowalne bezpieczeństwo. Pakiety aplikacji wywracają tę sytuację do góry nogami i wydają się mieć strukturę sprzyjającą uzależnieniu od dostawców. Istnieje wiele alternatywnych podejść technicznych, które zapewniłyby małe pliki APK podpisane przez programistów, ale nie preferowałyby one Play. Na przykład wszystkie warianty pakietu APK mogą zostać wygenerowane i podpisane przez programistę, a następnie przesłane do dowolnego sklepu z aplikacjami.
Z pewnością istnieją argumenty na temat tego, czy lepiej pozostawić bezpieczne przechowywanie kluczy prywatnych w rękach Google lub indywidualnych programistów. Ale ci programiści (prawdopodobnie) zwykle nie korzystają z centralnego repozytorium dla swoich kluczy. Zmuszając programistów do korzystania z podpisywania aplikacji przez Google Play, złośliwemu atakującemu wystarczy raz złamać zabezpieczenia Google, aby odzyskać tysiące lub miliony kluczy.
Oto, co Google mówi o tym, jak chroni Twój klucz podpisywania w swojej infrastrukturze:
[blockquoteauthor="Wojtek Kaliciński, rzecznik programistów Androida w Google"]Gdy korzystasz z funkcji podpisywania aplikacji przez Play, Twoje klucze są przechowywane w tej samej infrastrukturze, której Google używa do przechowywania własnych kluczy.
Dostęp do kluczy jest regulowany przez rygorystyczne listy ACL i ścieżki audytu zabezpieczające przed manipulacją dla wszystkich operacji.
Wszystkie artefakty wygenerowane i podpisane kluczem programisty są udostępniane w Konsoli Google Play do kontroli/atestacji.
Ponadto, aby zapobiec utracie kluczy, bardzo często wykonujemy kopie zapasowe naszej podstawowej pamięci masowej. Te kopie zapasowe są silnie zaszyfrowane i regularnie testujemy przywracanie z tych kopii zapasowych.
Jeśli chcesz poznać infrastrukturę techniczną Google, przeczytaj Dokumenty dotyczące bezpieczeństwa Google Cloud.[/zablokować cytat]
Mimo to wszystkie dźwięki, utrata i kradzież są nadal możliwe. Ścieżki audytu pomagają jedynie zapobiegać przyszłym atakom; nie odzyskają złamanych kluczy.
Możliwość nieautoryzowanych modyfikacji
Jednym z głównych problemów związanych ze sposobem, w jaki Google konfiguruje pakiety aplikacji, jest możliwość dodania do aplikacji nieautoryzowanych modyfikacji. Proces wyodrębniania plików APK z pakietu aplikacji nieodłącznie wiąże się z modyfikacjami, ponieważ Google musi ręcznie tworzyć każdy plik APK. Chwila Google obiecał, że tego nie robi i nie będzie wstrzykiwał ani modyfikował kodu, problem z procesem pakietu aplikacji polega na tym, że ma on taką możliwość.
Oto kilka przykładów tego, co firma na pozycji Google może zrobić:
Załóżmy, że istnieje bezpieczna aplikacja do przesyłania wiadomości, za pomocą której ludzie komunikują się bez ryzyka inwigilacji ze strony rządu. Może to być niezwykle przydatne narzędzie dla osób protestujących przeciwko autorytarnemu rządowi, a nawet dla osób, które po prostu chcą zachować swoją prywatność. Rząd ten, chcąc mieć możliwość sprawdzenia, co mówią użytkownicy aplikacji, mógłby spróbować zmusić Google do dodania backdoora monitorującego do kodu aplikacji.
Ten przykład jest nieco bardziej nieszkodliwy, ale dotyczy także niektórych osób. Załóżmy, że istnieje aplikacja, która jest pobierana miliony razy dziennie, ale nie zawiera żadnych reklam ani analiz. To ogromne źródło danych, do którego nie można uzyskać dostępu. Google, jako firma reklamowa, może chcieć uzyskać dostęp do tych danych.
W klasycznym modelu dystrybucji aplikacji APK Google nie może modyfikować aplikacji bez zmiany podpisu. Jeśli Google zmieni podpis, zwłaszcza w popularnej aplikacji, ludzie to zauważą, ponieważ aktualizacja nie zostanie zainstalowana. Jednak dzięki pakietom aplikacji i podpisywania aplikacji Google może po cichu wstrzykiwać własny kod do aplikacji przed ich dystrybucją. Podpis nie uległby zmianie, ponieważ Google byłby właścicielem klucza podpisującego.
Żeby było jasne, te przykłady są niezwykle mało prawdopodobne. Google ma tendencję do prostoty całkowicie wycofać się z kłopotliwych rynków, zamiast się przystosować. Ale choć jest to mało prawdopodobne, jest to nadal możliwe. To, że firma obiecuje, że coś się nie stanie, nie gwarantuje tego.
Przejrzystość kodu
Google, słysząc te obawy, wprowadził w tym tygodniu nową funkcję o nazwie Przejrzystość kodu dla pakietów aplikacji. Przejrzystość kodu umożliwia programiście zasadniczo utworzenie drugiego podpisu, który jest dostarczany użytkownikom wraz z aplikacją. Ten dodatkowy podpis należy utworzyć z osobnego klucza prywatnego, do którego dostęp ma tylko programista. Istnieją jednak pewne ograniczenia tej metody.
Przejrzystość kodu dotyczy tylko kodu. Może się to wydawać oczywiste, biorąc pod uwagę nazwę, ale oznacza to również, że nie pozwala użytkownikom weryfikować zasobów, manifestu ani niczego innego, co nie jest plikiem DEX lub biblioteką natywną. Chociaż złośliwe modyfikacje plików niebędących kodem mają zwykle znacznie mniejszy wpływ, nadal stanowią lukę w bezpieczeństwie aplikacji.
Kolejnym problemem związanym z przejrzystością kodu jest brak nieodłącznej weryfikacji. Dla jednego to funkcja opcjonalna, więc programiści muszą pamiętać o dołączeniu go do każdego nowego przesyłanego pliku APK. W tej chwili należy to zrobić z wiersza poleceń i za pomocą wersji bundletool to nie jest dostępne w Android Studio. Nawet jeśli programista dołączy tę opcję, system Android nie ma wbudowanej żadnej funkcji weryfikacji, która pozwalałaby sprawdzić, czy manifest przejrzystości kodu pasuje do kodu w aplikacji.
Do użytkownika końcowego należy sprawdzenie tego samodzielnie, porównując manifest z kluczem publicznym, który może dostarczyć programista, lub wysyłając plik APK do programisty w celu weryfikacji.
Chociaż przejrzystość kodu umożliwia potwierdzenie, że żaden kod w aplikacji nie został zmodyfikowany, nie obejmuje żadnej weryfikacji innych części aplikacji. W tym procesie nie ma również nieodłącznego zaufania. Można argumentować, że jeśli nie ufasz Google, prawdopodobnie stoisz przed zadaniem niezależnej weryfikacji, ale dlaczego miałbyś to robić?
Istnieją inne problemy z funkcją przejrzystości kodu, np wskazany autorstwa Marka Murphy'ego z CommonsWare. Polecam przeczytać jego artykuł, aby uzyskać bardziej dogłębną analizę tej funkcji.
Wygoda i wybór dla programistów
Trzecim (i ostatnim w tym artykule) powodem, dla którego niektórzy programiści kwestionują pakiety aplikacji, jest ograniczona wygoda i ograniczony wybór.
Jeśli programista utworzy nową aplikację w Sklepie Play po tym, jak Google zacznie wymagać pakietów aplikacji, i tak zdecyduje domyślną opcją pozwalającą Google zarządzać kluczem podpisującym, nigdy nie będą mieli dostępu do tego podpisu klucz. Jeśli ten sam programista będzie chciał następnie rozpowszechniać tę aplikację w innym sklepie z aplikacjami, będzie musiał użyć własnego klucza, który nie będzie pasował do klucza Google.
Oznacza to, że użytkownicy będą musieli albo instalować i aktualizować aplikacje z Google Play, albo ze źródeł zewnętrznych. Jeśli chcą zmienić źródło, muszą całkowicie odinstalować aplikację, co może spowodować utratę danych, i zainstalować ją ponownie. Agregatory APK takie jak APKMirror będzie wtedy musiał także poradzić sobie z wieloma oficjalnymi podpisami dla tej samej aplikacji. (Technicznie rzecz biorąc, już muszą to zrobić, ponieważ podpisywanie aplikacji umożliwia utworzenie nowego, bezpieczniejszego klucza dla nowych użytkowników, ale będzie to gorsze dla nich i innych witryn, gdy wszyscy ma żeby to zrobić.)
Odpowiedzią Google na ten problem jest użycie eksploratora pakietów aplikacji lub eksploratora artefaktów w Konsoli Play w celu pobrania wynikowych plików APK z przesłanego pakietu. Podobnie jak w przypadku Code Transparency, nie jest to rozwiązanie kompletne. Pliki APK pobrane z Konsoli Play zostaną podzielone dla różnych profili urządzeń. Chociaż Konsola Play obsługuje przesyłanie wielu plików APK dla jednej wersji jednej aplikacji, wiele innych kanałów dystrybucji tego nie umożliwia.
Dlatego wiele korzyści płynących z korzystania z pakietów aplikacji znika, gdy programiści zarządzają wieloma sklepami, co utrudnia dystrybucję. Z tą wiadomością Windows 11 Jest uzyskanie wsparcia dla aplikacji na Androida niektórzy uważają, że dzięki Amazon Appstore wymóg dotyczący pakietów aplikacji zniechęci programistów do dystrybucji na Amazon. Oczywiście głównym zmartwieniem Google jest własny sklep z aplikacjami, ale właśnie o to chodzi wpakowali ich w gorącą wodę z konkurentami prowadząc ich do zrobienia drobne, ugodowe zmiany jak zewnętrzne sklepy z aplikacjami działają na Androidzie.
Kilka problemów związanych z wieloma sklepami to wzajemna łączność aplikacji i szybkie testowanie.
Zacznijmy od wzajemnych połączeń aplikacji. Czy kiedykolwiek pobrałeś aplikację, która blokuje funkcje za zaporą? Prawie na pewno. Niektórzy programiści udostępniają te funkcje za zakup w aplikacji, ale inni mogą zdecydować się na utworzenie osobnej, płatnej aplikacji. Po zainstalowaniu tej aplikacji dodatkowej funkcje aplikacji głównej zostaną odblokowane.
Ale co powstrzymuje kogoś przed zainstalowaniem dodatku z pirackiego źródła? Cóż, istnieje wiele opcji dla programistów, ale przynajmniej jedna wymaga korzystania z uprawnień chronionych podpisem. Załóżmy, że główna aplikacja deklaruje uprawnienia chronione podpisem. Następnie aplikacja dodatkowa deklaruje, że chce skorzystać z tego uprawnienia. Idealnie byłoby, gdyby aplikacja dodatkowa zawierała także funkcję weryfikacji licencji, która łączy się z Internetem, aby upewnić się, że użytkownik jest legalny.
Jeśli obie aplikacje mają ten sam podpis, system Android przyzna uprawnienia aplikacji dodatkowej, a kontrole ochrony przed piractwem zostaną pomyślnie zakończone. Jeśli aplikacja dodatkowa nie ma prawidłowego podpisu, uprawnienia nie zostaną przyznane, a weryfikacja zakończy się niepowodzeniem.
Dzięki klasycznemu modelowi dystrybucji plików APK użytkownik może pobrać dowolną aplikację z dowolnego legalnego źródła i mieć z tym spokój. W przypadku bieżącego domyślnego modelu pakietu aplikacji podpisy w aplikacji głównej i aplikacji dodatkowej nie będą zgodne. Google utworzy unikalny klucz dla każdej aplikacji. Programista może zawsze zrezygnować z uprawnień chronionych podpisem i zastosować bezpośrednią weryfikację skrótu podpisu, ale jest to o wiele mniej bezpieczne.
A potem są testy szybkiego ognia. Użytkownicy cały czas wysyłają e-maile do programistów w sprawie problemów w ich aplikacjach. Czasami te problemy to proste rozwiązania: odtwórz problem, znajdź problem, napraw go i prześlij nową wersję. Ale czasami tak nie jest. Czasami programiści nie mogą odtworzyć problemu. Mogą naprawić to, co ich zdaniem stanowi problem, ale użytkownik musi to przetestować. Załóżmy teraz, że użytkownik zainstalował aplikację za pośrednictwem Google Play.
Dzięki modelowi APK programista może zmienić część kodu, zbudować i podpisać nowy plik APK, a następnie wysłać go użytkownikowi do przetestowania. Ponieważ podpis testowego pliku APK odpowiada temu, który zainstalował użytkownik, aktualizacja, przetestowanie i złożenie raportu jest prostym procesem. W przypadku pakietów aplikacji to się rozpada. Ponieważ Google podpisuje pakiet APK pierwotnie zainstalowany przez użytkownika, nie będzie on zgodny z podpisem pakietu APK wysyłanego przez programistę. Jeśli ta aplikacja zostanie opublikowana po terminie określonym w pakietach aplikacji, programista nie będzie miał nawet dostępu do kluczowych elementów używanych przez Google. Aby przetestować, użytkownik musiałby odinstalować bieżącą aplikację przed zainstalowaniem wersji testowej.
Jest tu mnóstwo problemów. Po pierwsze, istnieją niedogodności, zarówno po stronie programisty, jak i użytkownika. Konieczność odinstalowania aplikacji tylko po to, aby przetestować poprawkę, nie jest zabawna. A co jeśli problem zniknie? Czy były to zmiany wprowadzone przez programistę, czy może dlatego, że użytkownik skutecznie wyczyścił dane aplikacji? W Sklepie Play dostępne są testy wewnętrzne, które mają umożliwiać programistom szybkie kompilacje i dystrybucję, ale wymagają od użytkownika najpierw odinstalowania wydanej wersji. To naprawdę niczego nie naprawia.
Na wypadek, gdyby to wszystko brzmiało jak hipotetyczny nonsens, oto bardzo realny przykład programisty, który będzie miał te problemy, jeśli pozwoli Google wygenerować dla siebie klucz prywatny: João Dias. Jest twórcą Taskera i całej gamy aplikacji wtyczek, w tym pakietu AutoApps. Dzięki nowym wymaganiom dotyczącym pakietów aplikacji cykl rozwoju João może stać się znacznie trudniejszy, przynajmniej w przypadku nowych aplikacji. Bezpośrednie wysyłanie wersji testowych będzie mniej wygodne. Weryfikacja licencji będzie mniej skuteczna.
Może to brzmieć jak przypadek skrajny, ale João nie jest jakimś małym programistą i prawdopodobnie nie jest sam. W Sklepie Play jest wiele aplikacji, które polegają na weryfikacji podpisu w celu wykrycia nielegalnych użytkowników.
Oczywiście dzięki nowej opcji umożliwiającej programistom przesyłanie własnych kluczy podpisujących do Google problemy te zostały przynajmniej w pewnym stopniu złagodzone. Ale programiści muszą wyrazić zgodę, aby włączyć tę opcję dla każdej aplikacji. Jeśli tego nie zrobią, połączenia wzajemne nie będą działać, a szybka obsługa będzie wymagała przesłania pakietu do Google i zaczekania na wygenerowanie plików APK przed wysłaniem prawidłowego do użytkownika. Ponadto nadal oznacza to, że muszą dzielić się swoim kluczem prywatnym, co prowadzi nas z powrotem do obaw, które omawialiśmy wcześniej.
Rozwiązania
Jest to stary problem, biorąc pod uwagę, że wymagania dotyczące pakietu aplikacji opublikowano kilka miesięcy temu, dlatego w międzyczasie zaproponowano sporo rozwiązań.
Jednym z rozwiązań jest uniknięcie konieczności podpisywania aplikacji przez Play. Zamiast generować pakiet aplikacji, który Google następnie przetwarza w pliki APK i znaki, przetwarzanie to może wykonać Android Studio. Następnie programiści mogą po prostu przesłać plik ZIP pełen lokalnie podpisanych plików APK dla każdej konfiguracji wygenerowanej przez Google.
Dzięki takiemu rozwiązaniu Google w ogóle nie potrzebowałby dostępu do kluczy programistów. Proces byłby bardzo podobny do klasycznego modelu dystrybucji plików APK, ale obejmowałby wiele mniejszych plików APK, a nie tylko jeden.
Innym rozwiązaniem jest po prostu nie wymaganie korzystania z pakietów aplikacji i dalsze umożliwianie programistom przesyłania plików APK podpisanych lokalnie. Chociaż pakiety aplikacji mogą w wielu przypadkach będzie lepszym doświadczeniem dla użytkownika, niektóre aplikacje tak naprawdę nie korzystają na dzieleniu według konfiguracji przy minimalnym rozmiarze zmniejszenie.
Jeśli Google wdroży oba te rozwiązania, programista chcący korzystać z pakietów aplikacji nie będzie musiał mieć do tego ręki nad podpisaniem umowy z Google, a programista, którego aplikacja nie odniesie zbyt dużych korzyści z tego formatu, nie będzie musiał z niego korzystać Wszystko.
Odpowiedzi Google
Samopodpisanie
Kiedy po raz pierwszy zapytano ich o umożliwienie programistom obsługi podpisywania pakietów aplikacji, odpowiedź Google była bardzo niezobowiązująca:
[blockquoteauthor=""]Więc opowiedziałem krótko o wymogu, aby w przyszłym roku nowe aplikacje korzystały z pakietów aplikacji i jedną z rzeczy, które się z tym wiążą, jest to, że w związku z tym będziemy wymagać podpisywania aplikacji przez Play. Dlatego programiści będą musieli albo wygenerować klucz podpisywania aplikacji w Play, albo przesłać własny klucz do Play… ponieważ jest to warunek wstępny w przypadku pakietów aplikacji. Słyszeliśmy od programistów, że niektórzy z nich po prostu nie chcą tego robić. Nie chcą, aby klucze były zarządzane przez Play. Obecnie nie jest to możliwe, jeśli chcesz korzystać z pakietów aplikacji.
Słyszeliśmy jednak te opinie i… nie mogę teraz o niczym rozmawiać, nie mamy nic do ogłoszenia, ale zastanawiamy się, jak moglibyśmy rozwiać niektóre z tych obaw. Niekoniecznie musi to oznaczać możliwość przechowywania własnego klucza podczas przesyłania pakietów. Rozważamy różne opcje. Po prostu nie mamy rozwiązania, które moglibyśmy ogłosić w tej chwili. Jednak mamy jeszcze około roku do spełnienia tego wymogu, więc mam nadzieję, że będziemy mieli odpowiedź dla programistów na ten temat.[/blockquote]
To było pod koniec listopada ubiegłego roku i wygląda na to, że nic się nie wydarzyło. Ponieważ pozostało zaledwie kilka miesięcy do Zaczyna obowiązywać wymóg dotyczący pakietów aplikacji, programiści nadal nie mają możliwości obsługi podpisywania własnych aplikacji. Chociaż Google umożliwił to teraz wgrywać własny klucz zarówno dla nowych, jak i istniejących aplikacji, nadal wymaga to podpisania od programisty.
Zmiany w kodzie
Chociaż Google wyraźnie obiecał, że Sklep Play nie będzie modyfikował kodu aplikacji, obietnica nie stanowi gwarancji. W przypadku pakietów aplikacji i podpisywania aplikacji nie istnieją żadne ograniczenia techniczne uniemożliwiające Google modyfikowanie przesłanych aplikacji przed dystrybucją.
Google wprowadziło Przejrzystość kodu jako opcjonalna funkcja i choć w pewnym stopniu pomaga, wiąże się to z wieloma problemami, o czym mówiliśmy wcześniej.
Pakiety własnej roboty
Kiedy zapytano Google o umożliwienie programistom tworzenia własnych „pakietów” aplikacji (plików ZIP zawierających podzielone pliki APK), odpowiedź brzmiała po prostu „nie zrobimy tego”:
Prawdopodobnie nie tak, jak opisano w pytaniu, ponieważ jeszcze bardziej utrudniłoby to programistom proces publikowania, a my tak naprawdę chcemy uczynić go prostszym i bezpieczniejszym. Jednakże ponownie usłyszeliśmy te opinie i będziemy szukać możliwości, jak to umożliwić, jednak prawdopodobnie nie w sposób opisany tutaj.
Co ciekawe, Google wydaje się uzasadniać tym, że utrudniłoby to publikowanie. Jednak Google może nadal zautomatyzować ten proces w ramach okna dialogowego generowania pakietu APK w Android Studio. Co więcej, jeśli dana aplikacja jest dystrybuowana w wielu sklepach, faktycznie spowoduje to proces publikowania jest prostszy, ponieważ programiści nie będą musieli zarządzać wieloma kluczami podpisu i skargami użytkownicy.
A wraz z wprowadzeniem przejrzystości kodu wydaje się, że komplikacje wcale nie stanowią problemu. Przejrzystość kodu, przynajmniej na razie, wymaga od programisty użycia narzędzia wiersza poleceń, a użytkownicy muszą bezpośrednio zweryfikować ważność udostępnianej im aplikacji. Jest to bardziej skomplikowane niż proces samodzielnego tworzenia pakietów i nie jest jasne, dlaczego jest to rozwiązanie preferowane przez Google.
Iść naprzód
Pakiety aplikacji będą wymaganym formatem dystrybucji nowych aplikacji przesyłanych do Google Play od 1 sierpnia. Chociaż Google przynajmniej w pewnym stopniu rozwiązał większość problemów zgłoszonych przez programistów i ekspertów ds. bezpieczeństwa, odpowiedzi pozostawiają wiele do życzenia. Pakiety aplikacji jako format dystrybucji nowej generacji niosą ze sobą wiele oczywistych korzyści, ale zawsze będą pojawiać się obawy związane z przekazaniem Google częściowej lub całkowitej kontroli nad podpisywaniem aplikacji.
Z pewnością doceniamy reakcje i wysiłki Google, ale niektórzy, jak Mark Murphy, uważają, że nie posunęły się one wystarczająco daleko. Ponieważ rozwiązania takie jak samodzielnie utworzone pakiety nie są wdrażane, a termin dostarczenia pakietów aplikacji na Androida jest wymagany szybko zbliża się czas, nie wygląda na to, że programiści korzystający z Google Play będą w stanie przez długi czas zachować pełną kontrolę nad swoimi aplikacjami dłużej.
Jeszcze dziś po południu będziemy rozmawiać o konsekwencjach wymagań dotyczących pakietu aplikacji na Androida w przestrzeni Twittera, więc dołącz do nas!