Eteryu.space

Mój własny, prywatny DNS. Po co?

Eteryu — Mon, 12 Oct 2026 00:00:00 +0000

Kiedyś używałem publicznego DNS z filtrowaniem. Działał dobrze. Blokował większość reklam, trackerów i tego całego śmiecia, który ciągnie się za każdą stroną. Ale zawsze brakowało mi jednej rzeczy: kontroli.

Nie nad tym, jakie domeny trafiają na listy. One i tak pochodzą od tych samych ludzi, którzy tworzą listy dla publicznych resolverów. Różnica polega na tym, że sam decyduję, z których list korzystam, jak je łączę i co z nich wyciągam. Mogę dodać dowolną listę z internetu, nie tylko te, które ktoś uznał za godne dodania do swojego katalogu. I gdy czegoś nie chcę blokować, dodaję to do własnych wyjątków i następnego dnia jest już przepuszczane. Bez czekania, aż ktoś inny uzna, że to dobry pomysł.

To mnie uwierało. Nie z powodu paranoi, ale z poczucia, że oddaję kontrolę nad czymś fundamentalnym. Nad tym, jak moje urządzenia łączą się ze światem.

Co to właściwie jest?

Zbudowałem swój własny serwer DNS. Stoi w chmurze, więc mam do niego dostęp z każdego miejsca na świecie. Filtruje ruch według list, które sam wybieram i sam układam.

Działa to tak. Moje urządzenia pytają mój serwer o adres jakiejś strony. Serwer sprawdza, czy ta domena jest na liście, którą przygotowałem. Jeśli jest, odpowiada „nie znam takiej strony". Jeśli nie ma jej na liście, przekazuje zapytanie dalej.

Blokuję reklamy, trackery, telemetrię, domeny malware i phishing. Korzystam z ośmiu źródeł, które sam wybrałem. Jedne skupiają się na reklamach, inne na trackerach, jeszcze inne na zagrożeniach. Każde z nich wnosi coś innego.

Warto dodać, że to działa na poziomie DNS. Nie blokuje reklam w YouTube ani elementów wewnątrz strony. Do tego potrzebny jest osobny content blocker w przeglądarce. Mój resolver jest pierwszą warstwą, nie jedyną.

Jak łączę listy i usuwam duplikaty

Problem z wieloma źródłami jest taki, że często się nakładają. Ta sama domena może pojawić się w trzech, czterech, pięciu listach jednocześnie. Gdybym wrzucił wszystko do jednego worka bez czyszczenia, miałbym listę pełną powtórzeń, większą niż potrzeba i wolniejszą w działaniu.

Zamiast tego mój pipeline robi coś prostego. Zbiera wszystkie domeny ze wszystkich źródeł do jednego zbioru, który z definicji nie może zawierać duplikatów. Jeśli ta sama domena pojawi się pięć razy, będzie tylko raz.

Po zebraniu wszystkich domen usuwam redundantne subdomeny. Jeśli na liście jest example.com, nie ma sensu trzymać na niej także ads.example.com i track.example.com. Każda z tych subdomen zostanie zablokowana, jeśli zablokowana jest domena nadrzędna. Usuwam je. Lista staje się mniejsza, a blokada działa tak samo.

Efekt jest taki, że z kilkudziesięciu tysięcy wpisów ze wszystkich źródeł zostaje jedna, czysta lista. Bez duplikatów. Bez zbędnych subdomen. Tylko to, co faktycznie blokuje coś, czego nie chcę widzieć.

Automatyzacja

Ten proces dzieje się raz dziennie. Ja nie muszę nic robić. Lista sama się aktualizuje, sama się czyści i sama trafia do mojego resolvera.

Dlaczego to nie ma panelu ani statystyk?

Mój resolver nie ma panelu administracyjnego. Nie ma wykresów, nie ma listy ostatnich zapytań, nie ma licznika zablokowanych domen.

To celowa decyzja. Panel ze statystykami oznacza, że ktoś, nawet jeśli tylko ja, gdzieś te dane przechowuje. Lista ostatnich zapytań to nic innego jak historia tego, co robię w internecie. A ja nie chcę, żeby taka historia istniała w jakiejkolwiek formie.

Mój resolver przetwarza zapytanie, zwraca odpowiedź i zapomina. Nie zapisuje niczego i nie analizuje. Nie ma czego nie logować, bo nie ma gdzie logować.

Dla kogo to jest

To rozwiązanie dla kogoś, kto ma kilka urządzeń i chce, żeby wszystkie filtrowały tak samo. Telefon, laptop, tablet, cokolwiek. Bez instalowania osobnych aplikacji na każdym z nich.

Dla kogoś, kto ceni prywatność i nie potrzebuje wykresów, żeby czuć, że coś działa.

Dla kogoś, kto chce sam decydować, co blokuje, i nie czekać, aż ktoś inny zrobi to za niego.

Jeśli zależy Ci na panelu i statystykach, inne rozwiązania zrobią to lepiej. Ale jeśli cenisz kontrolę i prywatność bardziej niż wygodę, to jest dokładnie to.

Darmowy VPN z filtrowaniem DNS. Proton VPN + DoH/DoT przez WG Tunnel

Eteryu — Fri, 09 Oct 2026 00:00:00 +0000

Darmowy plan Proton VPN ma jedną poważną wadę. Nie ma w nim NetShield, czyli wbudowanego blokowania reklam, trackerów i malware. Płacący użytkownicy mają tę funkcję. Free tier dostaje tylko tunel.

To nie znaczy, że darmowy Proton jest bezużyteczny. Znaczy tylko, że trzeba mu trochę pomóc.

Co oferuje darmowy Proton VPN

Zacznijmy od faktów. Darmowy plan Proton VPN to:

Brak limitu danych. Nie ma throttlingu ani dziennego limitu transferu.
Jedno urządzenie. Możesz połączyć tylko jeden telefon albo komputer naraz.
10 krajów. Proton oferuje serwery w Holandii, Japonii, Rumunii, Polsce, USA, Meksyku, Kanadzie, Szwajcarii, Norwegii i Singapurze. Serwer jest przydzielany automatycznie, ale możesz przełączać się między krajami.
Brak NetShield. Blokowanie reklam, trackerów i malware jest tylko w planach płatnych.
Brak custom DNS w natywnej aplikacji. W oficjalnej aplikacji Proton VPN nie możesz ustawić własnego DNS. Ale jeśli korzystasz z pliku WireGuard .conf, możesz wpisać dowolny DNS w sekcji [Interface]. To ograniczenie dotyczy więc tylko aplikacji, nie protokołu.

Ostatnie dwa punkty bolą najbardziej. NetShield to funkcja, która filtruje zapytania DNS i blokuje domeny reklamowe oraz złośliwe. Custom DNS pozwala na wskazanie własnego resolvera, na przykład NextDNS albo HaGeZi DNS.

W płatnym planie możesz wybrać jedno albo drugie. Nie oba naraz. Proton traktuje je jako wzajemnie wykluczające się, bo NetShield sam filtruje DNS.

W darmowym nie masz żadnego z nich.

Dlaczego nie wystarczy zwykły DNS w pliku .conf

Proton VPN udostępnia pliki konfiguracyjne WireGuard. Możesz je pobrać z panelu konta i zaimportować do dowolnego klienta WireGuard. W pliku .conf jest sekcja [Interface], w której można wpisać adres DNS.

Więc tak, możesz dodać własny DNS już na tym etapie. Możesz tam wpisać adresy NextDNS, HaGeZi DNS albo dowolnego innego resolvera. I to zadziała.

Plain DNS w pliku .conf to nie to samo co szyfrowany DNS

Wpisanie adresu resolvera w sekcji [Interface] pliku .conf daje plain DNS. Zapytania lecą jako zwykły UDP na porcie 53, tylko wewnątrz tunelu WireGuard. Operator sieci ich nie widzi, ale Proton widzi. Po dotarciu do serwera Protona zapytanie jest odszyfrowywane i wysyłane dalej jako otwarty tekst. Jeśli chcesz szyfrowania end-to-end, potrzebujesz DoH albo DoT przez WG Tunnel.

Jeśli ufasz Protonowi, to nie problem. Proton ma politykę no-logs i niezależne audyty. Ale w modelu zero trust nie chodzi o to, komu ufasz. Chodzi o to, komu musisz ufać.

Wolę nie musieć ufać nikomu więcej niż to konieczne.

Różnica między UDP a DoT i DoH

To jest sedno całego artykułu. Warto zrozumieć, dlaczego szyfrowany DNS jest lepszy od zwykłego, nawet jeśli ten zwykły jest w tunelu VPN.

Protokół	Port	Szyfrowanie	Kto widzi zapytanie
Plain DNS (UDP)	53	Brak	Dostawca internetu, operator sieci, dostawca VPN
DoT (DNS over TLS)	853	Tak	Dostawca VPN (widzi zaszyfrowany ruch), ale nie treść
DoH (DNS over HTTPS)	443	Tak	Dostawca VPN (widzi ruch HTTPS), ale nie treść

Plain DNS to zapytanie wysłane otwartym tekstem. Każdy na drodze może je odczytać i zmodyfikować. W tunelu VPN jest chroniony przed operatorem sieci, ale nie przed dostawcą VPN.

DoT to to samo zapytanie DNS, ale opakowane w TLS. Wygląda jak każdy inny zaszyfrowany ruch na porcie 853. Dostawca VPN widzi, że łączysz się z jakimś serwerem na tym porcie, ale nie widzi, o co pytasz.

DoH to zapytanie DNS opakowane w HTTPS. Wygląda jak zwykły ruch webowy na porcie 443. Dostawca VPN nie odróżni go od przeglądania strony. To najlepsza opcja pod kątem ukrycia zapytań DNS przed wszystkimi pośrednikami.

DoH i DoT dają więc coś, czego plain DNS nie daje: szyfrowanie end-to-end między Twoim urządzeniem a resolverem DNS. Nikt po drodze nie widzi treści zapytania. Ani operator sieci, ani Proton.

Kiedy wybrać DoH, a kiedy DoT

Oba protokoły szyfrują DNS, ale różnią się charakterystyką. Wybór zależy od tego, gdzie i jak używasz telefonu.

DoH — wybierz, jeśli:

Korzystasz z publicznych sieci Wi-Fi (kawiarnie, hotele, lotniska), które często blokują niestandardowe porty.
Korzystasz głównie z sieci komórkowej. Operatorzy często blokują port 853 używany przez DoT, a DoH na porcie 443 jest znacznie trudniejszy do zablokowania.
Chcesz, żeby ruch DNS wyglądał jak zwykły ruch HTTPS. DoH używa portu 443, tego samego co przeglądanie stron. Trudniej go wykryć i zablokować.
Zależy Ci na maksymalnym ukryciu zapytań DNS przed operatorem sieci.

DoT — wybierz, jeśli:

Korzystasz głównie z domowego Wi-Fi, gdzie masz pewność, że port 853 nie jest blokowany.
Administrujesz własnym serwerem DNS i chcesz używać standardowego portu dla DNS over TLS.
Zależy Ci na prostocie konfiguracji w sieci, którą w pełni kontrolujesz.

Nie potrzebujesz ani DoH, ani DoT — jeśli:

Używasz VPN wyłącznie do ukrycia adresu IP i nie zależy Ci na ukryciu zapytań DNS przed dostawcą VPN.
Ufasz Protonowi w kwestii nieprzetrzymywania logów DNS. Proton ma politykę no-logs i audyty, więc dla wielu użytkowników to wystarczy.

Opcja pośrednia — Split DNS w WG Tunnel:

Możesz też użyć trybu Split w WG Tunnel. W tym trybie tylko wybrane domeny (np. banki, usługi urzędowe) idą przez szyfrowany DNS, a reszta przez zwykły DNS systemowy. To kompromis między prywatnością a wydajnością.

Rozwiązanie: WG Tunnel

Standardowy klient WireGuard na Androida nie obsługuje DoH ani DoT. Możesz wpisać adresy IP resolvera w pliku .conf, ale to wszystko. Nie ma opcji szyfrowania zapytań DNS.

WG Tunnel to alternatywny klient WireGuard, który obsługuje szyfrowany DNS bezpośrednio w aplikacji.

Ma cztery tryby pracy DNS:

Default – używa domyślnych ustawień systemowych.
Encrypted – wymusza szyfrowane zapytania (DoH lub DoT) przez cały tunel.
Split – kieruje tylko wybrane domeny przez DNS tunelu, resztę przez system.
System VPN mode – używa DNS dostarczonego przez Androida.

Dla naszego celu interesuje nas tryb Encrypted. W tym trybie WG Tunnel ignoruje adresy DNS z pliku .conf i używa własnego endpointu, który podajesz w ustawieniach aplikacji.

Wybór resolvera DNS

Potrzebujesz resolvera, który obsługuje DoH albo DoT. Masz kilka opcji. Wybór zależy od tego, co chcesz blokować i ile kontroli potrzebujesz.

Rekomendacja: Hagezi Pro + TIF

W społecznościach zajmujących się prywatnością i bezpieczeństwem sieciowym Hagezi Pro + TIF to obecnie złoty środek. HaGeZi to pseudonim niemieckiego dewelopera, który prowadzi jeden z najczęściej aktualizowanych i najlepiej ocenianych zestawów list blokujących na świecie.

Hagezi Pro to lista rozszerzona, która blokuje reklamy, trackery, analitykę, telemetrię, phishing, malware, scam i fake. Jest to wersja rekomendowana dla większości użytkowników.

Hagezi TIF (Threat Intelligence Feeds) to lista skupiona wyłącznie na zagrożeniach: phishing, malware, scam, fake i cryptojacking. Jest to poważne wzmocnienie bezpieczeństwa, rekomendowane jako uzupełnienie listy Pro.

Razem dają ochronę, która w testach blokowania osiąga wyniki powyżej 95%.

Uwaga techniczna: Lista Pro zawiera już część wpisów z TIF z ostatnich 14 dni, ale nie pełny feed. Pełny TIF jest szerszy i obejmuje zagrożenia starsze niż 14 dni. To wyjaśnia, dlaczego łączenie obu list ma sens.

Darmowe resolvery oferujące Hagezi Pro + TIF bez rejestracji

Nie musisz mieć konta ani płacić, żeby korzystać z tych list. Kilka darmowych, non-profit resolverów oferuje gotowe presety z Hagezi Pro + TIF:

Resolver	Adres DoH	Lokalizacja	Aktualizacje	Uwagi
HaGeZi DNS (Falkenstein)	`https://root.hagezi.org/dns-query`	Niemcy (Falkenstein)	Co 4-8h	Non-profit, EU
HaGeZi DNS (Norymberga)	`https://wurzn.hagezi.org/dns-query`	Niemcy (Norymberga)	Co 4-8h	Non-profit, EU
HaGeZi DNS (Helsinki)	`https://juuri.hagezi.org/dns-query`	Finlandia (Helsinki)	Co 4-8h	Non-profit, EU
DNSWarden	`https://dns.dnswarden.com/00000000000000000000018`	Nieokreślona	Nieokreślone	Pro + TIF
DNSBUNKER.org	`https://dnsbunker.org/dns-query`	Niemcy	Nieokreślone	Pro++ + TIF + NRD/DGA
OpenBLD.net	`https://ric.openbld.net/dns-query/hagezi`	Europa	Co godzinę	Pro + TIF w trybie RIC
RethinkDNS	`https://sky.rethinkdns.com/1:AAoACBAA`	Cloudflare	Raz w tygodniu	Pro + TIF

Od czego zacząć, jeśli nie chcesz się rejestrować

