W poprzednim artykule rozebraliśmy na czynniki pierwsze podstawowe nawyki, ustawienia systemowe oraz mity dotyczące lokalizacji i uprawnień. Wiemy już, jak nie wystawiać się na strzał. Czas pójść o krok dalej i wytoczyć ciężkie działa. Dzisiaj przejmiemy pełną kontrolę nad siecią oraz systemem, zmuszając najbardziej bezczelne aplikacje do gry na naszych warunkach. Zaczynamy od totalnej blokady komunikacji.
Ostatnia afera w Poznaniu wokół śledzenia użytkowników i brokerów danych znowu przypomniała nam o jednym: nasze smartfony bez przerwy nadają o tym, gdzie jesteśmy i co robimy. Dobra wiadomość jest taka, że odcięcie większości tego komercyjnego szpiegowania wcale nie wymaga bycia ekspertem od cyberbezpieczeństwa.
To kwestia kilku prostych nawyków, które wdrożysz na swoim telefonie właśnie podczas krótkiej przerwy na kawę.
W ostatnich dniach przez sieć przetoczyła się gorąca dyskusja na temat rzekomej inwigilacji uczestników festiwalu Pyrkon przez Poznański Urząd Miasta oraz Poznańską Lokalną Organizację Turystyczną (PLOT). Powodem całego zamieszania stał się krążący w mediach społecznościowych krótki wycinek z posiedzenia komisji miejskiej. Zawarte w nim niefortunne i mało precyzyjne wypowiedzi urzędników zasugerowały opinii publicznej, że miasto prowadzi masowe zbieranie prywatnych informacji o osobach odwiedzających tereny MTP.
Proces de-big-techowania mojego cyfrowego życia to maraton, a nie sprint. Po przygodach z MDM i wymianie urządzenia wiedziałem, że kolejny krok musi być bezkompromisowy. Gdy w końcu wziąłem do ręki Google Pixel 8 z zainstalowanym GrapheneOS cel był jeden, zbudowanie środowiska opartego na filozofii zero trust.
Wzorując się na świetnym wpisie z bloga davd.io (Back on GrapheneOS in 2026), postanowiłem spisać swoją obecną konfigurację. Nowoczesny degoogle nie musi być całkowitą ucieczką w cyfrowy niebyt. W GrapheneOS to my decydujemy, komu i ile o sobie mówimy.
Bezpieczeństwo systemów operacyjnych to nieustanna sztuka balansu. Jako użytkownicy zorientowani na maksymalną prywatność, często dążymy do rygorystycznego zamykania każdej możliwej luki. Co jednak zrobić w sytuacji, gdy aplikacja, której ufamy i która realizuje architekturę Zero-Knowledge, do poprawnego działania wymaga naciągnięcia domyślnych zasad bezpieczeństwa systemu?
W tym artykule weźmiemy na warsztat konkretny przypadek inżynieryjny z mojego codziennego setupu: aplikacje Ente Photos oraz Filen uruchomione na systemie GrapheneOS (Google Pixel 8). Obie te aplikacje wymagają do działania uprawnienia, które na pierwszy rzut oka może mrozić krew w żyłach każdego specjalisty ds. bezpieczeństwa – Dynamic Code Loading (DCL).
Znasz ten kultowy slogan reklamowy, że prywatność w Apple to fundamentalne prawo człowieka? Piękne hasło. Sam przez lata dawałem się na to złapać. Apple faktycznie zrobiło głośną akcję, odcinając Zuckerberga i resztę ferajny od śledzenia nas pomiędzy różnymi aplikacjami.
Oczywiście nie oznacza to, że z iOS nagle zniknęły wszystkie trackery, ponieważ aplikacje deweloperów nadal zbierają dane o tym, co robisz wewnątrz nich, a reklamiarze kombinują z fingerprintingiem. Apple zablokowało jednak ten najprostszy, systemowy transfer danych między korporacjami.
W codziennym użytkowaniu alternatywnych systemów operacyjnych, takich jak GrapheneOS, kluczowym elementem zarządzania oprogramowaniem bywają narzędzia typu Obtainium czy nadrzędne sklepy z aplikacjami pokroju Accrescent. Co ciekawe, ten model wychodzi już daleko poza niszowe, zorientowane na prywatność ROM-y. Coraz więcej użytkowników standardowego Androida decyduje się na porzucenie tradycyjnych sklepów. Ściąganie paczek instalacyjnych bezpośrednio z GitHubów deweloperów lub niezależnych źródeł to ogromna wygoda, ale też konkretne wyzwanie dla higieny bezpieczeństwa. Skąd mamy wiedzieć, czy do repozytorium nikt poza samym deweloperem niefortunnie nie dodał czegoś od siebie?
Przez długi czas podstawową linią obrony dla wielu użytkowników był AppVerifier, czyli świetne, lokalne narzędzie od dewelopera soupslurpr. Ostatnio jednak na scenie pojawił się nowy gracz. Mowa o Verified Apps, czyli oficjalnym projekcie bazującym na kodzie AppVerifiera, ale sygnowanym przez ekipę z Privacy Guides.
W środowisku osób dbających o prywatność i cyfrową suwerenność debaty o idealnym systemie operacyjnym trwają od lat. Jedni wybierają GrapheneOS ze względu na bezkompromisowe podejście do bezpieczeństwa, inni stawiają na LineageOS, /e/OS czy inne otwartoźródłowe alternatywy. Co jednak zrobić, gdy w danym momencie masz w kieszeni świetny, flagowy telefon z zamkniętym systemem, ale nie chcesz rezygnować z ochrony swoich danych?
Zanim nagła sytuacja życiowa i pobyt żony w szpitalu zmusiły mnie do szybkiego podreperowania domowego budżetu, sprzedaży iPhone’a 17 Pro i zakupu z drugiej ręki Pixela 8, stałem dokładnie przed takim dylematem. Cenny sprzętowo smartfon od Apple postanowiłem zaadaptować do własnych zasad.
W polskiej społeczności użytkowników dbających o prywatność F-Droid ma status niemal kultowy. Dla wielu to synonim wolnego oprogramowania (FOSS) i jedyna słuszna ucieczka przed inwigilacją ze strony Google Play. Każda próba krytyki tego zielonego robocika spotyka się z natychmiastowym oporem. Bronimy go z powodów czysto ideologicznych. Niestety, w świecie cyberbezpieczeństwa sama ideologia to za mało. Podczas gdy Android ewoluował, F-Droid utknął w przeszłości, stając się dziś jednym z najsłabszych ogniw na bezpiecznych systemach takich jak GrapheneOS.
W świecie cyberbezpieczeństwa często rozmawiamy o „modelach zagrożeń” (Threat Models) w sposób czysto teoretyczny. Analizujemy tabelki, czytamy dokumentację i zastanawiamy się, czy korporacyjny szum telemetryczny to wystarczający powód do zmiany nawyków. Sam byłem w tym miejscu, budując swój poprzedni setup na iPhonie 17 Pro. Wszystko zmieniło się w ułamku sekundy, gdy teoria zderzyła się z brutalną rzeczywistością.