Obowiązkowa weryfikacja programistów aplikacji na Androida – nasz komentarz

Od kilkunastu dni przez internet przetacza się się fala bardzo emocjonalnych i alarmistycznych postów mówiących, że to już koniec wolności w świecie Androida. W sukurs temu trendowi idą niektóre serwisy technologiczne sugerujące jakoby miały zostać zasypane wszelkie różnice pomiędzy Androidem a iOS-em w szeroko rozumianej otwartości. Niektórzy nawet wieszczą, że już nie będzie powodów do tego, aby wybierać Androida.

TLDR:

– Google wprowadza obowiązkową weryfikację programistów aplikacji na Androida

– Zmiany wymuszą podpisywanie wszystkich aplikacji specjalnym, indywidualnym kluczem programisty

– Wprowadzane regulacje obowiązywać będą na wszystkich certyfikowanych urządzeniach

– Takie podejście znane jest z systemu iOS, gdzie Apple wymaga konta dewelopera i ściśle kontroluje, kto otrzymuje certyfikaty

– W ocenie społeczności znacząco ograniczy to możliwość tzw. sideloadingu

– Po wprowadzeniu zmian certyfikaty “self-signed” nie będą honorowane na certyfikowanych urządzeniach

– Planowane zmiany będą obowiązywać od września 2026 roku i początkowo obejmą użytkowników z Brazylii, Indonezji, Singapuru i Tajlandii

Sprawa jednak nie jest taka prosta i oczywista. Co prawda w dalszym ciągu jest wiele niejasności, jednak zachowując chłodną głowę na podstawie dostępnych informacji spróbujemy wyjaśnić, co się już stało, co się stanie i jakie to może mieć (lub nie) konsekwencje dla użytkowników.

Historycznie Android kojarzony był z szeroko rozumianą wolnością wyboru, która w opinii wielu osób bywała okupiona bezpieczeństwem. W rzeczywistości jednak wpadki zdarzały i zdarzają się wszystkim. Także zawartość App Store konkurencyjnego Apple’a nie była wolna od incydentów zagrażających bezpieczeństwu użytkowników. Były to np. ataki na łańcuch dostaw (XCodeGhost, XcodeSpy) powodujące umieszczenie złośliwego kodu w legalnych aplikacjach. Mimo to, to właśnie Android ze swoim Sklepem Play mierzył się z opinią niezbyt bezpiecznego i zabałagionego aplikacjami wątpliwej jakości. Z czasem charakterystyczny bałagan zaczął ustępować miejsca coraz większej dbałości o prywatność i bezpieczeństwo. Aplikacje mogły coraz mniej i miały coraz mniejszy dostęp do zasobów. Jednym z przykładów takich zmian jest wymuszanie SELinux w trybie enforcing w wersji 5.0 (we wcześniejszych wersjach w trybie permissive), co miało na celu ograniczyć powierzchnię ataku nawet w przypadku skutecznego naruszenia bezpieczeństwa jednego z elementów systemu. Innym przykładem jest nowy model uprawnień wprowadzony w wersji 6.0, który umożliwił nadawanie aplikacjom uprawnień w trakcie działania aplikacji, a nie podczas instalacji, dzięki czemu użytkownicy mogli precyzyjnie nadawać uprawnienia aplikacjom w przeciwieństwie do sytuacji, kiedy podczas instalacji aplikacje otrzymywały szeroki wachlarz uprawnień do „wszystkiego”. Dodatkowo w wersji 11 znacząco ograniczono dostęp do plików (stał się bardziej precyzyjny zamiast dotychczasowego podejścia nadającego dostęp „do wszystkiego”). Ponadto oficjalny Sklep Play zamiast starać się zaimponować w liczbie oferowanych pozycji, zaczął kontrolować to, co się w nim zamieszcza (z różnym skutkiem, ale o tym za chwilę).

Pod koniec sierpnia na Android Developers Blog pojawił się komunikat, który miał wywrócić dotychczas dobrze ugruntowany świat Androida:

As new threats emerge, we’ve continued to evolve our defenses. Following recent attacks, including those targeting people’s financial data on their phones, we’ve worked to increase developer accountability to prevent abuse. We’ve seen how malicious actors hide behind anonymity to harm users by impersonating developers and using their brand image to create convincing fake apps. The scale of this threat is significant: our recent analysis found over 50 times more malware from internet-sideloaded sources than on apps available through Google Play.

