<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Prywatność on Morfitronik</title>
    <link>https://morfikov.github.io/tags/prywatnosc/</link>
    <description>Recent content in Prywatność on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Fri, 07 Aug 2026 02:42:00 +0200</lastBuildDate><atom:link href="https://morfikov.github.io/tags/prywatnosc/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zmusić jeden proces do korzystania z VPN na linux (Wireguard)</title>
      <link>https://morfikov.github.io/post/jak-zmusic-jeden-proces-do-korzystania-z-vpn-na-linux-wireguard/</link>
      <pubDate>Fri, 07 Aug 2026 02:42:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zmusic-jeden-proces-do-korzystania-z-vpn-na-linux-wireguard/</guid>
      <description>&lt;p&gt;Jakiś już dłuższy czas temu opisywałem mechanizm &lt;a href=&#34;https://morfikov.github.io/post/jak-zmusic-jeden-proces-do-korzystania-z-vpn-na-linux-openvpn/&#34;&gt;przekierowania ruchu sieciowego jednego lub
wybranych procesów do VPN na przykładzie OpenVPN&lt;/a&gt; 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&#39;a, a konkretnie pojawił się
&lt;a href=&#34;https://www.wireguard.com/&#34;&gt;wireguard&lt;/a&gt;, 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 &lt;a href=&#34;https://www.wireguard.com/quickstart/&#34;&gt;skonfigurowanie do pracy VPN na bazie wireguard&lt;/a&gt; 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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Oblivious DoH (ODoH) z dnscrypt-proxy na Debian Linux</title>
      <link>https://morfikov.github.io/post/oblivious-doh-odoh-z-dnscrypt-proxy-na-debian-linux/</link>
      <pubDate>Mon, 21 Nov 2022 17:42:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/oblivious-doh-odoh-z-dnscrypt-proxy-na-debian-linux/</guid>
      <description>&lt;p&gt;Parę miesięcy temu natrafiłem na taki oto &lt;a href=&#34;https://blog.cloudflare.com/oblivious-dns/&#34;&gt;artykuł na blogu Cloudflare&lt;/a&gt;, 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&#39;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 (&lt;a href=&#34;https://datatracker.ietf.org/doc/html/rfc9230&#34;&gt;RFC9230&lt;/a&gt;). Póki co, jedynym znanym mi narzędziem, które posiada wsparcie dla
ODoH jest &lt;a href=&#34;https://dnscrypt.info/&#34;&gt;dnscrypt-proxy&lt;/a&gt;, którego instalację i konfigurację do współpracy z &lt;code&gt;dnsmasq&lt;/code&gt;
już &lt;a href=&#34;https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/&#34;&gt;jakiś czas temu opisywałem&lt;/a&gt;. Mając wsparcie dla ODoH w &lt;code&gt;dnscrypt-proxy&lt;/code&gt; 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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Zmiana adresu MAC (BSSID) routera WiFi w OpenWRT</title>
      <link>https://morfikov.github.io/post/zmiana-adresu-mac-bssid-routera-wifi-w-openwrt/</link>
      <pubDate>Sun, 30 Jan 2022 20:23:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/zmiana-adresu-mac-bssid-routera-wifi-w-openwrt/</guid>
      <description>&lt;p&gt;Pisząc ostatnio artykuł o tym &lt;a href=&#34;https://morfikov.github.io/post/jak-ukryc-nazwe-sieci-wifi-essid-przed-wigle-net-google-mozilla/&#34;&gt;jak uchronić nasz prywatny punkt dostępu do sieci WiFi przed
