Jakiś już dłuższy czas temu opisywałem mechanizm przekierowania ruchu sieciowego jednego lub wybranych procesów do VPN na przykładzie OpenVPN pod moim Debianem. Zawarta w tamtym artykule konfiguracja jak najbardziej działa do tej pory, choć minęło już prawie 6 lat od jej wdrożenia w życie. Od tamtego momentu jednak, sporo się zmieniło w świecie linux'a, a konkretnie pojawił się wireguard, który jest nieco bardziej dostosowany do otaczającej nas rzeczywistości i kładzie na łopatki wysłużonego już OpenVPN. Nie mam nic do OpenVPN ale przydałoby się zrobić podobne rozwiązanie opisane w powyżej podlinkowanym artykule ale na przykładzie właśnie wireguard. Samo skonfigurowanie do pracy VPN na bazie wireguard jest w zasadzie dość proste i nie trzeba pisać kolejnego artykułu na ten temat. Niemniej jednak, stawiając VPN w opisany na stronie wireguard sposób będziemy przesyłać przez to połączenie cały ruch sieciowy, czego raczej nie chcemy. To tutaj właśnie zaczynają się problemy z wireguard, których w OpenVPN nie szło zaobserwować, a które uniemożliwiają poprawne działanie (zapętlanie się) połączenia VPN. Postaramy się zatem przyjrzeć nieco bliżej samej konfiguracji wireguard i spróbować sprawić, by ruch sieciowy tylko wybranych przez nas procesów był kierowany w tunel VPN.

Parę miesięcy temu natrafiłem na taki oto artykuł na blogu Cloudflare, który poświęcony jest poprawie prywatności wykonywanych przez klientów zapytań DNS za sprawą wykorzystania mechanizmu zwanego Oblivious DoH (ODoH). Oczywiście postanowiłem już wtedy zbadać czym ten ODoH jest ale standardowe narzędzia dostępne w linux'ie (Debian/Ubuntu) jeszcze (przynajmniej wtedy) nie dojrzały do obsługi ODoH. Obecnie już jest trochę lepiej ale Oblivious DoH wciąż jest w fazie eksperymentów (RFC9230). Póki co, jedynym znanym mi narzędziem, które posiada wsparcie dla ODoH jest dnscrypt-proxy, którego instalację i konfigurację do współpracy z dnsmasq już jakiś czas temu opisywałem. Mając wsparcie dla ODoH w dnscrypt-proxy możemy pokusić się o wdrożenie Oblivious DoH w swoim systemie i sprawdzić czy faktycznie taki zabieg przyczyni się do poprawy prywatności wykonywanych przez nas zapytań DNS i właśnie temu zagadnieniu będzie poświęcony niniejszy wpis.

Pisząc ostatnio artykuł o tym jak uchronić nasz prywatny punkt dostępu do sieci WiFi przed zmapowaniem i umieszczeniem jego fizycznej lokalizacji w serwisach pokroju Wigle.net czy też w usługach Google/Mozilla, poruszony został temat ewentualnego usuwania wpisów z takich baz danych AP za sprawą dopisywania do nazwy sieci (ESSID) sufiksu _nomap . Nie wszystkie organizacje/firmy respektują naszą prywatność i raczej też nie będą tej końcówki w nazwie sieci honorować. Jako, że jednym z dwóch parametrów, na podstawie których takie mapowanie punktów dostępowych się odbywa, jest adres MAC interfejsu bezprzewodowego danego AP (BSSID), to możemy od czasu do czasu pokusić się o zmianę tego adresu. Jest to mniej więcej to samo rozwiązanie, co zastosowane przy klonowaniu adresu MAC dla portu WAN routera, które z reguły użytkownicy wykorzystują do obchodzenia zabezpieczeń tych bardziej wrednych ISP. Jako, że temat zmiany BSSID trochę się różni od zmiany adresu MAC dla portu WAN, to w niniejszym artykule postanowiłem opisać jak w routerze z wgranym firmware OpenWRT podejść do tego zadania.