To better protect users from repeat bad actors spreading malware and scams, we’re adding another layer of security to make installing apps safer for everyone: developer verification. (…)

Google poinformował, że wprowadzi obowiązek podpisywania aplikacji indywidualnym kluczem programisty, wydawanym przez Google. Podpisanie aplikacji takim kluczem będzie warunkiem możliwości instalacji na dowolnym certyfikowanym urządzeniu. Całość rozpoczyna się słowami „You shouldn’t have to choose between open and secure.”. To właśnie kwestie związane z bezpieczeństwem są podawane jako główny powód tej decyzji. Tu pojawia się pierwsza kontrowersja, bowiem tym razem obostrzenia mają dotyczyć nie tylko aplikacji pochodzących ze Sklepu Play zarządzanego przez Google, lecz wszystkich instalowanych aplikacji, bez względu na to, czy pochodzą one z któregoś z alternatywnych źródeł, czy też zostały stworzone np. przez nas i chcemy je zainstalować na własnym urządzeniu na własne potrzeby tylko po to, by sprawdzić się w tworzeniu aplikacji mobilnych.

Po zmianach, aby móc skorzystać z aplikacji, którą posiadamy w postaci pliku z rozszerzeniem .apk, będziemy potrzebowali smartfona z jakąś niecertyfikowaną instalacją Androida (np. któryś z tzw. customowych ROM-ów lub… Huwawei ze swoim własnym ekosystemem). W przeciwnym razie nasza aplikacja będzie musiała posiadać indywidualny, wygenerowany przez Google klucz programisty. To istotny w całej sprawie szczegół. Google zarzeka się, że chodzi tu wyłącznie o weryfikację samych programistów, nie zaś o cenzurę, czy kontrolę tworzonego przez społeczność oprogramowania. Na poziomie deklaracji programiści nadal mają mieć taką samą swobodę tworzenia, jak dotychczas. Twórcy systemu powołują się przy tym na szacunki mówiące, że wśród aplikacji pochodzących spoza sklepu Play ryzyko, że będą złośliwym oprogramowaniem jest ponad 50 razy większe.

I tu pojawia się kolejna kontrowersja. Podając te dane światowy gigant nie powołuje się na żaden konkretny raport. Pomimo znacznych wysiłków nie udało mi się znaleźć w zasobach dostępnych w internecie żadnego raportu ani innego wpisu prezentującego te dane. Nie jest znana metodologia badania, które doprowadziło do takich wniosków, zatem trudno się do niego merytorycznie odnieść. Można założyć, że Google bazując (przypuszczalnie) na danych telemetrycznych z Play Protect wie, co mówi, jednak brak transparentności w tej sprawie zachęcił mnie, aby poszukać takich informacji w innych źródłach.

Okazuje się, że raporty innych firm nie prezentują tak wysokich wartości. Raport Zimperium wspomina zaledwie o dwukrotnie większej szansie na złapanie malware w przypadku aplikacji spoza oficjalnego kanału dystrybucji. Przy tym autorzy badania wskazują, że w środowiskach korporacyjnych sideloading występuje na 23 – 24% urządzeniach. Dla porównania praca ModZoo koncentruje się głównie na alternatywnych sklepach z aplikacjami (takich, jak np. F-Droid) i mówi o 10-krotnie wyższym ryzyku wystąpienia malware w przypadku korzystania z takich źródeł dystrybucji.

Najlepsze w całej sprawie i zarazem pomijane przez wszystkich jest to, że cała dyskusja o tych danych i tak nie ma sensu. Gigant z Mountain View powołuje się na dane o 50-krotnie wyższym ryzyku infekcji złośliwym oprogramowaniem ze źródeł spoza Sklepu Play i tym tłumaczy potrzebę licencjonowania jakiejkolwiek działalności deweloperskiej na Androidzie, ale zaraz… przecież cały rwetes dotyczy źródeł alternatywnych. Z deklaracji, tak tych opublikowanych oficjalnie na Android Developers Blog, jak i tych wygłaszanych przez samych pracowników Google’a na X-ie jasno wynika, że weryfikacja ma dotyczyć tylko samych programistów, co ma dać nam pewność, że dana aplikacja pochodzi od określonego programisty. Zatem oprogramowanie poza oficjalnym Sklepem Google nadal nie będzie w żaden sposób kontrolowane. To, co ląduje w Sklepie Play jest choćby automatycznie skanowane. To, co poza, nie i  – jeśli wierzyć deklaracjom – nie będzie. Jak zatem plan masowego koncesjonowania możliwości tworzenia oprogramowania na Androida ma realnie wpłynąć na bezpieczeństwo użytkowników? Na to pytanie jak dotychczas nikt nie udzielił odpowiedzi. Niestety, odnoszę wrażenie, że nawet nikt go jeszcze nie zadał. Oczywiście, taki wymóg może w jakimś stopniu utrudnić prowadzenie powtarzalnych kampanii, jednak pytanie czy konieczność podawania danych osobowych jest barierą nie do przejścia dla cyberprzestępców wydaje się pytaniem retorycznym.