zmapowaniem&lt;/a&gt; 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 &lt;code&gt;_nomap&lt;/code&gt; . 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 &lt;a href=&#34;https://morfikov.github.io/post/jak-sklonowac-adres-mac-w-openwrt/&#34;&gt;klonowaniu
adresu MAC dla portu WAN routera&lt;/a&gt;, 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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak ukryć nazwę sieci WiFi (ESSID) przed Wigle.net/Google/Mozilla</title>
      <link>https://morfikov.github.io/post/jak-ukryc-nazwe-sieci-wifi-essid-przed-wigle-net-google-mozilla/</link>
      <pubDate>Sat, 29 Jan 2022 17:12:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-ukryc-nazwe-sieci-wifi-essid-przed-wigle-net-google-mozilla/</guid>
      <description>&lt;p&gt;Parę dni temu napisał do mnie megabajt z forum DUG z wiadomością, że nazwa mojego WiFi figuruje w
bazie danych serwisu &lt;a href=&#34;https://wigle.net/&#34;&gt;Wigle.net&lt;/a&gt; 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ę &lt;a href=&#34;https://f-droid.org/en/packages/net.wigle.wigleandroid/&#34;&gt;WiGLE WiFi
Wardriving&lt;/a&gt;, 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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Randomizacja adresów MAC WiFi w smartfonie z Androidem</title>
      <link>https://morfikov.github.io/post/randomizacja-adresow-mac-wifi-w-smartfonie-z-androidem/</link>
      <pubDate>Fri, 15 Oct 2021 19:46:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/randomizacja-adresow-mac-wifi-w-smartfonie-z-androidem/</guid>
      <description>&lt;p&gt;Posiadacze smartfonów z Androidem w wersji 10+ rzadko kiedy orientują się, że w tej wersji został
wprowadzony dość &lt;a href=&#34;https://source.android.com/devices/tech/connect/wifi-mac-randomization&#34;&gt;ciekawy mechanizm mający na celu poprawnie prywatności&lt;/a&gt; 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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Zmiana implementacji WebView z Google/AOSP na Bromite w Androidzie</title>
      <link>https://morfikov.github.io/post/zmiana-implementacji-webview-z-google-aosp-na-bromite-w-androidzie/</link>
      <pubDate>Fri, 08 Oct 2021 23:47:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/zmiana-implementacji-webview-z-google-aosp-na-bromite-w-androidzie/</guid>
      <description>&lt;p&gt;Przeglądając ostatnio opcje deweloperskie w swoim telefonie z Androidem 11, wpadła mi w oczy pozycja
&lt;code&gt;WebView implementation&lt;/code&gt; . 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&#39;ów). Dlatego też w tym przypadku w implementacji WebView widnieje w zasadzie
tylko jedna opcja, tj. Android System WebView. W przypadku stock&#39;owych ROM&#39;ó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?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Czym jest tryb lockdown w smartfonie z Androidem</title>
      <link>https://morfikov.github.io/post/czym-jest-tryb-lockdown-w-smartfonie-z-androidem/</link>
      <pubDate>Mon, 27 Sep 2021 05:50:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/czym-jest-tryb-lockdown-w-smartfonie-z-androidem/</guid>
      <description>&lt;p&gt;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&#39;owych ROM&#39;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. &lt;a href=&#34;https://android-developers.googleblog.com/2020/09/lockscreen-and-authentication.html&#34;&gt;tryb lockdown&lt;/a&gt;, 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&#39;u i
zweryfikować na ile może on być użyteczny.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Kopia zapasowa danych smartfona z Androidem (OAndBackupX, Syncthing)</title>
      <link>https://morfikov.github.io/post/kopia-zapasowa-danych-smartfona-z-androidem-oandbackupx-syncthing/</link>
      <pubDate>Sun, 26 Sep 2021 16:44:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/kopia-zapasowa-danych-smartfona-z-androidem-oandbackupx-syncthing/</guid>
      <description>&lt;p&gt;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 &lt;a href=&#34;https://morfikov.github.io/post/czy-smartfon-z-androidem-bez-google-apps-services-ma-sens/&#34;&gt;czy smartfon z
