Ostatnio na Mastodonie pojawiło się kilka pytań o zarządzanie uprawnieniami w systemie GrapheneOS, a dokładniej o to, jak w praktyce działa funkcja Storage Scopes. Zauważyłem, że to mechanizm, który przy pierwszym kontakcie potrafi wywołać spory mętlik. Postanowiłem napisać ten wpis, aby w jednym miejscu wyjaśnić, dlaczego ta opcja to absolutny przełom w dążeniu do cyfrowej prywatności.
Ostatnio na moim profilu na Mastodonie zostałem zapytany o to, jak dokładnie używam aparatu w moim setupie na GrapheneOS. Postanowiłem napisać krótki wpis, aby w jednym miejscu wyjaśnić, jak to zrobiłem.
Zależało mi na zastąpieniu domyślnego aparatu systemowego, ponieważ aplikacja od Google w pełni wykorzystuje procesor i robi po prostu o wiele lepsze zdjęcia, co doskonale widać zwłaszcza w trybie nocnym. Wszystko to chciałem osiągnąć, zachowując pełną prywatność i bez wpuszczania usług Google do głównego profilu w telefonie.
W świecie cyfrowej prywatności bardzo łatwo wpaść w pułapkę myślenia życzeniowego. Inspiracją do dzisiejszego wpisu jest dyskusja, na którą natrafiłem niedawno na Mastodonie. Wymieszały się w niej fakty techniczne, komercyjny marketing oraz – co najgorsze – przesadna ideologia, która z realnym bezpieczeństwem ma niewiele wspólnego.
Czas domknąć ten temat kompleksowo i wyprostować mity, które w imię walki z Big Tech, sprzedają użytkownikom złudne poczucie bezpieczeństwa.
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).
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ą.