Nawiasem mówiąc, nawet fakt, że dana aplikacja pochodzi z oficjalnego repozytorium Androida nie oznacza, że jest bezpieczna. Prawdę mówiąc Sklep Play nigdy nie słynął ze szczególnej troski o jakość i bezpieczeństwo tego, co się w nim pojawia. Aby choć trochę odmienić ten trend, kilka lat temu dla kont publikujących w sklepie wprowadzono obowiązek wykorzystywania dwuskładnikowego uwierzytelniania, co miało ograniczyć możliwość wrogiego przejmowania istniejących już, często popularnych projektów, identyfikując jako jedno z istotnych zagrożeń dołączanie złośliwego kodu w aktualizacjach.

W przeszłości na sekuraku niejednokrotnie opisywaliśmy przypadki, kiedy złośliwe aplikacje skutecznie udawały np. 2FA authenticatory. Na szczególną uwagę zasługuje opisany przez nas przypadek aplikacji CamScanner — Phone PDF Creator, która w Sklepie Play miała ponad 100 milionów pobrań. Dla zachowania równowagi warto wspomnieć, że u konkurencji również znajdowano, także współcześnie, złośliwe oprogramowanie w oficjalnym sklepie. Dość widowiskowa okazała się kampania SparkCat z końca 2024 roku, podczas której badacze z Kaspersky’ego wśród różnych aplikacji użytkowych wykryli niepożądane działania. Aplikacje korzystając z uprawnienia dostępu do galerii zdjęć wykonywały zrzuty ekranu, a następnie rozszyfrowyway tekst korzystając z technologii Google OCR. Kampania zorientowana była na kradzież haseł do portfeli kryptowalutowych lub fraz odzyskiwania

Niezależnie od tego, trudno nie zgodzić się ze stwierdzeniem, że co do zasady oprogramowanie pochodzące z niesprawdzonych źródeł potencjalnie bardziej naraża nas na kontakt z malware, ale niestety oficjalny kanał dystrybucji oprogramowania, na który jako sugerowany wzorzec bezpieczeństwa powołują się przedstawiciele Google również nie jest od niego całkowicie wolny. Chcę, żeby to mocno wybrzmiało w tym tekście. Zresztą ten wątek, to i tak ślepa uliczka w kontekście argumentu przytoczonego akapit wyżej.

Wróćmy jednak do weryfikacji. Nie jest jasne, którzy programiści otrzymają możliwość podpisywania swoich aplikacji. Można się spodziewać, że programiści tworzący aplikacje takie, jak popularny w pewnych środowiskach Termux (dostępny w Sklepie Play tylko w bardzo okrojonej wersji), czy chociażby xDrip+ rozbudowujący funkcjonalność czujników do mierzenia poziomu cukru (w ogóle niedostępny w Sklepie Play) dalej będą mogły trafiać na certyfikowane urządzenia, ponieważ ich twórcy potencjalnie nie będą mieli problemów z procesem weryfikacji. Poważne obawy pojawiają się jednak w kontekście tych, którzy tworzą aplikacje będące w sprzeczności z interesem finansowym Google’a, dające dostęp do np. funkcjonalności YouTube Premium (wspominany często Revanced), omijając ograniczenia oficjalnej aplikacji YouTube. Twórcy wszelkich blokerów reklam, czy oprogramowania umożliwiającego rootowanie Androida w opinii wielu wypowiadających się internautów nie mogą już spać tak spokojnie. Można długo debatować nad moralnym uzasadnieniem dla tworzenia i używania tego typu narzędzi, jednak nie o tym jest ten tekst. Wreszcie nie można przejść obojętnie wobec faktu, że w pewnych specyficznych sytuacjach warunek podania imienia i nazwiska, adresu zamieszkania, adresu e-mail i numeru telefonu może okazać się zaporowy.