Androidem bez Google Play Services ma sens&lt;/a&gt;. 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&#39;u trzeba było wyłączyć smartfon. Parę dni temu natrafiłem
na &lt;a href=&#34;https://github.com/machiav3lli/oandbackupx&#34;&gt;narzędzia OAndBackupX&lt;/a&gt;, 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&#39;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&#39;owym ROM&#39;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&#39;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 &lt;a href=&#34;https://github.com/syncthing/syncthing&#34;&gt;Syncthing&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Blokowanie dostępu do sensorów (kamera/mikrofon/gps) aplikacjom w Androidzie</title>
      <link>https://morfikov.github.io/post/blokowanie-dostepu-do-sensorow-kamera-mikrofon-gps-aplikacjom-w-androidzie/</link>
      <pubDate>Wed, 22 Sep 2021 02:04:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/blokowanie-dostepu-do-sensorow-kamera-mikrofon-gps-aplikacjom-w-androidzie/</guid>
      <description>&lt;p&gt;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ę &lt;code&gt;Sensors Off&lt;/code&gt; , która
była ukryta pod &lt;code&gt;Quick settings developer tiles&lt;/code&gt; . 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.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Pozorowanie lokalizacji GPS w Androidzie (mock location)</title>
      <link>https://morfikov.github.io/post/pozorowanie-lokalizacji-gps-w-androidzie-mock-location/</link>
      <pubDate>Tue, 21 Sep 2021 19:33:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/pozorowanie-lokalizacji-gps-w-androidzie-mock-location/</guid>
      <description>&lt;p&gt;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 &lt;a href=&#34;https://www.thesun.co.uk/tech/7811918/google-is-tracking-you-even-with-airplane-mode-turned-on/&#34;&gt;Android rejestruje dane geolokalizacji&lt;/a&gt; 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. &lt;a href=&#34;https://github.com/mcastillof/FakeTraveler&#34;&gt;Fake Traveler&lt;/a&gt;, 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?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak blokować rozmowy GSM w smartfonie z Androidem (YACB)</title>
      <link>https://morfikov.github.io/post/jak-blokowac-rozmowy-gsm-w-smartfonie-z-androidem-yacb/</link>
      <pubDate>Sat, 18 Sep 2021 15:22:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-blokowac-rozmowy-gsm-w-smartfonie-z-androidem-yacb/</guid>
      <description>&lt;p&gt;Czy przytrafiła może wam się taka sytuacja, w której to ktoś dzwonił do was z niewiadomego numeru i
przy tym nie był to nikt, kto by zasługiwał na jakąś większą uwagę z waszej strony? Zwykle, gdy mam
do czynienia z kimś takim, to nawet nie odbieram telefonu. Niemniej jednak, najwyraźniej jeden z
moich numerów ostatnio stał się celem ataku jakiegoś spamera z bliżej nieokreślonego call center i
ten czteroliterowy osobnik wydzwania do mnie od kilku dni średnio co 20 minut i to z wielu różnych
numerów. Do tej pory spamerzy w zasadzie omijali mnie szerokim łukiem ale zachowanie tej dość
nieuprzejmej osoby sprawiło, że postanowiłem opracować jakieś rozwiązanie na wypadek, gdyby takich
osobników z gatunku &amp;quot;brakującego ogniwa ewolucji Homo sapiens&amp;quot; było więcej. Po chwili wertowania
netu udało mi się znaleźć appkę, co się zwie &lt;a href=&#34;https://gitlab.com/xynngh/YetAnotherCallBlocker&#34;&gt;Yet Another Call Blocker&lt;/a&gt; (YACB), która w zasadzie
jest tym, czego standardowo brakuje w każdym smartfonie z Androidem na pokładzie, tj. dość
zaawansowanego filtra rozmów przychodzących realizowanych w przestarzałej już technologi GSM, czyli
w zwykłych rozmowach telefonicznych na komórkę. Jako, że ten YACB jest bardzo ciekawym kawałkiem
oprogramowania i do tego w pełni OpenSource (dostępnym w repozytorium F-Droid), to postanowiłem
napisać o nim kilka słów, bo jest to wręcz nieocenione narzędzie w walce z wszelkim syfem pokroju
różnych spamerów z call center.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Szyfrowany DNS z dnscrypt-proxy i dnsmasq na Debian linux</title>
      <link>https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/</link>
      <pubDate>Sat, 19 Sep 2020 14:13:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/</guid>
      <description>&lt;p&gt;Ostatnio na forum dug.net.pl jeden z użytkowników &lt;a href=&#34;https://forum.dug.net.pl/viewtopic.php?id=31524&#34;&gt;miał dość spory problem&lt;/a&gt; z ogarnięciem