Parę dni temu napisał do mnie megabajt z forum DUG z wiadomością, że nazwa mojego WiFi figuruje w bazie danych serwisu Wigle.net oraz, że lepiej nie zdradzać nazw swoich WiFi osobom trzecim, bo ktoś w oparciu o te dane może poznać nasze fizyczne położenie. Jak najbardziej istnieje taka możliwość, a sam serwis Wigle.net nie jest jedynym, który zbiera informacje o położeniach geograficznych punktów dostępowych WiFi, bo od lat robi to też Google i Mozilla. Niemniej jednak, podchodziłbym z pewną dozą ostrożności do danych zgromadzonych w serwisie Wigle.net (i tych pozostałych dwóch też), bo nie zawsze muszą one być akuratne. W zasadzie to nie zdziwiłem się zbytnio, że nazwa mojej sieci WiFi figuruje w bazie danych Wigle.net, bo sam ją tam umieściłem świadomie jakiś czas temu w ramach testów wykorzystując do tego celu aplikację WiGLE WiFi Wardriving, którą można wgrać przez F-Droid na każdy telefon z Androidem. Jako, że nadarzyła się okazja, to postanowiłem napisać parę słów na temat unikania bycia zmapowanym, tak by jakiś nieznany nam bliżej osobnik przez przypadek nie wrzucił lokalizacji naszych domowych/firmowych AP do bazy danych Google/Mozilla czy też wspomnianego wyżej serwisu Wigle.net, o ile oczywiście sobie tego nie życzymy.

Posiadacze smartfonów z Androidem w wersji 10+ rzadko kiedy orientują się, że w tej wersji został wprowadzony dość ciekawy mechanizm mający na celu poprawnie prywatności osób korzystających z takich urządzeń. Chodzi o randomizację adresów MAC przy połączeniach z sieciami WiFi. Nie zawsze ten mechanizm jest włączony domyślnie, przez co w kwestii prywatności użytkowników telefonów niewiele się zmienia, np. tak jest w przypadku mojego Xiaomi Redmi 9. Samo włączenie randomizacji MAC nie jest niczym skomplikowanym i nie trzeba do tego nawet praw administratora root (stosowna opcja jest do załączenia w oknie konfiguracji połączenia WiFi). Zwykle jednak przy wykorzystaniu standardowej randomizacji MAC mamy generowany unikalny adres MAC dla danej sieci WiFi (w oparciu o jej ESSID). Można jednak pójść o krok dalej i sprawić, że przy każdym połączeniu, nawet do tej samej sieci WiFi, będziemy mieli generowany inny adres MAC, co z kolei powinno nam zapewnić nieco więcej prywatności w publicznych sieciach WiFi oraz też przeciwdziałać śledzeniu nas przy roamingu między takimi sieciami.