Zacznij od HaGeZi DNS z serwera Falkenstein (https://root.hagezi.org/dns-query). Nie wymaga konta, działa w Europie, aktualizuje listy co kilka godzin. To najprostsza droga do Hagezi Pro + TIF. Jeśli chcesz samodzielnie wybrać listy, użyj generatora RethinkDNS na https://rethinkdns.com/configure albo DNSWarden na https://dnswarden.com/customfilter.html. Jeśli potrzebujesz logów i własnych reguł, wybierz NextDNS.

Generatory własnych konfiguracji

Jeśli chcesz samodzielnie wybrać, które listy mają być aktywne, masz dwa narzędzia.

RethinkDNS oferuje generator konfiguracji pod adresem https://rethinkdns.com/configure. Możesz tam zaznaczyć dokładnie te listy, które Cię interesują (np. Hagezi Pro i Hagezi TIF), a następnie skopiować wygenerowany link DoH lub DoT. RethinkDNS udostępnia oba formaty – wystarczy kliknąć, żeby przełączyć między nimi. Zaleta: pełna kontrola. Wada: aktualizacje raz w tygodniu.

DNSWarden oferuje podobny generator pod adresem https://dnswarden.com/customfilter.html. Pozwala wybrać listy z predefiniowanego zestawu, w tym Hagezi Pro i TIF, i wygenerować własny link DoH, DoT lub DoQ. Nie wymaga rejestracji. DNSWarden udostępnia też gotowe presety, na przykład https://dns.dnswarden.com/00000000000000000000018 dla Hagezi Pro + TIF.

Inne opcje z własnym panelem

Resolver	Adres DoH	Filtrowanie	Konto?
NextDNS	`https://dns.nextdns.io/twoj-id`	Pełna konfiguracja, własne listy, logi	Tak (darmowy plan, 300k zapytań)
Control D	`https://freedns.controld.com/x-hagezi-proplus`	Hagezi Pro Plus	Nie (darmowy preset)
AdGuard DNS	`https://dns.adguard-dns.com/dns-query`	Reklamy, trackery, malware	Nie

NextDNS to najpotężniejsza opcja. W darmowym planie dostajesz 300 000 zapytań miesięcznie, co dla jednej osoby jest praktycznie nieosiągalne. Możesz wybierać listy blokujące, tworzyć własne reguły, przeglądać logi.

Control D w wersji darmowej nie ma panelu, ale udostępnia gotowe resolvery z listami Hagezi. Adres x-hagezi-proplus to bardzo agresywny zestaw, który blokuje reklamy, trackery, malware i phishing.

Konfiguracja krok po kroku

1. Konto Proton VPN

Załóż darmowe konto na protonvpn.com. Nie musisz podawać danych osobowych. Wystarczy adres e-mail.

2. Plik WireGuard z Protona

Zaloguj się na account.protonvpn.com/downloads, wybierz WireGuard, a następnie wybierz serwer. Dla darmowego planu wybierz jeden z 10 dostępnych krajów. Polska jest jedną z opcji.

Wybór serwera a IPv6: Obsługa IPv6 w Proton VPN zależy od platformy. Oficjalnie IPv6 jest wspierane w rozszerzeniu przeglądarki oraz w kliencie na Linuksa. Na pozostałych platformach (Windows, macOS, iOS) Proton domyślnie blokuje cały wychodzący ruch IPv6, aby zapobiec wyciekom. Około 80% serwerów Proton jest kompatybilnych z IPv6. Jeśli chcesz korzystać z IPv6 przez tunel na Androidzie, wybierz serwer oznaczony jako IPv6 (np. PL-FREE#17). Serwer CH-FREE#2 jest kompatybilny z IPv6, ale wymaga ręcznej konfiguracji adresu ULA (fd54:...) zamiast domyślnego adresu 2a07:....

Pobierz plik .conf. Nie musisz go edytować. WG Tunnel i tak użyje własnego DNS.

3. Konfiguracja WG Tunnel

Otwórz WG Tunnel i zaimportuj plik .conf z Protona.

Następnie przejdź do Ustawienia → DNS settings i ustaw:

Tunnel DNS mode: Encrypted
Tunnel DNS Protocol: DoH
Tunnel DNS Endpoint: wklej adres wybranego resolvera, na przykład https://root.hagezi.org/dns-query
Transit DNS requests: Redirect (przekierowuje zapytania do innych serwerów DNS na ten z tunelu)

Zapisz ustawienia.

4. Połączenie i weryfikacja

Połącz tunel. Następnie wejdź na https://adblock.turtlecute.org/ i sprawdź, ile procent reklam i trackerów jest blokowanych. Powinieneś zobaczyć wynik powyżej 90%.

Możesz też wejść na ipleak.net i sprawdzić, czy DNS nie wycieka. Powinien być widoczny tylko resolver, którego używasz. Upewnij się, że na liście nie pojawia się adres DNS Twojego dostawcy internetu.

Czego się spodziewać

Blokowanie reklam i trackerów. W zależności od wybranego resolvera i list, zablokujesz od 90 do 97 procent reklam i trackerów. Hagezi Pro + TIF daje najlepsze wyniki, ale może czasem zablokować coś, czego potrzebujesz. Wtedy dodaj domenę do wyjątków (jeśli resolver na to pozwala) albo wybierz mniej agresywną listę.

Szyfrowany DNS. Twoje zapytania DNS będą szyfrowane end-to-end. Proton nie zobaczy, o co pytasz. Operator sieci też nie.

Stabilność połączenia. WG Tunnel działa stabilnie, ale nie jest tak dojrzały jak standardowy WireGuard. W nowszych wersjach naprawiono problemy z baterią, a deweloper aktywnie rozwija projekt. Jeśli zauważysz problemy, wróć do standardowego klienta i zaakceptuj plain DNS.

Podsumowanie

Darmowy Proton VPN to dobry tunel. Brakuje mu filtrowania DNS, ale można to obejść. WG Tunnel plus resolver DoH z listami Hagezi Pro + TIF daje Ci to, czego brakuje w darmowym planie: blokowanie reklam, trackerów, malware i phishingu, oraz szyfrowanie zapytań DNS przed wszystkimi pośrednikami.

Nie musisz płacić, żeby mieć prywatny i filtrowany DNS. Musisz tylko wiedzieć, jak go skonfigurować.

Cyfrowa higiena bez wymówek: Czy warto aktualizować telefon? Brudny sekret przycisku „Przypomnij później”

Eteryu — Mon, 31 Aug 2026 00:00:00 +0000

Zauważyłem to u swojej żony, jednak szybko dotarło do mnie, że problem ten ma skalę globalną. Przyznam szczerze: sam też kiedyś tak robiłem, dopóki nie zrozumiałem, co tak naprawdę kryje się pod maską tych irytujących powiadomień. Na ekranie pojawia się komunikat o dostępnej aktualizacji systemu lub aplikacji, a nasz palec automatycznie wędruje w stronę przycisku „Przypomnij później”. Tydzień później sytuacja się powtarza. Kiedy pytam o powód, słyszę żelazny argument: "A po co mi to? Przecież teraz wszystko działa".

Większość z nas traktuje aktualizacje oprogramowania jak zło konieczne. Kojarzą nam się z długim restartem telefonu w najmniej odpowiednim momencie, zmianą wyglądu ulubionej aplikacji albo obawą, że nowa wersja spowolni urządzenie. Niestety w dzisiejszym internecie takie podejście to odpowiednik zignorowania pilnego wezwania z salonu samochodowego o wadliwych hamulcach tylko dlatego, że rano silnik odpalił bez problemu.

Czas odczarować mit aktualizacji.

Psychologia przycisku „Przypomnij później”

Dlaczego tak bardzo nienawidzimy aktualizować naszych urządzeń? Psychologia i branża IT doskonale znają ten mechanizm. Odkładamy to na później z czterech głównych powodów:

Boję się, że coś się zepsuje. Każdy ma znajomego (albo sam nim jest), któremu po aktualizacji systemu przestała działać drukarka lub telefon zaczął szybciej rozładowywać baterię.
Nie lubię zmian. Zwyczajnie boimy się, że deweloperzy znowu przenieśli nasz ulubiony przycisk w inne miejsce i będziemy musieli uczyć się interfejsu na nowo.
Nie teraz! Komunikaty o aktualizacji zawsze wyskakują w momencie, gdy jesteśmy w środku ważnej pracy lub piszemy pilną wiadomość.
Brak miejsca na dysku. To szara proza życia. Smartfony pękają w szwach od zdjęć i filmów, a nowa paczka aktualizacyjna wymaga zwolnienia nierzadko kilku gigabajtów pamięci. O wiele łatwiej jest kliknąć „Przypomnij później”, niż decydować, które wspomnienia z wakacji usunąć.

Problem polega na tym, że to "później" zazwyczaj zamienia się w "nigdy". A to najgorszy możliwy scenariusz dla bezpieczeństwa Twoich danych.

Brudny sekret aktualizacji: Syndrom darmowego ślusarza

Większość użytkowników myśli, że paczka aktualizacyjna przynosi po prostu nowe funkcje, takie jak dodatkowe ikony, zaokrąglone rogi czy tryb ciemny. Prawda wygląda zgoła inaczej.

Przeważająca większość aktualizacji (zwłaszcza tych mniejszych, oznaczonych numerami w stylu x.x.1) to krytyczne łatki bezpieczeństwa, czyli tak zwane Security Patches.

Wyobraź sobie, że producent zamków w Twoich drzwiach wejściowych dzwoni z pilną informacją. Złodzieje właśnie odkryli, że ten konkretny model można otworzyć za pomocą zwykłej spinki do włosów. Producent natychmiast wysyła pod Twój dom ślusarza, który za darmo i w pięć minut chce wymienić zamek na nowy, w pełni bezpieczny model.

Kliknięcie „Przypomnij później” na ekranie telefonu to nic innego, jak zatrzaśnięcie drzwi przed nosem tego ślusarza i pójście spać z nadzieją, że nikt w nocy nie przyjdzie ze spinką.

FAKT Z BRANŻY: Badania Ponemon Institute wskazują, że aż 60% ofiar naruszeń danych (data breaches) przyznaje, iż do udanego włamania doszło wyłącznie z powodu wykorzystania znanej, ale niezałatanej przez nich luki w oprogramowaniu.

N-Day: Hakerzy szarpią za każdą klamkę

W filmach hakerzy włamują się do systemów za pomocą tak zwanych ataków Zero-Day. To potężne, nieznane nikomu luki w oprogramowaniu warte miliony dolarów. Zejdźmy jednak na ziemię. Zwykły użytkownik pada ofiarą ataków typu N-Day.

Co to oznacza w praktyce? Kiedy Apple, Google czy Microsoft publikują aktualizację naprawiającą błąd, dołączają do niej dokumentację techniczną. To trochę tak, jakby producent opublikował w porannej gazecie artykuł: "Naprawiliśmy błąd, przez który zamki w domach na osiedlu X można było otworzyć spinką".

Przestępcy natychmiast czytają tę gazetę i poddają łatkę inżynierii wstecznej. Zyskują w ten sposób gotowy, darmowy przepis na włamanie. Wiedzą doskonale, że łatka już istnieje, ale mają też pełną świadomość, że miliony ludzi zignorowało wirtualnego ślusarza. Uruchamiają więc zautomatyzowane boty, które niczym złodzieje biegnący przez osiedle nocą, szarpią za absolutnie każdą klamkę. Zalogują się tylko tam, gdzie drzwi same ustąpią.

Włamania te udają się nie dlatego, że nie było obrony. Udają się dlatego, że ofierze nie chciało się tej obrony zainstalować.

Co najgorsze, współcześni przestępcy wcale nie potrzebują Twojej pomocy. Klasyczna wymówka: "Przecież uważam na to co robię i nie klikam w podejrzane linki" przestała działać lata temu. Najdroższe i najbardziej niebezpieczne wektory włamań to dzisiaj tak zwane Zero-Click Exploits. To ataki, które nie wymagają od ofiary absolutnie żadnej interakcji. Telefon zostaje zainfekowany przez sam fakt odebrania spreparowanej wiadomości (np. w iMessage czy WhatsAppie), często zanim zdążysz w ogóle wyciągnąć go z kieszeni. Jedyną tarczą przed atakiem Zero-Click jest załatana dziura w kodzie.

WYŚCIG Z CZASEM: Z regularnych analiz branży cyberbezpieczeństwa (takich jak Verizon Data Breach Investigations Report czy raporty Mandiant) płynie jasny wniosek: czas od opublikowania informacji o nowej luce do jej masowego wykorzystania przez hakerów drastycznie się kurczy. Dawniej liczono go w miesiącach, dziś to często zaledwie dni. Hakerzy wiedzą, że zwlekasz z aktualizacją, dlatego ich zautomatyzowane skanery atakują natychmiast. Jeśli ignorujesz komunikat przez miesiąc, jesteś już idealnym celem.

Jak to wdrożyć w życie? (Cyfrowa higiena)

W ramach filozofii Zero Trust nie ma miejsca na kompromisy w kwestii aktualizacji. Oto jak powinieneś skonfigurować swój system, aby przestać być najsłabszym ogniwem łańcucha bezpieczeństwa:

Włącz absolutny automatyzm. Każdy system (iOS, Android, Windows, macOS) pozwala na uruchomienie automatycznych aktualizacji w tle. Ustaw to tak, aby urządzenie pobierało i instalowało łatki w nocy, gdy jest podłączone do ładowarki i sieci Wi-Fi. Budzisz się rano, a Twój zamek jest już wymieniony bez jakiejkolwiek Twojej ingerencji.
Aktualizuj przeglądarkę natychmiast. Twoja przeglądarka internetowa to Twój główny punkt styku z groźnym światem. Jeśli Chrome, Firefox czy Brave krzyczy na czerwono i prosi o restart, zrób to w tej samej sekundzie. Tutaj naprawdę nie ma miejsca na odkładanie spraw na później.
Mniej aplikacji to mniej łat do łatania. Przejrzyj regularnie telefon i usuń programy, których nie używałeś od roku. Po co trzymać w systemie stare zamki w drzwiach, z których i tak nikt już nie korzysta, a mogą stanowić łatwe wejście dla włamywacza?
Zrozum, kiedy czas powiedzieć "do widzenia" (Problem EOL). Największym błędem jest używanie przestarzałego smartfona do logowania się do banku pod pretekstem "przecież wciąż działa". Kiedy urządzenie osiąga status End of Life (EOL) i producent oficjalnie kończy wsparcie, Twój wirtualny ślusarz na zawsze przestaje do Ciebie przyjeżdżać. Otwierasz wtedy drzwi dla hakerów na oścież. Ekologia i oszczędność są ważne, ale nie mogą odbywać się kosztem Twojego bezpieczeństwa finansowego.

Podsumowanie

Następnym razem, gdy Twoje urządzenie poprosi o restart w celu instalacji nowej wersji systemu, nie traktuj tego jako irytującej przeszkody w pracy. Potraktuj to jako darmową szczepionkę na wirusa, którego ktoś właśnie wpuścił do sieci, lub wizytę ślusarza, który za darmo dba o Twój majątek.

Odblokuj teraz swój telefon, wejdź w ustawienia i sprawdź zakładkę z aktualizacjami. Kto wie, może Twój wirtualny ślusarz właśnie czeka pod drzwiami?

Jak zabezpieczyć telefon i swoje dane w 15 minut. 4 kroki dla każdego

Eteryu — Fri, 28 Aug 2026 00:00:00 +0000

Większość poradników o prywatności w internecie zaczyna się od radykalnych kroków. Instalacja Linuxa, rezygnacja ze smartfona i kasowanie wszystkich kont w mediach społecznościowych. Efekt jest taki, że przeciętny użytkownik odbija się od ściany i wraca do starych przyzwyczajeń.

Tymczasem w cyberbezpieczeństwie doskonale sprawdza się zasada Pareta. Wdrożenie zaledwie dwudziestu procent kluczowych zabezpieczeń eliminuje osiemdziesiąt procent realnych zagrożeń.

Twój model zagrożeń to na ogół nie są wysoce wykwalifikowane służby wywiadowcze. Twoim przeciwnikiem są zautomatyzowane boty, wycieki z baz danych i masowe kampanie phishingowe.

Oto absolutne minimum cyfrowego przetrwania. Przejście przez te cztery kroki zajmuje dokładnie piętnaście minut. Wdróż je dzisiaj, wyrób w sobie prosty nawyk robienia kopii zapasowych i przestań martwić się o bezpieczeństwo swoich danych.

1. Ewakuacja pamięci, czyli menedżer haseł (5 minut)

Nigdy więcej nie używaj tego samego hasła w dwóch różnych miejscach. Ponowne użycie tego samego ciągu znaków to najczęstsza przyczyna przejęcia konta po wycieku danych z losowego sklepu internetowego. Rozwiązaniem jest bezpieczny menedżer haseł. Możesz założyć darmowe konto w sprawdzonym rozwiązaniu chmurowym (np. Bitwarden) lub zainstalować aplikację w pełni lokalną, która nie wysyła nigdzie danych (np. KeePassDX).

Taki zabieg całkowicie eliminuje problem zgadywania haseł przez zautomatyzowane algorytmy. Musisz zapamiętać tylko jedno mocne hasło główne, a całą resztę skomplikowanych ciągów znaków aplikacja uzupełni za Ciebie.

Jak przeprowadzić szybką ewakuację:

Zainstaluj wybrany menedżer haseł i utwórz niezwykle silne, ale łatwe do zapamiętania dla Ciebie hasło główne (Master Password).

Na start zmień i wygeneruj długie oraz unikalne hasła tylko do trzech krytycznych usług.

Niech to będzie Twoja główna skrzynka pocztowa, aplikacja bankowa oraz Profil Zaufany.

Ważne: Nie próbuj przenieść wszystkich swoich kont jednego dnia, ponieważ szybko się zniechęcisz. Aby utrzymać porządek, wdróż warstwowy model haseł (znany w branży jako 3 Tier Password System). Podziel swoje wpisy na trzy główne foldery. Pierwszy z nich to Krytyczne (finanse, główna poczta i dokumenty). Drugi to Codzienne (konta społecznościowe i popularne sklepy). Trzeci to z kolei Inne (jednorazowe zakupy i mało ważne fora). Jeśli wybierzesz lokalny program taki jak KeePassDX, musisz bezwzględnie pamiętać o regularnym robieniu kopii zapasowej swojej bazy. Plik z hasłami znajduje się wyłącznie w pamięci Twojego telefonu i w przypadku jego awarii bezpowrotnie stracisz wszystkie dane.

2. Drugi zamek w drzwiach, czyli kody 2FA (5 minut)

Nawet najdłuższe hasło wygenerowane przez menedżer może zostać przechwycone przez fałszywą stronę logowania. Z tego powodu potrzebujesz drugiej warstwy ochrony.

Poczta to najważniejszy punkt całego systemu, ponieważ to właśnie tam trafiają linki do resetowania haseł ze wszystkich innych portali. Nawet jeśli ktoś zdobędzie Twoje główne hasło, bez fizycznego dostępu do tokena na Twoim telefonie nie zaloguje się na pocztę. Bezwzględnie unikaj weryfikacji przez wiadomości tekstowe, ponieważ są one podatne na przechwycenie oraz ataki polegające na duplikacji karty SIM (tzw. SIM swapping).

Jak wdrożyć kody 2FA w praktyce:

Zainstaluj aplikację typu authenticator (polecam otwarte rozwiązania takie jak Aegis, Ente Auth lub 2FAS).

Zaloguj się na swoją główną skrzynkę pocztową w przeglądarce i wejdź w ustawienia bezpieczeństwa.

Znajdź opcję logowania dwuetapowego (często nazywaną 2FA lub Aplikacja uwierzytelniająca).

Zeskanuj wyświetlony kod QR za pomocą zainstalowanej przed chwilą aplikacji.

Ważne: Podczas konfiguracji system wygeneruje listę jednorazowych kodów awaryjnych. Zawsze przechowuj je w bezpiecznym miejscu – najlepiej je wydrukuj. W przypadku utraty lub awarii telefonu to one będą Twoim jedynym kołem ratunkowym. Identyczna zasada dotyczy samej aplikacji do kodów. Pamiętaj o regularnym eksportowaniu zaszyfrowanej kopii zapasowej swojej bazy tokenów bezpośrednio z ustawień aplikacji, aby nie stracić dostępu do kont w razie uszkodzenia lub kradzieży urządzenia.

3. Oślepienie trackerów na poziomie DNS (3 minuty)

Możesz instalować dziesiątki rozszerzeń blokujących reklamy w przeglądarce, ale nie ochronią one systemu operacyjnego ani poszczególnych aplikacji przed wysyłaniem telemetrii. Najskuteczniejsza blokada działa na poziomie całej sieci. Taka konfiguracja drastycznie zmniejsza powierzchnię ataku bez konieczności instalowania jakichkolwiek dodatkowych programów.

AndroidApple (iOS / macOS)

Wejdź w ustawienia systemowe i odszukaj opcję Prywatny DNS (zazwyczaj w zakładce Sieć i internet). Zamiast opcji automatycznej wybierz ręczne wprowadzanie nazwy hosta, wpisz adres wybranego dostawcy i zapisz zmiany.

Wejdź na stronę internetową wybranego dostawcy i pobierz z niej zaufany profil konfiguracyjny (Configuration Profile), który natywnie zmieni serwery w systemie. Zatwierdź instalację profilu w ustawieniach urządzenia.

4. Autopilot bezpieczeństwa i aktualizacje (2 minuty)

Stare oprogramowanie to dziurawe oprogramowanie. Hakerzy nie muszą wymyślać nowych metod ataku, jeśli użytkownicy sami zapominają o łataniu znanych luk bezpieczeństwa. Włącz w ustawieniach systemu oraz sklepu z aplikacjami bezwarunkowe i automatyczne aktualizacje. Dla zdecydowanej większości użytkowników takie łatki to jedyna linia obrony przed atakami wykorzystującymi znane podatności.

Warto wiedzieć: Puryści cyfrowej higieny często zarządzają swoimi aplikacjami ręcznie i weryfikują sygnatury pobierając kod bezpośrednio z repozytoriów za pomocą narzędzi takich jak Obtainium. Jest to doskonała praktyka zapewniająca pełną suwerenność, ale wymaga ona rygorystycznej dyscypliny.

Na początku drogi z cyfrową higieną włączenie pełnej automatyzacji to po prostu konieczny i mądry kompromis, który ratuje nas przed własnym zapominalstwem.

Podsumowanie

Te cztery kroki to absolutny fundament przetrwania w sieci. Wdrożenie ich zajmuje zaledwie kwadrans, a odpowiednio skonfigurowany system zaczyna natychmiast pracować na Twoją korzyść. Nie musisz zamykać się w cyfrowym bunkrze. Wystarczy po prostu przestać zostawiać otwarte drzwi do własnego domu.

Prywatny DNS – co to jest i dlaczego musisz go mieć? Wyjaśniam w 5 minut

Eteryu — Fri, 28 Aug 2026 00:00:00 +0000

W jednym z ostatnich wpisów pokazałem, jak w kilkanaście minut zabezpieczyć telefon przed większością realnych zagrożeń. Wspomniałem tam o zmianie serwerów DNS jako absolutnym fundamencie cyfrowej higieny. Temat potraktowałem jednak bardzo skrótowo, co wywołało w komentarzach słuszny niedosyt.

Obiecałem rozwinąć ten wątek i wyjaśnić całą mechanikę w sposób przystępny dla osób nietechnicznych. Czas obietnicę spełnić. Zobaczmy, co dokładnie dzieje się pod maską Twojego urządzenia, gdy wpisujesz adres strony internetowej, i dlaczego przejęcie kontroli nad tym procesem to Twoja najważniejsza tarcza obronna.

1. Czym tak naprawdę jest DNS?

Najpopularniejsza definicja mówi, że DNS (Domain Name System) to internetowa książka adresowa. Ty zapamiętujesz przyjazne i łatwe do wymówienia nazwy witryn, ale komputery oraz routery komunikują się ze sobą wyłącznie za pomocą ciągów cyfr, czyli adresów IP.

Kiedy wpisujesz w przeglądarce adres mojego bloga, Twój telefon nie ma pojęcia, gdzie fizycznie znajduje się serwer, z którym musi się połączyć. Musi najpierw wysłać zapytanie w świat i zapytać o konkretny numer docelowy.

Samo porównanie do prostej książki telefonicznej jest jednak sporym uproszczeniem. DNS to w rzeczywistości potężna, globalna sieć współpracujących ze sobą centrali, pozbawiona jednej głównej bazy danych. Aby lepiej to zrozumieć, wyobraź sobie wyspecjalizowany serwer DNS (nazywany fachowo rekursywnym resolverem) jako Twojego osobistego Asystenta.

Oto droga, jaką ten Asystent musi pokonać w ułamku sekundy po kliknięciu linku:

Pamięć podręczna (Cache): Zanim zapytanie trafi do sieci, lokalny resolver w systemie operacyjnym Twojego urządzenia lub w routerze sprawdza własną pamięć podręczną. Asystent zagląda do podręcznego notatnika. Jeśli ktoś niedawno pytał o tę samą stronę, adres IP jest gotowy do podania, co drastycznie skraca czas ładowania i zmniejsza ruch w sieci. Połączenie następuje natychmiast.
Główna centrala (Root Servers): Jeśli adresu brakuje w notatniku, Asystent udaje się do głównych zarządców internetu. To fundament całej sieci oparty na trzynastu potężnych klastrach serwerów rozmieszczonych na całym świecie. Oni nie znają dokładnego adresu docelowej witryny, ale wiedzą, kto zarządza wszystkimi adresami z daną końcówką i tam kierują Asystenta.
Kierownik strefy (TLD Servers): Asystent trafia do serwera zarządzającego daną domeną najwyższego poziomu, na przykład obsługującego końcówki .pl, .net lub .space. Ten serwer posiada już informacje o rejestratorze, u którego właściciel wykupił konkretny adres, i podaje Asystentowi odpowiednie namiary.
Właściwe źródło (Authoritative Name Server): Asystent dociera w końcu do autorytatywnego serwera, który fizycznie odpowiada za poszukiwaną domenę. To on posiada ostateczną władzę nad domeną i przechowuje rekordy z właściwym adresem IP. Nie musi już komunikować się z innymi serwerami, po prostu wydaje Asystentowi ostateczny wynik.
Powrót z adresem: Asystent wraca do Twojej przeglądarki z konkretnym ciągiem cyfr, zapisuje go w swoim notatniku na przyszłość, a Ty widzisz poprawnie załadowaną stronę internetową.

2. Dlaczego domyślny DNS to luka w prywatności?

Po wyjęciu smartfona z pudełka i pierwszym połączeniu z siecią, Twoje urządzenie domyślnie korzysta z Asystenta przydzielonego przez dostawcę internetu lub operatora sieci komórkowej. To ogromny błąd z punktu widzenia cyfrowej higieny.

Twój operator dokładnie widzi, o jakie adresy pyta Twoje urządzenie. Zna całą historię zapytań systemowych. Wie, kiedy korzystasz z aplikacji bankowej, z jakiego komunikatora wysyłasz wiadomości i jakie konkretnie serwisy odwiedzasz po zmroku. Co gorsza, klasyczne zapytania przesyłane są jawnym tekstem. Nawet jeśli sama strona WWW jest w pełni zabezpieczona kłódką szyfrowania, każdy punkt pośredniczący w sieci i tak doskonale widzi, z jaką domeną próbujesz nawiązać połączenie.

To czyste profilowanie behawioralne podane wielkim korporacjom niemalże na tacy.

3. Aktywna tarcza, czyli jak działa Prywatny DNS

Odzyskanie kontroli polega na zwolnieniu Asystenta narzuconego przez operatora i zatrudnieniu własnego, wysoce zaufanego dostawcy Prywatnego DNS, który deklaruje rygorystyczną politykę nieprzetrzymywania logów aktywności. Taka zmiana wprowadza dwa potężne mechanizmy obronne.

Szyfrowana koperta (DoH oraz DoT)

Twój nowy zaufany dostawca umieszcza wszystkie zapytania wychodzące z telefonu w zaszyfrowanym tunelu. Wykorzystuje do tego nowoczesne protokoły bezpieczeństwa. Tryb prywatny opiera się najczęściej na standardzie DNS over TLS (DoT) lub DNS over HTTPS (DoH). Dzięki wykorzystaniu kryptografii Twój dostawca internetu widzi jedynie sam fakt łączenia się z bezpiecznym serwerem DNS, tracąc bezpośredni wgląd w to, o jakie domeny pyta Twój system. Odcinasz mu w ten sposób najprostszą i najbardziej jawną drogę do śledzenia Twojej aktywności.

Cyfrowa czarna dziura (Sinkholing)

To absolutnie najważniejsza funkcja z perspektywy brutalnego odcinania telemetrii. Zaufany serwer DNS posiada wbudowane i nieustannie aktualizowane listy zagrożeń. Działa to jak potężny filtr ruchu sieciowego blokujący podejrzane zapytania bazując na znanych czarnych listach. Kiedy jakakolwiek usługa lub aplikacja działająca w tle na Twoim telefonie próbuje wysłać dane do serwera śledzącego, wysyła Asystenta po docelowy numer IP.

Asystent przed wyjściem w świat rzetelnie sprawdza swoją lokalną listę. Widzi jasno, że to domena przeznaczona do zbierania informacji o użytkownikach. W tym momencie odmawia wykonania polecenia. Wraca do aplikacji i kłamie, twierdząc, że taki adres w ogóle w internecie nie istnieje (najczęściej zwracając tak zwany pusty pakiet lub niefunkcjonalny adres zerowy).

Dzięki technice Sinkhole aplikacja kompletnie nie potrafi nawiązać szkodliwego połączenia. Złośliwa reklama się nie ładuje. Skrypty analityczne uderzają w próżnię, a Twoja prywatna telemetria pozostaje bezpiecznie na urządzeniu.

W ten sposób, dokonując jednej bardzo prostej zmiany w ustawieniach systemu, natychmiastowo oślepiasz skrypty śledzące we wszystkich zainstalowanych aplikacjach naraz, absolutnie nie obciążając przy tym baterii telefonu.

4. Jak wdrożyć własnego Asystenta? Praktyka dla każdego

Teoria zawsze brzmi wspaniale, ale jak przełożyć to wszystko na praktykę? Obecnie jest to wyjątkowo proste i nie wymaga dyplomu z informatyki.

Dla niespecjalistów szukających błyskawicznego rozwiązania w chmurze, idealnym wyborem są usługi takie jak NextDNS, Control D czy też AdGuard DNS. Pozwalają one na założenie darmowego konta, w którym z poziomu intuicyjnego panelu sami decydujemy, jak agresywnie chcemy wycinać reklamy i skrypty śledzące. Alternatywą dla entuzjastów kontroli nad własnym sprzętem jest postawienie lokalnego rozwiązania typu Pi-hole na minikomputerze Raspberry Pi, które działa jako domowy mechanizm Sinkhole dla wszystkich podpiętych do routera urządzeń. Zostańmy jednak przy prostej chmurze.

Apple (iOS / macOS)Android

Użytkownicy sprzętu od Apple mają ułatwione zadanie. Zarówno system iPhone'a jak i Maca natywnie wspierają szyfrowane protokoły DNS bez konieczności instalowania zasobożernych aplikacji firm trzecich.

Wystarczy u wybranego dostawcy (na przykład NextDNS) wygenerować specjalny profil konfiguracyjny (niewielki plik o rozszerzeniu ukrytym pod nazwą .mobileconfig) i jednym kliknięciem zatwierdzić jego instalację w ustawieniach urządzenia. Od tej sekundy cały ruch automatycznie ląduje w zaszyfrowanym tunelu.

W nowszych odsłonach oprogramowania z zielonym robotem proces ten zajmuje dosłownie trzydzieści sekund.

Wystarczy otworzyć systemowe ustawienia sieciowe, wpisać w wewnętrzną wyszukiwarkę hasło Prywatny DNS, a następnie podać unikalny adres serwera wygenerowany przez naszego zaufanego operatora w wybranym profilu. System sam w sposób zautomatyzowany przejmie pełną kontrolę nad szyfrowaniem.

Tym jednym konkretnym ruchem zatrzaskujesz cyfrowe drzwi przed wścibskimi operatorami oraz masową machiną inwigilacji reklamowej. Twój nowy Asystent w końcu zaczyna pracować wyłącznie w interesie Twoim, a nie potężnych korporacji.

Cyfrowa higiena bez złudzeń. Dlaczego Twoja klawiatura to legalny keylogger?

Eteryu — Thu, 27 Aug 2026 00:00:00 +0000

Kiedy myślimy o prywatności w smartfonie, instynktownie zaklejamy kamerę, blokujemy dostęp do mikrofonu i wyłączamy usługi lokalizacji. Zżera nas niepokój o to, że aplikacje mogą nas podsłuchiwać. Tymczasem często dobrowolnie oddajemy wszystkie nasze najskrytsze myśli, wpisywane hasła, numery kart, zapytania w wyszukiwarce i intymne wiadomości jednemu niepozornemu elementowi systemu. Tym elementem jest klawiatura ekranowa.

W dopełnieniu koncepcji Zero Trust czas zająć się dwoma najbardziej newralgicznymi i najczęściej ignorowanymi komponentami mobilnymi, czyli klawiaturą oraz schowkiem systemowym.

Klawiatura: legalny keylogger w Twojej kieszeni

Domyślne klawiatury dostarczane ze współczesnymi systemami, z Google Gboard na czele, to zaawansowane koszmary telemetryczne. Pod przykrywką wygody w postaci autokorekty, podpowiedzi słów i naklejek, nieustannie mapują one Twój styl pisania oraz nawyki językowe.

Narzędzia te zbierają nie tylko słowniki Twoich prywatnych fraz, ale budują całe profile behawioralne w oparciu o analizę dynamiki uderzeń w klawisze. Mierzą tempo pisania, długość przerw i specyfikę popełnianych błędów. Co gorsza, lokalne słowniki automatyczne potrafią zapamiętywać i po czasie podpowiadać poufne dane takie jak numery PIN, frazy z menedżera haseł czy dolegliwości wpisywane w oknie wyszukiwarki.

[ ZAGROŻENIE: Telemetryczna klawiatura domyślna ]

 Uderzenie w klawisz ──► [ KLAWIATURA (np. Gboard) ] ──► [ Słownik lokalny / AI ]
                                   │
                                   ▼ (Telemetria i statystyki)
                       [ SERWERY GOOGLE / CLOUD ]


[ ROZWIĄZANIE: Odizolowana maszyna do pisania ]

 Uderzenie w klawisz ──► [ HELIBOARD / FUTO ] ──► System Android (AOSP)
                                   │
                                ( X ) ──► BRAK INTERNETU / ZABLOKOWANY FIREWALL

Jak okiełznać klawiaturę? Strategia dla iOS oraz Androida

Problem ten można rozwiązać na dwa sposoby, w zależności od używanego ekosystemu.

1. iOS i metoda prymitywnej maszyny do pisania

W zamkniętym ekosystemie Apple instalowanie zewnętrznych klawiatur bywa problematyczne pod kątem uprawnień. Producent chwali się wprawdzie prywatnością różnicową (Differential Privacy) i przetwarzaniem danych głównie na samym urządzeniu, jednak w myśl zasady ograniczonego zaufania nie chcemy, aby system tworzył jakiekolwiek słowniki naszych zachowań. Najskuteczniejszą metodą jest w tym przypadku całkowite ograniczenie funkcji klawiatury systemowej.

Wchodzisz w ustawienia ogólne, następnie w zakładkę klawiatury i wyłączasz absolutnie wszystko. Zaznacz do wyłączenia autokorektę, sprawdzanie pisowni, podpowiedzi tekstowe oraz automatyczne wielkie litery. Klawiatura zostaje wtedy sprowadzona do roli prymitywnej maszyny do pisania. Jej zadaniem jest po prostu wprowadzanie znaków bez semantycznej analizy tekstu, bez próby zgadywania Twoich intencji i bez budowania lokalnego indeksu haseł.

2. Android, bezpieczne alternatywy i fizyczne odcięcie sieci

Środowisko Androida daje pełną wolność i pozwala na całkowite usunięcie klawiatury producenta. Najlepsze i zorientowane na prywatność alternatywy to obecnie HeliBoard oraz FUTO Keyboard.

Co sprawia, że są one bezpieczne?

Przejrzystość kodu: HeliBoard to projekt w pełni darmowy i otwartoźródłowy na licencji FOSS. Z kolei FUTO Keyboard nie posiada wprawdzie ścisłej licencji FOSS, ale udostępnia swój kod do pełnego wglądu i gwarantuje bezpieczeństwo dzięki działaniu wyłącznie w trybie offline. Obie aplikacje są pozbawione modułów śledzących.
Brak uprawnienia do sieci: HeliBoard na poziomie manifestu aplikacji w ogóle nie deklaruje dostępu do internetu (android.permission.INTERNET). Fizycznie nie posiada w kodzie funkcji pozwalającej na połączenie z siecią, więc nie wyśle telemetrii. Podobną filozofię ścisłego odcięcia od sieci stosuje FUTO.
Awaryjna zapora sieciowa: Jeśli z jakiegoś powodu musisz korzystać ze standardowej klawiatury systemowej, użyj lokalnego firewalla takiego jak RethinkDNS. Zablokuj w nim ruch sieciowy dla aplikacji klawiatury na poziomie pakietowym.
Wyłączone uczenie i lokalne słowniki: Nawet jeśli klawiatura jest fizycznie odcięta od sieci, w jej ustawieniach bezwzględnie wyłącz opcje uczenia się wpisywanego tekstu. Dlaczego? Twój lokalny słownik z hasłami może zostać mimowolnie wysłany na serwery przez systemową kopię zapasową (Cloud Backup). Ponadto nadgorliwe podpowiedzi mogą zdradzić Twoje hasło osobom zerkającym Ci przez ramię (tzw. shoulder surfing), a złośliwe aplikacje nadużywające uprawnień ułatwień dostępu (Accessibility Services) mogą odczytać podpowiadane wrażliwe frazy bezpośrednio z ekranu.

Schowek: otwarta księga dla aplikacji

Drugim najsłabszym ogniwem systemu jest schowek. To tymczasowy bufor pamięci RAM, do którego trafia wszystko, co skopiujesz. Są to kody jednorazowe z wiadomości SMS, hasła i tokeny dostępowe z menedżera haseł, numery kont bankowych czy adresy portfeli kryptowalutowych.

Do niedawna schowek był strefą całkowicie niechronioną (każda aplikacja w tle mogła go do woli "podsłuchiwać"). Dopiero systemy operacyjne z ostatnich lat (od iOS 14 i Androida 12) zaczęły wyświetlać wyraźne alerty o odczycie schowka. Nagle okazało się, że dziesiątki popularnych aplikacji, od sieci społecznościowych po darmowe gry, pasywnie skanowały zawartość schowka przy każdym uruchomieniu programu lub wpisaniu znaku.

Cyberzagrożenie w postaci ataków typu Clipper

Clipper to złośliwe oprogramowanie działające w tle. Monitoruje ono zawartość schowka w poszukiwaniu wzorców przypominających numery kont bankowych lub adresy kryptowalutowe. Kiedy wykryje skopiowany ciąg, w ułamku sekundy podmienia go w pamięci na adres należący do atakującego. Jeśli bezrefleksyjnie wkleisz adres i klikniesz wyślij, Twoje środki znikną bezpowrotnie.

[ ATAK TYPU CLIPPER: Podmiana bufora ]

Skopiowano:  PL 12 3456 7890 ... (Twój bank)
                    │
                    ▼
          [ ZŁOŚLIWY CLIPPER ] ──► Podmienia bufor w RAM
                    │
Wklejono:    PL 99 8765 4321 ... (Konto Hakera)


[ BEZPIECZNY SCHOWEK: Czyszczenie i izolacja ]

Menedżer haseł ──► [ SCHOWEK RAM ] ──► ( Wklejenie hasła )
                        │
                  [ TIMER 20s ] ──► ( BUFOR AUTOMATYCZNIE WYCZYSZCZONY! )

Cztery filary bezpiecznego schowka

1. Wyłącz historię schowka w klawiaturze Funkcje takie jak historia schowka w Gboardzie tworzą niezaszyfrowany i trwały rejestr wszystkiego, co zostało skopiowane w ciągu dnia. To podanie swoich haseł na talerzu. W ustawieniach klawiatury bezwzględnie wyłącz przechowywanie historii skopiowanych elementów.

2. Ustaw automatyczne czyszczenie bufora Wprawdzie system Android (od wersji 13) automatycznie czyści schowek systemowy po 60 minutach, jednak dla haseł to wciąż ogromne okno ekspozycji. Bezpieczne menedżery haseł, takie jak Bitwarden czy KeePassDX, posiadają krytyczną funkcję nadpisania i wyczyszczenia schowka po zaledwie kilkudziesięciu sekundach od skopiowania ciągu. Upewnij się, że opcja ta jest aktywna. Hasło po wklejeniu musi natychmiast znikać z pamięci RAM.

3. Restrykcyjna kontrola uprawnień w systemie W nowszych wersjach systemów (np. iOS, Android) oraz w wariantach ukierunkowanych na utwardzenie, takich jak GrapheneOS, bezwzględnie zwracaj uwagę na powiadomienia na ekranie (tzw. toast notifications) o tym, że jakaś aplikacja uzyskała dostęp do schowka. Jeśli usługa lub gra pyta o dostęp do bufora, należy natychmiast odrzucić taką prośbę lub odebrać to uprawnienie w ustawieniach.

4. Weryfikacja kontekstowa i zasada ograniczonego zaufania Nawet na utwardzonym telefonie wypracuj nawyk precyzyjnego sprawdzania danych. Przy przelewach bankowych lub przesyłaniu krytycznych danych zawsze weryfikuj pierwsze i ostatnie znaki wklejonego ciągu. To najprostsza i najskuteczniejsza tarcza na ataki typu Clipper.

Podsumowanie

Wygoda to największy wróg bezpieczeństwa. Inteligentne autokorekty, uczące się słowniki i zapamiętywanie skopiowanych haseł brzmią jak ułatwienie życia, ale generują ogromną powierzchnię ataku.

Wyciszając klawiaturę do poziomu prostej maszyny do pisania, odcinając jej dostęp do sieci oraz wymuszając automatyczne czyszczenie schowka, odzyskujesz kontrolę nad najważniejszym punktem styku z Twoim urządzeniem. Cyfrowy sejf na nic się nie zda, jeśli klawiatura sama raportuje na zewnątrz każdą kombinację cyfr, którą wprowadzasz.

Cyfrowa higiena bez czarnej magii. Czym są aliasy e-mail i dlaczego wystarczy Ci jedna skrzynka?

Eteryu — Mon, 24 Aug 2026 00:00:00 +0000

Większość dyskusji o prywatności w sieci skupia się na przeglądarkach, trackerach czy sieciach VPN. Bardzo często zapominamy jednak o elemencie, który identyfikuje nas w internecie mocniej niż odcisk palca — naszym głównym adresie e-mail.

W dzisiejszym internecie Twój e-mail to odpowiednik cyfrowego numeru PESEL. Podajesz go w banku, przy zakupie butów, rejestracji na forum dyskusyjnym czy odbieraniu darmowego e-booka. Efekt? Brokerzy danych z łatwością łączą Twoje aktywności z setek różnych serwisów w jeden spójny profil, a każdy wyciek bazy danych w losowym sklepie oznacza falę spamu i phishing na Twojej głównej skrzynce.

Kiedy pojawia się temat obrony, wielu użytkowników uważa stosowanie aliasów pocztowych za "czarną magię" lub decyduje się na zakładanie kilku osobnych, fizycznych kont pocztowych. Czas to odczarować.

Czym tak naprawdę jest alias pocztowy?

Alias e-mail nie jest nowym kontem pocztowym. Nie wymaga rejestracji nowej skrzynki, wymyślania kolejnego hasła ani konfigurowania osobnego logowania dwuskładnikowego (2FA).

Wyobraź sobie, że Twoja prawdziwa skrzynka pocztowa to pancerny, dobrze strzeżony sejf. Zamiast dawać każdemu klucz do drzwi frontowych, instalujesz w ścianie setki jednorazowych wrzutni na listy. Każdy sklep czy portal wrzuca korespondencję do innej wrzutni, a wszystkie listy i tak lądują w tym samym sejfie. Jeśli jedna wrzutnia zacznie przeciekać — po prostu ją zamurowujesz jednym ruchem.

Alias to wirtualny, tymczasowy lub stały adres-przekaźnik, który przechwytuje pocztę, oczyszcza ją i bezpiecznie przesyła dalej do Twojej skrzynki głównej.

Mit "Konta A i Konta B" (Zasada KISS)

Częstym błędem jest tworzenie osobnych skrzynek: jednej do banku, drugiej do zakupów, trzeciej na spam. Prowadzi to do niepotrzebnego skomplikowania (overengineeringu), konieczności ciągłego przelogowywania się i chaosu zarządzania hasłami.

W paradygmacie Zero Trust i prostoty (KISS) wystarczy jedno główne konto bazowe, którego adresu nikt na zewnątrz nie zna.

[ MIT: Złudzenie bezpieczeństwa (3 osobne konta) ]

Sklep internetowy  ──► [ Skrzynka A: Śmieciowa ] ──► Osobny login, hasło i 2FA
Bank / Urząd       ──► [ Skrzynka B: Ważna ]     ──► Osobny login, hasło i 2FA
Znajomi / Praca    ──► [ Skrzynka C: Prywatna ]  ──► Osobny login, hasło i 2FA


[ FAKT: Tarcza Aliasów (1 dobrze strzeżony skarbiec) ]

Sklep internetowy  ──► [ alias-buty@anonaddy.me ] ──┐
Bank / Urząd       ──► [ bank.91x@twojadomena.pl] ─┼─► [ SERWIS ALIASÓW ] ══► [ GŁÓWNY E-MAIL ]
Newsletter         ──► [ promo.123@anonaddy.me ] ───┘    (Addy / SL)          (Tuta / Proton)

Trzy filary obrony: Przed czym chronią Cię aliasy?

1. Izolacja wycieków baz danych (Data Breaches) Gdy sklep internetowy padnie ofiarą ataku hakerskiego, do sieci wycieka wyłącznie wygenerowany dla niego alias. Twój prawdziwy adres e-mail pozostaje w 100% niewidoczny. Gasisz pożar jednym kliknięciem, bez panicznej zmiany haseł wszędzie indziej.

WYCIEK BAZY DANYCH W USŁUDZE "X":

[ Atakujący ] ──► Kradnie alias: sklep-x@anonaddy.me
                         │
                         ▼
               [ Panel Menedżera Aliasów ]
                         │
 [ WYŁĄCZASZ SUWAK ] ──( X )──► RUCH ZABLOKOWANY!
                         │
             [ Twoja Główna Skrzynka ] ──► Czysta i nienaruszona

2. Oślepienie brokerów danych (Cross-Site Tracking) Użycie unikalnego aliasu do każdej usługi niszczy wspólny identyfikator. Korporacje i algorytmy nie są w stanie łatwo połączyć Twojej aktywności z forum hobbystycznego z zakupami w aptece.

3. Zero-jedynkowy wykrywacz spamu Jeśli na alias wygenerowany wyłącznie dla sklepu meblowego nagle zaczną przychodzić oferty szybkich pożyczek, masz twardy dowód na to, kto sprzedał Twoje dane lub doprowadził do ich wycieku.

A co jeśli muszę odpisać?

To najczęstsza obawa. Użytkownicy pytają: "Jeśli kliknę Odpowiedz w swojej skrzynce, mój prywatny e-mail się zdemaskuje!".

Nic z tych rzeczy. Serwisy takie jak Addy.io czy SimpleLogin obsługują tzw. adresy zwrotne (Reverse Aliases), rozwiązując ten problem w genialny sposób.

Gdy dostajesz e-maila ze sklepu na swój alias, serwis przekaźnikowy podmienia w nim adres nadawcy na długi, specjalnie wygenerowany ciąg znaków. Kiedy klikasz "Odpowiedz" w swoim kliencie poczty, wysyłasz wiadomość właśnie na ten techniczny adres. Serwis odbiera ją, podmienia nagłówki w locie i przesyła do sklepu tak, jakby została wysłana prosto z Twojego aliasu. Pełne maskowanie w obie strony.

Jak wdrożyć to u siebie? (Mit abonamentowej pułapki)

Wdrożenie tej architektury jest banalnie proste. Zbudowanie szczelnego systemu prywatności nie oznacza też wpadnięcia w abonamentową studnię bez dna. Własna domena (jak moja eteryu.space) to luksus i kaprys, a nie wymóg technologiczny do zbudowania osobistego, darmowego systemu.

Darmowe plany mają haczyki

Zarówno Addy.io, jak i SimpleLogin oferują darmowe plany, ale każdy z nich ma inne ograniczenie. Wybór między nimi zależy od tego, czy częściej odbierasz pocztę, czy musisz na nią odpowiadać. Poniżej rozbijam to na czynniki pierwsze.

Oto jak mądrze żonglować opcjami i jakie narzędzia masz do wyboru:

1. Mainstreamowe, wbudowane rozwiązania (Dla początkujących) Jeśli używasz sprzętu Apple i masz subskrypcję iCloud+, masz już wbudowaną funkcję Ukryj mój e-mail (Hide My Email). Świetną, w 100% darmową alternatywą, która również pozwala na bezpośrednie odpisywanie z aliasów bez ujawniania tożsamości, jest z kolei DuckDuckGo Email Protection (@duck.com). To dowód na to, że aliasy to dziś rynkowy standard.

2. Dedykowane serwisy open-source (Dla wymagających) Otwartym standardem rynkowym dla zaawansowanych użytkowników są dziś dwa potężne serwisy: Addy.io oraz SimpleLogin (będący obecnie częścią ekosystemu Proton).

Jak wdrożyć system na ich bazie?

Skonfiguruj jeden skarbiec: Podepnij wygenerowane aliasy pod jedną, dobrze zabezpieczoną skrzynkę pocztową (np. Tuta, Proton).
Automatyzuj: Nowoczesne menedżery haseł (jak Bitwarden czy KeePassDX) integrują się z tymi serwisami po API. Możesz generować aliasy jednym kliknięciem podczas rejestracji w nowej aplikacji.
Zrozum haczyki darmowych planów: Oba te serwisy mają świetne plany darmowe, ale musisz wybrać ten, który lepiej pasuje do Twojego stylu korzystania z sieci:

Opcja A: Addy.io (Mistrzowskie żonglowanie pulą) W darmowym planie Addy.io pozwala na odbieranie nieskończonej ilości e-maili, ale blokuje możliwość odpisywania z aliasów (wymaga to planu Lite za 1$ miesięcznie). Cały "myk" polega na świadomym operowaniu wariantami, które otrzymujesz całkowicie za darmo:

Współdzielone aliasy losowe (np. losoweznaki@anonaddy.me) – to absolutny fundament prywatności. Nie zdradzają żadnego wzorca i nie da się na ich podstawie zbudować Twojego profilu. Masz ich do dyspozycji 10 i powinieneś ich używać najczęściej, jako stałych punktów kontaktu (np. bank, operator komórkowy, czy oficjalny formularz).
Aliasy oparte na nicku (np. cokolwiek@twojnick.anonaddy.com) – masz ich nielimitowaną ilość, ale z punktu widzenia OPSEC mają słaby punkt: stały nick. Przy wyciekach z różnych baz pozwala to powiązać te konta. Dlatego powinieneś używać ich na dwa sposoby: po pierwsze, jako typowe jednorazówki, robiąc szybki zakup w sklepie bez zakładania konta (a po transakcji po prostu usuwasz alias w panelu). Po drugie, w usługach, które same w sobie nic o Tobie nie wiedzą, a jedynie wymagają maila do rejestracji (jak np. GitHub).

Żelazna zasada aliasów opartych na nicku

Nigdy nie używaj aliasów opartych na nicku tam, gdzie podajesz prawdziwe dane, podpinasz kartę płatniczą albo wiążesz konto z realną tożsamością. Stały nick w adresie pozwala powiązać Twoje konta z różnych wycieków w jeden profil.

Opcja B: SimpleLogin (Darmowe odpisywanie, ale twardy limit aliasów) Jeśli wiesz, że będziesz musiał często odpisywać na wiadomości bez płacenia abonamentu, wybierz SimpleLogin. Wersja w pełni darmowa pozwala na Reverse Aliasing, jednak nakłada twardy limit – możesz wygenerować łącznie tylko 10 aliasów.

Podsumowanie

Higiena cyfrowa to nie utrudnianie sobie życia dziesiątkami logów. To inteligentna architektura. Jeden pancerny skarbiec i nieskończona liczba jednorazowych drzwi wejściowych. Jeśli z jakiegoś powodu nie chcesz płacić za cyfrowe usługi, Twój system nie przestanie działać — wystarczy, że odpowiednio dobierzesz dostawcę aliasów i mądrze zarządzisz darmowymi pulami, które oferuje.

Z ofiary do administratora. Ekstremalne utwardzanie Google Chrome

Eteryu — Sat, 22 Aug 2026 00:00:00 +0000

W świecie cyberbezpieczeństwa często rozmawiamy o modelach zagrożeń (Threat Models) w sposób czysto teoretyczny. Moja własna teoria zderzyła się z rzeczywistością w najgorszym możliwym momencie. Kiedy moja żona leżała w szpitalu, nowo kupiony telefon zaczął nagle żyć własnym życiem. Pojawiła się zielona ikona aktywnego mikrofonu, z galerii w locie znikały dowody, a połączenia były bezpodstawnie przekierowywane. Towarzyszyła temu paraliżująca świadomość, że ktoś obcy na żywo obserwuje mój ekran.

Śledztwo ujawniło wtedy brutalną prawdę. Telefon posiadał ukryty profil korporacyjny do zarządzania urządzeniami mobilnymi (MDM). Byłem ofiarą potężnego systemu szpiegowskiego. Z tej pułapki udało mi się wyrwać tylko dzięki zastosowaniu radykalnej zapory. Główną bitwę o przetrwanie wygrał wtedy RethinkDNS ustawiony w bezwzględnym trybie domyślnej blokady ruchu (Default Deny) oraz szyfrowany Quad9 DNS, które wspólnie całkowicie sparaliżowały sieć komunikacyjną napastnika.

Architektura absolutnej władzy

Aby w pełni zrozumieć sens naszych dzisiejszych działań, musimy na chwilę zatrzymać się przy samej technologii zarządzania urządzeniami. Systemy klasy MDM posiadają absolutną i niepodważalną władzę nad systemem operacyjnym. Zostały zaprojektowane dla wielkich korporacji, aby administrator mógł zdalnie i bezgłośnie zarządzać tysiącami urządzeń swoich pracowników.

W rękach napastnika to najgorszy możliwy koszmar. Taki profil pozwala na cichą instalację oprogramowania, podgląd zawartości ekranu, blokowanie kluczowych ustawień oraz przekierowywanie całego ruchu sieciowego na złośliwe serwery bez wiedzy użytkownika. Zwykły właściciel telefonu staje się bezradnym zakładnikiem we własnej kieszeni.

Inżynieria ma jednak to do siebie, że każdy miecz ma dwa ostrza. Ta sama absolutna władza może działać w odwrotnym kierunku. Kiedy sam przejmujesz stery i stajesz się swoim własnym administratorem, system korporacyjny zamienia się w ostateczny bastion prywatności. Zamiast wymuszać instalację aplikacji szpiegujących, możesz wymusić żelazne blokady na poziomie samego systemu. Możesz zakazać aplikacjom komunikacji z chmurą, zablokować niebezpieczne protokoły i narzucić rygorystyczne konfiguracje. To najczystsza forma ucieleśnienia zasady Zero Trust.

Skoro profil korporacyjny pozwala na odbieranie kontroli, postanowiłem wykorzystać go do jej odzyskania.

Dlaczego pacjentem został Google Chrome?

Musimy w tym miejscu oddać królowi to, co królewskie. Kiedy oceniamy narzędzia tworzone przez największych gigantów technologicznych, często wpadamy w pułapkę ich całkowitego odrzucenia ze względu na obawy o prywatność. Tymczasem pod kątem czystego cyberbezpieczeństwa rozwiązania korporacyjne zazwyczaj nie mają sobie równych. Firma Google posiada gigantyczny budżet, najlepszych inżynierów, najszybszy proces łatania błędów i bezkonkurencyjną architekturę piaskownicy (Sandbox).

Problem z najpopularniejszą przeglądarką nie polega na jej podatności na ataki. Problem leży w modelu biznesowym opartym na potężnej inwigilacji. Zrozumienie tej subtelnej różnicy to klucz do budowania dojrzałego bezpieczeństwa. Zamiast uciekać do niszowych projektów, które mogą nie nadążać z wydawaniem aktualizacji, możemy wziąć ten pancerny korporacyjny czołg i po prostu wyciąć z niego cały sprzęt szpiegowski.

Celem jest zmuszenie technologii wielkich korporacji do działania wyłącznie na naszych rygorystycznych warunkach.

Co dokładnie zrobiliśmy i jak przebiegła operacja?

Zamiast polegać na standardowych wtyczkach blokujących reklamy, postanowiłem zaatakować problem u samego źródła. Wykorzystałem technologię profili roboczych, z którą kiedyś sam musiałem walczyć. Za pomocą aplikacji Test DPC służącej do symulowania środowiska korporacyjnego sam mianowałem się głównym zarządcą. Następnie wycelowałem te administracyjne uprawnienia prosto w przeglądarkę Google Chrome.

Cały proces utwardzania podzieliliśmy na trzy kluczowe etapy operacyjne:

Etap pierwszy: Flagi przeglądarki

Aby nasza operacja w ogóle mogła się udać na urządzeniu bez odblokowanego dostępu root, musieliśmy najpierw otworzyć ukrytą furtkę. W wewnętrznym menu ustawień eksperymentalnych przeglądarki (chrome://flags) wymusiliśmy uruchomienie funkcji czytania komend startowych z lokalnego pliku tekstowego. To przygotowało nam grunt pod główne uderzenie.

Etap drugi: Wstrzyknięcie pancerza w terminalu Termux

Tutaj przeszliśmy do najcięższej inżynierii. Używając lokalnego terminala Termux oraz poleceń pomostu debugowania ADB (Android Debug Bridge), uzyskaliśmy bezpośredni dostęp do powłoki systemowej. Wewnątrz tymczasowego katalogu utworzyliśmy twardy plik konfiguracyjny, który silnik Chromium musi odczytać przy każdym uruchomieniu.

To właśnie na tym poziomie wprowadziliśmy najbardziej drastyczne modyfikacje:

Blokada kompilatora: Wyłączyliśmy dynamiczne renderowanie skryptów JavaScript (Just In Time), co drastycznie ucina podatność na luki typu Zero Day.
Sprzętowa izolacja: Zablokowaliśmy stronom możliwość odczytu danych sprzętowych (API Canvas) oraz narzuciliśmy rygorystyczną izolację każdej witryny w osobnym procesie pamięci (Strict Origin Isolation).
Głuchota na serwery: Całkowicie wycięliśmy mechanizmy raportowania awarii (Crashpad) i systemy śledzenia ukryte w platformie Privacy Sandbox.

Etap trzeci: Polisy korporacyjne w Test DPC

Na sam koniec domknęliśmy system odgórnymi politykami w naszym sztucznym profilu roboczym (Work Profile). Używając narzędzia Test DPC narzuciliśmy przeglądarce absolutne posłuszeństwo:

Dezaktywacja sztucznej inteligencji: Całkowicie ubezwłasnowolniliśmy usługi oparte na algorytmach, inteligentne podpowiedzi oraz asystenta Gemini.
Cyfrowa amnezja: Narzuciliśmy politykę, w której przeglądarka ma całkowity zakaz pamiętania haseł, nie używa autouzupełniania i odcina wszelką synchronizację danych z chmurą.
Szczelność protokołów: Wymusiliśmy globalne połączenia DNS over HTTPS oraz zabezpieczyliśmy protokół WebRTC przed wyciekami prawdziwego adresu IP.

Efekt końcowy i wnioski

Prawdziwa dojrzałość inżynieryjna polega na dostrzeganiu wielkiego potencjału tam, gdzie inni widzą tylko zagrożenie. Bierzemy oprogramowanie, które pod względem budżetu i architektury piaskownicy nie ma sobie równych na rynku, a następnie siłowo wycinamy z niego cały kod śledzący. Otrzymujemy w ten sposób potężne i skrajnie bezpieczne narzędzie, któremu niezwykle trudno dorównać.

Mechanizmy służące do zarządzania urządzeniami są przerażająco skuteczne, gdy służą do inwigilacji. Okazuje się jednak, że kiedy zrozumiesz zasady ich działania, możesz użyć dokładnie tej samej architektury do zbudowania wokół siebie nieprzebijalnej tarczy. Prawdziwa prywatność wymaga odrobiny tarcia i zmiany nawyków, ale poczucie pełnej kontroli nad własnym urządzeniem w pełni to rekompensuje.

Dajcie znać co myślicie! Jeśli ten temat Was zainteresował i chcielibyście poznać techniczną stronę całego przedsięwzięcia, dajcie znać. Przy odpowiednim odzewie planuję stworzyć na blogu zupełnie nową sekcję Guides, gdzie w pierwszej kolejności udostępnię pełną notatkę konfiguracyjną i gotowe komendy krok po kroku.

Poznaj GrapheneOS w praktyce. Dlaczego Storage Scopes to absolutny „game changer”?

Eteryu — Sun, 16 Aug 2026 00:00:00 +0000

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.

W standardowym Androidzie model uprawnień do pamięci urządzenia, mimo wprowadzanych ulepszeń, wciąż potrafi być problematyczny. Choć nowsze wersje systemu (od Androida 13) oferują wybiórczy dostęp do zdjęć, to wiele aplikacji (np. komunikatory, menedżery plików czy starsze programy) nadal stosuje szantaż: żądają szerokiego dostępu i jeśli odmówisz, zazwyczaj po prostu się zawieszają lub odmawiają działania, ponieważ deweloper nie przewidział innej ścieżki. Jesteśmy wtedy zmuszeni kliknąć opcję zezwalającą na wszystko. Problem polega na tym, że oddajemy w ten sposób wgląd w naszą prywatność: prywatne zdjęcia z wakacji, zrzuty ekranu z aplikacji bankowych, memy czy dokumenty pobrane z innych źródeł.

GrapheneOS rozwiązuje ten problem przez sprytne oszustwo systemowe.

Oto krótkie zestawienie różnic w podejściu do uprawnień:

Cecha	Standardowy Android	GrapheneOS (`Storage Scopes`)
Brak zgody na pełny dostęp	Często powoduje zawieszanie się lub odmowę uruchomienia aplikacji.	Aplikacja działa stabilnie, ponieważ uważa, że otrzymała pełne uprawnienia.
Widoczność plików	Aplikacja ma prawo skanować szerszy zakres pamięci.	Aplikacja widzi tylko wskazany przez Ciebie folder lub plik.
Prywatność	Umiarkowana, zależna często od uczciwości twórców aplikacji.	Absolutna. Kod aplikacji jest ślepy na resztę systemu.

Warto w tym miejscu zadać ważne pytanie: czy sam system Android nie posiada bezpiecznych rozwiązań? Posiada. Od lat istnieje mechanizm SAF (Storage Access Framework) oraz nowszy Photo Picker (Selektor zdjęć). Pozwalają one aplikacji wywołać bezpieczne, systemowe okno wyboru, przez które wskazujemy konkretny plik, nie dając programowi uprawnień do niczego więcej.

Niestety, wymaga to dobrej woli i odpowiedniego zaprogramowania aplikacji przez twórców. Wiele z nich (w tym najpopularniejsze komunikatory) celowo ignoruje te bezpieczne standardy, wymuszając na użytkowniku szeroki dostęp pod pretekstem „wygody”. I właśnie dla takich opornych, żądających pełnego dostępu aplikacji, GrapheneOS stworzył Storage Scopes – mechanizm, który rozwiązuje sprawę siłowo, bez pytania dewelopera o zdanie.

1. Systemowe kłamstwo i wirtualna piaskownica

Zamiast blokować aplikację i ryzykować jej awarię, system GrapheneOS kłamie. Zwraca aplikacji informację zwrotną potwierdzającą rzekome otrzymanie pełnego dostępu do pamięci urządzenia. Aplikacja jest zadowolona i działa w pełni stabilnie.

W rzeczywistości system izoluje ją w wirtualnej piaskownicy. Aplikacja widzi i ma dostęp wyłącznie do tych folderów lub plików, które Ty jej ręcznie wskażesz. Cała reszta pamięci telefonu po prostu dla niej nie istnieje.

2. Praktyczne zastosowanie na przykładzie aparatów i komunikatorów

Wyobraźmy sobie konfigurację z aplikacją Pixel Camera. Zależy nam na rewelacyjnej jakości zdjęć i algorytmach firmy Google, ale ze względów bezpieczeństwa absolutnie nie chcemy, aby kod tej korporacji miał wgląd w naszą prywatną galerię.

Włączając Storage Scopes dla tej aplikacji, tworzymy wyizolowane środowisko. Co ciekawe, w konfiguracji w ogóle nie musimy wskazywać jej żadnego folderu. Dlaczego? Ponieważ w systemie Android aplikacje nie potrzebują specjalnych uprawnień, by zapisywać tworzone przez siebie pliki w standardowych folderach publicznych (np. DCIM). Aparat zrobi więc zdjęcie i bez problemu je zapisze, ale dzięki systemowemu kłamstwu pozostanie całkowicie ślepy na jakiekolwiek starsze fotografie czy zrzuty ekranu obecne w pamięci urządzenia.

Z kolei mechanizm wskazywania konkretnych ścieżek idealnie sprawdza się w przypadku komunikatorów, takich jak WhatsApp czy Discord. Zamiast pozwalać im czytać całą rolkę aparatu, można przyznać im w Storage Scopes dostęp tylko do jednego pustego folderu, do którego sami będziemy kopiować pliki przeznaczone do wysłania.

3. Konfiguracja krok po kroku

Konfiguracja jest bardzo intuicyjna. Kiedy nowo zainstalowana aplikacja w GrapheneOS po raz pierwszy prosi o dostęp do plików, w systemowym oknie z zapytaniem (pop-upie) na samym dole znajdziesz bezpośredni przycisk Storage scopes. To najszybsza i najwygodniejsza metoda.

Warto jednak wiedzieć, jak zarządzać tymi ustawieniami ręcznie lub jak je modyfikować po czasie:

Jak zarządzać Storage Scopes z poziomu ustawień:

Wchodzimy w ustawienia danej aplikacji (czyli w Informacje o aplikacji).

Wybieramy zakładkę z uprawnieniami, a następnie pozycję Zdjęcia i filmy lub Pliki i multimedia.

Zamiast standardowej opcji zezwalającej na pełny dostęp, wybieramy na samym dole opcję Setup Storage Scopes.

W nowym oknie klikamy Add folder (Dodaj folder) lub Add file (Dodaj plik).

Wskazujemy w systemowym menedżerze konkretne miejsce, z którego aplikacja ma prawo czytać dane.

Ważne: Możesz dodać kilka folderów naraz. Pamiętaj również, że w każdej chwili możesz wrócić do tych ustawień, aby zmodyfikować zakres przydzielonych zasobów. Warto też wiedzieć, że jeśli odinstalujesz aplikację używającą Storage Scopes, a potem zainstalujesz ją ponownie, system potraktuje ją jako zupełnie nowy program. Straci ona dostęp do plików, które wcześniej sama stworzyła – aby go przywrócić, musisz ręcznie dodać odpowiedni folder w ustawieniach.

Prywatność nie musi oznaczać rezygnacji z wygody. Mechanizm Storage Scopes świetnie udowadnia, że można używać popularnych aplikacji o zamkniętym kodzie w sposób w pełni kontrolowany i bezpieczny.

Jak zainstalować Pixel Camera na GrapheneOS bez usług Google

Eteryu — Sat, 15 Aug 2026 00:00:00 +0000

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.

Oto krótkie podsumowanie, dlaczego w ogóle warto to zrobić:

Cecha	Aparat GrapheneOS (Secure Camera)	Pixel Camera (Offline)
Jakość zdjęć i tryb nocny	Przeciętna. Nie wykorzystuje w pełni układu Tensor i zaawansowanych algorytmów Google.	Rewelacyjna. Pełne wsparcie procesora, fenomenalny tryb nocny (Night Sight) i HDR+.
Prywatność (Out-of-the-box)	Absolutna. Z założenia pozbawiona dostępu do sieci (`Network`) i jakiejkolwiek telemetrii.	Wymaga ręcznego odcięcia od sieci (`Network Permission`), by powstrzymać telemetrię.
Integracja z galerią	Bezproblemowa, korzysta z domyślnej galerii systemowej.	Wymaga instalacji mostka (`Gcam Services Provider`), by płynnie połączyć się z zewnętrzną galerią (np. Ente).

1. Pixel Camera w odpowiedniej wersji

Kluczowa sprawa to aplikacja działająca bez usług Google Play w głównym profilu. Nie znajdziemy w internecie gotowego pliku instalacyjnego z zaufanego źródła. Zdecydowałem się na użycie Aurora Store. Nie polecam korzystania z tego sklepu na co dzień, ale w tym konkretnym przypadku był to świadomy kompromis i najlepsze wyjście z sytuacji.

Co ważne, nie musimy już pobierać starszych wersji z tzw. ręcznego pobierania. Jeszcze do niedawna, od wersji 10 aplikacja wymuszała obecność usług Google Play z powodu braku dostępu do systemowej czcionki, co powodowało jej natychmiastowe zamykanie się.

Dlaczego najnowsze wersje znów działają?

Zespół GrapheneOS zaimplementował niedawno na poziomie systemu specjalną „zaślepkę" (ang. shim), która emuluje zachowanie usługi ładowania czcionek od Google. Dzięki temu rozwiązaniu, system skutecznie „oszukuje" aplikację, dostarczając jej to, czego wymaga, bez konieczności faktycznej instalacji usług Google Play. W efekcie najnowsze wersje Pixel Camera znów działają stabilnie prosto z pudełka.

Jak to zrobić:

Pobieramy sklep Aurora Store (podczas instalacji wybieramy standardową paczkę, zazwyczaj pierwszą z brzegu, bez dopisków „hw" czy „preload").

Wyszukujemy standardowo aplikację Pixel Camera i po prostu ją instalujemy. Aurora Store sama dobierze najnowszą, kompatybilną z Twoim modelem telefonu wersję.

Aplikację Aurora Store od razu odinstalowujemy, jeśli nie korzystamy z niej na co dzień.

Ważne dla osób aktualizujących aparat: Jeśli miałeś zainstalowaną polecaną przeze mnie wcześniej, starszą wersję 9.x (build 68469120), całkowicie ją odinstaluj przed instalacją nowej. Przeskok na wersje z linii 10+ to spora zmiana i pozostawienie starych plików w pamięci podręcznej może powodować błędy. Najlepiej zainstalować nową wersję na czysto!

Kluczowe ustawienia po instalacji:

Ostatnim etapem, w którym domykamy kwestie bezpieczeństwa i optymalizacji, jest nałożenie na aparat trzech restrykcji. Dostęp do sieci możesz zablokować już w samym oknie instalatora, natomiast po resztę musisz wejść w ustawienia nowo zainstalowanej aplikacji (pamiętaj, by ustawić to ponownie, jeśli instalowałeś aparat na czysto):

Network Permission (Dostęp do sieci) – w systemie GrapheneOS przełącznik ten pojawia się już podczas instalacji i warto go od razu odznaczyć. Jeśli tego nie zrobiłeś, permanentnie odbierz to uprawnienie w ustawieniach. Aplikacja będzie całkowicie odcięta od internetu, a telemetria Google nie ma jak opuścić urządzenia.

Storage Scopes (Zakresy pamięci) – zamiast dawać aplikacji Google pełny dostęp do wszystkich Twoich plików, uruchamiamy tę potężną funkcję GrapheneOS. Dzięki niej aparat uważa, że ma dostęp do pamięci (więc normalnie i bez błędów zapisuje zrobione zdjęcia), ale w rzeczywistości widzi tylko i wyłącznie własny folder. Jest całkowicie „ślepy" na resztę zawartości Twojego dysku.

Allow background usage (Działanie w tle) – wyłączamy tę opcję. Aparat nie ma żadnego powodu, by pracować w pamięci RAM, gdy z niego nie korzystasz. To prosty nawyk, który znakomicie oszczędza baterię i zasoby telefonu.

2. Gcam Services Provider

Oryginalne wersje Pixel Camera domyślnie do podglądu zdjęć używają usługi Google Photos. Ponieważ moją główną galerią oraz szyfrowaną chmurą end to end jest Ente Photos, potrzebowałem sposobu na ich połączenie.

Z rozwiązaniem przychodzi tutaj Gcam Services Provider w wariancie photosonly. Jest to open source'owy mostek autorstwa lukaspieper, dzięki któremu aparat działa stabilnie offline i płynnie współpracuje z zewnętrzną galerią.

Wchodzimy na platformę GitHub do sekcji wydań (releases) oficjalnego repozytorium: lukaspieper / Gcam-Services-Provider.
Wybieramy opcję photos only. Ja instaluję i aktualizuję ją wygodnie przez aplikację Obtainium.
Bezpośredni link do pliku: app-photosonly-release.apk

I to tyle! Ten prosty zestaw pozwala cieszyć się świetną jakością zdjęć oraz bezproblemową współpracą z wybraną galerią. To idealne rozwiązanie na systemie GrapheneOS – nie tylko dla Pixela 8, ale dla każdego, kto nie korzysta z usług Google wcale lub zrezygnował z nich w swoim głównym profilu.

Koniec z teatrem prywatności. Czym jest Threat Modeling i jak przestać działać po omacku

Eteryu — Sun, 09 Aug 2026 00:00:00 +0000

W świecie cyfrowej higieny bardzo łatwo wpaść w pułapkę maksymalizmu. Ktoś przeczyta o inwigilacji, kupuje Google Pixela, instaluje GrapheneOS, konfiguruje osobne profile, po czym czuje frustrację, bo system wymaga ciągłej uwagi i rygorystycznych nawyków. Jeszcze gorzej, gdy użytkownicy szukają uniwersalnych dekalogów prywatności i traktują technologię jak magiczną tarczę z pudełka, która w trybie out of the box załatwi za nich cały problem.

Prawda jest brutalna: nie istnieje jeden uniwersalny model bezpieczeństwa. Bezpieczeństwo to proces zarządzania ryzykiem, a nie zestaw aplikacji do pobrania. Aby przestać działać po omacku, musisz zacząć od fundamentu, na którym opiera się każda świadoma architektura, czyli od modelowania zagrożeń (Threat Modeling).

Czym właściwie jest Threat Modeling? Od STRIDE do praktyki

Jeżeli śledzisz mojego bloga od jakiegoś czasu, prawdopodobnie kojarzysz modelowanie STRIDE, którego używałem chociażby przy analizie zagrożeń dla mechanizmów Dynamic Code Loading. W inżynierii oprogramowania i architekturze systemów kategoryzujemy zagrożenia (spoofing, tampering, repudiation itd.), by precyzyjnie załatać wektory ataku na poziomie kodu czy jądra systemu.

W przypadku bezpieczeństwa osobistego mechanizm myślenia pozostaje dokładnie ten sam, ale odrzucamy korporacyjny formalizm na rzecz prostego i pragmatycznego celu:

Threat modeling to proces, w którym świadomie określasz, co chcesz chronić, przed kim chcesz to chronić i ile jesteś w stanie poświęcić wygody, czasu oraz pieniędzy, aby to osiągnąć.

To narzędzie, które pozwala oddzielić realne wektory ataków od paranoi. Bez niego kończysz z teatrem prywatności, w którym zabezpieczasz rzeczy bezwartościowe kosztem ogromnego utrudnienia sobie życia, jednocześnie zostawiając krytyczne punkty wejścia całkowicie odsłonięte.

Klasyczny błąd na starcie: Nihilizm kontra paranoja

Początkujący wpadają zazwyczaj w jedną ze skrajności:

Nihilizm („Nic nie mam do ukrycia”): Rezygnacja z jakiejkolwiek higieny, bo wielkie korporacje technologiczne i tak wiedzą wszystko. Błąd polega na niezrozumieniu, że nie chronisz się tylko przed rządem, ale przed wyciekami z baz danych, kradzieżą tożsamości, profilowaniem behawioralnym i zautomatyzowanymi oszustwami.
Paranoja (Syndrom Edwarda Snowdena): Próba budowania profilu odpornego na zaawansowane podmioty państwowe (APT), podczas gdy realnym zagrożeniem dla użytkownika jest złośliwy plik APK pobrany z niepewnego źródła, skrypt śledzący w przeglądarce lub wyciek hasła z menedżera online.

Własny Threat Model ma Cię wyśrodkować i stać się Twoim cyfrowym kompasem.

5 pytań, od których musisz zacząć swój Threat Model

Najbardziej funkcjonalne podejście do osobistego modelowania zagrożeń opiera się na pięciu prostych pytaniach, spopularyzowanych między innymi przez Electronic Frontier Foundation (EFF):

1. Co chcę chronić? (Inwentaryzacja aktywów)

Nie ochronisz czegoś, o czym nie wiesz. Twoimi aktywami są między innymi:

Dane kryptograficzne: Hasła, klucze SSH, fraza nasienna do portfela kryptowalut (seed phrase), klucze GPG.
Tożsamość i finanse: Dostęp do banku, numer PESEL, główne konto email, które służy do resetowania haseł w innych serwisach.
Prywatność komunikacji: Wiadomości w komunikatorach Signal lub Matrix, historia lokalizacji GPS, prywatne zdjęcia.
Metadane i profil behawioralny: Informacje, które zbierają o Tobie brokerzy danych i sieci reklamowe.

2. Przed kim chcę to chronić? (Przeciwnicy i adwersarze)

Kto może chcieć uzyskać dostęp do Twoich aktywów?

Masowe systemy śledzące: Google, Meta oraz operatorzy telekomunikacyjni, których celem jest monetyzacja Twojej uwagi i profilowanie reklamowe.
Cyberprzestępcy i oszuści: Automatyczne boty, phishing, ransomware, złodzieje sesji przeglądarki (infostealery).
Lokalni intruzi: Ktoś, kto ukradnie Twój fizyczny telefon w pociągu, ciekawski znajomy lub pracodawca instalujący oprogramowanie MDM na prywatnym sprzęcie.
Aparat państwowy i służby: Wektory celowane, relewantne głównie dla dziennikarzy śledczych, aktywistów czy osób podwyższonego ryzyka.

3. Jakie jest prawdopodobieństwo, że będę celem? (Ocena ryzyka)

Bądź realistą. Jakie jest prawdopodobieństwo, że trafisz na celownik agencji wywiadowczej? Zapewne bliskie zeru. Jakie jest prawdopodobieństwo, że Twój adres email wycieknie w kolejnym naruszeniu bazy sklepu internetowego, a Twoje dane trafią do sieci reklamowej poprzez brokerów danych, aplikacje z zaszytymi skryptami śledzącymi czy niejasne zgody marketingowe? Bliskie 100%.

Twoje zasoby obronne powinny być proporcjonalne do prawdopodobieństwa zdarzenia.

4. Jakie będą konsekwencje, jeśli ochrona zawiedzie? (Wycena straty)

Co się stanie, jeśli dany wektor zostanie przełamany?

Wyciek historii wyszukiwania to naruszenie prywatności, ale zwykle niska szkoda krytyczna.
Przejęcie głównego konta email lub menedżera haseł to katastrofa (Total Compromise), czyli utrata tożsamości cyfrowej i finansów.

Aktywa o najwyższych konsekwencjach utraty wymagają najcięższych i precyzyjnie dobranych mechanizmów obrony: sprzętowe klucze YubiKey chronią przed zdalnym przejęciem tożsamości, osobne profile w GrapheneOS gwarantują lokalną izolację aplikacji na urządzeniu, a kopie zapasowe offline zabezpieczają przed bezpowrotną utratą danych.

Krótka uwaga o dywersyfikacji danych

Jeśli jedno konto email kontroluje całe Twoje życie cyfrowe, staje się pojedynczym punktem awarii. Aby uniknąć scenariusza Total Compromise, w dobrze zaprojektowanym Threat Modelu stosuje się dywersyfikację danych (kompartmentalizację).

Polega ona na logicznym rozdzieleniu tożsamości: osobnego adresu używasz wyłącznie do spraw krytycznych (banki, urzędy), osobnego do komunikacji ze znajomymi, a do rejestracji w sklepach czy newsletterach wykorzystujesz dedykowane aliasy pocztowe (np. SimpleLogin lub Addy.io). Dzięki temu wyciek bazy danych ze sklepu internetowego nie wystawia na celownik Twojej bankowości ani głównej tożsamości. Więcej o samej mechanice dywersyfikacji i praktycznym wdrażaniu aliasów opowiem w osobnym wpisie z serii o cyfrowej higienie.

5. Ile wysiłku jestem w stanie włożyć w ochronę? (Budżet wygody)

Każde zabezpieczenie ma swój koszt: jeśli nie finansowy, to w postaci czasu i komfortu użytkowania. Jeśli stworzysz model tak rygorystyczny, że codzienne korzystanie z telefonu stanie się koszmarem, po miesiącu sam go wyłączysz. Bezpieczeństwo, które sabotuje Twoją codzienną pracę, to złe bezpieczeństwo.

Praktyczny przykład: Jak to wygląda w akcji?

Weźmy za przykład komunikację ze znajomymi na smartfonie:

Aktywo: Treść wiadomości oraz metadane mówiące o tym, z kim rozmawiasz.
Adwersarz: Automatyczne skanowanie treści przez korporacje w celu profilowania reklamowego oraz potencjalny wyciek z serwerów operatora aplikacji.
Konsekwencje: Średnie lub wysokie, obejmujące naruszenie intymności i wyciek prywatnych spraw.
Rozwiązanie z Threat Modelu: Rezygnacja z nieszyfrowanych wiadomości SMS i komunikatorów bez pełnego szyfrowania end to end (E2EE), takich jak standardowy Messenger. Wdrożenie platformy Signal lub Matrix.
Czego NIE musisz robić: Jeśli Twoim adwersarzem nie jest agencja wywiadowcza, nie musisz stawiać własnego węzła w sieci Tor i komunikować się wyłącznie za pomocą jednorazowych kluczy PGP na systemie Tails uruchamianym z pamięci USB.

Wymówka „Ale to mój Threat Model”: Relatywizm, ideologia i błędy w sztuce

W społecznościach zajmujących się bezpieczeństwem i prywatnością bardzo łatwo trafić na pułapkę relatywizmu. Dyskusja o dziurawej konfiguracji czy błędnym podejściu często kończy się uniwersalną wymówką: „Każdy ma inny Threat Model, ja mam właśnie taki”.

To hasło zbyt często służy do pudrowania błędów w sztuce i zasłaniania nielogicznych założeń. Własny model zagrożeń nie oznacza, że prawa matematyki, działanie systemów operacyjnych czy wektory ataków przestają w Twoim przypadku obowiązywać. Jeżeli na przykład poświęcasz godziny na izolację aplikacji i tunelowanie ruchu, ale jednocześnie powierzasz klucze kryptograficzne podmiotowi, który żyje z analizy danych, to nie jest to inny model zagrożeń. To jest błędnie przeprowadzona analiza ryzyka.

Technologia, polityka i ideologiczna ślepota

Warto w tym miejscu poruszyć jeszcze jeden problem, który trawi współczesną scenę cybersec i o którym pisałem w kontekście pragmatycznego puryzmu: mieszanie analizy zagrożeń z ideologią.

To prawda, że technologia i polityka są ze sobą nierozerwalnie powiązane. Decyzje o tym, jak projektowane są protokoły szyfrowania, jakie prawa mają organy ścigania czy jak reguluje się rynek telekomunikacyjny, zawsze wynikają z określonego układu sił politycznych. Walka o prywatność to w dużej mierze walka o wolność obywatelską.

Jednak w momencie, w którym zaczynasz dobierać narzędzia bezpieczeństwa wyłącznie na podstawie swojej przynależności plemiennej czy ideologicznej, popełniasz krytyczny błąd w sztuce. Przykładem są osoby, które odrzucają obiektywnie bezpieczną architekturę systemową tylko dlatego, że kojarzy im się z określoną korporacją lub opcją polityczną, wybierając w zamian rozwiązania ideologicznie słuszne, ale technicznie dziurawe, pozbawione izolacji i realnego wsparcia.

Cyfrowa asceza a mądra kontrola

Taka ideologiczna ślepota często prowadzi do skrajnej cyfrowej ascezy, czyli całkowitego bojkotu oprogramowania czy infrastruktury od technologicznych gigantów, nawet wtedy, gdy oferują one obiektywnie najwyższy standard bezpieczeństwa.

Tymczasem pragmatyczny inżynier bezpieczeństwa nie obraża się na rzeczywistość, lecz analizuje wektory ataku i architekturę. Przykładem jest instalacja krytycznych aplikacji bankowych: pobranie ich z oficjalnego Sklepu Play, który zapewnia weryfikację sygnatur i bezpieczny łańcuch dostaw, jest obiektywnie bezpieczniejsze niż korzystanie z alternatywnych klientów w rodzaju Aurory czy ręczne instalowanie plików APK z sieci.

Podobnie wygląda kwestia przeglądarek: dogmatyczne odrzucenie silnika Chromium na rzecz alternatyw pozbawionych zaawansowanej piaskownicy i wieloprocesowej izolacji pamięci zwiększa Twoją podatność na ataki zero day. Od momentu, w którym potrafisz przejąć kontrolę nad narzędziem na własnych zasadach – odciąć telemetrię, zablokować śledzenie i odpowiednio utwardzić konfigurację – technologia od Big Techu staje się po prostu potężnym aktywem obronnym.

Warto pamiętać o zasadniczym fakcie: chociaż nie z każdego przestarzałego sprzętu zrobisz fortecę, to na każdym współczesnym, wspieranym urządzeniu masz realną moc, by wycisnąć maksimum prywatności i bezpieczeństwa – o ile rozumiesz jego architektoniczne granice i nie rezygnujesz ze zdrowego rozsądku. Threat modeling nie ocenia moralności korporacji: ocenia realną skuteczność zabezpieczeń, które masz w ręku.

Threat modeling nie służy do budowania bezpiecznej bańki dla własnego ego, manifestowania poglądów politycznych ani usprawiedliwiania niedociągnięć słowami „bo ja tak lubię”. To chłodne i inżynieryjne narzędzie. Złośliwy kod, ataki zero day czy zautomatyzowane infostealery nie sprawdzają Twoich poglądów na świat ani tego, czy dany projekt ma licencję FOSS. Jeśli w Twoim modelu obrony są logiczne dziury, nazwanie ich własnym podejściem nie sprawi, że potencjalny atak je ominie.

Podsumowanie: Proces, nie produkt

Budowanie bezpieczeństwa bez modelowania zagrożeń przypomina stawianie płotu wokół domu bez sprawdzenia, z której strony prowadzi droga, a gdzie stoją otwarte drzwi na taras. Skutkuje to wydawaniem pieniędzy i energii na niepotrzebne restrykcje przy jednoczesnym ignorowaniu realnych punktów wejścia.

Zamiast szukać idealnego zestawu aplikacji czy kopiować cudze konfiguracje jeden do jednego, zacznij od kartki papieru i odpowiedzi na pięć podstawowych pytań. Twój Threat Model nie musi być idealny od pierwszego dnia: ma być realny, spójny logicznie i dostosowany do Twojego stylu życia.

Dopiero weryfikując swoje założenia z chłodną kalkulacją ryzyka, przestajesz uprawiać teatr prywatności i zaczynasz uprawiać twardą inżynierię własnego bezpieczeństwa.

Złudzenie prywatności z pudełka: Dlaczego podejście „set and forget” to pułapka

Eteryu — Fri, 07 Aug 2026 00:00:00 +0000

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.

Mit izolacji: microG vs. Sandboxed Google Play

Wielu entuzjastów systemów typu /e/OS powiela niebezpieczny w swojej ignorancji mit, jakoby system ten nie łączył się z serwerami Google. Twierdzenie, że microG nie generuje ruchu do Mountain View, bo podmienia API map na OpenStreetMap, to dowód na fundamentalny brak zrozumienia architektury mobilnej.

Fakty o microG: Aby dostarczać powiadomienia push (FCM) czy przechodzić weryfikację aplikacji, microG musi utrzymywać stałe, bezpośrednie połączenie z serwerami Google. Co gorsza, w /e/OS działa on z pełnymi uprawnieniami systemowymi. Usługi te są domyślnie zainstalowane w systemie i nie da się ich w prosty sposób usunąć.
Fakty o GrapheneOS: Po czystej instalacji ten system generuje absolutne zero ruchu do infrastruktury Google. Usługi Google (jeśli w ogóle zdecydujemy się na ich instalację) uruchamia się w Sandboxed Google Play jako zwykłą aplikację użytkownika. Oznacza to brak uprawnień systemowych i całkowity brak dostępu do identyfikatorów sprzętowych.

Pisanie, że GrapheneOS łączy się z Google, a /e/OS tego nie robi, to stawianie rzeczywistości na głowie.

/e/OS: Kompromis biznesowy, a nie technologia bez kompromisów

Wyjaśnijmy to prosto: system /e/OS to w dużej mierze po prostu nakładka na LineageOS podpięta pod chmurę Murena.

Wybierając ten system, dokonujesz transakcji. Zamieniasz chmurę Google na chmurę Murena i zyskujesz wygodę out of the box, ale w zamian godzisz się na twarde ustępstwa:

Opóźnione łatki bezpieczeństwa.
Modyfikację systemu w postaci signature spoofing (fałszowania sygnatur), która bezpośrednio osłabia fabryczny model uprawnień Androida.

Nie można też zapominać o modelu biznesowym. Murena to firma komercyjna, która znalazła świetną niszę. Sprzedają sprzęt po zawyżonych cenach i oferują zaledwie 1 GB darmowej pamięci w chmurze, aby szybko zmonetyzować użytkownika płatną subskrypcją. Co więcej, na koncie mają wpadki, takie jak integracja funkcji speech-to-text z zewnętrznym API OpenAI. To klasyczny model freemium, a nie bezinteresowna krucjata o naszą prywatność.

Niebezpieczny absurd: EOL jako ostoja prywatności

Szczytem iluzji w społecznościach de-google jest chwalenie się używaniem starych smartfonów, takich jak Galaxy S8 czy S9, jako głównych urządzeń służących do ochrony. Promowanie sprzętu ze statusem EOL (End of Life) pod szyldem bezpieczeństwa to czysty technologiczny absurd.

Urządzenia te od lat cierpią na:

Brak aktualizacji Vendor Patch Level.
Brak poprawek kernela i sterowników.
Brak aktualizacji mikrokodu modemu.
Wyłączony mechanizm Android Verified Boot z powodu odblokowanego bootloadera.

Dziurawy modem, niezałatany procesor czy brak sprzętowej weryfikacji rozruchu całkowicie unieważniają jakąkolwiek ochronę, jaką teoretycznie miała dać zmiana systemu operacyjnego.

„Privacy Theater” kontra twarda inżynieria

Ideologiczne odcinanie się od wielkich korporacji stało się klasycznym Privacy Theater (teatrem prywatności). Świadome dbanie o bezpieczeństwo nie jest religijną ascezą, gdzie odrzucamy infrastrukturę tylko dlatego, że ma w nazwie literę "G". Google dysponuje największym zespołem inżynierów i najszybciej łataną infrastrukturą na rynku.

Znakomicie widać to na przykładzie przeglądarek. Ideolodzy promują projekty takie jak Mull, które zostały oficjalnie porzucone i stanowią obecnie zagrożenie z powodu braku łatek na podatności. Tymczasem z punktu widzenia architektonicznej piaskownicy i tempa patchowania luk 0-day, absolutnym szczytem bezpieczeństwa pozostają odpowiednio utwardzone (flagami i konfiguracją) przeglądarki oparte na Chromium, Chrome, czy dedykowane rozwiązania jak Vanadium w GrapheneOS. Twarda inżynieria nie ma barw partyjnych.

Złudzenie „Set and Forget” w cyberbezpieczeństwie

Wielu użytkowników traktuje nowe systemy, aplikacje czy urządzenia z naklejką privacy-friendly jak magiczne tarcze. Instalują je, polegają na domyślnej konfiguracji i zapominają o sprawie, wierząc, że od teraz są w pełni chronieni. Takie podejście, określane jako set and forget (ustaw i zapomnij), to jeden z największych i najbardziej naiwnych błędów współczesnego bezpieczeństwa.

Pasywność to proszenie się o kłopoty: Poleganie na raz skonfigurowanym systemie, który działa w tle, sprawia, że o jego słabych punktach dowiadujemy się zazwyczaj dopiero po fakcie – czyli w momencie, gdy dojdzie już do incydentu lub wycieku.
Brak nadzoru unieważnia narzędzia: Narzędzia pozostawione same sobie, bez regularnych audytów, sprawdzania logów czy przeglądu uprawnień, szybko tracą swoją wartość obronną. Sama obecność zabezpieczeń nie gwarantuje sukcesu; kluczowe jest to, jak system jest zarządzany w czasie.

Oprogramowanie to żywy organizm, a wektory ataków ewoluują z każdym dniem. Pasywne podejście sprawia, że Twój świetnie zapowiadający się „bezpieczny setup” błyskawicznie staje się przestarzały.

Dlaczego prywatność „Out of the Box” to technologiczny mit?

Żaden system operacyjny ani przeglądarka – niezależnie od tego, jak agresywnie blokuje skrypty domyślnie i jak mocno jest pozycjonowana marketingowo – nie stanowi magicznego rozwiązania. Osiągnięcie prawdziwej prywatności nie sprowadza się do wyjęcia telefonu z pudełka, lecz wymaga naszego ciągłego zaangażowania.

To Twoje nawyki decydują o bezpieczeństwie: Żadna architektura nie ochroni Cię, jeśli zignorujesz podstawy. Cyberprzestępcy doskonale wiedzą, jak omijać systemowe piaskownice, bazując na błędach użytkowników – wykorzystują do tego phishing, zainfekowane reklamy czy złośliwe rozszerzenia.
Słabe punkty poza systemem: Najbezpieczniejszy OS mobilny staje się bezużyteczny, jeśli na potęgę stosujesz recykling haseł i używasz tych samych ciągów znaków we wszystkich serwisach.
Wojna o mentalną przestrzeń: Odzyskiwanie prywatności to ciągła walka o kontrolę nad naszą uwagą. Wymaga bezwzględnej higieny aktualizacji, modelowania zagrożeń i ostrożnego, krytycznego poruszania się po sieci.

System jest tylko narzędziem. To, czy użyjesz go do zbudowania solidnej fortecy, czy stworzysz w nim iluzję bezpieczeństwa, zależy wyłącznie od Ciebie.

Podsumowanie: Higiena ponad magię

Szerzenie narracji o jednej słusznej drodze lub nazywanie wszystkiego scamem to po prostu sekciarstwo. Prawda jest taka, że zmiana ikonek i przeskoczenie na nową chmurę out of the box nie uczynią nikogo bezpiecznym, dopóki użytkownik nie zmieni swoich nawyków i nie zacznie stosować higieny cyfrowej.

Świadomy użytkownik, rozumiejący własne zagrożenia, jest w stanie zbudować potężnie zabezpieczony i prywatny profil nawet na stockowym Androidzie. Wymaga to jednak odpowiedniej izolacji i kontroli. Bez zrozumienia własnych potrzeb, żaden system nie zapewni Ci magicznej ochrony.

Cyfrowa higiena bez podglądaczy. Jak łatwo odciąć algorytmy i zabezpieczyć zdjęcia?

Eteryu — Tue, 30 Jun 2026 00:00:00 +0000

W poprzednich artykułach rozebraliśmy na czynniki pierwsze zaawansowane metody kontroli nad siecią i aplikacjami. Wiemy już, jak postawić systemowy firewall oraz jak zamknąć podejrzane programy w bezpiecznej kwarantannie. Dzisiaj zrobimy kolejny ważny krok w stronę odzyskiwania prywatności. Zajmiemy się dwoma rzeczami, które większość z nas wysyła w świat całkowicie dobrowolnie każdego dnia. Chodzi o to, co oglądamy w wolnym czasie oraz o to, co fotografujemy naszymi telefonami.

Dobra wiadomość jest taka, że odcięcie korporacyjnych algorytmów od naszych codziennych nawyków wcale nie wymaga zaawansowanej wiedzy. Wszystko opiera się na wdrożeniu dwóch prostych narzędzi, które pozwolą Ci korzystać z telefonu na Twoich własnych, twardych warunkach.

1. Alternatywne frontendy, czyli YouTube bez karmienia algorytmów Google

Większość osób traktuje oficjalną aplikację YouTube jako zwykły, wygodny odtwarzacz wideo. W rzeczywistości jest to potężne narzędzie do zbierania danych, które zostało zaprojektowane tak, aby kontrolować nasze zachowanie. Google nie tylko zapisuje to, jaki film został przez Ciebie kliknięty. Algorytm na bieżąco analizuje, jak długo Twój palec zatrzymał się nad miniaturką filmu, zanim w nią puknąłeś. Sprawdza również, kiedy przewijasz nudne momenty oraz w jakich godzinach najczęściej odpalasz konkretne kategorie filmów. Korzysta nawet z czujników telefonu, aby odnotować, kiedy obracasz urządzenie w dłoni. Wszystko to dzieje się po to, aby precyzyjnie poznać Twoje nawyki i utrzymać Twoją uwagę przed ekranem jak najdłużej.

Problem: Oficjalna aplikacja to pułapka bez wyjścia

Jeśli chcesz korzystać z YouTube na oficjalnych warunkach, ale bez reklam i z funkcją odtwarzania przy zablokowanym ekranie, musisz płacić za subskrypcję Premium. Co gorsza, nawet wersja płatna nie zwalnia Cię ze śledzenia i budowania Twojej cyfrowej tożsamości w bazach danych korporacji. Podczas korzystania z aplikacji jesteś zalogowany swoim kontem Google, więc każdy Twój ruch jest przypisany bezpośrednio do Twojego profilu.

Rozwiązanie: Całkowicie anonimowe oglądanie przez PipePipe

Rozwiązaniem, które całkowicie zmienia reguły gry, są tak zwane alternatywne frontendy. Jest to po prostu nowa, niezależna aplikacja do obsługi YouTube. Moim osobistym faworytem jest obecnie PipePipe. To świetny, otwartoźródłowy program napisany z myślą o nowoczesnych telefonach z systemem Android, który powstał jako ulepszona wersja klasycznej aplikacji NewPipe.

Aplikacja działa w sposób genialny w swojej prostocie. Pobiera ona filmy bezpośrednio z serwerów YouTube, ale robi to w sposób całkowicie anonimowy. Program nie używa oficjalnych kodów Google i nie wymaga od Ciebie logowania się na jakiekolwiek konto. Dla korporacji jesteś po prostu losowym, bezwartościowym zapytaniem z sieci, a nie konkretnym profilem reklamowym.

Co zyskujesz, przechodząc na PipePipe?

Brak reklam i śledzenia: Zapominasz o podwójnych, niemożliwych do pominięcia spotach reklamowych, ponieważ ruch sieciowy jest całkowicie czysty.
Odtwarzanie w tle i Picture-in-Picture: Możesz zablokować telefon i wrzucić go do kieszeni, a podcast nadal gra. Możesz też zmniejszyć film do małego, pływającego okienka podczas przeglądania innych rzeczy. Wszystko to dostajesz całkowicie za darmo.
Wbudowany SponsorBlock: Świetna funkcja, która automatycznie wycina z wnętrza filmów irytujące fragmenty, w których twórca zachwala gry mobilne lub inne produkty. Oszczędzasz dzięki temu mnóstwo czasu.
Pełna lokalność: Twoje subskrypcje, historia oglądania oraz playlisty są zapisywane wyłącznie w pamięci Twojego telefonu. Żadna zewnętrzna firma nie ma do nich dostępu.

Finał: Szybka migracja bez straty ulubionych kanałów

Przesiadka na PipePipe wcale nie oznacza, że musisz szukać setek swoich ulubionych twórców od nowa. Cały proces zamkniesz w trzech prostych krokach:

Instalacja: Otwórz program Obtainium, wklej link do oficjalnego repozytorium PipePipe na GitHubie i pobierz aplikację bezpośrednio ze źródła (warto zweryfikować podpis instalatora wbudowanym narzędziem, aby mieć pewność co do integralności kodu).
Eksport z Google: Wejdź na komputerze na stronę usługi Google Takeout. Odznacz wszystkie pozycje, wybierz tylko sekcję o nazwie YouTube i YouTube Music i wyeksportuj dane. W pobranej paczce ZIP znajdziesz plik tekstowy zawierający listę Twoich subskrypcji.
Import w locie: W aplikacji PipePipe wejdź w Ustawienia, następnie w zakładkę Treść i wybierz Importuj/Eksportuj. Kliknij opcję importu subskrypcji i wskaż pobrany wcześniej plik. Od tej sekundy masz swój własny YouTube, który działa na Twoich własnych warunkach.

2. Cyfrowy odcisk palca ukryty w Twoich zdjęciach

Wyobraź sobie taką sytuację. Robisz smartfonem zdjęcie swojego kota w salonie lub nowego przedmiotu, który chcesz wystawić na sprzedaż. Fotka wygląda super, więc bez większego zastanawiania się wrzucasz ją na publiczne forum internetowe, grupę na komunikatorze Telegram, do aplikacji Discord albo na portal ogłoszeniowy typu OLX czy Vinted.

Problem polega na tym, że wraz z plikiem graficznym wysyłasz w świat niewidzialny dla oka, ukryty pakiet danych o nazwie EXIF.

Problem: Zdjęcia, które mówią o Tobie za dużo

Standardowo każdy nowoczesny smartfon podczas naciśnięcia przycisku aparatu zapisuje wewnątrz zdjęcia potężną dawkę ukrytych informacji. Znajduje się tam dokładny model Twojego telefonu, unikalny numer seryjny aparatu, dokładna data i godzina zrobienia zdjęcia oraz to, co najgroźniejsze – precyzyjne współrzędne GPS miejsca, w którym stoisz.

Każdy, kto pobierze takie zdjęcie z sieci, może w kilka sekund użyć darmowego narzędzia internetowego, wyciągnąć te ukryte dane i zobaczyć na mapie pinezkę wskazującą bezpośrednio na okno Twojego mieszkania.

Sposób, w jaki różne platformy traktują te dane, drastycznie się różni:

Typ platformy	Jak traktuje Twoje dane EXIF?	Co to oznacza dla Ciebie?
Prywatne komunikatory (np. Signal)	Całkowicie usuwają metadane w locie podczas wysyłania (end-to-end).	Pełne bezpieczeństwo – nikt nie widzi Twoich danych.
Duże social media (np. Facebook, Instagram)	Wycinają EXIF dla innych użytkowników, ale zapisują go dla siebie.	Znajomi nie poznają Twojego adresu, ale korporacja użyje go do profilowania reklam.
Fora, blogi, portale sprzedażowe (np. OLX, Vinted, Discord)	Bardzo często zostawiają pliki w stanie nienaruszonym.	Wysokie ryzyko – każdy może pobrać zdjęcie i wyciągnąć z niego Twój adres GPS.

Rozwiązanie: Image Toolbox jako lokalna gilotyna na metadane

Podstawowa higiena bezpieczeństwa nakazuje czyszczenie plików graficznych, zanim opuszczą one bezpieczną przestrzeń Twojego urządzenia. Do tego zadania najlepiej nadaje się aplikacja Image Toolbox. Jest to nowoczesne, niesamowicie szybkie i darmowe narzędzie, które zachwyca estetycznym interfejsem.

Najważniejszą cechą Image Toolbox jest to, że działa w stu procentach lokalnie. Aplikacja nie potrzebuje dostępu do internetu, a Twoje zdjęcia nie są wysyłane na żadne zewnętrzne serwery w celu obróbki. Wszystko dzieje się w ułamku sekundy w pamięci Twojego własnego telefonu.

Aplikacja pozwala na pełną kontrolę nad wysyłanym plikiem:

Usuwanie ukrytych danych jednym kliknięciem: Program całkowicie odcina cyfrowy odcisk palca, kasując współrzędne GPS, parametry aparatu oraz daty.
Przetwarzanie wielu zdjęć na raz: Nie musisz bawić się w pojedyncze pliki. Jeśli chcesz wysłać znajomym paczkę kilkudziesięciu zdjęć z wakacji, wrzucasz je wszystkie do aplikacji, a ta seryjnie tworzy czyste pliki pozbawione lokalizacji.
Zmniejszanie wagi plików: Przy okazji usuwania metadanych możesz szybko zmniejszyć rozmiar zdjęć lub zmienić ich format na nowoczesny i lekki WebP, co świetnie sprawdza się przed wrzuceniem grafik w sieć.

Finał: Wdrożenie zasady ograniczonego zaufania

Konfiguracja tego nowego nawyku jest bardzo prosta. Dodaj Image Toolbox do swojej listy w Obtainium, pobierając plik APK bezpośrednio z oficjalnych wydań (Releases) projektu na GitHubie. Dla pełnego bezpieczeństwa przepuść paczkę przez wbudowany w system lub zewnętrzny weryfikator aplikacji (App Verifier). Zanim wyślesz jakiekolwiek zdjęcie w publiczne miejsce w sieci, po prostu otwierasz je najpierw w tym programie i oczyszczasz.

Krok wyprzedzający

Warto wdrożyć jedną kluczową zmianę bezpośrednio w systemie. Wejdź w ustawienia uprawnień swojej systemowej aplikacji Aparat i całkowicie odbierz jej dostęp do lokalizacji GPS. Zdjęcia i tak posegregujesz w galerii na podstawie dat, a Twój smartfon przestanie dopisywać współrzędne geograficzne do każdego Twojego kroku.

Podsumowanie: Twoje dane, Twoje reguły

Wprowadzenie tych dwóch prostych narzędzi do codziennej rutyny drastycznie zmniejsza Twój cyfrowy ślad. Przesiadając się na aplikację PipePipe i czyszcząc zdjęcia przez Image Toolbox, przejmujesz kontrolę nad dwoma dużymi źródłami wycieku danych, które większość użytkowników po prostu ignoruje.

Pierwszy krok uwalnia Twoje codzienne nawyki i zainteresowania spod oka algorytmów profilujących Google. Drugi krok gwarantuje, że pliki, którymi dzielisz się w sieci, niosą ze sobą wyłącznie treść wizualną, a nie precyzyjny adres Twojego domu czy harmonogram dnia.

Prywatność nie wymaga od Ciebie rezygnacji z rozrywki czy technologii – wymaga jedynie korzystania z nich na Twoich własnych, twardych warunkach. Wszystkie te narzędzia są darmowe i gotowe do wdrożenia w kilka minut. Wybór należy do Ciebie.

Cyfrowa higiena bez kompromisów. Jak łatwo odizolować toksyczne aplikacje?

Eteryu — Sat, 27 Jun 2026 00:00:00 +0000

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.

1. RethinkDNS jako sieciowy szwajcarski scyzoryk (3w1)

Sam używałem tego rozwiązania jako głównej tarczy podczas walki z inwigilacją przez korporacyjne MDM. Całą konfigurację wyklikałem w zaledwie dziesięć minut na tylnym siedzeniu Bolta, jadąc do żony do szpitala. W czasie jednego krótkiego kursu odciąłem sieć wszystkim aplikacjom, tworząc restrykcyjną białą listę i spinając całość z bezpiecznym DNS od Quad9.

Jak powtórzyć ten wyczyn na własnym telefonie?

Problem: Androidowy konflikt interesów

Fabryczny Android ma jedną dużą wadę architektoniczną, ponieważ pozwala na uruchomienie tylko jednego tunelu VPN na raz. Chcesz zablokować aplikacji X dostęp do sieci za pomocą firewallu? System stawia lokalny VPN. Chcesz zaszyfrować ruch i zmienić IP na przykład przez Mullvada? Musisz włączyć kolejny VPN, który natychmiastowym ruchem wyłączy ten pierwszy.

Efekt jest taki, że albo chronisz swoją prywatność w drodze do serwera, albo kontrolujesz, co ucieka z telefonu. Nie dało się mieć ciasteczka i zjeść ciasteczka. Do teraz.

Rozwiązanie: Jeden proces, by wszystkimi rządzić

Aplikacja RethinkDNS rozwiązuje ten problem genialnie. Działa jak centralny hub, który bierze na siebie całą komunikację sieciową telefonu, ale wewnątrz pozwala Ci skonfigurować trzy niezależne warstwy. Dopiero gdy wszystko poustawiasz, aplikacja odpala jeden lekki tunel systemowy.

Oto jak skonfigurować te trzy pieczenie na jednym ogniu:

Warstwa pierwsza, czyli DNS (Zanim wyjdzie zapytanie): W zakładce DNS nie musisz polegać na domyślnych serwerach swojego operatora komórkowego. Możesz wybrać wbudowane w Rethinka listy blokujące syf albo podpiąć zewnętrzny adres, na przykład bezpieczny 9.9.9.9 od Quad9 czy NextDNS. Każde zapytanie o domenę reklamową zostanie ubite na starcie.
Warstwa druga, czyli Firewall (Kto ma prawo mówić): Przechodzisz do zakładki Apps. Tutaj zaczyna się absolutna władza. Możesz włączyć tryb Whitelisting, który blokuje wszystko domyślnie oprócz wybranych aplikacji, dokładnie tak jak zrobiłem to w taksówce. Możesz też po prostu przejrzeć listę i odciąć internet kalkulatorowi, czytnikowi PDF czy gierce offline.
Warstwa trzecia, czyli Proxy i VPN (Jak bezpiecznie lecieć w świat): To tutaj dzieje się magia. Nie musisz instalować osobnej aplikacji od dostawcy VPN. Wchodzisz w sekcję Proxy, wybierasz WireGuard i importujesz zwykły plik konfiguracyjny .conf, który pobierasz ze swojej strony profilowej na przykład w Mullvadzie czy Protonie.

Finał: Klikasz Start i zapominasz

Kiedy przejdziesz przez te trzy zakładki, wracasz na ekran główny Rethinka i klikasz wielki przycisk uruchomienia. System tworzy jeden tunel.

Od tej sekundy proces wygląda tak: toksyczna aplikacja próbuje wysłać paczkę danych, firewall w locie sprawdza, czy ma na to zgodę, a jeśli tak, DNS filtruje czy adres nie jest trackerem. Na koniec czysty ruch zostaje zapakowany w bezpieczny tunel WireGuard i wysłany w świat.

Wszystko dzieje się w ułamku sekundy, w jednym procesie, bez kłótni systemowych i bez katowania baterii kilkoma programami działającymi w tle.

2. Cyfrowa kwarantanna na toksyczne aplikacje

Są takie aplikacje, których po prostu potrzebujesz do życia lub pracy, chociaż doskonale wiesz, że ich kod pisali specjaliści od wysysania danych. Microsoft Teams, Facebook, Messenger, aplikacje linii lotniczych czy popularne dyskonta spożywcze. Wszystkie one potrafią bezwstydnie żądać dostępu do Twoich kontaktów czy całej galerii zdjęć, a jeśli im odmówisz, potrafią być niesamowicie upierdliwe lub wręcz odmawiają posłuszeństwa. Zamiast bawić się w hakowanie uprawnień przez komputer, możesz użyć genialnego mechanizmu izolacji, który Twój telefon ma już wbudowany pod maską.

Private Space / Secure Folder (wewnątrz profilu)Osobny profil użytkownika (pełna separacja)

Jeśli masz nowszego Androida z funkcją Private Space lub używasz telefonu Samsung z funkcją Bezpieczny Folder, konfiguracja jest banalnie prosta. Wchodzisz w ustawienia bezpieczeństwa systemu, aktywujesz tę osobną przestrzeń i zabezpieczasz ją osobnym kodem PIN lub odciskiem palca. Od tej chwili na dole listy aplikacji pojawia się specjalna, zablokowana sekcja.

Konfiguracja aplikacji polega po prostu na zainstalowaniu jej bezpośrednio wewnątrz tej ukrytej przestrzeni. Kiedy to zrobisz, system odpala dla niej kompletnie czyste środowisko. Taki program ma swoją osobną pamięć podręczną i nie widzi Twoich prywatnych zdjęć ani kontaktów z głównego profilu. Jeśli nienasytny komunikator wewnątrz prywatnej przestrzeni zażąda dostępu do książki adresowej, dajesz mu zgodę bez mrugnięcia okiem. Aplikacja przeszuka bazę danych, zobaczy cyfrowe nic, nie zgłosi błędu i pozwoli Ci działać. Myśli, że dostała to, czego chciała, a w rzeczywistości została całkowicie oszukana.

W przypadku Samsunga powiadomienia o nowych wiadomościach zobaczysz na głównym ekranie w dyskretnej, ukrytej formie. Z kolei na czystym Androidzie z funkcją Private Space aplikacje zostaną całkowicie zamrożone i nie będą zawracać Ci głowy ani zużywać baterii, dopóki sam nie zdecydujesz się odblokować swojej prywatnej przestrzeni.

Jeśli Twój telefon nie ma jeszcze funkcji Private Space, możesz użyć klasycznych profili użytkowników, które działają dokładnie tak jak konta dla różnych osób na domowym komputerze. Wchodzisz w ustawienia systemowe, wybierasz sekcję Użytkownicy i klikasz Dodaj użytkownika. Przełączanie między nimi zajmuje jedno kliknięcie w górnej belce powiadomień.

Konfiguracja tej metody wymaga odrobiny cierpliwości, ponieważ system tworzy wtedy drugi, fabrycznie nowy telefon wewnątrz starego. Przełączasz się na nowy profil i instalujesz tam aplikacje. Ta metoda daje najbardziej bezwzględną izolację ze wszystkich możliwych, ponieważ aplikacje z drugiego profilu są całkowicie zamrożone i nie mają żadnego kontaktu z Twoim głównym kontem.

Haczyk polega na tym, że dopóki nie przełączysz się ręcznie na ten drugi profil, nie zobaczysz pochodzących z niego powiadomień. To genialne rozwiązanie na aplikacje służbowe, które chcesz kompletnie wyciszyć po godzinach pracy.

Niezależnie od wybranej ścieżki, efekt końcowy jest ten sam. Toksyczna aplikacja ląduje w kontrolowanej piaskownicy, a Ty odzyskujesz prywatność bez rezygnacji z narzędzi niezbędnych do codziennego funkcjonowania.

Podsumowanie: Twoje własne zasady

Wprowadzenie tych dwóch mechanizmów w życie zajmie Ci łącznie kilkanaście minut, a diametralnie zmieni zasady gry. Łącząc RethinkDNS z systemową izolacją (Private Space lub Profilami użytkowników), tworzysz wokół swoich danych potężny mur o dwóch niezależnych warstwach. Pierwsza warstwa pilnuje, by z Twojego urządzenia nie wypłynął żaden nieautoryzowany pakiet informacji. Druga dba o to, by aplikacje, na które jesteś skazany, żyły w cyfrowej niewiedzy i były całkowicie odcięte od Twojej prywatności.

Smartfon ma być narzędziem, które ułatwia Ci codzienne funkcjonowanie, a nie szpiegiem pracującym na etacie u brokerów danych. Najlepsze jest to, że nie potrzebujesz do tego skomplikowanego hakowania systemu. Wszystkie te opcje masz już pod maską – wystarczy po prostu zacząć z nich korzystać na własnych warunkach.

Cyfrowa higiena podczas przerwy na kawę. Jak łatwo odzyskać kontrolę nad telefonem?

Eteryu — Wed, 24 Jun 2026 00:00:00 +0000

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ę.

1. Zmyj swój cyfrowy tatuaż

Większość z nas nosi w kieszeni unikalny numer ukryty głęboko w systemie, tak zwany identyfikator reklamowy. To właśnie ten cyfrowy tatuaż pozwala firmom marketingowym i brokerom danych łączyć Twoje luźne ruchy w różnych aplikacjach w jeden spójny profil.

AndroidiOS (Apple)

Począwszy od systemu Android 12, Google umożliwiło użytkownikom całkowite usunięcie identyfikatora reklamowego. W celu jego trwałego usunięcia należy wykonać poniższe kroki:

Otwórz główne Ustawienia telefonu i przejdź do zakładki Google (lub Usługi Google).
Wybierz kartę Wszystkie usługi, a następnie kliknij w sekcję Reklamy.
Wybierz opcję „Usuń identyfikator reklamowy” i potwierdź swój wybór.

Starsze wersje systemu (Android 11 i niżej)

Na starszych urządzeniach opcja całkowitego usunięcia może nie być dostępna. Wtedy w tym samym menu warto wybrać opcję nakazującą systemowi zablokowanie personalizacji reklam.

Jeśli ekran jest zupełnie pusty i widzisz tylko pojedynczy link informacyjny, to gratulacje. Oznacza to, że po wcześniejszym wyłączeniu personalizacji reklam bezpośrednio na swoim koncie Google, system automatycznie wykasował ten identyfikator z poziomu urządzenia.

Apple rozwiązuje ten problem systemowo. Funkcja App Tracking Transparency sprawia, że przy instalacji aplikacji wystarczy kliknąć „Poproś aplikację o nieśledzenie”.

W ustawieniach systemowych warto też wyłączyć opcję „Pozwalaj aplikacjom żądać możliwości śledzenia”, co odcina aplikacjom samą możliwość wyświetlania takich zapytań. Apple posiada również własny system reklamy ukierunkowanej, który można wyłączyć w sekcji Reklamy Apple w ustawieniach prywatności.

W obu przypadkach cel zostaje osiągnięty: dla całego przemysłu reklamowego stajesz się czystą kartą.

2. Wielka czwórka uprawnień: Lokalizacja, Sieć, Tło i ukryte skanowanie

Zanim bezrefleksyjnie klikniesz „Zezwól” przy kolejnym wyskakującym okienku po instalacji nowej aplikacji, zatrzymaj się na sekundę. Aby aplikacja mogła Cię skutecznie profilować, musi zebrać dane, działać po cichu, kiedy śpisz, i mieć jak wysłać te paczki na serwer brokerów.

Oto jak skutecznie rozbić ten proces na czynniki pierwsze:

Lokalizacja to nie przymus (Case pogodynki i taksówek). Aplikacje do zamawiania taksówek oraz pogodynki świetnie dadzą sobie radę bez GPS, wystarczy ręcznie wpisać adres lub nazwę miasta. Zamiast usług od Google czy Apple, możesz postawić na rozwiązania w stu procentach lokalne i otwartoźródłowe, takie jak Organic Maps czy OsmAnd. Wgrywasz do nich pobrane wcześniej mapy i podróżujesz całkowicie offline. Jeśli natomiast jakaś inna apka koniecznie domaga się lokalizacji, zawsze wybieraj opcję „przybliżona” zamiast precyzyjnej.
Ukryte radary (Skanowanie Wi-Fi i Bluetooth). Większość ludzi myśli, że jak wyłączy GPS, to jest niewidzialna. Nic bardziej mylnego. Telefony domyślnie przeczesują otoczenie w poszukiwaniu routerów i beaconów reklamowych, nawet gdy masz te moduły oficjalnie wyłączone. Brokerzy danych używają tych sygnałów, by wiedzieć, przy której półce sklepowej stoisz. Wejdź w ustawienia lokalizacji, znajdź sekcję Skanowanie Wi-Fi i Bluetooth i wyłącz obie te opcje.
Odcięcie od sieci, po co im internet? Jeśli aplikacja (np. czytnik PDF, kalkulator czy gra jednoosobowa) działa w stu procentach lokalnie, warto zablokować jej dostęp do internetu komórkowego i Wi-Fi. Choćby zebrała tonę statystyk wewnątrz telefonu, bez dostępu do sieci nie ma jak wysłać ich w świat.

Blokada sieci na czystym Androidzie

Nakładki takie jak One UI (Samsung) czy HyperOS (Xiaomi) mają wbudowane opcje blokowania sieci w ustawieniach aplikacji. Jeśli używasz „czystego” Androida, np. na Pixelu, możesz użyć prostej i bezpiecznej aplikacji typu firewall, na przykład NetGuard.
Koniec z pracą na trzy zmiany (Działanie w tle). Wiele aplikacji żyje własnym życiem, kiedy z nich nie korzystasz. Wejdź w ustawienia aplikacji (lub baterii) i dla wszystkiego, co nie musi wysyłać Ci natychmiastowych powiadomień, całkowicie wyłącz opcję „Zezwalaj na działanie w tle” (Allow background usage). Telefon nie tylko przestanie nadawać za Twoimi plecami, ale też podziękuje Ci za to znacznie dłuższym czasem pracy na jednym ładowaniu.

3. Postaw systemową tarczę na trackery

Wszystko, co mimo powyższych blokad spróbuje wysłać zapytanie z Twojego telefonu, można przefiltrować w locie, zanim w ogóle dotrze do serwerów szpiegujących czy analitycznych. Masz do wyboru dwie najprostsze drogi:

Prywatny DNS (Darmowy i lekki). To genialna funkcja wbudowana w każdy nowoczesny telefon. Wchodzisz w ustawienia sieciowe, znajdujesz opcję Prywatny DNS i wpisujesz tam darmowy adres filtrujący, na przykład od NextDNS lub AdGuard. Od tej sekundy system sam automatycznie blokuje zapytania do znanych sieci reklamowych.
VPN z filtrem (Wygoda Premium). Jeśli zależy Ci nie tylko na blokowaniu trackerów, ale chcesz też zamaskować swój adres IP i zaszyfrować ruch, świetnym rozwiązaniem są sprawdzone usługi takie jak Proton VPN czy Mullvad.

Podsumowanie: Prywatność to proces

Prywatność to proces, a nie stan zero czy jeden. Nie musisz nagle wyrzucać telefonu ani rezygnować z technologii. Wdrożenie tych kilku prostych kroków sprawi, że Ty i Twój telefon przestaniecie być otwartą księgą dla komercyjnych firm. Cyfrowa higiena jest prosta, wystarczy zacząć od małych, świadomych zmian.

Lekcja prywatności z Poznania. Czego uczy nas "afera" wokół Pyrkonu?

Eteryu — Mon, 22 Jun 2026 00:00:00 +0000

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.

Choć w sieci dostępny jest pełny, dwugodzinny zapis tego posiedzenia, większość komentujących oparła swoje oburzenie wyłącznie na wyrwanym z kontekstu fragmencie. W internetowych debatach natychmiast wybuchło oburzenie, podsycone bezpośrednio przez samych autorów medialnego zamieszania. Profile, które nagłośniły sprawę, zaczęły wybiórczo podbijać wyłącznie te komentarze, które wpisują się w sensacyjną narrację o nielegalnym szpiegowaniu obywateli i rażącym łamaniu przepisów RODO. Głosy merytoryczne, precyzyjnie wyjaśniające techniczną naturę przetwarzania danych czy mechanizmy komercyjnych zgód u operatorów są w tej dyskusji systemowo ignorowane i pomijane, byle tylko utrzymać wysoki poziom emocji. Kiedy jednak te emocje opadną i spojrzymy na mechanizmy rynkowe z chłodną, techniczną głową, okazuje się, że problem leży zupełnie gdzie indziej. I jest on o wiele poważniejszy niż lokalne, polityczne przepychanki oparte na słowach urzędników.

1. Jak powstają takie raporty, czyli makro vs mikro

W oficjalnym oświadczeniu wydanym przez PLOT organizacja wprost odniosła się do burzy medialnej wywołanej wyciętym fragmentem nagrania. Prezes zarządu, Jan Mazurczak, jednoznacznie potwierdził w nim techniczną naturę badania: miasto nie kupuje bilingów, numerów PESEL ani nazwisk. Samorządy i lokalne organizacje turystyczne kupują po prostu gotowe, w pełni zagregowane i zanonimizowane produkty statystyczne od firm zewnętrznych – w tym przypadku od wyspecjalizowanej firmy analitycznej Selectivv.

Warto wyraźnie rozróżnić dwie sytuacje:

Dla firmy analitycznej identyfikatory urządzeń mobilnych to dane, które przetwarza ona na podstawie zgód pobieranych w tysiącach darmowych aplikacji. Brokerzy danych muszą pilnować procedur i dbać o własne zaplecze prawne.
Dla Poznańskiego Urzędu Miasta czy PLOT sytuacja wygląda zupełnie inaczej. Żadne unikatowe identyfikatory czy dane osobowe do urzędników nie trafiają. Miasto kupuje wyłącznie suche, zbiorcze wykresy procentowe, tabele i trendy.

Żaden analityk nie łączy prywatnych wiadomości z telefonu konkretnego uczestnika z jego osobistym kontem bankowym, bo takie działanie byłoby przestępstwem. W publicznych debatach urzędnicy często używają skrótów myślowych, mówiąc ogólnie o „zliczaniu telefonów" czy „danych od operatorów" (co mogłoby sugerować namierzanie kart SIM przez maszty BTS). W rzeczywistości – jak potwierdza oświadczenie PLOT – głównym motorem tych analiz jest ekosystem reklamy mobilnej.

Analizy opierają się na anonimowych identyfikatorach reklamowych urządzeń (MAID). Dla systemów analitycznych Twój smartfon to po prostu anonimowa kropka przemieszczająca się po mapie. Jeśli algorytm widzi, że tysiące takich kropek rano znajdowały się na terenie Międzynarodowych Targów Poznańskich, a po południu przemieściły się w rejon konkretnych hoteli czy restauracji, po prostu łączy te punkty, zliczając masowe trendy.

Podobnie wygląda kwestia szacowania wydatków – to średnia estymacja ekonometryczna. Ogólny, odnotowany przez partnerów finansowych wzrost obrotów w handlu i gastronomii w danym rejonie dzieli się przez szacowaną liczbę nadmiarowych turystów. Z perspektywy prawa wszystko jest czyste. PLOT wskazuje, że model przetwarzania danych przez Selectivv posiada audyt niezależnej firmy Deloitte Consulting S.A., który potwierdza pełną zgodność z RODO oraz brak możliwości identyfikacji konkretnych osób fizycznych.

2. Gdzie leży prawdziwy problem? Historia zatacza koło

Skoro od strony prawa wszystko jest w porządku, to dlaczego sprawa wciąż budzi tak duży niepokój? Ponieważ cała ta sytuacja obnaża brutalną prawdę o współczesnym internecie: prawdziwym źródłem danych dla brokerów informacji nie są urzędy miast, ale smartfony, które codziennie nosimy w kieszeniach, a dokładniej oprogramowanie, które sami na nich instalujemy.

Co ciekawe, dokładnie z tą samą sytuacją mieliśmy do czynienia już wiele lat temu. Jak przypominał serwis Niebezpiecznik.pl w swoim głośnym artykule „Za darmowe aplikacje mobilne płacisz informacjami o sobie", ta sama firma – Selectivv – wywołała potężny skandal po festiwalu Open'er 2017. Analizując smartfony uczestników tamtego wydarzenia, firma opublikowała infografiki pokazujące między innymi, ile procent festiwalowiczów „stara się o dziecko" (wywnioskowane przez analityków na podstawie profilu zachowań oraz używania specyficznych aplikacji zdrowotnych czy ciążowych) albo w jakich dyskontach najczęściej robią zakupy.

Fakt, że po niemal dekadzie, wdrożeniu restrykcyjnego unijnego prawa RODO i setkach debat o prywatności dokładnie te same mechanizmy i ta sama firma nadal z powodzeniem analizują nasze zachowania, pokazuje jedno: systemowe i prawne próby ochrony naszej prywatności, w oderwaniu od świadomości użytkownika, to fikcja.

Większość darmowych programów, prostych gier, aplikacji pogodowych czy latarek utrzymuje się z tego, że w ich kodzie zaszyte są pakiety reklamowe i analityczne (tak zwane SDK). To właśnie te komponenty bez przerwy odczytują unikalny identyfikator reklamowy Twojego telefonu i potrafią wysyłać go w świat razem z dokładną lokalizacją GPS. Choć duże platformy zakupowe (jak niezwykle popularne Temu) zbierają potężne ilości danych głównie na własny użytek, to właśnie setki mniejszych, darmowych aplikacji stanowią główny silnik zasilający bazy zewnętrznych hurtowni danych.

Użytkownicy w sieci często podnoszą argument: „Przecież to zgody wymuszone! Jeśli chcę mieć telefon czy konto w banku, muszę podpisać umowę, więc nie ma tu mowy o uczciwym wyborze". Niestety, od strony formalnej i biznesowej rzeczywistość bywa jeszcze bardziej cyniczna. Operatorzy telekomunikacyjni, budując własne narzędzia analityczne (na przykład Orange Insights), wykorzystują logowania do stacji bazowych (BTS). Po pełnej anonimizacji danych (gdy algorytm zlicza tylko suche statystyki typu „w tym kwadrancie zalogowało się 500 kart SIM"), RODO przestaje mieć zastosowanie, bo z wykresu zbiorczego nie da się zidentyfikować żywego człowieka.

Co więcej, operatorzy stosują prosty mechanizm psychologiczny: oferują stałą zniżkę na fakturze (na przykład 5 zł miesięcznie) w zamian za zaznaczenie zgód marketingowych i analitycznych przy podpisywaniu umowy lub w aplikacji. Klient kalkuluje szybko i wybiera tańszy abonament. W ten sposób ludzie dosłownie sprzedają historię swojej lokalizacji za parę złotych rabatu, dając telekomom pełne prawo do komercyjnej analizy tego ruchu, a potem w internetowej przestrzeni wybucha zdziwienie, że firmy z tych zgód korzystają. Oficjalnie można te zgody wycofać – ale wtedy traci się rabat.

3. Sprawdź swój telefon: Exodus Privacy

Zamiast teoretyzować, szukać spisków lub opierać się na emocjach wywołanych wypowiedziami polityków, warto zejść na poziom twardych faktów technicznych. Każdy może samodzielnie zweryfikować, co tak naprawdę dzieje się wewnątrz własnego smartfona.

Doskonale nadaje się do tego platforma Exodus Privacy (exodus-privacy.eu.org). To w pełni darmowy i niezależny projekt prowadzony przez francuską organizację pożytku publicznego, który pozwala przeanalizować niemal każdą aplikację dostępną w sklepie Google Play pod kątem wbudowanych elementów śledzących oraz wymaganych uprawnień.

Wystarczy wpisać na stronie głównej projektu lub w bazie reports.exodus-privacy.eu.org nazwę dowolnego programu, z którego korzystasz na co dzień, aby czarno na białym zobaczyć listę wbudowanych trackerów reklamowych i analitycznych. To potężne źródło wiedzy, które potrafi otworzyć oczy i skutecznie wyleczyć z technologicznej naiwności. Ludzi trzeba uświadamiać i pokazywać im te mechanizmy merytorycznie, zamiast zamieniać temat prywatności w polityczną burzę.

4. Cyfrowa higiena zamiast skarg do radnych

Oficjalna odpowiedź PLOT dobitnie pokazuje jedno: nie ma sensu liczyć na odgórne zmiany systemowe, nowe ustawy czy rewolucje w prawie. Wszystko, co się wydarzyło, odbyło się legalnie, zgodnie z procedurami i pod osłoną unijnych przepisów. Prawo zawsze będzie o krok za technologią, a korporacje zawsze znajdą sposób, by napisać regulamin i warunki korzystania z usług (TOS) na pięćdziesiąt stron drobnym drukiem, którego nikt nie przeczyta.

Skoro oficjalne systemy zgód i prawo RODO chronią przede wszystkim urzędy i firmy od strony formalnej, jedyną skuteczną barierą ochronną przed masowym profilowaniem pozostaje nasza własna, codzienna higiena cyfrowa. Musimy zacząć działać u samego źródła. Narzędzia obrony mamy we własnych rękach.

Co możesz zrobić na swoim telefonie od zaraz?

Kontroluj i cofaj uprawnienia: Wejdź w ustawienia systemowe swojego smartfona i bezwzględnie zablokuj dostęp do lokalizacji GPS, kontaktów, aparatu czy pamięci urządzenia wszystkim aplikacjom, które nie potrzebują tego do swojego podstawowego działania. Aplikacja z przepisami kulinarnymi czy latarka nie muszą wiedzieć, gdzie aktualnie przebywasz.
Odcinaj dostęp do sieci aplikacjom offline: Programom, które działają całkowicie lokalnie (takim jak proste gry jednoosobowe, kalkulatory, dyktafony czy lokalne odtwarzacze muzyki), warto całkowicie odebrać uprawnienie do korzystania z transmisji danych i Wi-Fi. Gra nadal będzie działać idealnie, ale zaszyte w niej skrypty reklamowe stracą techniczną możliwość wysłania jakichkolwiek informacji na serwery zewnętrznych firm.
Blokuj działanie w tle: Odbierz uprawnienia do pracy w tle aplikacjom, które nie muszą bez przerwy nasłuchiwać na zablokowanym ekranie. Jeśli program nie służy do komunikacji i nie musi dostarczać natychmiastowych powiadomień, powinien uruchamiać się tylko wtedy, gdy świadomie go otwierasz, a po wyjściu – natychmiast kończyć swoją aktywność.
Zresetuj lub usuń identyfikator reklamowy: W ustawieniach prywatności systemu Android (sekcja Prywatność -> Reklamy) znajdziesz opcję odpowiedzialną za Twój identyfikator reklamowy (GAID) – możesz go w każdej chwili zresetować lub całkowicie usunąć. Z kolei w systemie iOS (Apple) warto wejść w sekcję Prywatność i bezpieczeństwo -> Śledzenie i całkowicie zabronić aplikacjom wysyłania żądań śledzenia, co odetnie im dostęp do Twojego profilu reklamowego (IDFA).
Wybieraj otwarte oprogramowanie (FOSS): Kiedy to tylko możliwe, zastępuj darmowe, własnościowe aplikacje zbierające dane ich otwartymi, bezpiecznymi alternatywami, które nie posiadają wbudowanych modułów śledzących.

Prawdziwa walka o prywatność nie rozgrywa się na sesji rady miasta, w komitetach politycznych ani w sekcji komentarzy na portalach społecznościowych. Ona rozgrywa się w menu ustawień Twojego własnego smartfona. Zamiast bezrefleksyjnie klikać „akceptuję wszystko" dla własnej wygody, dla kilku złotych zniżki lub w naiwnej wierze, że przed tym wszystkim obroni nas RODO, zacznij świadomie kontrolować to, co Twoje urządzenie wysyła w świat. Zamiast robić medialny wir w szklance wody i licytować się na oburzenie, o wiele lepiej zacząć rzetelnie edukować ludzi: pokazywać im, jakie konkretnie informacje, w jaki sposób i przez kogo są o nich zbierane, a przede wszystkim jak skutecznie i samodzielnie się przed tym bronić.

Mój zero-trust setup w 2026 roku: Google Pixel 8 + GrapheneOS

Eteryu — Mon, 22 Jun 2026 00:00:00 +0000

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.

Architektura profili: Separacja i pragmatyzm

Fundamentem mojego setupu jest ścisła izolacja danych. Zamiast mieszać wszystko w jednym miejscu, podzieliłem system na dwie sfery:

Profil główny (Main Profile): Całkowicie pozbawiony usług Google. Czyste środowisko FOSS (Free and Open Source Software). To tutaj toczy się 90% mojego cyfrowego życia.
Obszar prywatny (Private Space): Odizolowana przestrzeń, w której żyją zapiaskowniczone (sandboxed) Google Services oraz Google Play Store.

Konto używane w Play Store to zwykła „wydmuszka" bez powiązania z moją tożsamością. Samego sklepu używam wyłącznie do pobierania i aktualizowania aplikacji bankowych. Uważam, że oficjalne repozytorium to wciąż najbezpieczniejsze miejsce, z którego można pobrać aplikacje finansowe, ponieważ minimalizuje to ryzyko podrzucenia zmodyfikowanego pliku APK.

Ruch sieciowy: Izolacja WireGuard i specyfika Private Space

Prywatność na urządzeniu nie ma sensu bez zabezpieczenia sieci. Na obu profilach używam oficjalnego klienta WireGuard. Całość opiera się na plikach konfiguracyjnych .conf, które można w prosty sposób wygenerować bezpośrednio na stronie internetowej Mullvad VPN.

Podczas generowania profilu na ich platformie możemy zintegrować tunel z DNS content blockerem, który wycina reklamy, trackery i malware. Tak przygotowany plik pobieramy, a następnie importujemy do aplikacji WireGuard.

Warto pamiętać, że oba środowiska są od siebie odizolowane i nie współdzielą działających w tle połączeń VPN. WireGuard musi być zainstalowany i skonfigurowany na każdym profilu osobno. Aby ruch się nie mieszał, zastosowałem dywersyfikację geograficzną: profil główny łączy się przez lokalizację w Warszawie (PL), natomiast Private Space tuneluje ruch przez Amsterdam (NL).

Kluczowa jest tu jednak specyfika działania samego systemu. Gdy opuszczam Private Space i blokuję tę przestrzeń, wszystkie znajdujące się tam aplikacje – w tym również tamtejszy klient WireGuard – są całkowicie zamrażane. Ruch sieciowy dla profilu prywatnego zostaje odcięty, a aktywny pozostaje wyłącznie VPN i procesy w profilu głównym. Na obu profilach mam włączone systemowe opcje Always On oraz Block Connections without VPN. Dzięki temu, nawet podczas przełączania przestrzeni czy ewentualnego rozłączenia tunelu, telefon całkowicie blokuje niezaszyfrowany ruch, zapobiegając wyciekom danych (leakom).

Wygoda i Hardware: Bezpieczeństwo bez kompromisów w UX

Częstą obawą przy przejściu na GrapheneOS jest utrata wygody, jaką dają systemy komercyjne. W moim przypadku Google Pixel 8 pod kontrolą alternatywnego ROM-u w żaden sposób nie odstaje od zwykłego telefonu z iOS czy stockowym Androidem. Co więcej, uważam, że jest od nich lepszy, bo to ja mam nad wszystkim pełną kontrolę.

Jak wygląda codzienne użytkowanie od strony technicznej?

Karta SIM: Korzystam z fizycznej karty SIM. Z perspektywy prywatności nie różni się ona niczym od eSIM, a zapewnia pełną niezależność sprzętową.
Uwierzytelnianie: Do odblokowywania urządzenia używam PIN-u z włączoną opcją scrambled PIN. To losowy układ cyfr na ekranie przy każdej próbie odblokowania, co uniemożliwia odczytanie kodu na podstawie śladów palców lub podglądania.
Biometria: Używam również odcisku palca. Skaner działa bezbłędnie w każdym z profili. Warto pamiętać, że ze względów bezpieczeństwa w GrapheneOS zarówno PIN, jak i odciski palców trzeba skonfigurować osobno dla każdego profilu użytkownika.
Higiena powiadomień: Moje podejście do powiadomień push jest bardzo restrykcyjne. Jedyne aplikacje w całym telefonie, które mają uprawnienia do wysyłania powiadomień, to Molly, Telefon, Zegar (na potrzeby budzika), Wiadomości oraz ntfy. Całkowite odcięcie się od usług Google na profilu głównym rozwiązałem za pomocą wdrożenia pary Molly i ntfy działających w oparciu o protokół UnifiedPush. Dzięki temu wiadomości przychodzą natychmiast, a brak ciągłego odpytywania serwerów w tle przekłada się na znacznie lepsze utrzymywanie baterii.
Zapiaskowane usługi Google: W Private Space usługi Google są całkowicie „ślepe i głuche". Mają odebrane uprawnienia do lokalizacji czy danych urządzenia. Działają wyłącznie jako odizolowane procesy tła niezbędne do tego, by aplikacje bankowe nie zgłaszały błędów.

Komunikacja, tożsamość i przeglądanie sieci

Moja poczta to Tuta Mail w połączeniu z Addy.io do tworzenia aliasów, gdzie posługuję się wygodnym panelem webowym. Dla każdej usługi tworzę osobny alias. Jeśli baza danych jakiegoś serwisu wycieknie, po prostu usuwam alias, a mój główny adres pozostaje bezpieczny.

W kwestii przeglądania internetu stosuję zasadę absolutnego minimalizmu i pełnego zaufania do inżynierii GrapheneOS. Pozbyłem się z systemu wszelkich zewnętrznych forków (takich jak Cromite), aby maksymalnie zmniejszyć powierzchnię ataku i nie polegać na zewnętrznych deweloperach.

Cały ruch webowy obsługuje u mnie jedna przeglądarka, ale podzielona na dwie instancje odizolowane zarówno na poziomie systemu, jak i sieci:

Vanadium w profilu głównym (Codzienny driver): Służy mi do codziennego przeglądania sieci. Za blokowanie reklam, skryptów śledzących i malware odpowiada tutaj tunel WireGuard zintegrowany z filtrami DNS od Mullvad VPN. Dzięki temu ochrona działa na poziomie sieciowym, a przeglądarka nie jest obciążona dodatkowym, zewnętrznym kodem.
Vanadium w Private Space (Dane wrażliwe): Druga, całkowicie czysta instancja przeglądarki, działająca w odizolowanym obszarze systemu. Używam jej wyłącznie do logowania się do bankowości czy usług urzędowych, gdzie i tak posługuję się realnymi danymi osobowymi. Ta przestrzeń posiada swój własny, osobny tunel VPN z filtrowaniem DNS, a gdy ją opuszczam, całe środowisko (wraz z przeglądarką, sesjami i procesami sieciowymi) zostaje natychmiast zamrożone.

Higiena uprawnień i bezpieczny łańcuch dostaw

Moje podejście do uprawnień nie znosi kompromisów. Wszystkie aplikacje, które nie wymagają połączenia z internetem do swojego podstawowego działania, mają całkowicie odebrany dostęp do sieci poprzez funkcję Network Permission. Podobnie te, które nie muszą działać w tle, nie mają pozwolenia na Allow Background Usage. GrapheneOS pozwala na taką blokadę nawet wobec domyślnych aplikacji systemowych, co na stockowym Androidzie jest niewykonalne.

Do pobierania i aktualizacji aplikacji na profilu głównym używam zamkniętego, bezpiecznego łańcucha dostaw składającego się z zestawu:

Obtainium -> GitHub -> AppVerifier BG

Obtainium pobiera czyste pliki bezpośrednio z wydań (releases) na repozytoriach autorów. Następnie AppVerifier BG (fork oryginału oferujący bazę tworzoną przez Privacy Guides dla ich projektu Verified Apps oraz opcję importu, eksportu i tworzenia lokalnej bazy) sprawdza, czy podpis kryptograficzny pobranej aplikacji jest w 100% zgodny z oryginałem. To świetny podwójny test (double-check) chroniący przed sytuacją, w której konto dewelopera na GitHubie zostało przejęte i podmieniono w nim pliki APK.

Mój codzienny zestaw aplikacji (App Stack)

Na chwilę obecną zbieram się do stworzenia mojego małego homelabu i rozpoczęcia przygody z self-hostingiem. Póki co używam albo aplikacji lokalnych z możliwością eksportu danych, albo zaufanych chmur typu zero-knowledge.

Podstawowe narzędzia, takie jak Telefon, Wiadomości, Zegar, Aparat czy Menedżer plików, to bezpieczne aplikacje systemowe dostarczane przez GrapheneOS. Reszta mojego stacku wygląda następująco:

Prywatność, Bezpieczeństwo i Komunikacja

KeePassDX: Menedżer haseł. Działa w 100% lokalnie i pozwala na eksport bazy haseł do bezpiecznego pliku .kdbx.
Aegis: Obsługa weryfikacji dwuskładnikowej (2FA). Bezpieczna, otwarta aplikacja z opcją szyfrowanego eksportu bazy do pliku.
Molly: Utwardzony pod kątem bezpieczeństwa fork Signala, który służy mi jako główny komunikator.
ntfy: Wspomniany wcześniej klient powiadomień UnifiedPush, który dostarcza wiadomości z Molly.
HeliBoard: Klawiatura. To jedno z najbardziej wrażliwych miejsc w systemie, bo to właśnie klawiatury bywają największymi zbieraczami danych. Choć HeliBoard to rozwiązanie FOSS i privacy-friendly, profilaktycznie ma całkowicie odcięty dostęp do sieci (Network Permission) oraz wyłączoną opcję uczenia się na podstawie wpisywanego tekstu.

Przechowywanie danych i Produktywność

Filen: Dysk chmurowy działający w modelu zero knowledge, przeznaczony do bezpiecznego przechowywania plików i backupów.
Ente Photos: Świetna alternatywa dla Google Photos. Szyfrowany (E2EE) cloud storage dla zdjęć oraz lokalna galeria działająca na urządzeniu.
Quillpad: Otwartoźródłowa aplikacja, która przejmuje u mnie rolę edytora tekstu, notatnika i narzędzia do list todo. Zastąpiła dotychczasowe rozwiązania, idealnie wpisując się w mój minimalistyczny workflow oparty na filozofii FOSS.

Fotografia i higiena metadanych (OpSec)

Pixel Camera: Oficjalna aplikacja aparatu od Google dla serii Pixel zapewnia pełną jakość przetwarzania obrazu i zaawansowane algorytmy trybu nocnego. Działa u mnie całkowicie na moich warunkach, ponieważ ma permanentnie odebrane uprawnienie dostępu do sieci (Network Permission).
GCam Services Provider (photosonly): To lekki, otwartoźródłowy mostek (stub) autorstwa lukaspieper, który imituje obecność usług Google Play wyłącznie w zakresie wymaganym do podglądu zdjęć. Dzięki niemu aparat działa stabilnie offline i płynnie przekazuje pliki do zewnętrznej galerii (Ente Photos).
Image Toolbox: Kluczowe narzędzie w moim codziennym OpSec. Zanim jakiekolwiek zdjęcie z galerii trafi do sieci, na bloga czy do komunikatora, przepuszczam je przez Image Toolbox za pomocą szybkiego menu Udostępnij. Aplikacja w sekundę sterylizuje plik z metadanych EXIF, wycinając lokalizację GPS, znacznik czasu oraz model urządzenia.

Rozrywka i Codzienność

NewPipe: Pełni u mnie funkcję awaryjnego klienta YouTube. Zastąpił aplikację PipePipe, ponieważ nie potrzebuję aż tylu źródeł wideo i korzystam tylko z YT. Każda linijka niewykorzystywanego kodu to zbędne ryzyko w moim threat modelu, podejściu zero trust i pod kątem attack surface. Ponadto NewPipe jest częściej aktualizowany i bardziej stabilny. Dodatkowo mocno ograniczam korzystanie z YouTube na telefonie, więc sięgam po niego tylko, gdy naprawdę muszę.
Auxio: Odtwarzacz przejmujący rolę słuchania muzyki (wcześniej realizowaną przez PipePipe). Używam go, aby intencjonalnie i świadomie budować własną playlistę. Zanim na dobre rozpocznę przygodę z selfhostingiem i własnym homelabem, jest to dla mnie świetne rozwiązanie, które przy okazji omija problemy z frontendami YouTube i ich API.
Breezy Weather: Przejrzysta, estetyczna i otwarta aplikacja pogodowa.
Calculator You: Otwarta, nowoczesna alternatywa dla domyślnego kalkulatora systemowego.

A co z bankowością i bezpieczeństwem niskopoziomowym?

Wielu użytkowników obawia się, czy aplikacje bankowe w ogóle ruszą na alternatywnym systemie operacyjnym. W Polsce sytuacja wygląda zaskakująco dobrze, ale zamiast opisywać każdy bank z osobna, odsyłam Was do gotowych, stale aktualizowanych zestawień kompatybilności:

Warto pamiętać, że GrapheneOS chroni nas znacznie głębiej niż na poziomie samych uprawnień w interfejsie. System natywnie blokuje dostęp do mechanizmów Dynamic Code Loading (DCL) poprzez pamięć operacyjną czy pamięć masową oraz skutecznie odpiera dziesiątki innych exploitów. O tym procesie, jak i o analizie zagrożeń za pomocą frameworku STRIDE.

Podsumowanie

Wdrożenie modelu zero trust na Pixelu 8 wymaga zmiany pewnych przyzwyczajeń, ale daje niesamowite poczucie kontroli. Świadomość, że mój telefon nie wysyła telemetrycznego raportu o każdym moim kroku do korporacyjnych serwerów, jest warta każdej minuty spędzonej na konfiguracji.

Nowoczesny degoogle to nie asceza. To stan, w którym smartfon w końcu staje się moim narzędziem, a nie ja jego produktem.

A jak wyglądają Wasze doświadczenia z GrapheneOS? Idziecie w pełną izolację czy szukacie kompromisów? Dajcie znać w komentarzach na Mastodonie!

Świadomy kompromis: Dynamic Code Loading vs Piaskownica GrapheneOS

Eteryu — Sun, 21 Jun 2026 00:00:00 +0000

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).

Oto szczegółowa analiza techniczna tego kompromisu, przeprowadzona za pomocą frameworku modelowania zagrożeń STRIDE.

Czym jest Dynamic Code Loading (DCL) i dlaczego system go nienawidzi?

W klasycznym modelu Androida aplikacja instalowana jest jako kompletny pakiet APK. System operacyjny podczas instalacji zna strukturę kodu i może narzucić mu odpowiednie ramy. Dynamic Code Loading (DCL) to mechanizm, w którym aplikacja już po uruchomieniu pobiera i wykonuje dodatkowy kod (pliki .dex lub natywne biblioteki współdzielone .so), który nie był spakowany w pierwotnym instalatorze.

Architektonicznie DCL dzieli się na dwa podstawowe typy:

DCL via Storage: Kod jest pobierany, zapisywany w pamięci masowej urządzenia, a następnie stamtąd mapowany i uruchamiany.
DCL via Memory: Kod trafia do pamięci RAM jako surowy strumień bajtów bezpośrednio z sieci i tam jest wykonywany, całkowicie pomijając zapis plików na dysku.

Dlaczego GrapheneOS domyślnie to blokuje?

W standardowym Androidzie DCL to gigantyczny wektor ataku dla bezplikowego złośliwego oprogramowania (fileless malware). Z tego powodu GrapheneOS stosuje bezwzględną politykę jądra i SELinux, blokując operacje typu execmem (zasada Write XOR Execute – obszar pamięci nie może być jednocześnie zapisywalny i wykonywalny).

W naszym przypadku aplikacje potrzebują tego mechanizmu do legalnych celów:

Ente Photos wykorzystuje DCL via Memory do inicjalizacji zaawansowanych modeli lokalnego uczenia maszynowego (np. rozpoznawanie twarzy w galerii bezpośrednio na urządzeniu).
Filen wykorzystuje hybrydę DCL via Memory oraz Storage do obsługi swojego natywnego, wysoce wydajnego silnika kryptograficznego.

Bez ręcznego przyznania uprawnienia DCL w ustawieniach systemu, obie aplikacje natychmiast wykrzywią się pod barierą SELinux i odmówią współpracy.

Modelowanie zagrożeń (Framework STRIDE)

Zgoda na DCL to otwarcie furtki. Aby ocenić ryzyko, musimy zmapować potencjalne zagrożenia za pomocą metodologii STRIDE:

Spoofing (Podszywanie się): Ryzyko, że serwer dewelopera zostanie przejęty lub ruch sieciowy zostanie przekierowany (ataki DNS Spoofing / MitM), w wyniku czego aplikacja pobierze złośliwy kod udający legalny moduł.
Tampering (Manipulacja danymi): Ryzyko modyfikacji dociąganego kodu w locie (RAM) lub w lokalnych katalogach zapisu na dysku (Storage) przez inny złośliwy proces. Zagrożenie to dotyczy szczególnie aplikacji Filen.
Information Disclosure (Wyciek danych): Jeśli dynamicznie załadowany kod okazałby się złośliwy (np. w wyniku ataku na łańcuch dostaw dewelopera), mógłby podjąć próbę eksfiltracji kluczy szyfrujących lub bazy danych aplikacji.

Wielowarstwowa architektura zabezpieczeń (Środki zaradcze)

Zgodnie z zasadą Defense-in-Depth (obrona w głąb), ryzyko związane z przyznaniem DCL zostało zredukowane do poziomu akceptowalnego (Residual Risk) za pomocą trzech niezależnych warstw ochronnych.

1. Zabezpieczenie łańcucha dostaw (Supply Chain Security)

Tradycyjne sklepy z aplikacjami zostały całkowicie pominięte. Do instalacji i aktualizacji służy menedżer Obtainium, pobierający pakiety bezpośrednio z sekcji Releases oficjalnych, otwartych repozytoriów GitHub deweloperów.

Integralność pobranego APK jest weryfikowana w tle przez narzędzie AppVerifier BG. Agreguje ono zewnętrzną bazę sygnatur kryptograficznych Verified Apps (od Privacy Guides) oraz lokalną bazę zaufanych certyfikatów, budowaną ręcznie po uprzednim, manualnym sprawdzeniu klucza dewelopera. Taka potrójna walidacja całkowicie eliminuje ryzyko ataku typu Spoofing lub Tampering na etapie wdrażania kodu.

2. Piaskownica pamięci masowej (Storage Scopes & SAF)

Nawet jeśli załadowany dynamicznie kod okazałby się złośliwy, system operacyjny nie pozwala mu na swobodne skanowanie urządzenia:

Ente Photos operuje w ramach Storage Scopes – system emuluje dla niej puste środowisko, dając jej wgląd wyłącznie w dwa jawnie wskazane katalogi (DCIM/Camera oraz Pictures/Screenshots).
Filen idzie krok dalej i wykorzystuje systemowy mechanizm Storage Access Framework (SAF). Aplikacja ma zerowy, stały dostęp do pamięci urządzenia. Wybór plików do synchronizacji odbywa się przez systemowy komponent Files. Filen otrzymuje od systemu jedynie tymczasowy, wyizolowany token dostępu (URI) do jednego, konkretnego pliku wskazanego przez użytkownika.

Napastnik odbija się od barier piaskownicy systemu i nie ma technicznej możliwości wyciągnięcia nieautoryzowanych struktur danych.

3. Bezwzględne zamrażanie procesów i optymalizacja sieciowa

Zarówno Ente, jak i Filen mają systemowy profil baterii ustawiony na "Ograniczone" (Restricted) oraz całkowicie wyłączoną możliwość działania w tle (Allow background usage: Disabled).

Ponieważ backup realizuję wyłącznie manualnie, scenariusz wygląda następująco: otwieram aplikację, wykonuję transfer, po czym zamykam program. W tym dokładnie momencie jądro systemu natychmiastowo i bezwarunkowo wysyła sygnał terminacji procesu (SIGKILL). Proces aplikacji oraz wszelkie struktury dynamicznie załadowanego kodu w RAM-ie przestają istnieć. Wyjątek DCL nie ma fizycznej możliwości wykonania jakiejkolwiek ukrytej aktywności w tle.

Ważna uwaga dotycząca Security Fatigue (Zmęczenia bezpieczeństwem): GrapheneOS umożliwia permanentne odcięcie sieci na poziomie SELinux dla każdej aplikacji. W tym modelu zdecydowałem o pozostawieniu sieci jako aktywnej. Skoro jądro systemu natychmiast zabija proces po wyjściu z aplikacji, ryzyko sieciowe w tle spada do zera. Wprowadzanie manualnego, ciągłego ryglowania sieci w ustawieniach przed i po każdym backupie generowałoby wyłącznie security fatigue – frustrację użytkownika, która w dłuższej perspektywie prowadzi do błędów ludzkich.

Podsumowanie, czyli dojrzałe zarządzanie ryzykiem

Przyznanie uprawnienia DCL dla aplikacji Open Source, takich jak Ente czy Filen, w połączeniu z rygorystyczną konfiguracją GrapheneOS, to podręcznikowy przykład świadomego zarządzania ryzykiem szczątkowym.

Rezygnacja z nadmiarowej blokady sieciowej na rzecz automatyzacji czyszczenia pamięci przez sygnał SIGKILL to świadoma decyzja inżynieryjna. Zabezpieczenia zostały zoptymalizowane tak, aby skutecznie neutralizować realne zagrożenia (aktywność DCL w tle), jednocześnie chroniąc użytkownika przed proceduralnym zmęczeniem. Weryfikowalność otwartego kodu kryptograficznego tych narzędzi jest znacznie cenniejsza niż ślepe trzymanie się blokad systemowych za cenę korzystania z zamkniętych, komercyjnych "czarnych skrzynek".

Apple i prywatność? No nie do końca. Przedstawiam "Spersonalizowane kolekcje"

Eteryu — Thu, 18 Jun 2026 00:00:00 +0000

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.

Problem pojawia się wtedy, gdy zdamy sobie sprawę, że te wszystkie rygorystyczne zasady dotyczą wszystkich, tylko nie samego Apple.

Najnowsze odkrycia pokazują, że we własnym sklepie z aplikacjami korporacja urządza sobie polowanie na nasze dane, które u innych deweloperów uznałoby za skrajną bezczelność.

Wielki Brat w wersji Spersonalizowane Kolekcje

Cała sprawa z telemetrią w App Store ciągnie się od dłuższego czasu, ale właśnie teraz, w czerwcu 2026 roku, temat wrócił z podwójną siłą. Apple odpaliło w sklepie nową funkcję o nazwie Personalized Collections, czyli Spersonalizowane Kolekcje.

Oficjalnie chodzi o to, żeby system lepiej rozumiał co nas kręci i podrzucał nam trafniejsze rekomendacje aplikacji. Brzmi super? No to zobaczmy, jaką cenę za to płacimy. Chłopaki z grupy Mysk, czyli ci sami badacze, którzy niedawno wypuścili genialną, otwartą aplikację Loupe, postanowili przeanalizować pakiety danych wysyłane przez system.

Co dokładnie widzi Apple?

Okazuje się, że App Store rejestruje w czasie rzeczywistym dosłownie każdy Twój krok:

Precyzyjne kliknięcia: Rejestrowanie każdego pojedynczego dotknięcia ekranu razem z dokładnymi współrzędnymi miejsca, w które klikasz.
Behawioralne przewijanie: Śledzenie każdego przewinięcia strony i sprawdzaniu, na które ikony patrzysz najdłużej.
Logowanie klawiatury: Logowanie każdej wpisywanej litery w wyszukiwarce, zanim w ogóle klikniesz szukaj. Serwery Apple wiedzą co piszesz w ułamku sekundy.
Analiza pisania: Analizowanie tempa i charakterystyki Twojego pisania na klawiaturze.

Twoje imię, Twoje nazwisko i Twój DSID

Jeżeli wydawało Ci się, że te statystyki są zbierane anonimowo, to mam złe wieści. Badacze z Mysk udowodnili, że pakiety danych telemetrycznych są wysyłane do Apple razem z unikalnym identyfikatorem o nazwie DSID (Directory Services Identifier).

Co to oznacza w praktyce?

DSID jest na sztywno powiązany z Twoim kontem iCloud i Apple ID. Apple nie zbiera więc suchych danych o jakimś losowym smartfonie. Oni wiedzą dokładnie, że to Ty, czyli konkretna osoba znana z imienia i nazwiska, szukasz określonej aplikacji, interesujesz się daną kategorią i klikasz w określone elementy interfejsu. Wszystkie te tąpnięcia, wyszukiwania i ruchy budują Twój profil behawioralny bezpośrednio pod Twoim nazwiskiem.

Iluzja wyboru, czyli brak opcji wyjścia

Najbardziej irytujące w tym wszystkim jest to, jak Apple podchodzi do naszej zgody. Możesz wejść w ustawienia konta i wyłączyć pokazywanie tych spersonalizowanych rekomendacji albo udostępnianie analiz. Poczujesz się bezpieczniej? Niepotrzebnie.

Badacze udowodnili, że ten przełącznik gasi tylko to, co Ty widzisz na ekranie. W tle aplikacja App Store nadal bezczelnie wysyła pełne logi z każdego Twojego tapnięcia prosto na serwery firmy. Twój sprzeciw nie ma dla nich znaczenia.

Często w dyskusjach pojawia się argument, że to i tak nadal lepsze niż Google. Prawda jest jednak taka, że to popularny mit, a różnica powoli się zaciera. Google robi to samo, tylko z otwartą przyłbicą, bo doskonale wiemy, że żyją z reklam. Apple z kolei wycięło konkurencję reklamową pod hasłami ochrony prywatności tylko po to, żeby zbudować swój własny, nienaruszalny monopol.

Klasyk: masz niby wybór między przeglądarkami, ale aplikacje i tak pobierzesz tylko z App Store, a Apple pilnuje, żeby nikt nie wszedł na ich podwórko.

Jesteś w sytuacji bez wyjścia, ponieważ albo zgadzasz się na to, że ktoś nagrywa całą Twoją sesję, albo zostajesz z telefonem bez żadnych dodatkowych aplikacji. Korporacje sukcesywnie przesuwają granice, bo wiedzą, że użytkownicy i tak nie mają łatwej alternatywy.

O co naprawdę chodzi w tej grze?

Odpowiedź jest prosta i jak zwykle chodzi o pieniądze. Apple od dłuższego czasu bardzo agresywnie rozwija swoją własną sieć reklamową Apple Ads. Wycięcie konkurencji, takiej jak na przykład Meta, było genialnym ruchem biznesowym. Gdy inni zostali z odciętym kurkiem, Apple stworzyło monopol na dane.

Zbieranie tak szczegółowych danych i przypisywanie ich do Twojego DSID służy po prostu profilowaniu nas pod reklamy, które potem oglądamy w App Store, Apple News czy ich nowych, spersonalizowanych sekcjach.

Zastanów się nad jednym. Gdyby jakikolwiek niezależny deweloper wrzucił do swojej aplikacji kod, który bez Twojej wiedzy rejestruje każde kliknięcie, każdą literę z klawiatury i wysyłał to razem z Twoimi danymi osobowymi, Apple natychmiast wyrzuciłoby go ze sklepu za złamanie regulaminu. Kiedy robi to samo Apple, nazywa się to dbaniem o wrażenia użytkownika.

Moje małe podsumowanie

Dla mnie ta sytuacja to podręcznikowy przykład korporacyjnej hipokryzji i kolejny potężny dowód na to, dlaczego moja ucieczka z iOS miała głęboki sens. Pokazuje to czarno na białym, że na iPhonie masz dokładnie tyle prywatności, na ile w danym momencie łaskawie pozwoli Ci gigant z Cupertino.

Życie z iPhonem, gdy jesteś zorientowany na prywatność lub ruch FOSS, to niestety sztuka ciągłych kompromisów i trudnych wyborów. W zamkniętym ogrodzie Apple zasady gry ustala tylko jedna firma.

Właśnie dlatego przesiadka na systemy takie jak GrapheneOS przestaje być niszową zabawą dla paranoików. To po prostu jedyny logiczny i pragmatyczny krok, jeśli chcesz odzyskać pełną kontrolę nad tym, co dzieje się z Twoimi danymi na Twoim własnym telefonie.

Sprawdź, co Apple już o Tobie wie

Wejdź na privacy.apple.com, zaloguj się i pobierz swoje dane. Przeszukaj je pod kątem fraz „App Store Analytics", „DSID" albo „Personalized Collections". Możesz się zdziwić, jak szczegółowe dane Apple ma o Twoim korzystaniu ze sklepu.

Weryfikacja sygnatur APK. Poznaj Verified Apps, oficjalny projekt od Privacy Guides

Eteryu — Mon, 15 Jun 2026 00:00:00 +0000

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.

Każda aplikacja, która pozwala na realną weryfikację kodu w ramach modelu zero trust, jest warta uwagi, a ten konkretny projekt rozwija się obecnie naprawdę prężnie. Ma on ambicję mocno uprościć proces kontroli cyfrowych sygnatur.

Dwie filozofie, jeden cel

Choć pod maską oba programy robią dokładnie to samo, czyli kalkulują hashe SHA256 przed właściwą instalacją, to reprezentują zupełnie inne podejście do wygody użytkownika:

AppVerifier stawia na twardą decentralizację. Aplikacja bazuje na czystej matematyce. Jeśli nie zna danego hasha, po prostu informuje, że nie ma go w bazie. Wtedy cała odpowiedzialność spada na użytkownika. Trzeba ręcznie przekopać dedykowany wątek na forum GrapheneOS lub stronę dewelopera, skopiować skrót certyfikatu i zweryfikować go za pomocą wbudowanej funkcji schowka. Bywa to upierdliwe na dłuższą metę.
Verified Apps idzie w stronę automatyzacji i crowdsourcingu, ale w bardzo bezpiecznym, lokalnym wydaniu. Zamiast pobierać bazę dynamicznie z sieci przy każdym uruchomieniu, projekt od Privacy Guides zaszywa całe crowdsourcingowe repozytorium bezpośrednio wewnątrz aplikacji. Baza jest sprawdzana całkowicie lokalnie, a jej aktualizacja następuje wraz z nowym wydaniem programu. Zielony ekran oznacza, że podpis znajduje się w tym oficjalnym spisie, a czerwony alarmuje o niezgodności lub braku rekordu.

Automatyzacja, która nie odbiera kontroli

W tym miejscu warto na chwilę się zatrzymać, aby nie wpaść w pułapkę własnych paradygmatów. Krytyka korporacyjnego modelu technologii często opiera się na tym, że rozleniwił nas funkcjami ułatwiającymi bezrefleksyjne korzystanie ze sprzętu, odbierając nam w zamian kontrolę nad własnymi danymi. Czy zachwyt nad automatyzacją Verified Apps nie jest więc przejawem niekonsekwencji?

Nie, ponieważ istnieje fundamentalna różnica w architekturze obu tych rozwiązań:

Automatyzacja Big Techu to czarna skrzynka. Ma być bezobsługowo po to, aby nikt nie pytał, co dzieje się w tle i jakie dane telemetryczne opuszczają telefon.

Automatyzacja w wydaniu Verified Apps jest w pełni transparentna. Opiera się na otwartym kodzie i jawnej bazie danych na GitHubie, którą każdy z nas może zweryfikować, a nawet współtworzyć. Narzędzie od Privacy Guides nie podejmuje decyzji za użytkownika i nie ukrywa procesów, ono po prostu zdejmuje z niego powtarzalną, mechaniczną pracę polegającą na ręcznym sprawdzaniu ciągów znaków. Ostateczna kontrola i rygor modelu zero trust nadal zostają po stronie użytkownika.

Pułapka jednego wzorca

Ta automatyzacja ma jednak na tym etapie rozwoju swoje wady, co widać chociażby przy próbach instalacji i aktualizacji programów takich jak Obsidian.

Wersja Obsidianu dystrybuowana przez Google Play posiada inny podpis cyfrowy niż oficjalne wydanie Standalone APK, które twórcy wrzucają bezpośrednio na GitHuba. Choć baza Verified Apps docelowo agreguje podpisy z różnych źródeł, w tym z GitHuba, F-Droida czy Play Store, to jako młody projekt nie ma jeszcze w swoich plikach absolutnie wszystkiego. Przy próbie aktualizacji Obsidianu z poziomu zewnętrznego instalatora system potrafi przywitać użytkownika twardym komunikatem o nieznanej sygnaturze.

W starym AppVerifierze można w takiej sytuacji po prostu wkleić zaufany hash ze schowka, by aplikacja dokonała matematycznego porównania na miejscu. Verified Apps to projekt świadomie odchudzony, z którego całkowicie usunięto funkcję porównywania poprzez schowek. Owszem, program pozwala łatwo skopiować lub udostępnić wyliczony hash na zewnątrz, ale samej weryfikacji ze schowkiem wewnątrz aplikacji już nie przeprowadzimy. Jeśli trafimy na prawidłową aplikację, której brakuje w bazie, jedyną opcją automatyczną jest użycie wbudowanej funkcji i wygenerowanie gotowego zgłoszenia na GitHubie projektu, aby dołożyć swoją cegiełkę do rozwoju tego narzędzia.

Trzecia droga: AppVerifierBG

Dla osób, które nie chcą rezygnować z wygody automatycznej bazy danych, ale jednocześnie potrzebują pełnej funkcjonalności manualnej, na horyzoncie pojawia się też ciekawa alternatywa w postaci AppVerifierBG (forka tworzonego przez użytkownika RoundSalmon4).

Projekt ten skutecznie łączy oba światy. Z jednej strony zachowuje tradycyjne funkcje oryginału, w tym niezwykle przydatne sprawdzanie i porównywanie podpisów bezpośrednio ze schowka. Z drugiej strony pozwala na zaciągnięcie i zintegrowanie zewnętrznych baz danych (w tym tej stworzonej przez Verified Apps) oraz budowanie własnych, w pełni lokalnych zestawów zaufanych sygnatur przez samego użytkownika.

Podsumowanie

Automatyzacja od Privacy Guides nie jest jeszcze idealna, ale potencjał społeczności jest ogromny. Rynek narzędzi do weryfikacji sygnatur APK dynamicznie się rozwija, a możliwość wyboru między surową matematyką, centralną bazą a hybrydowymi rozwiązaniami pokroju AppVerifierBG to świetna wiadomość dla każdego, kto poważnie podchodzi do bezpieczeństwa swojego systemu.

Wypróbuj zanim ocenisz

Jeśli używasz Androida — niezależnie od tego, czy to GrapheneOS, LineageOS czy zwykły system — zainstaluj Verified Apps z GitHub Releases. Sprawdź, czy Twoje kluczowe programy są w bazie. Jeśli nie — zgłoś je przez wbudowany formularz. To najprostszy sposób, by dołożyć cegiełkę do ekosystemu.

Pragmatyczny puryzm. Jak wycisnąłem maksimum prywatności z iOS przed przejściem na GrapheneOS

Eteryu — Wed, 10 Jun 2026 00:00:00 +0000

Pragmatyczny puryzm. Jak wycisnąłem maksimum prywatności z iOS przed przejściem na GrapheneOS

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.

Postawiłem sobie cel: stworzyć maksymalnie zanonimizowany i odcięty od telemetrii ekosystem bez zmiany platformy sprzętowej.

Tamto podejście nazywałem „pragmatycznym puryzmem”. Była to próba wyciśnięcia maksimum prywatności z iOS przy użyciu zaawansowanych narzędzi sieciowych i rygorystycznej higieny systemowej.

U podstaw tej decyzji leżała jednak znacznie głębsza, filozoficzna niezgoda na współczesny model technologiczny. Chciałem przestać być tylko „użytkownikiem”, któremu korporacja łaskawie pozwala korzystać ze swoich usług na określonych przez nią warunkach. Chciałem stać się realnym właścicielem i administratorem urządzenia, za które zapłaciłem. Na iOS oznaczało to pójście pod prąd całego systemu. Oto szczegółowa analiza konfiguracji, z którą mierzyłem się na co dzień, zanim ostatecznie przeszedłem na GrapheneOS.

Warstwa 1: Kontrola ruchu u źródła (NextDNS)

Największym problemem iOS jest jego zamknięty charakter – bez uprawnień roota lub jailbreaku nie da się tam ręcznie edytować pliku hosts ani kontrolować systemowych demonów. Dlatego fundamentem mojego bezpieczeństwa była warstwa sieciowa, całkowicie niezależna od kaprysów Apple. Ruch wychodzący z telefonu filtrowałem za pomocą NextDNS, wdrożonego bezpośrednio przez natywny profil konfiguracyjny (Encrypted DNS).

Moja konfiguracja opierała się na trzech filarach:

Lista filtrów HaGeZi Pro++ – absolutna rynkowa czołówka pod kątem wycinania trackerów, reklam i telemetrii, charakteryzujące się genialnym stosunkiem skuteczności do braku tzw. false positives.
Native Tracking Protection (zakładka Apple) – zdecydowałem się na odważny krok i włączyłem dedykowaną blokadę Apple w NextDNS. Co ważne pod kątem technicznym: system znosił to nadzwyczaj stabilnie. Kluczowe usługi, takie jak systemowe powiadomienia Push (APNs) czy pobieranie aplikacji z App Store, działały bez zarzutu. Dzieje się tak, ponieważ zaawansowane filtry sieciowe celowo oszczędzają krytyczne domeny (np. push.apple.com), jednocześnie bezlitośnie odcinając milczącą telemetrię analityczną w tle.
Własne reguły blokowania – na poziomie DNS całkowicie i permanentnie czyściłem ruch z domen powiązanych m.in. z korporacją Meta (Facebook).

Prawdziwa siła tego setupu tkwiła jednak w rygorystycznym uszczelnieniu samej usługi NextDNS w zakładkach Security i Privacy. Aby zminimalizować ryzyko infekcji i wycieku metadanych, aktywowałem tam pełny pakiet ochrony defensywnej: Threat Intelligence Feeds, DNS Rebinding Protection, IDN Homograph Attacks Protection, Typosquatting Protection oraz Domain Generation Algorithms (DGAs) Protection. Dodatkowo bezwzględnie blokowałem nowo zarejestrowane domeny (NRDs) oraz domeny zaparkowane (Block Parked Domains), które masowo służą jako infrastruktura do ataków typu phishing i dystrybucji malware.

Z punktu widzenia codziennej użyteczności i prywatności operacyjnej kluczowe były jeszcze trzy decyzje. Po pierwsze, świadomie włączyłem funkcję Allow Affiliate & Tracking Links – dzięki temu linki zakupowe czy afiliacyjne w przeglądarce nie były zrywane, ale NextDNS w locie oczyszczał je z unikalnych tokenów śledzących ID, pozostawiając sam czysty adres URL docelowej witryny. Po drugie, aktywowałem Anonymized EDNS Client Subnet (ECS). Ta funkcja maskuje dokładny adres IP klienta przesyłany do zewnętrznych serwerów autorytatywnych DNS, podając im jedynie ogólny identyfikator regionu, co pozwala na optymalne trasowanie ruchu bez zdradzania mojej dokładnej lokalizacji. Całość dopełniał włączony Cache Boost, optymalizujący zapytania i oszczędzający baterię, oraz restrykcyjna polityka przechowywania danych: retencja logów została ustawiona na absolutne minimum (1 dzień), a serwer logowania fizycznie zablokowany w jurysdykcji szwajcarskiej.

Warstwa 2: Demontaż domyślnego ekosystemu (FOSS, Privacy Devs i pełny de-Google)

Realny de-Apple na iOS wymagał wejścia głębiej niż zwykłe ukrycie ikon w bibliotece aplikacji. Odinstalowałem z telefonu wszystko, co system pozwolił usunąć. Na polu bitwy pozostały jedynie nieliczne, systemowe komponenty: Kontakty, Wiadomości, Zegar, App Store, Znajdź, Podgląd, Aparat i Pliki.

Kluczowym elementem tej warstwy było całkowite odcięcie usług iCloud oraz permanentne wyłączenie Siri. Żadne dane systemowe nie były synchronizowane z serwerami Apple – zamiast tego cała aktywność została przekierowana do bezpiecznych, zewnętrznych zamienników.

Aby jednak odciąć system od analizowania moich zachowań w czasie rzeczywistym, musiałem pójść o krok dalej i zrezygnować z większości funkcji smart. Wyłączyłem nie tylko asystenta głosowego, ale też wszelkie sugestie Siri, zbieranie informacji o sposobie użytkowania, podpowiedzi w schowku systemowym, a nawet indeksowanie Spotlight. Doprowadziłem to do takiego ekstremum, że na telefonie nie dało się nawet wyszukać aplikacji po nazwie. Jeśli chciałem coś uruchomić, musiałem doskonale wiedzieć, w którym folderze się znajduje. Smartfon stał się z powrotem prostym, pasywnym narzędziem, które nie analizowało moich intencji.

Dopełnieniem tego rygoru było całkowite wykastrowanie systemowej klawiatury. Wyłączyłem autokorektę, sprawdzanie pisowni oraz podpowiedzi tekstowe. Współczesne klawiatury ekranowe to telemetryczne koszmary, które nieustannie mapują styl pisania użytkownika i budują lokalne słowniki, rejestrując specyficzne frazy, a nawet wprowadzane dane wrażliwe. Innymi słowy, w moim setupie klawiatura została sprowadzona do roli „prymitywnej maszyny do pisania” – miała bezmyślnie wprowadzać znaki, bez próby ich semantycznej analizy czy zapamiętywania moich nawyków językowych.

Jednak mój puryzm szedł jeszcze dalej. Wielu użytkowników uciekających przed ekosystemem Apple wpada prosto w ramiona usług Alphabet, instalując mapy, dyski czy przeglądarki z tego samego źródła. Na moim iPhonie panował całkowity, stuprocentowy de-Google. Nie tylko nie posiadałem tam ani jednej aplikacji tej firmy, ale też odciąłem się od niej na poziomie infrastrukturalnym. Monopolistyczną wyszukiwarkę z Mountain View na stałe zastąpił europejski, zorientowany na prywatność Qwant.

Czym tak naprawdę jest Alphabet? Dla przeciętnego użytkownika synonimem internetowego monopolu jest słowo „Google”. Rzeczywistość bywa jednak brutalna. Od wielkiej restrukturyzacji w 2015 roku nad wszystkim stoi potężny holding Alphabet Inc. Ucieczka z tego ekosystemu jest niezwykle trudna, ponieważ w skład konglomeratu wchodzą marki i usługi, z których większość z nas korzysta bezwiednie każdego dnia: - Google (wyszukiwarka, Mapy, Gmail, Google Drive, przeglądarka Chrome) - Android (system operacyjny napędzający większość smartfonów na świecie) - YouTube (największa globalna platforma wideo) - Google DeepMind (oddział odpowiedzialny za rozwój zaawansowanej sztucznej inteligencji, w tym modeli Gemini) - Waymo (autonomiczne pojazdy i taksówki) - Fitbit (technologia ubieralna, sensory fitness i zdrowotne)

Świadomość, że jedna korporacja agreguje dane z naszej lokalizacji (Mapy), prywatnych wiadomości (Gmail), oglądanych filmów (YouTube), parametrów biologicznych (Fitbit), a nawet zapytań wpisywanych do AI, była dla mnie ostatecznym argumentem za tym, by przeprowadzić grubą linię demarkacyjną.

Iluzja chmury i trudna prawda o Apple

Dlaczego rezygnacja z iCloud była tak krytyczna? Marketing Apple karmi nas hasłem „Co dzieje się na iPhonie, zostaje na iPhonie”. Rzeczywistość bywa jednak brutalna.

Lokalny sprzęt kontra chmura: Lekcja z San Bernardino Wszyscy pamiętamy sprawę z 2016 roku, gdy Apple stanowczo odmówiło FBI stworzenia specjalnego backdoora (tzw. GovtOS) do odblokowania iPhone'a zamachowca z San Bernardino. Tim Cook słusznie argumentował wtedy, że osłabienie lokalnych zabezpieczeń smartfona zagrozi milionom użytkowników na świecie.

Ta spektakularna walka w świetle jupiterów dotyczyła jednak wyłącznie bezpieczeństwa fizycznego sprzętu. W tle, bez wielkiego rozgłosu, toczyła się zupełnie inna gra – gra o chmurę iCloud. Choć Apple wprowadziło zaawansowaną ochronę danych (Advanced Data Protection), domyślne kopie zapasowe iCloud przez lata były (i w standardowej konfiguracji wciąż są) otwartą księgą dla organów ścigania.

Apple posiada klucze deszyfrujące do standardowych backupów iCloud i regularnie przekazuje je rządom na całym świecie w odpowiedzi na wnioski prawne. Co gorsza, nawet przy włączonym E2EE, pewne metadane oraz logi systemowe i tak trafiają na serwery korporacji. Dodajmy do tego architekturę zamkniętego kodu – bez niezależnego audytu nigdy nie mamy 100% pewności, co i kiedy system wysyła w tle.

W mojej konfiguracji Apple ID zostało sprowadzone do roli czysto technicznej, niezbędnej jedynie do pobierania programów z App Store. Moje konto iCloud było klasycznym „burner account” – założonym na losowe, sfabrykowane dane, bez jakiegokolwiek powiązania z moją realną tożsamością, numerem telefonu, kartą płatniczą czy osobistym adresem e-mail.

Całkowicie zrezygnowałem z automatycznych kopii zapasowych w chmurze Apple. Co więcej – choć nie synchronizowałem z nią absolutnie niczego, profilaktycznie aktywowałem funkcję Advanced Data Protection (ADP). Chodziło o bezwzględne, kryptograficzne usunięcie jakichkolwiek kluczy deszyfrujących z infrastruktury Apple, aby zabezpieczyć profil przed telemetrycznym wyciekiem danych operacyjnych lub przypadkowym włączeniem backupu po kolejnej dużej aktualizacji systemu. Zamiast tego za backup służył mi Filen, do którego regularnie, całkowicie ręcznie eksportowałem bazy danych, pliki i konfiguracje z kluczowych aplikacji. Brak systemowej automatyzacji nadrabiałem żelazną, rygorystyczną dyscypliną.

Dobór alternatyw na iOS to sztuka trudnych kompromisów – wybór aplikacji w 100% otwartoźródłowych (FOSS) w App Store jest mocno zwężony ze względu na politykę Apple. Moja strategia była prosta: tam, gdzie nie mogłem wdrożyć FOSS, stawiałem na niezależnych deweloperów z segmentu privacy-focused, którzy oferują przejrzyste, subskrypcyjne modele biznesowe i nie żyją ze sprofilowanych reklam ani handlu danymi.

Bezpieczna chmura, multimedia i notatki (Zero-Knowledge & FOSS)

Zamiast ekosystemu iCloud, postawiłem na niezależne alternatywy działające w architekturze Zero-Knowledge, gdzie klucze szyfrujące należą wyłącznie do mnie:

Ente Photos – genialny, otwartoźródłowy zamiennik dla Apple Photos, oferujący pełne szyfrowanie (E2EE) biblioteki zdjęć przed opuszczeniem urządzenia.
Filen – szyfrowana chmura na dokumenty i pliki, zastępująca iCloud Drive i służąca jako bezpieczny magazyn na moje ręczne kopie zapasowe.
Notesnook – prywatne, w pełni szyfrowane notatki, które całkowicie wyparły systemowe Apple Notes.

Codzienne narzędzia i utility

Podczas ostatniego etapu czyszczenia systemu pozbyłem się kolejnych mniejszych narzędzi od Apple. To tutaj najlepiej widać miks rozwiązań otwartoźródłowych oraz usług od twórców stawiających na prywatność:

Apple Translate → Kagi Translate (świetny przykład komercyjnego, ale czystego narzędzia od dewelopera zorientowanego stricte na prywatność).
Kalkulator → Next.calc
Dyktafon → Alog
Miara → ARuler
Mapy i Pogoda → CoMaps (fork Organic Maps bazujący na OpenStreetMap) oraz OSS Weather.

Do tego zestawu należał również sprawdzony duet zabezpieczający: Bitwarden oraz 2FAS, a także zorientowana na prywatność poczta Tuta Mail (jej charakterystyczna bordowa ikona z literą „M” zajmowała stałe miejsce w moim docku).

Warstwa 3: Przeglądarka jako manifest suwerenności

Wybór przeglądarki na iOS to technicznie trudny temat. Choć przepisy w UE wymusiły na Apple teoretyczne otwarcie systemu na alternatywne silniki (jak Blink czy Gecko), w praktyce większość niszowych projektów wciąż dzieli ten sam fundament: WebKit. Skoro technologiczna baza była podobna, kluczowy stawał się dla mnie model biznesowy twórcy oraz poziom kontroli, jaki mi oferuje.

W roli mojej głównej przeglądarki osadziłem Quiche Browser (fioletowo-biały pierścień w docku). Urzekł mnie przejrzysty i czysty model biznesowy niezależnego dewelopera, stojący w opozycji do wielkich korporacji. Innymi słowy w zamian za niedrogą subskrypcję wspierałem świetny, niezależny projekt i otrzymywałem kapitalny, głęboki tryb ciemny. To tutaj, w parze z wyszukiwarką Qwant, budowałem swój codzienny punkt dostępu do sieci.

Brak możliwości realnej zmiany silnika przeglądarki czy głębokiej konfiguracji jej zabezpieczeń (jak choćby brak opcji całkowitego wyłączenia JIT z poziomu standardowych ustawień aplikacji) był dla mnie kolejnym przypomnieniem o mojej systemowej pozycji. Choć płaciłem za flagowy sprzęt, iOS cały czas traktował mnie jak „użytkownika”, którego trzeba prowadzić za rękę, a nadrzędna rola „właściciela”, który ma prawo samodzielnie konfigurować swoje środowisko i decydować o powierzchni ataku, pozostała zablokowana za korporacyjnym murem. Moja ochrona przed telemetrycznym i złośliwym kodem w sieci musiała więc w całości spoczywać na wcześniejszej warstwie – bezwzględnym filtrowaniu ruchu na poziomie NextDNS.

Wielkie ustępstwa i zarządzanie ryzykiem

Mój pragmatyzm polegał na tym, że nie odcinałem się od społeczeństwa grubą kreską. Musiałem funkcjonować w realiach, które wymuszały kompromisy. O ile sam portal Facebook zdołałem całkowicie i bezpowrotnie zlikwidować, zastępując go zdecentralizowanym Mastodonem, o tyle z komunikatorem sprawa była znacznie trudniejsza. Moim celem było całkowite przejście na Signala, jednak zderzyłem się ze ścianą – znajomi nie wykazali chęci do migracji, a pisanie samemu ze sobą mijało się z celem.

Zostałem zmuszony do zachowania Messengera. Do tego doszła konieczność korzystania z zaawansowanych modeli AI, jak DeepSeek, do trudnych obliczeń i wsparcia w kodowaniu.

Jak podchodziłem do tego bezpiecznie? Poprzez izolację i minimalizację uprawnień:

Wszystkie te aplikacje miały systemowo zablokowany dostęp do lokalizacji, odświeżania w tle, mikrofonu, kontaktów oraz asystenta Siri.
W przypadku DeepSeek dbałem o to, by nigdy nie wprowadzać tam danych osobowych, prywatnych dokumentów ani wrażliwego kodu, a w opcjach profilu miałem bezwzględnie wyłączony trening modelu na moich zapytaniach.
Ruch generowany przez aplikacje Mety był permanentnie filtrowany przez profil NextDNS. Co ciekawe, poprzez ręczną analizę logów udało mi się całkowicie i permanentnie zablokować domeny telemetryczne (w tym m.in. graph.facebook.com oraz dwie powiązane), co pozwoliło drastycznie ograniczyć apetyt na dane samego Messengera, bez jednoczesnego zakłócania podstawowej komunikacji tekstowej.

Co ciekawe, w tej konfiguracji świadomie nie korzystałem z Lockdown Mode. Choć tryb blokady od Apple drastycznie zmniejsza powierzchnię ataku na exploity typu zero-day (np. w iMessage czy silniku Safari), to z punktu widzenia infosec nie chroni przed telemetrycznym głodem samych aplikacji i śledzeniem behawioralnym. Całość mojego specyficznego setupu funkcjonowała w ramach jednego, głównego profilu systemowego – zabezpieczonego nie przez odgórne, sztywne restrykcje kodu Apple, ale przez opisaną wcześniej, rygorystyczną higienę sieciową oraz radykalne ograniczenie funkcji systemu.

Wnioski z tamtej perspektywy: Iluzja wygody a cena suwerenności

Patrząc wstecz na konfigurację mojego starego iPhone'a 17 Pro, czuję dumę z tego, jak szczelną klatkę udało mi się na nim zbudować. To była fascynująca walka o każdy bajt danych i dowód na to, że świadomy użytkownik potrafi zabezpieczyć się w każdych warunkach – nawet akceptując rynkowe ograniczenia iOS, całkowicie odcinając iCloud, uciszając Siri i godząc się na brak pełnego dostępu do natywnych aplikacji FOSS. Fakt, że już na tamtym etapie całkowicie pożegnałem się z usługami Alphabet (Google) i wyszukiwałem informacje przez Qwanta, dał mi doskonały punkt startowy do dalszej drogi.

Wielu przeciętnych konsumentów zapyta w tym miejscu: po co to wszystko? Po co łamać sobie ergonomię systemu, rezygnować ze Spotlight, wyłączać autokorektę klawiatury i spędzać czas na manualnym, regularnym eksportowaniu backupów do Filen (lub obecnie, na GrapheneOS, do Mega, które działa podobnie do Google Drive czy iCloud i automatycznie backupuje zdjęcia prosto z aparatu)? Czy to nie jest zbyt wysoka cena, zbyt wielkie poświęcenie za odrobinę prywatności?

Z perspektywy czasu odpowiadam z pełnym przekonaniem: nie, to nie jest wysoka cena.

Współczesny Big Tech zaszczepił w nas złudne przekonanie, że wygoda musi oznaczać całkowitą bezobsługowość – magię funkcji typu „włącz i zapomnij” (set-and-forget). Za tę bezobsługowość płacimy jednak bezpowrotną utratą kontroli. Wielkie korporacje nie handlują przecież pojedynczymi plikami; one agregują metadane, analizują nasz styl pisania, relacje między dokumentami i naszą lokalizację, budując z tych puzzli naszego „cyfrowego bliźniaka” (digital twin). Handlują predykcją naszych zachowań, a my stajemy się produktem.

W tym kontekście kilka kliknięć potrzebnych do ręcznego zabezpieczenia swoich danych szybko przestaje być uciążliwością, a staje się naturalną rutyną – dokładnie taką samą jak odłożenie kluczy na miejsce czy zamknięcie drzwi wejściowych po powrocie do domu. To nie jest poświęcenie; to podstawowa polisa ubezpieczeniowa na własną cyfrową suwerenność.

Budowanie prywatności na platformie Apple zawsze przypominało jednak próbę postawienia zamku na wynajmowanym gruncie – zasady gry mogą zmienić się z każdą aktualizacją systemu, a ostateczna kontrola i tak należy do korporacji. Kiedy sytuacja zmusiła mnie do przesiadki na Pixela 8, poczułem ogromną ulgę.

Wdrożenie realnego de-Google nie wymaga już teraz ciągłej walki z systemem, a to, co na iPhonie wymagało drastycznych kompromisów kosztem codziennej wygody, w moim nowym środowisku z GrapheneOS stało się po prostu naturalnym, systemowym standardem. Przesiadka ta całkowicie zmieniła moje paradygmaty. Na iOS byłem zmuszony do radykalnego barykadowania się przed światem. Dzisiaj, na GrapheneOS, jeśli potrzebuję konkretnej usługi, uruchamiam ją wyłącznie na moich własnych warunkach. Wykorzystuję do tego pełną piaskownicę systemową (Sandboxed Google Play), anonimowe konta odpadowe stworzone tylko do pobierania aplikacji oraz odizolowane, szyfrowane przestrzenie prywatne (Private Space), których używanie jest oficjalnie rekomendowane przez społeczność.

Dopiero teraz, trzymając w ręku urządzenie, w którym to ja kontroluję każdy proces, każdy klucz kryptograficzny i każde uprawnienie bez pytania korporacji o zgodę, czuję, że odzyskałem pełną cyfrową suwerenność. Pokonałem drogę od ubezwłasnowolnionego konsumenta do realnego właściciela własnego cyfrowego śladu. Droga przez „pragmatyczny puryzm” była jednak potrzebna – to ona ukształtowała moje dzisiejsze nawyki.

Polisa, nie poświęcenie

Wybierz jedną funkcję smart, z której zrezygnujesz dziś: Spotlight, autokorektę albo sugestie Siri. Zobacz, czy przez tydzień za nią zatęsknisz. Większość nawyków cyfrowych to iluzja wygody, którą można zastąpić rutyną.

A o tym, jak dokładnie wygląda mój aktualny setup Pixela 8, jak konfiguruję Profile użytkowników i jak ujarzmiłem usługi Google w bezpiecznym sandboxie, przeczytacie już niedługo w osobnym wpisie.

Ewolucja zaufania. Dlaczego czas F-Droida mija

Eteryu — Sun, 07 Jun 2026 00:00:00 +0000

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.

Trzy grzechy główne F-Droida

Dlaczego uważam to repozytorium za przestarzałe? Chodzi o czystą architekturę bezpieczeństwa.

Po pierwsze: przeterminowane Target SDK i mit "elektrośmieci". Wiele aplikacji w F-Droidzie nie było aktualizowanych pod kątem nowoczesnych wersji Androida. Wśród obrońców sklepu panuje przekonanie, że porzucanie starych wersji to "zamienianie sprawnego sprzętu w elektrośmieci". To fundamentalny błąd wynikający z mylenia dwóch parametrów: minSdkVersion oraz targetSdkVersion.

O tym, na jak starym urządzeniu w ogóle uruchomi się dany program, decyduje wyłącznie minSdkVersion – podnoszenie standardów bezpieczeństwa nie odcina więc starszych telefonów. Z kolei targetSdkVersion to informacja dla nowoczesnych systemów, jak aplikacja ma się zachowywać pod kątem ochrony danych. Jeśli deweloper celowo utrzymuje tam archaiczny numerek, robi to najczęściej po to, aby jego program – uruchomiony na Twoim nowym smartfonie – mógł bezkarnie omijać nowoczesne restrykcje prywatności, takie jak zapytania o dostęp do schowka czy precyzyjną lokalizację.

Po drugie: model podpisów cyfrowych i centralizacja ryzyka. F-Droid w swoim głównym repozytorium domyślnie sam buduje kod ze źródeł i podpisuje pakiety instalacyjne własnym, centralnym kluczem kryptograficznym. Taki model całkowicie centralizuje zaufanie – w razie kompromitacji infrastruktury F-Droida, zagrożone są wszystkie aktualizacje naraz. Dodatkowo uniemożliwia to łatwą migrację na oficjalne wydania z GitHuba z powodu konfliktu podpisów w systemie.

Po trzecie: zacofany instalator. Oficjalny klient F-Droida przez lata ignorował nowoczesne API systemowe Androida. Wprowadzenie tak podstawowej funkcji jak automatyczne, bezobsługowe aktualizacje w tle (Unattended Updates) zajęło twórcom wieki, co mocno odstaje od dzisiejszych standardów UX i bezpieczeństwa.

Błąd logiczny: Przenoszenie nawyków z desktopu

Częstym argumentem obrońców F-Droida jest porównywanie go do oficjalnych repozytoriów Debiana czy Fedory. To klasyczna pułapka myślowa (false equivalency), wynikająca z ignorowania różnic w architekturze systemów.

Na tradycyjnym desktopowym Linuksie aplikacja użytkownika ma domyślnie dostęp do całego katalogu domowego (/home). Może bez problemu czytać Twoje klucze SSH czy sesje przeglądarek. Choć nowoczesne formaty jak Flatpak wprowadzają dziś silny sandboxing, to w powszechnej świadomości wciąż pokutuje model, w którym zaufanie do repozytorium musi być absolutne.

Na nowoczesnym systemie mobilnym, a szczególnie na GrapheneOS, sytuacja jest skrajnie inna – tu rządzi bezkompromisowy sandboxing na poziomie jądra. System nie ufa nikomu i dzięki funkcjom typu Storage Scopes izoluje programy tak głęboko, że nie widzą one plików innych aplikacji. To nie sklep ma nas chronić przed złośliwym deweloperem – od tego jest pancerna piaskownica systemu operacyjnego.

Mit „audytu kodu” przez centralny sklep

Kolejny mit to przekonanie, że centralny sklep gwarantuje czystość kodu. Prawda jest brutalna: F-Droid w żaden sposób nie audytuje milionów linii kodu pod kątem ukrytego malware przy każdej aktualizacji. Sprawdza jedynie, czy licencja jest otwartoźródłowa (FOSS).

Historia open-source dobitnie pokazała, że otwarty kod nie jest automatyczną gwarancją braku złośliwych intencji. Skoro i tak chroni nas wyłącznie sandboxing, kluczowa staje się zdecentralizowana kryptografia, a nie centralny nadzór jednej instytucji.

Nowe podejście: Bezpośrednie zaufanie i kryptografia

W świecie GrapheneOS standardem staje się model pełnej decentralizacji. Zamiast oddawać kontrolę centralnemu pośrednikowi, pobieramy aplikacje FOSS bezpośrednio od ich twórców za pomocą klienta Obtainium, który ciągnie pliki prosto z wydań na GitHubie czy GitLabie. W tym modelu każda aplikacja jest podpisana unikalnym kluczem kryptograficznym samego dewelopera.

Zamiast ufać zielonemu robocikowi na słowo, nowoczesny system weryfikacji pozwala w ułamku sekundy porównać unikalny skrót kryptograficzny (hash SHA-256) certyfikatu aplikacji ze znanymi, zaufanymi sygnaturami deweloperów, które są dodatkowo krzyżowo sprawdzane przez zaawansowaną społeczność.

Czas na ewolucję

F-Droid odegrał piękną i ważną rolę w historii alternatywnego Androida. Pokazał nam, że życie bez korporacyjnych usług jest możliwe. Jednak dziś, gdy mamy do dyspozycji systemy o tak potężnej architekturze jak GrapheneOS, instalowanie na nich aplikacji za pośrednictwem przestarzałego F-Droida to krok w tył.

Ślepe traktowanie tego sklepu jako wyroczni bezpieczeństwa to podejście rodem z 2010 roku. Dojrzałe podejście do prywatności wymaga ewolucji.

Zmień model dystrybucji

Zrezygnuj z centralnych pośredników na rzecz pełnej kontroli. Zainstaluj Obtainium, aby pobierać aplikacje bezpośrednio od deweloperów, i korzystaj z weryfikacji sum kontrolnych (hashes) oraz podpisów cyfrowych. To jedyna droga do pełnej, zdecentralizowanej kontroli nad tym, co uruchamiasz na swoim urządzeniu.

Jak okiełznałem system z MDM. Moja droga do GrapheneOS

Eteryu — Fri, 05 Jun 2026 00:00:00 +0000

Jak okiełznałem system z MDM. Moja droga do 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ą.

Gdy moja żona nagle trafiła do szpitala, priorytety zmieniły się w mgnieniu oka. Aby podreperować budżet, sprzedałem iPhone'a, a za ułamek zdobytej kwoty kupiłem z drugiej ręki Pixela 8. Od dawna interesowałem się rozwiązaniami privacy-focused oraz ruchem FOSS, więc ten model był naturalnym kierunkiem — docelowo miał na nim wylądować GrapheneOS. Na tamten moment nie posiadaliśmy jednak w domu komputera, ale jak się później okazało... to i tak nic by nie zmieniło. Ukryty profil MDM, który znajdował się na telefonie, skutecznie zablokowałby każdą próbę odblokowania bootloadera i flashowania systemu. Musiałem więc uruchomić go na oprogramowaniu fabrycznym.

Chcę Wam opowiedzieć o incydencie, który zmusił mnie do natychmiastowej ewakuacji cyfrowej tożsamości i o tym, jak techniki obronne pozwoliły mi przetrwać najgorszy moment.

Kiedy Twój telefon zaczyna żyć własnym życiem

To był potwornie ciężki okres. Moja żona leżała w szpitalu, a telefon był moim jedynym, krytycznym oknem na świat i jedynym źródłem informacji o jej stanie zdrowia. Połowa moich myśli była na oddziale szpitalnym, gdy nagle zauważyłem, że mój nowo kupiony Pixel 8 zachowuje się nietypowo.

Zaczęło się od drobnych anomalii, które szybko przerodziły się w techniczny koszmar:

Aktywny podsłuch: Na ekranie pojawiała się zielona ikona aktywnego mikrofonu, mimo że nie prowadziłem żadnej rozmowy ani nie używałem aplikacji dyktafonu.
Zdalne sterowanie: Telefon losowo wykonywał akcje, jakby ktoś sterował nim w czasie rzeczywistym.
Manipulacja danymi: Z systemowej galerii Google Photos zaczęły znikać pojedyncze zdjęcia i zrzuty ekranu.
Intercepcja połączeń: Zauważyłem bezpodstawne przekierowania moich połączeń przychodzących na obcy, nieznany numer.

Najgorszy był efekt "migawki" — ekran zachowywał się tak, jakby ktoś robił zrzuty ekranu w locie. W warunkach skrajnego stresu rodzinnego, świadomość, że ktoś obcy patrzy na mój ekran i słucha mojego otoczenia, była paraliżująca.

Śledztwo w trybie naprawy: Syndrom MDM

Wiedziałem, że standardowy restart nic nie da. Wyłączyłem urządzenie i uruchomiłem je w trybie naprawy (Recovery/Repair Mode). To tam klocki układanki wreszcie wpadły na swoje miejsce.

Urządzenie jest kontrolowane przez administratora...

Telefon posiadał ukryty, nadrzędny profil MDM (Mobile Device Management). Ktoś sprzedał mi urządzenie korporacyjne jako czysty sprzęt konsumencki. Profil MDM dawał zdalnemu napastnikowi uprawnienia administracyjne wyższe niż moje własne. Mógł w locie podglądać ekran, aktywować sensory i manipulować routingiem połączeń.

Sprawę natychmiast zgłosiłem na Policję, a urządzenie zostało zakwalifikowane do zwrotu. Pojawił się jednak kluczowy problem: jak bezpiecznie przeczekać kilka dni, mając na telefonie krytyczne konta bankowe, mailowe i komunikatory, w dodatku bez możliwości odcięcia się od sieci ze względu na sytuację w szpitalu?

Incident Response w warunkach bojowych

Musiałem działać jak inżynier w strefie konfliktu. Zastosowałem podręcznikową taktykę izolacji skażonego hosta za pomocą trzech kroków:

1. Bezpieczny bastion dla dowodów (ente Photos)

Zanim zacząłem głębszą konfigurację, zabezpieczyłem zrzuty ekranu dokumentujące aktywność aplikacji oraz sam komunikat o MDM. Ponieważ napastnik bezczelnie usuwał pliki z Google Photos, zainstalowałem ente Photos — w pełni szyfrowaną (E2EE) alternatywę dla chmury giganta. Napastnik stracił możliwość manipulowania tymi plikami, co uratowało moją dokumentację dla Policji.

2. Zapora ogniowa w trybie Default-Deny

Zainstalowałem lokalny firewall RethinkDNS i natychmiast przełączyłem go w tryb całkowitej blokady ruchu wychodzącego. Analizując logi w locie, zauważyłem, że ataki i próby eksfiltracji danych szły głównie przez systemowe procesy Shell oraz SystemUI. Odcięcie im dostępu do sieci sparaliżowało architekturę Command & Control (C2) napastnika.

3. Szyfrowany i filtrowany DNS od Quad9

W RethinkDNS zmieniłem domyślny routing zapytań na Quad9 DNS. Poza szyfrowaniem ruchu, Quad9 automatycznie dropuje zapytania do znanych złośliwych domen i serwerów botnetowych na poziomie infrastruktury.

Dzięki tej sterylnej kwarantannie zyskałem cenny czas. Wszystkie dowody przesłałem prowadzącej sprawę policjantce za pomocą bezpiecznej, szyfrowanej skrzynki Tuta Mail. W tym sztucznie utrzymywanym środowisku spokojnie zmieniłem hasła i klucze sesyjne we wszystkich krytycznych usługach.

Nowy początek: GrapheneOS jako cyfrowa forteca

Po odesłaniu wadliwego urządzenia skontaktowałem się ze sprzedawcą. Sklep wykazał się niesamowitą postawą — w ramach wymiany nie tylko dostarczyli mi pewny egzemplarz Pixela 8, ale ich serwisant samodzielnie wgrał GrapheneOS na nowy telefon przed wysyłką. Chciał mieć absolutną pewność, że sprzęt trafi do mnie w 100% czysty i bezpieczny.

Wgranie GrapheneOS całkowicie eliminuje ryzyko przetrwania ukrytych profilów korporacyjnych (dzięki mechanizmowi Verified Boot). Na tym systemie buduję swój obecny Threat Model, oparty na braku ślepego zaufania (Zero Trust):

Całkowita de-googlizacja: Profil główny jest całkowicie wolny od kodu Google (FOSS). Przestarzałego F-Droida zastąpiłem nowoczesnymi, bezpiecznymi menedżerami Obtainium i Accrescent.
Ścisła izolacja (Multiple Profiles): Wszystkie usługi komercyjne zamknąłem w odizolowanym, osobnym profilu użytkownika.
Separacja sieciowa: Ruch sieciowy obu profili jest całkowicie odseparowany przez niezależne instancje WireGuard w trybie Always-on.

Wnioski na przyszłość

Prywatność i cyberbezpieczeństwo to nie są hobbystyczne fanaberie. Skompromitowane urządzenie mobilne to bezpośrednie zagrożenie dla Twojego życia osobistego, finansów i spokoju psychicznego.

Nie czekaj na anomalię

Jeśli podejrzewasz, że Twój system zachowuje się nienaturalnie — nie czekaj. Odetnij procesy systemowe od sieci, zabezpiecz tożsamość za pomocą szyfrowanych narzędzi i szukaj rozwiązań, które dają Ci pełną kontrolę nad krzemem, za który zapłaciłeś. Dla mnie tą jedyną, bezpieczną odpowiedzią stał się duet czystego sprzętu i GrapheneOS.