zadania polegającego na zaszyfrowaniu zapytań DNS z wykorzystaniem &lt;a href=&#34;https://dnscrypt.info/&#34;&gt;dnscrypt-proxy&lt;/a&gt; i
&lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;dnsmasq&lt;/a&gt;. Ładnych parę lat temu opisywałem &lt;a href=&#34;https://morfikov.github.io/tags/resolver/&#34;&gt;jak skonfigurować te dwa narzędzia na Debianie&lt;/a&gt;
(i też na OpenWRT), choć od tamtego czasu w świecie linux&#39;owym trochę rzeczy się pozmieniało. Dla
przykładu, dnscrypt-proxy przeszedł gruntowną przebudowę, no i też systemd jest w powszechniejszym
użyciu niż to miało miejsce w tamtych czasach, przez co w sporej części przypadków usługi takie jak
&lt;code&gt;systemd-networkd.service&lt;/code&gt; czy &lt;code&gt;systemd-resolved.service&lt;/code&gt; są już włączone domyślnie. Zatem sporo
informacji zawartych w tych napisanych przeze mnie artykułach już niekoniecznie może znaleźć
obecnie zastosowanie. Dlatego też pomyślałem, że nadszedł już czas, by ździebko zaktualizować tamte
wpisy. Ostatecznie stanęło jednak na tym, by w oparciu o te artykuły napisać kompletnie nowy tekst
na temat szyfrowania zapytań DNS na linux przy wykorzystaniu oprogramowania &lt;code&gt;dnscrypt-proxy&lt;/code&gt; oraz
&lt;code&gt;dnsmasq&lt;/code&gt; i zawrzeć w nim te wszystkie ciekawsze informacje, które udało mi się pozyskać przez te
ostatnie lata w kwestii poprawy bezpieczeństwa i prywatności przy przeglądaniu stron WWW.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zmusić jeden proces do korzystania z VPN na linux (OpenVPN)</title>
      <link>https://morfikov.github.io/post/jak-zmusic-jeden-proces-do-korzystania-z-vpn-na-linux-openvpn/</link>
      <pubDate>Wed, 02 Sep 2020 18:36:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zmusic-jeden-proces-do-korzystania-z-vpn-na-linux-openvpn/</guid>
      <description>&lt;p&gt;Parę dni temu &lt;a href=&#34;https://forum.dug.net.pl/viewtopic.php?id=31514&#34;&gt;na forum dug.net.pl pojawiło się zapytanie&lt;/a&gt; dotyczące skonfigurowania linux&#39;a w
