Android 17, wydany 16 czerwca 2026 roku i początkowo udostępniony dla większości obsługiwanych urządzeń Pixel, wprowadza kilka zmian dotyczących bezpieczeństwa sieciowego, które wpływają na znacznie więcej niż wygląd czy codzienne działanie smartfona. Google skupiło się na informacjach, które mogą zostać ujawnione podczas łączenia telefonu ze stronami internetowymi, aplikacjami, domowym sprzętem Wi-Fi oraz sieciami komórkowymi. Szczególnie istotne są trzy zmiany: Encrypted Client Hello, czyli ECH, które może ukrywać domenę żądaną podczas szyfrowanego połączenia; bardziej rygorystyczna kontrola dostępu aplikacji do urządzeń w sieci lokalnej; a także silniejsza ochrona przed atakami, które celowo wymuszają przełączenie telefonu na podatne na zagrożenia połączenie 2G. Żadne z tych rozwiązań nie sprawia, że telefon z Androidem staje się całkowicie odporny na śledzenie lub oszustwa, ale razem zamykają kilka istniejących od lat luk, które wcześniej pozwalały obserwatorom sieci, nadmiernie ingerującym aplikacjom i przestępcom korzystającym z fałszywego sprzętu komórkowego dowiedzieć się o aktywności użytkownika więcej, niż było to konieczne.
HTTPS już teraz szyfruje informacje wymieniane między smartfonem a bezpieczną stroną internetową, w tym hasła, wiadomości i większość zawartości strony. Do niedawna część początkowego etapu połączenia mogła jednak nadal ujawniać, z jaką domeną internetową telefon próbował się połączyć. Problem dotyczy mechanizmu Server Name Indication, powszechnie określanego skrótem SNI. Przeglądarka lub aplikacja wykorzystuje tę informację, aby serwer obsługujący wiele stron wiedział, którą z nich ma udostępnić. Tradycyjne połączenia TLS mogły ujawniać tę nazwę jeszcze przed ustanowieniem w pełni zaszyfrowanej sesji, co oznaczało, że operator sieci Wi-Fi, dostawca internetu lub osoba obserwująca ruch sieciowy mogła potencjalnie zobaczyć domenę, nawet jeśli nie była w stanie odczytać zawartości samego połączenia.
Android 17 wprowadza wbudowaną obsługę Encrypted Client Hello, która ma ograniczyć ten problem. ECH szyfruje wrażliwe informacje na początkowym etapie połączenia TLS, w tym nazwę serwera. W rezultacie obserwator znajdujący się pomiędzy telefonem a miejscem docelowym otrzymuje mniej użytecznych informacji pozwalających dokładnie określić, z jaką obsługiwaną stroną lub usługą łączy się użytkownik. Ma to szczególne znaczenie w sieciach, nad którymi użytkownik nie ma kontroli, takich jak Wi-Fi w hotelach, na lotniskach, w kawiarniach czy innych miejscach publicznych, gdzie ruch przechodzi przez urządzenia zarządzane przez inną organizację. Rozwiązanie to może również ograniczyć ilość informacji o przeglądaniu widocznych dla dostawcy internetu.
Istnieje jednak ważne ograniczenie. Android 17 nie ukrywa automatycznie każdej domeny żądanej przez każdą aplikację. W przypadku aplikacji kierowanych na Androida 17, czyli API level 37, ECH może być używane wtedy, gdy oprogramowanie sieciowe wewnątrz aplikacji obsługuje ten mechanizm i gdy serwer docelowy jest również skonfigurowany do obsługi ECH. Google wskazuje między innymi WebView, HttpEngine oraz zgodne wersje OkHttp jako przykłady rozwiązań zapewniających odpowiednią obsługę. Jeżeli drugi koniec połączenia nie obsługuje ECH, Android nie może po prostu zaszyfrować informacji, których serwer nie byłby w stanie przetworzyć. Oznacza to, że ECH stanowi istotną poprawę prywatności, ale jego zasięg będzie rósł wraz z wdrażaniem tego rozwiązania przez twórców aplikacji i administratorów stron internetowych.
Dla zwykłego użytkownika Androida główną zaletą ECH jest to, że rozwiązanie działa w dużej mierze w tle. Nie trzeba aktywować osobnego trybu prywatności za każdym razem, gdy obsługiwana aplikacja łączy się ze stroną internetową. Jeżeli wszystkie wymagane elementy połączenia obsługują ECH, informacje są chronione jako część standardowej zaszyfrowanej sesji. Ma to znaczenie, ponieważ funkcje prywatności są najbardziej skuteczne wtedy, gdy ich działanie nie zależy od regularnego zmieniania ustawień przez użytkownika ani od znajomości technicznych szczegółów połączeń TLS.
ECH nie należy jednak utożsamiać z pełną anonimowością. Sieć nadal może widzieć, że telefon wymienia dane, a zazwyczaj również adres IP, z którym się łączy. W niektórych przypadkach jeden adres IP jest współdzielony przez wiele domen, co utrudnia dokładne ustalenie miejsca docelowego, ale w innych sytuacjach sam adres może nadal dostarczać określonych wskazówek. Odpowiedniej ochrony wymagają również zapytania DNS, ponieważ nieszyfrowane wyszukiwanie DNS może ujawnić nazwę domeny jeszcze zanim ECH będzie miało możliwość ją ukryć. Funkcja Private DNS w Androidzie oraz inne metody szyfrowanego DNS pozostają więc istotnym uzupełnieniem ECH, a nie rozwiązaniem przez nie zastępowanym.
Praktyczna zmiana polega zatem na ograniczeniu niepotrzebnego ujawniania informacji, a nie na całkowitym zniknięciu wszystkich identyfikatorów sieciowych. To ważne rozróżnienie przy ocenie zmian prywatności w Androidzie 17. Użytkownik połączony z publiczną siecią Wi-Fi mógł wcześniej chronić zawartość sesji HTTPS, a mimo to ujawniać żądaną domenę podczas ustanawiania połączenia. ECH może zamknąć właśnie tę lukę tam, gdzie jest obsługiwane. Nadal konieczne są jednak rozsądne praktyki bezpieczeństwa, takie jak instalowanie aktualizacji, unikanie niezaufanych certyfikatów oraz korzystanie z aktualnych wersji przeglądarek i aplikacji, ponieważ ECH chroni jedynie określony fragment komunikacji sieciowej, a nie wszystkie możliwe sposoby gromadzenia informacji.
Domowa sieć Wi-Fi może zawierać znacznie więcej informacji, niż wielu użytkowników przypuszcza. Telefony często współdzielą tę samą sieć lokalną z telewizorami, drukarkami, głośnikami, przystawkami multimedialnymi, komputerami, kamerami bezpieczeństwa oraz urządzeniami inteligentnego domu. Aplikacja, która może skanować taką sieć, jest potencjalnie w stanie ustalić, jakie urządzenia są obecne, a ich zestaw może stać się kolejną wskazówką umożliwiającą identyfikację gospodarstwa domowego. Przed wprowadzeniem nowych ograniczeń Android traktował komunikację w sieci lokalnej inaczej niż dostęp do oczywiście wrażliwych danych, takich jak kamera czy precyzyjna lokalizacja, mimo że szczegółowa lista podłączonych urządzeń również może ujawniać informacje o użytkowniku.
Android 17 zmienia tę sytuację w przypadku aplikacji kierowanych na API level 37, wymuszając ochronę sieci lokalnej. Taka aplikacja nie może po prostu uzyskać nieograniczonego dostępu do urządzeń znajdujących się w lokalnej sieci, jeśli chce je wyszukiwać lub się z nimi komunikować. Android wprowadza uprawnienie czasu wykonywania ACCESS_LOCAL_NETWORK dla aplikacji, które rzeczywiście potrzebują szerokiego dostępu do sieci LAN. Uprawnienie to należy do istniejącej grupy Nearby Devices. Ma to wpływ na sposób wyświetlania prośby użytkownikowi: osoba, która wcześniej przyznała odpowiednie uprawnienie Nearby Devices, nie zawsze musi zobaczyć dodatkowy komunikat wyłącznie dlatego, że aplikacja zaczęła korzystać z nowego uprawnienia do sieci lokalnej.
Rozwiązanie rozwija mechanizmy wprowadzone w Androidzie 16, w którym twórcy aplikacji mogli testować ograniczenia dotyczące sieci lokalnej i dobrowolnie je wdrażać, zanim stały się obowiązkowe dla aplikacji kierowanych na Androida 17. Celem nie jest blokowanie legalnej komunikacji pomiędzy telefonami a urządzeniami znajdującymi się w domu. Android rozdziela natomiast aplikacje, które mają rzeczywisty powód, aby widzieć sieć lokalną, od tych, których główne funkcje mogą działać bez tak szerokiego dostępu. Takie podejście utrudnia ciche skanowanie sieci i daje systemowi wyraźniejszą podstawę do ograniczania aplikacji, które nie mają uzasadnionej potrzeby sprawdzania urządzeń znajdujących się w pobliżu.
Wiele legalnych funkcji Androida opiera się na komunikacji z urządzeniami znajdującymi się w pobliżu. Aplikacja wideo może przesyłać treści na telewizor, aplikacja inteligentnego domu może sterować oświetleniem lub termostatem, a narzędzie użytkowe może komunikować się z drukarką lub magazynem sieciowym. Wymaganie nieograniczonego dostępu do całej sieci dla każdej z tych czynności samo w sobie tworzyłoby problem z prywatnością. Android 17 obsługuje więc systemowe mechanizmy wyboru urządzeń, które pozwalają aplikacji komunikować się z urządzeniem wybranym przez użytkownika bez wcześniejszego przyznawania jej prawa do sprawdzania wszystkiego, co jest podłączone do tej samej sieci.
Dobrym przykładem jest przesyłanie obrazu na telewizor. Jeżeli użytkownik chce wysłać film na konkretny ekran, najważniejsza jest decyzja, który telewizor ma go odtworzyć. Aplikacja wideo nie musi do tego otrzymywać stałej listy wszystkich komputerów, kamer, głośników i innych dostępnych urządzeń znajdujących się w domu. Systemowy mechanizm wyboru może obsłużyć ten proces i przyznać aplikacji dostęp tylko do wskazanego urządzenia. Aplikacje, które rzeczywiście wymagają szerszej i trwałej komunikacji z urządzeniami w sieci lokalnej, mogą natomiast poprosić o ACCESS_LOCAL_NETWORK i wyjaśnić, dlaczego taki dostęp jest potrzebny.
Dla użytkownika oznacza to, że dostęp do sieci lokalnej staje się czymś, nad czym warto się zastanowić, a nie niewidoczną konsekwencją instalacji aplikacji. Taka prośba może być uzasadniona w przypadku oprogramowania do zarządzania inteligentnym domem, diagnostyki sieci czy sterowania urządzeniami, ale znacznie trudniej ją uzasadnić w aplikacji, której funkcje nie mają nic wspólnego ze sprzętem znajdującym się w pobliżu. Android 17 nie jest w stanie samodzielnie ocenić zasadności każdego konkretnego żądania, ale wymuszenie granicy uprawnień ogranicza automatyczny dostęp i zachęca twórców aplikacji do proszenia wyłącznie o te możliwości sieciowe, które są rzeczywiście potrzebne.