Konieczność przejścia weryfikacji nie ominie także wszelkiej maści hobbystów, którzy niedługo, aby móc podzielić się z rodziną i znajomymi swoją amatorską, stworzoną w celach edukacyjnych aplikacją do wyświetlania słodkich kotków będą musieli przechodzić przypuszczalnie uciążliwy proces weryfikacji, który wymaga podawania swoich pełnych danych teleadresowych firmie zza oceanu. Trudno nie zgodzić się z tymi, którzy uważają, że pewna niepisana umowa pomiędzy twórcami systemu a użytkownikami została złamana. Mimo wszystko uważam, że opinie jakoby nie było już powodów do używania Androida są mocno przesadzone. Warto przypomnieć, że w urządzeniach od Apple’a wszelkie odstępstwa od oficjalnego kanału dystrybucji oprogramowania (z małymi wyjątkami, np. na terytorium państw członkowskich Unii Europejskiej) zawsze wymagają poważnej ingerencji w system operacyjny (hasło: jailbreaking iOS). Zapowiadane zmiany nawet nie zbliżają nas do tak daleko idących ograniczeń.

Na ciekawy aspekt całej sprawy zwrócono uwagę w serwisie Arstechnica. Autor artykułu zauważa, że plany Google’a mogą stać w sprzeczności z przegraną ostatnio przez firmę sprawą antymonopolową wniesioną przez Epic Games. Sprawa dotyczyła możliwości dostępu do alternatywnych źródeł oprogramowania. Sąd nakazał dopuszczenie alternatywnych sklepów oraz ograniczenia w płatnościach wymuszanych przez Google. Z doniesień medialnych wynika, że pozwany planuje odwołać się od wyroku do Sądu Najwyższego. Niezależnie od dalszego przebiegu tej sprawy brak transparentności i brak zaufania ze strony użytkowników wyzwalają w wielu osobach poważne obawy.

Planowane zmiany dotkną na początku jedynie Brazylii, Indonezji, Singapuru i Tajlandii (wrzesień 2026). Z deklaracji wynika, że reszta świata zostanie objęta tymi zmianami dopiero w kolejnych latach. Ze statystyk wynika, że znaczna większość użytkowników nie korzysta z sideloadingu (i mimo wszystko ze względów bezpieczeństwa całe szczęście). Można się spodziewać, że poza wąskimi środowiskami bardziej świadomych użytkowników temat przejdzie bez większego echa. Całej reszcie pozostanie przyzwyczaić się i dostosować do nowej sytuacji, a jeśli ktoś jednak zechce uciec spod topora z literą G, to zawsze ma do wyboru tzw. customowe ROM-y (takie, jak np. LineageOS). Ma, albo… nie ma. Tych, którzy czytając poprzednie zdanie zapalili się już do „orania” pamięci ROM swojego smartfona muszę nieco zmartwić. Bardzo trudno w dzisiejszych czasach znaleźć model, który nadawałby się do instalacji własnego Androida (zablokowane bootloadery, niekompatybilne układy SOC). Zresztą ta branża od dawna jest już w odwrocie. Co prawda niektórzy zdążyli już nawet ogłosić, że ta zmiana będzie nową szansą dla podupadającego „rynku” customowych ROM-ów, ale czy tego chcemy, czy też nie, czasy, kiedy powszechnie modyfikowaliśmy swoje smartfony zaraz po wyjęciu z pudełka minęły już raczej bezpowrotnie. A dla większości z nas to i tak nie ma znaczenia. Trudno nie odnieść wrażenia, że w całej sprawie najbardziej zawiodła komunikacja. Trzeba zadać sobie pytanie, ilu z nas realnie odczuje skutki tej decyzji?

Na koniec chciałbym napisać, że mam świadomość, iż może się wydawać, że zająłem w tej sprawie jednoznacznie stanowisko. Nie chciałbym nikomu narzucać swojego punktu widzenia. W internecie można znaleźć także głosy aprobujące nowy pomysł, choć subiektywnie trudno nie odnieść wrażenia, że są mniej liczne i jakby cichsze. Nie jest żadną tajemnicą, że jednym z powodów, dla których osoby związane z branżą cybersecurity często przywoływanego w tym kontekście iOS-a (na iPhone’ach) określają jako ten bezpieczniejszy system właśnie za jego brak otwartości i trzymanie użytkownika w klatce w myśl zasady, że bezpieczny system, to ten, który użytkownikowi nie daje zbyt wielu okazji do zrobienia sobie krzywdy. Może zatem nie ma o co się tak burzyć?

~pu