taki sposób, by ten umożliwił pojedynczemu procesowi w systemie (i tylko jemu) korzystanie z VPN,
podczas gdy wszystkie pozostałe aplikacje korzystają ze standardowego łącza internetowego naszego
ISP. Oczywiście to niekoniecznie musi być tylko jeden proces, bo to zagadnienie można rozciągnąć
też na większą grupę procesów jednego lub więcej użytkowników. By to zadanie zrealizować, trzeba
zdać sobie sprawę z faktu, że każdy proces w linux ma swojego właściciela, a ten właściciel
przynależy do co najmniej jednej grupy. Dzięki takiemu rozwiązaniu, każdy proces w systemie ma
przypisany m.in. identyfikator użytkownika (UID) oraz identyfikatory grup (GID), z którymi działa i
na podstawie których to linux przyznaje uprawienia dostępu do różnych części systemu, np. urządzeń
czy plików na dysku. W ten sposób możemy bardzo prosto ograniczyć dostęp do określonych zasobów
konkretnym użytkownikom (bardziej ich procesom). Problem się zaczyna w przypadku sieci, gdzie w
zasadzie dostęp do internetu ma domyślnie przyznany każdy proces. Naturalnie możemy skonfigurować
filtr pakietów i zezwolić tylko części aplikacji na dostęp do sieci ale w dalszym ciągu, gdy tylko
odpalimy VPN (w tym przypadku OpenVPN), to każdy proces mający prawo wysyłać pakiety sieciowe
będzie je przesyłał z automatu przez VPN, jak tylko to połączenie zostanie zestawione. Istnieje
jednak sposób, by nauczyć linux&#39;a aby tylko procesy określonych użytkowników czy grup miały dostęp
do VPN i gdy to połączenie zostanie zerwane, to te procesy nie będą mogły korzystać ze
standardowego łącza internetowego. Trzeba jednak zaprzęgnąć do pracy &lt;code&gt;iptables&lt;/code&gt; / &lt;code&gt;nftables&lt;/code&gt; ,
tablice routingu oraz nieco inaczej skonfigurować klienta OpenVPN.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak włączyć stabilne adresy prywatne w IPv6 na linux</title>
      <link>https://morfikov.github.io/post/jak-wlaczyc-stabilne-adresy-prywatne-w-ipv6-na-linux/</link>
      <pubDate>Wed, 19 Aug 2020 19:31:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-wlaczyc-stabilne-adresy-prywatne-w-ipv6-na-linux/</guid>
      <description>&lt;p&gt;Jakiś już czas temu opisywałem &lt;a href=&#34;https://morfikov.github.io/post/jak-wlaczyc-ipv6-privacy-extensions-w-debianie-slaac/&#34;&gt;jak włączyć rozszerzenia prywatności IPv6 na Debianie&lt;/a&gt; (IPv6