Mimo powszechnego wykorzystania 4G i 5G obsługa 2G nadal stanowi problem bezpieczeństwa, ponieważ telefon zdolny do połączenia ze starszą technologią może zostać w niektórych sytuacjach zmuszony do opuszczenia bezpieczniejszej sieci. Przestępcy mogą korzystać z fałszywych stacji bazowych, czasami określanych jako symulatory stacji komórkowych lub SMS blastery, które emitują silny sygnał komórkowy w pobliżu potencjalnych ofiar. Podatny telefon może zostać przełączony z LTE lub 5G na 2G, gdzie starsze mechanizmy ochronne są słabsze. Atakujący mogą następnie wykorzystać takie połączenie do wstrzykiwania fałszywych wiadomości SMS lub przeprowadzania innych form przechwytywania danych, które byłyby znacznie trudniejsze w nowoczesnych sieciach komórkowych.
SMS blastery są szczególnie niebezpieczne, ponieważ wiadomości dostarczane przy użyciu fałszywego sprzętu komórkowego mogą ominąć część zabezpieczeń stosowanych przez legalnych operatorów sieci. Wiadomość może wyglądać jak komunikat banku, firmy kurierskiej, instytucji państwowej lub innej znanej organizacji i kierować odbiorcę na stronę phishingową. Taki atak ma charakter lokalny: przestępcy potrzebują odpowiedniego sprzętu radiowego znajdującego się w zasięgu atakowanych telefonów. Google wskazywało przykłady przenośnego i montowanego w pojazdach sprzętu wykorzystywanego w ruchliwych obszarach miejskich, co pokazuje, dlaczego możliwość przełączania nowoczesnych smartfonów na 2G nadal może być atrakcyjna dla atakujących, nawet tam, gdzie operatorzy stopniowo ograniczają normalne działanie sieci 2G.
Od Androida 12 zgodne urządzenia umożliwiają wyłączenie 2G na poziomie modułu radiowego, co zapobiega zwykłemu wyszukiwaniu takich sieci i łączeniu się z nimi. Android 17 rozwija to rozwiązanie, umożliwiając operatorom komórkowym skonfigurowanie ochrony 2G w taki sposób, aby połączenia 2G były domyślnie wyłączone dla ich abonentów. Nie jest to jednak uniwersalne ustawienie, które Google aktywuje na każdym telefonie z Androidem 17. Silniejsza domyślna ochrona zależy od udziału operatora oraz obsługi przez konkretne urządzenie. Tam, gdzie rozwiązanie zostanie wdrożone, korzyść dla bezpieczeństwa jest jednak istotna, ponieważ telefon unika podatnego połączenia, zanim SMS blaster otrzyma możliwość wykorzystania wymuszonego przejścia na starszą sieć.
Przede wszystkim należy rozumieć, że wyłączenie 2G nie jest tym samym co blokowanie zwykłego spamu SMS. Rozwiązanie to eliminuje drogę, którą może wykorzystać określona grupa ataków komórkowych. Jeżeli telefon odmawia zwykłych połączeń 2G, fałszywa stacja bazowa nie może po prostu wymusić przełączenia urządzenia na 2G i następnie wykorzystać słabości starszej technologii w typowy sposób. Ma to szczególne znaczenie w krajach, w których legalna sieć 2G została już wyłączona lub jest bliska wyłączenia, ponieważ nowoczesny telefon może mieć niewiele praktycznych powodów, aby zachowywać stałą możliwość codziennego łączenia się z 2G.
Istnieją jednak sytuacje, w których 2G nadal może być przydatne. Niektóre regiony wciąż opierają się na starszym zasięgu komórkowym, a osoby podróżujące mogą trafić na sieci roamingowe, w których usługi 4G lub 5G nie są dostępne. Dokumentacja Androida ostrzega, że urządzenie z wyłączonym 2G może w takich warunkach utracić zwykłą łączność komórkową do czasu ponownego włączenia tej funkcji przez użytkownika. Połączenia alarmowe są jednak traktowane inaczej: według Androida wyłączenie 2G ze względów bezpieczeństwa nie uniemożliwia wykonywania połączeń alarmowych, ponieważ urządzenie nadal może wyszukać i wykorzystać 2G, jeżeli jest to konieczne do połączenia ze służbami ratunkowymi. Pozwala to zapewnić silniejszą ochronę podczas normalnego użytkowania bez celowego usuwania istotnego rozwiązania awaryjnego.
Łącznie obsługa ECH w Androidzie 17, obowiązkowe ograniczenia sieci lokalnej dla nowych aplikacji kierowanych na tę wersję systemu oraz rozszerzone możliwości operatorów związane z wyłączaniem 2G odpowiadają na trzy różne rodzaje ujawniania informacji. ECH zmniejsza ilość danych o miejscu docelowym widocznych podczas obsługiwanych szyfrowanych połączeń; uprawnienia sieci lokalnej ograniczają ciche sprawdzanie urządzeń korzystających z tej samej sieci Wi-Fi; natomiast silniejsze mechanizmy 2G utrudniają przeprowadzanie ataków SMS opartych na wymuszonym przełączaniu sieci tam, gdzie operatorzy i urządzenia obsługują tę funkcję. Żadnego z tych rozwiązań nie należy traktować jako zamiennika aktualizacji oprogramowania, ostrożnego zarządzania uprawnieniami czy sceptycznego podejścia do niespodziewanych wiadomości. Ich znaczenie polega na ograniczaniu ryzyka jeszcze zanim użytkownik będzie musiał na nie reagować, dzięki czemu kilka wcześniej bardziej otwartych elementów komunikacji sieciowej w Androidzie staje się domyślnie lepiej chronionych.