Przeglądając ostatnio opcje deweloperskie w swoim telefonie z Androidem 11, wpadła mi w oczy pozycja WebView implementation . Nie ukrywam, że trochę mnie ona zainteresowała i zacząłem się zastanawiać czym tak naprawdę jest ten cały WebView. Mój smartfon działa aktualnie pod kontrolą crDroid (ROM na bazie AOSP/LineageOS) i nie jest on sprzęgnięty z usługami od Google (brak jakichkolwiek GAPPS'ów). Dlatego też w tym przypadku w implementacji WebView widnieje w zasadzie tylko jedna opcja, tj. Android System WebView. W przypadku stock'owych ROM'ów producentów telefonów będziemy mieli zaś do czynienia z Google System WebView. Jakby nie patrzeć, zarówno Android/AOSP System WebView, jak i Google System WebView pochodzą od Google, który niezbyt troszczy się o naszą prywatność. W mojej głowie pojawiło się zatem pytanie na temat tego czym te dwie implementacje się od siebie różnią, no i naturalnie też czy są jakieś alternatywne implementacje WebView, z których można by skorzystać zastępując te domyślnie preinstalowane?

Jeśli mamy wgranego w miarę nowego Androida (9+) na naszego smartfona i korzystamy aktywnie z tego urządzenia, to zapewne zdążyliśmy się już przyzwyczaić, że co kilka dni musimy wpisywać ręcznie hasło do blokady ekranu i to nawet pomimo aktywnej biometrii w ustawieniach systemu. Co ciekawe, w stock'owych ROM'ach producentów telefonów (nawet w moim Xiaomi Redmi 9), nie ma żadnej opcji, która byłaby w stanie skonfigurować czas, po którym taki monit z hasłem ma wyskakiwać. Przyznam, że trochę mnie ten ficzer denerwował ale nie mogłem z nim w zasadzie nic zrobić i trzeba było nauczyć się go tolerować. Do niedawna nawet nie wiedziałem, że takie pytanie użytkownika o hasło bierze się z faktu przejścia telefonu w jeden ze jego trybów pracy, tj. tryb lockdown, w który telefon jest przełączany automatycznie zwykle co 72 godziny (3 dni). Ludzie mówią, że ten tryb ma chronić użytkownika smartfona na wypadek utraty urządzenia. Z racji, że aktualnie wgrałem sobie custom ROM na bazie AOSP/LineageOS, to postanowiłem sprawdzić czy jakieś opcje konfiguracji tego trybu są w nim dostępne. Przy okazji chciałem nieco bardziej zapoznać się z tym mechanizmem lockdown'u i zweryfikować na ile może on być użyteczny.

Jak to zwykło się mawiać w świecie IT: ludzie dzielą się na te osobniki, które robią backup i te, co backup robić będą. Jakiś czas temu pochyliłem się nad zagadnieniem czy smartfon z Androidem bez Google Play Services ma sens. Poruszyłem tam problem tworzenia kopi zapasowej danych użytkownika zgromadzonych w telefonie. W tym podlinkowanym artykule zostało przestawione jak przy pomocy TWRP dokonać pełnego backupu całego systemu urządzenia i o ile pod względem technicznym takie podejście było jak najbardziej w pełni do zaakceptowania, to jednak to rozwiązanie miało dość istotną wadę, tj. na czas backup'u trzeba było wyłączyć smartfon. Parę dni temu natrafiłem na narzędzia OAndBackupX, które jest w stanie zrobić kopię zapasową wszystkich zainstalowanych w Androidzie aplikacji (oraz ich ustawień), wliczając w to nawet appki systemowe. OAndBackupX jest o tyle lepszym rozwiązaniem w stosunku do TWRP, że można przy jego pomocy robić kopię danych pojedynczych aplikacji, a nie od razu całego ROM'u, co nie tylko jest czasochłonne ale również zjada sporo miejsca na dysku komputera, czy gdzie ten backup zamierzamy przechowywać. Niestety OAndBackupX wymaga uprawnień root, zatem na stock'owym ROM'ie producenta naszego telefonu nie damy rady z tego narzędzia skorzystać. Jeśli jednak mamy alternatywny ROM na bazie AOSP/LineageOS, to przydałoby się rzucić okiem na ten kawałek oprogramowania, bo zdaje się ono być wielce użyteczne, zwłaszcza w przypadku osób mojego pokroju, czyli linux'iarzy, którzy o backup swoich danych chcą zatroszczyć się tylko i wyłącznie we własnym zakresie, zaprzęgając do pracy choćby Syncthing.

Raczej już nikogo nie dziwią różne moduły elektroniczne implementowane w smartfonach pokroju żyroskopu, akcelerometru, magnetometru czy też i innych czujników realizujących pewne określone funkcje. Te wszystkie rzeczy potocznie zwykło nazywać się sensorami i na dobrą sprawę zdążyły się one zadomowić na dobre w tych naszych telefonach i to do tego stopnia, że nawet sobie nie zdajemy sprawy, że w ogóle one istnieją i non stop działają w tle. Przekopując ostatnio ustawienia Androida, natknąłem się w opcjach deweloperskich na dość enigmatycznie brzmiącą opcję Sensors Off , która była ukryta pod Quick settings developer tiles . Zaznaczenie tej opcji sprawiło, że do dyspozycji użytkownika został oddany dodatkowy kafelek (dostępny z poziomu górnej belki), którego zadaniem jest sterowanie dostępem aplikacji do sensorów smartfona (nie tylko tych wymienionych wyżej ale też do kamery mikrofonu, czy nawet GPS). Postanowiłem się trochę pobawić tym mechanizmem i zobaczyć czy można z niego zrobić jakieś użyteczne narzędzie w kontekście ochrony prywatności.

Wiele osób nie pozostawia suchej nitki na mechanizmie geolokalizacji zaszytym w smartfonach z Androidem na pokładzie. No i faktycznie w sporej części przypadków zastrzeżenia jakie są kierowane pod adresem lokalizacji/GPS w kwestii permanentnego śledzenia nas przez Google nie są przesadzone. Niektórzy spierają się, że wystarczy włączyć tryb samolotowy (Airplane Mode) w telefonie i nasza pozycja przestaje być rejestrowana w czasie rzeczywistym ale nie jest to prawdą. Jakiś czas temu świat obiegła informacja, że Android rejestruje dane geolokalizacji nawet, gdy tryb samolotowy jest włączony, a telefon nie ma włożonych kart SIM i to przy jednoczesnym wyłączeniu WiFi i BT. Jak to do końca jest z tą lokalizacją i czy faktycznie nie da się jej wyłączyć w Androidzie? A może powinniśmy pójść w drugą stronę i zamiast starać się wyłączać lokalizację, to spróbować oszukać system przez jej pozorowanie? Taki zabieg jest możliwy ale wymagana jest zewnętrzna aplikacja do pozorowania lokalizacji, np. Fake Traveler, którą trzeba określić w ustawieniach deweloperskich Androida. Czy ten zabieg wpłynie pozytywnie na lokalizację w kontekście naszej prywatności? Czy może lepiej jest jednak zostawić telefon w domu i pójść na niejawne spotkanie bez tego urządzenia?