Privacy Extensions) w przypadku korzystania z mechanizmu automatycznej konfiguracji adresacji
hostów SLAAC (StateLess Address AutoConfiguration). Miało to za zadanie poprawić nieco prywatność
osób podłączonych do internetu za sprawą protokołu IPv6, bo generowane adresy IP standardowo
zawierają adresy MAC kart sieciowych (&lt;a href=&#34;https://en.wikipedia.org/wiki/MAC_address&#34;&gt;identyfikator EUI64&lt;/a&gt;). Parę dni temu dowiedziałem się, że
w linux można również aktywować inny mechanizm zwany stabilnymi adresami prywatnymi
(&lt;a href=&#34;https://tools.ietf.org/html/rfc7217&#34;&gt;stable-privacy addresses&lt;/a&gt;), które to wykorzystują inny system przy generowaniu identyfikatorów
interfejsów sieciowych. Ten mechanizm sprawia, że część adresu IPv6 odpowiedzialna za identyfikację
hosta ma losowe, choć stabilne wartości, które nie mają nic wspólnego z adresem MAC karty sieciowej
naszego komputera. W ten sposób możemy ukrócić śledzenie nas w sieci na podstawie adresu IPv6.
Poniższy artykuł ma za zadanie pomóc skonfigurować nam te stabilne adresy prywatne na linux oraz
pokazać w jaki sposób są one w stanie pomóc naszej prywatności.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak włączyć w Firefox ESNI (Encrypted SNI)</title>
      <link>https://morfikov.github.io/post/jak-wlaczyc-w-firefox-esni-encrypted-sni/</link>
      <pubDate>Mon, 10 Aug 2020 18:15:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-wlaczyc-w-firefox-esni-encrypted-sni/</guid>
      <description>&lt;p&gt;Obecnie szyfrowanie zapytań DNS staje się powoli normą za sprawą protokołu DoH (&lt;a href=&#34;https://en.wikipedia.org/wiki/DNS_over_HTTPS&#34;&gt;DNS over HTTPS&lt;/a&gt;)
lub DoT (&lt;a href=&#34;https://en.wikipedia.org/wiki/DNS_over_TLS&#34;&gt;DNS over TLS&lt;/a&gt;). Można by zatem pomyśleć, że wraz z implementacją szyfrowania tego
kluczowego dla działania internetu protokołu (przynajmniej z naszego ludzkiego punktu widzenia),
poprawie ulegnie również nasza prywatność w kwestii odwiedzanych przez nas stron WWW. Niemniej
jednak, w dalszym ciągu można bez problemu wyciągnąć adresy domen, które zamierzamy odwiedzić. Nie
ma przy tym żadnego znaczenia ile stron jest hostowanych na danym adresie IP, ani nawet fakt, że
ruch do serwera WWW będzie szyfrowany (w pasku adresu wpiszemy &lt;code&gt;https://&lt;/code&gt; ) z wykorzystaniem
protokołu SSL/TLS (w tym również TLS v1.3). Wszystko przez rozszerzenie SNI (&lt;a href=&#34;https://en.wikipedia.org/wiki/Server_Name_Indication&#34;&gt;Server Name
Indication&lt;/a&gt;), którego to zadaniem jest umożliwienie jednemu serwerowi na prezentowanie wielu
certyfikatów hostowanych w jego obrębie domen. Dzięki takiemu rozwiązaniu, każda domena może
szyfrować ruch niezależnie od siebie na linii serwer&amp;lt;-&amp;gt;klient (używać innych kluczy szyfrujących).
Niemniej jednak, podczas nawiązywania szyfrowanego połączenia, w pakiecie ClientHello przesyłanym
do takiego serwera musi znaleźć się nazwa domeny, której to certyfikat serwer będzie musiał nam
przedstawić. Niestety ten pakiet jest przesyłany przez sieć otwartym tekstem, przez co każdy, kto
podsłuchuje naszą komunikację (w tym też nasz ISP), bez problemu może ustalić na jakie strony
internetowe wchodzimy. Ostatnimi czasy jednak pojawiły się dwa rozszerzenia ECH (&lt;a href=&#34;https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello&#34;&gt;Encrypted Client
Hello&lt;/a&gt;) oraz ESNI (&lt;a href=&#34;https://tools.ietf.org/html/draft-ietf-tls-esni-07&#34;&gt;Encrypted SNI&lt;/a&gt;), które mają zaadresować problemy związane z prywatnością
przez pełne zaszyfrowanie pakietu ClientHello lub też zaszyfrowanie jedynie pola SNI w tym pakiecie.
Póki co, prace nad tymi rozszerzeniami nie są jeszcze skończone ale Firefox w połączeniu z
CloudFlare powoli testują ESNI. Postanowiłem zatem dobrowolnie przyłączyć się do grupy testerów i
wdrożyć na swoim linux&#39;ie to rozszerzenie ESNI dla przeglądarki Firefox.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zmienić hostname w telefonie z Androidem</title>
      <link>https://morfikov.github.io/post/jak-zmienic-hostname-w-telefonie-z-androidem/</link>
      <pubDate>Wed, 29 Jan 2020 19:00:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zmienic-hostname-w-telefonie-z-androidem/</guid>
      <description>&lt;p&gt;Przeglądając ostatnio listę sprzętów podłączonych do mojego routera WiFi, zauważyłem, że niektóre
pozycje na niej w polu z hostname mają coś na wzór &lt;code&gt;android-4c52c33baae0b4fa&lt;/code&gt; . Pierwsza część
nazwy tego hosta wskazuje na system operacyjny, a drugi kawałek to unikalny numerek ID.  Nie jestem
zbytnio fanem rozgłaszania takich informacji publicznie, bo mogą one ułatwić ewentualne ataki, oraz
też identyfikują jednoznacznie dane urządzenie (&lt;a href=&#34;https://source.android.com/devices/tech/connect/wifi-mac-randomization&#34;&gt;osobną kwestią jest adres MAC karty sieciowej&lt;/a&gt;).
Ponadto, mając w sieci wiele mobilnych urządzeń, ciężko jest czasem połapać się który telefon ma
przypisany konkretny adres IP (bez patrzenia w ustawienia telefonu). Z reguły na linux&#39;owym
desktopie czy laptopie zmiana hostname jest stosunkowo łatwym zadaniem ale w przypadku smartfona z
Androidem ten zabieg okazał się niezmiernie trudnym procesem. Jak zatem zmienić hostname telefonu,
by można było mu przypisać jakaś w miarę ludzką nazwę?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak włączyć IPv6 Privacy Extensions w Debianie (SLAAC)</title>
      <link>https://morfikov.github.io/post/jak-wlaczyc-ipv6-privacy-extensions-w-debianie-slaac/</link>
      <pubDate>Sun, 10 Feb 2019 08:22:55 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-wlaczyc-ipv6-privacy-extensions-w-debianie-slaac/</guid>
      <description>&lt;p&gt;Protokół IPv6 został opracowany już dość dawno temu, a jednak ilość hostów w internecie
komunikujących się za jego pomocą wciąż nie jest zbyt wysoka
i &lt;a href=&#34;https://www.google.com/intl/en/ipv6/statistics.html&#34;&gt;oscyluje w granicach 25%&lt;/a&gt;. Faktem jest, że
migracja z IPv4 na IPv6 może być sporym kosztem dla niektórych podmiotów jeśli chodzi o kwestię
związaną z wymianą sprzętu i ze zmianą konfiguracji sieci, co pewnie zniechęca część ISP do
wdrożenia tego protokołu. Użytkownicy korzystający z sieci z kolei nie wiedzieć czemu też
preferują IPv4 nad IPv6. Jakiś czas temu czytałem nawet artykuł na temat zagrożenia prywatności
jakie może nieść ze sobą protokół IPv6. Chodzi generalnie o to, że obecnie wszyscy przywykliśmy do
rozwiązania jakie oferuje nam NAT, które jest w stanie utrudnić nieco naszą identyfikację i analizę
naszej aktywności w internecie. W przypadku IPv6 adresy IP są dość unikatowe w skali globalnej, a
część odpowiedzialna za identyfikację hosta (ostatnie 64 bity) stanowi identyfikator EUI64, który z
kolei jest generowany na podstawie adresu MAC karty sieciowej. W taki oto sposób interfejs tej
karty będzie miał stały identyfikator EUI64, a hosta będzie można zidentyfikować bez problemu i
bez względu na to u którego ISP podłączymy nasz komputer. Rozwiązaniem tego problemu jest mechanizm
zwany IPv6 Privacy Extensions. Przydałoby się zatem rzucić na niego okiem i jeśli okaże się
użyteczny, to wypadałoby go włączyć w naszym Debian Linux.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Szyfrowanie rozmów i SMS&#39;ów na smartfonie z Androidem (Signal)</title>
      <link>https://morfikov.github.io/post/szyfrowanie-rozmow-i-smsow-na-smartfonie-z-androidem-signal/</link>
      <pubDate>Sun, 26 Mar 2017 18:35:14 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/szyfrowanie-rozmow-i-smsow-na-smartfonie-z-androidem-signal/</guid>
      <description>&lt;p&gt;Każdy z nas ma już raczej w swoim posiadaniu telefon, czy jego nieco bardziej zaawansowaną wersję
określaną mianem smartfona. Te urządzenia to w zasadzie przenośne i do tego bardzo małe komputery,
które umożliwiają nam komunikowanie się z osobami na całym świecie. Wykonywanie połączeń głosowych,
przesyłanie SMS&#39;ów/MMS&#39;ów czy też korzystanie z Internetu w naszych komórkach od dawna jest już
standardem i ciężko byłoby nam się obejść bez tej technologii obecnie. Problem w tym, że nasza
komunikacja jest narażona na podsłuch. W przypadku Internetu większość połączeń jest już szyfrowana
na linii dwóch klientów (E2E, End To End). Natomiast jeśli chodzi o telefony, to tutaj sprawa kuleje
i to bardzo poważnie, bo w zasadzie nasze połączenia głosowe czy SMS&#39;y są do wglądu dla każdych
służb, które z jakiegoś powodu uznają, że mogą naruszać naszą prywatność. Jedyna opcja, która jest
w stanie zabezpieczyć nas przed tego typu praktykami, to szyfrowanie rozmów. Tak się składa, że jest
kilka aplikacji na Androida, które są w stanie realizować tego typu przedsięwzięcie. Jedną z nich
jest darmowa i otwartoźródłowa aplikacja Signal, której się przyjrzymy nieco bliżej w tym artykule.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zlokalizować skradziony/zagubiony smartfon z Androidem</title>
      <link>https://morfikov.github.io/post/jak-zlokalizowac-skradziony-zagubiony-smartfon-z-androidem/</link>
      <pubDate>Fri, 27 Jan 2017 18:52:06 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zlokalizowac-skradziony-zagubiony-smartfon-z-androidem/</guid>
      <description>&lt;p&gt;Smartfony towarzyszą nam w codziennym życiu praktycznie cały czas. Dlatego też zaczynamy
przechowywać w tych urządzeniach coraz to więcej informacji osobistych, które są w stanie dość
dokładnie opisać nasze życie prywatne. Co jednak w przypadku, gdy taki telefon zgubimy lub też
zostanie nam on skradziony przez kogoś? Gdy chodzi o urządzenia z Androidem, to Google oferuje
usługę, która jest w stanie połączyć się z naszym smartfonem i przy odrobinie szczęścia ujawnić
nam jego położenie geograficzne lub też pozwolić nam na zdalne zablokowanie systemu w telefonie.
Chodzi oczywiście o usługę &amp;quot;Znajdź telefon/smartfon&amp;quot; (find my phone), na którą rzucimy sobie okiem w
tym artykule.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Factory Reset Protection (FRP) w smartfonach z Androidem</title>
      <link>https://morfikov.github.io/post/factory-reset-protection-frp-w-smartfonach-z-androidem/</link>
      <pubDate>Fri, 20 Jan 2017 18:37:11 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/factory-reset-protection-frp-w-smartfonach-z-androidem/</guid>
      <description>&lt;p&gt;Kupowanie telefonów czy smartfonów z Androidem z innych źródeł niż oficjalne punkty sprzedaży nie
zawsze jest bezpieczną opcją. Gdy nabywamy takie urządzenie od znajomego, to raczej nie powinniśmy
się martwić o to, że ten telefon może być kradziony. Niemniej jednak, po zakupie takiego urządzenia,
poprzedni użytkownik zwykle resetuje jego ustawienia do fabrycznych, by klient miał świeży system i
nie był w stanie uzyskać dostępu do prywatnych danych poprzedniego właściciela smartfona. Nie byłoby
w tym nic nadzwyczajnego, gdyby nie fakt, że nabywca tak odsprzedanego telefonu może mieć pewne
problemy ze skonfigurowaniem Androida, bo ten system zwróci mu komunikat: &amp;quot;Urządzenie zostało
zresetowane. Aby kontynuować, zaloguj się na konto Google, które było wcześniej synchronizowane na
tym urządzeniu&amp;quot;, czyli telefon został zablokowany przez mechanizm Factory Reset Protection Lock (FRP
Lock). Jeśli znajomy mieszka blisko nas, to naturalnie możemy się przejść do niego w celu zdjęcia
tej blokady. A co w przypadku, gdy nabyliśmy urządzenie na odległość? Czy jest jakiś sposób na
obejście tej blokady w przypadku smartfonów Neffos od TP-LINK?&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
