Hasło „VPN bez logów” brzmi prosto, ale w praktyce obejmuje kilka różnych kategorii danych. Poszczególni dostawcy rozumieją je na swój sposób, a część logów jest dla działania usługi po prostu niezbędna. Dlatego punkt wyjścia to rozróżnienie, o jakie logi w ogóle chodzi.
Najczęściej mówi się o trzech podstawowych grupach:
logi eksploatacyjne / techniczne – dane o wydajności i stabilności usługi, np. obciążenie serwerów, statystyki ilościowe, błędy, liczba jednoczesnych połączeń, ogólna liczba użytkowników; zwykle są mocno zanonimizowane lub zagregowane;
logi metadanych połączeń – informacje o tym, kto, kiedy i skąd łączył się z usługą VPN, np. adres IP użytkownika, czas rozpoczęcia i zakończenia sesji, przypisany adres IP VPN, lokalizacja serwera, wykorzystany protokół;
logi treści – pełna lub częściowa historia ruchu przechodzącego przez VPN, np. odwiedzane adresy URL, docelowe adresy IP, treść zapytań DNS, a w skrajnych przypadkach nawet dane z niezaszyfrowanego ruchu (HTTP, stare protokoły itp.).
Z punktu widzenia prywatności najbardziej wrażliwe są metadane połączeń oraz ewentualne logi treści. To właśnie dzięki nim da się połączyć konkretną aktywność w sieci z konkretnym użytkownikiem. Logi eksploatacyjne, pod warunkiem odpowiedniego zanonimizowania, zwykle nie pozwalają na taką identyfikację – służą głównie do zarządzania infrastrukturą.
Problem w tym, że wielu dostawców nie precyzuje, do której kategorii odnoszą się ich deklaracje „no-logs”. Niektórzy mówią, że nie przechowują „logów aktywności” (history of browsing activity), ale zbierają np. adres IP i znaczniki czasu. Z prawnego czy marketingowego punktu widzenia dalej mogą się nazywać „no-logs VPN”, choć z perspektywy użytkownika to wciąż istotne metadane.
Które dane są krytyczne z punktu widzenia prywatności
Dla realnej ochrony prywatności kluczowe jest to, czy z logów da się odtworzyć scenariusz: „Użytkownik X o adresie IP od dostawcy Y w dniu Z korzystał z danego serwera VPN i wykonał konkretną akcję w sieci”. Do takiej rekonstrukcji zwykle wystarczą stosunkowo skromne informacje.
Najbardziej problematyczne są:
oryginalny adres IP użytkownika (assigned by ISP) – umożliwia powiązanie aktywności z konkretnym łączem internetowym, a często z konkretną osobą lub gospodarstwem domowym;
znaczniki czasu (czas rozpoczęcia / zakończenia sesji VPN) – w połączeniu z logami innych podmiotów pozwalają na korelację działań, nawet jeśli nie są przechowywane treści;
przypisany adres IP VPN i lokalizacja serwera – gdy inne strony czy usługi logują ten adres, organy ścigania mogą pytać dostawcę VPN, komu był on przydzielony w danym momencie;
logi DNS i adresy URL – bezpośrednio pokazują, jakie domeny i zasoby były odwiedzane, co często wystarcza do profilowania użytkownika lub wskazania naruszenia prawa.
Jeżeli dostawca VPN nie loguje żadnego z powyższych elementów w sposób umożliwiający identyfikację konkretnego użytkownika, ryzyko korelacji logów spada bardzo mocno. Jeżeli natomiast przechowuje choćby część tych danych, znaczenie ma: jak długo, w jakiej formie (anonimizacja, pseudonimizacja) i czy może je powiązać z kontem rozliczeniowym (e-mail, metoda płatności).
Niektóre firmy deklarują, że zbierają np. „statystyki sesji”, ale bez zapisu IP użytkownika, jedynie licznik równoczesnych połączeń na konto. To istotna różnica względem pełnych logów połączeń i nie każda wzmianka o „session data” oznacza automatycznie zagrożenie prywatności – trzeba wczytać się w szczegóły.
„No-logs” w marketingu a w praktyce technicznej
Określenie „VPN bez logów” nie ma precyzyjnej, prawnej definicji. To termin marketingowy. Jedna firma użyje go, bo nie przechowuje logów historii przeglądania, inna – bo kasuje dane po kilku godzinach, a jeszcze inna – bo logi są zanonimizowane. Dla użytkownika to trzy zupełnie różne modele ryzyka, chociaż wszystkie sprzedaje się tym samym hasłem.
Częste chwyty marketingowe to w szczególności:
„no traffic logs” – brak logów ruchu, ale pozostają logi połączeń (czas, IP, lokalizacja);
„no activity logs” – brak historii odwiedzanych stron, ale logowane są metadane typu IP + timestamp;
„we may collect diagnostic data” – domyślna zgoda na zbieranie niejasno zdefiniowanych informacji w celu „ulepszania usługi”;
„temporary logs for abuse prevention” – przechowywanie logów przez krótki okres w celu przeciwdziałania nadużyciom (spam, DDoS, ataki).
W praktyce wiele zależy od tego, czy z „diagnostycznych” lub „tymczasowych” danych da się wrócić do konkretnego użytkownika. Jeżeli dostawca przechowuje pełne IP, znaczniki czasu oraz przypisany IP serwera VPN, a okres retencji to np. 30 dni, to z perspektywy organów ścigania są to realne logi – nawet jeśli marketing mówi co innego.
Dlatego weryfikacja „no-logs” polega głównie na przełożeniu języka marketingu na konkret techniczny. Kluczowe jest pytanie: czy dana kategoria danych, w połączeniu z innymi źródłami, pozwala na identyfikację użytkownika i korelację jego działań. Jeżeli tak – jest to logowanie w istotnym sensie, choćby firma próbowała nazywać to inaczej.
Źródło: Pexels | Autor: Stefan Coders
Realistyczne oczekiwania: czego da się dowiedzieć z zewnątrz, a czego nie
Granice weryfikowalności po stronie użytkownika
Nie ma technicznej możliwości, aby zwykły użytkownik uzyskał pełny wgląd w infrastrukturę dostawcy VPN. Nie zobaczy konfiguracji wszystkich serwerów, systemów logowania, systemów SIEM, procedur reagowania na incydenty czy faktycznej praktyki administratorów. Może natomiast złożyć w całość szereg pośrednich sygnałów.
Zewnętrzna ocena sprowadza się do analizy czterech warstw:
deklaracje prawne i marketingowe – polityka prywatności, regulamin, strona z funkcjami, wpisy blogowe;
jurysdykcja i otoczenie prawne – kraj rejestracji spółki, realne miejsca prowadzenia działalności, listy retencyjne;
zewnętrzne potwierdzenia – niezależne audyty, sprawy sądowe, incydenty bezpieczeństwa, komunikaty dla organów ścigania;
testy techniczne – zachowanie aplikacji, wycieki IP/DNS/WebRTC, sposób aktualizacji, stosowane protokoły.
Każda z tych warstw jest niedoskonała. Dokumenty prawne można napisać, ale nie stosować. Audyt jest chwilową fotografią, nie stałym nadzorem. Jurysdykcja nie zawsze przekłada się na faktyczną praktykę. Testy techniczne mówią o wyciekach, ale nie o tym, co dzieje się z logami wewnątrz serwerowni. Dlatego kluczowe jest podejście probabilistyczne: ocena ryzyka i prawdopodobieństwa niewygodnych praktyk, nie absolutna pewność.
Użytkownik może dojść do wniosku, że dany VPN „prawdopodobnie nie loguje w sposób ryzykowny” na bazie spójności deklaracji, audytów, historii firmy i testów technicznych. Nie jest jednak w stanie udowodnić ponad rozsądną wątpliwość, że logów nie ma ani dziś, ani nie pojawią się jutro po cichej zmianie polityki.
Prawdopodobieństwo zamiast absolutnej pewności
Różnica pomiędzy stwierdzeniem „VPN nie loguje” a „wszystko wskazuje, że VPN nie prowadzi ryzykownych logów” jest zasadnicza. Z punktu widzenia praktyki bezpieczeństwa operuje się właśnie na drugim poziomie. Istnieje szereg rzeczy, które zmniejszają prawdopodobieństwo logowania, ale nic nie jest gwarantem.
Elementy, które zwiększają zaufanie:
jasna, jednoznaczna polityka prywatności, wprost wykluczająca zbieranie IP, timestampów i historii ruchu;
jurysdykcja bez obowiązkowej retencji danych dla usług VPN;
niezależne audyty polityki no-logs, powtarzane co kilka lat, z jawnymi raportami;
publicznie opisane sprawy, w których przejęcie serwerów lub wnioski organów ścigania nie przyniosły logów pozwalających na identyfikację;
architektura oparta o serwery RAM-only i minimalizację danych w aplikacjach klienckich.
Elementy, które ryzyko zwiększają:
rozmyte sformułowania o „diagnostic data”, „troubleshooting” czy „abuse prevention” bez doprecyzowania zakresu;
jurysdykcja z agresywną retencją danych lub historią masowej inwigilacji;
brak jakichkolwiek audytów lub niejasne informacje o rzekomych kontrolach („internal audit”);
incydenty, w których dostawca przekazał dane prowadzące do identyfikacji użytkownika, mimo wcześniejszych obietnic no-logs;
brak reakcji na pytania społeczności, krytykę ekspertów, niewyjaśnione kontrowersje.
Ocena końcowa nie jest zero-jedynkowa. Można założyć, że przy zwykłym korzystaniu z sieci, przy braku zainteresowania ze strony wyspecjalizowanych służb, solidny komercyjny VPN z wysoką reputacją znacząco utrudnia powiązanie aktywności online z konkretną osobą. Dla użytkownika potrzebującego ochrony przed dobrze zorganizowanym aparatem państwowym ten sam poziom może być niewystarczający.
Rola reputacji, historii firmy i incydentów
Te same dokumenty prawne i te same deklaracje brzmią inaczej w zależności od tego, kto je składa. Spółka działająca od wielu lat, reagująca na błędy, współpracująca z audytorami i otwarcie opisująca incydenty budzi inne zaufanie niż anonimowy podmiot zarejestrowany w egzotycznej jurysdykcji, o którym niewiele wiadomo poza agresywną reklamą.
Przy weryfikacji polityki no-logs dobrze jest prześledzić:
historię marki – od kiedy istnieje, czy zmieniała właściciela, czy pojawiały się informacje o przejęciu przez fundusz lub inną korporację;
incydenty bezpieczeństwa – czy kiedykolwiek informowała o włamaniu na serwer, przejęciu infrastruktury, podatnościach, a jeśli tak – jak zareagowała;
sprawy sądowe i wnioski organów ścigania – czy publicznie opisuje, jakie dane mogła (lub nie mogła) przekazać;
reakcję społeczności – fora, niezależne recenzje, analizy techniczne, dyskusje ekspertów.
Przykład z praktyki: w kilku głośnych przypadkach organy ścigania przejęły serwery popularnych usług VPN, licząc na uzyskanie logów. Publicznie ujawnione dokumenty sądowe wskazały jednak, że nie udało się zdobyć informacji pozwalających na identyfikację użytkownika, bo logi po prostu nie były przechowywane w sposób użyteczny. Dla tych konkretnych dostawców były to najcenniejsze „dowody” na to, że ich polityka no-logs nie jest pustą deklaracją.
Z drugiej strony zdarzały się i takie przypadki, w których VPN promowany jako „no-logs” przekazał organom ścigania dane IP i znaczniki czasu, a szczegóły wyszły na jaw dopiero z dokumentów procesowych. W konsekwencji reputacja danego brandu została trwale nadszarpnięta – i słusznie, bo wykazało to rozjazd między marketingiem a realną praktyką.
Modele zagrożeń a wystarczalność komercyjnego VPN
Ocena VPN „bez logów” powinna być powiązana z własnym modelem zagrożeń. Inaczej podchodzi się do tematu, gdy celem jest ochrona przed profilowaniem reklamowym i ciekawskim dostawcą internetu, a inaczej, gdy w grę wchodzi działalność dziennikarska w autorytarnym państwie.
Dla większości osób korzystających z sieci w celach prywatnych, w tym do:
ograniczenia profilowania reklamowego i śledzenia między stronami,
bezpieczniejszego korzystania z publicznych Wi‑Fi,
ukrycia aktywności przed lokalnym dostawcą internetu,
zmiany lokalizacji IP w celu dostępu do treści z innych krajów,
dobrze dobrany komercyjny VPN, z rozsądną polityką no‑logs, audytami i bez głośnych wpadek, jest co do zasady wystarczający. Minimalizuje ślad, utrudnia korelację logów i zapewnia rozsądny balans pomiędzy wygodą a prywatnością.
W zastosowaniach wysokiego ryzyka – np. aktywizm polityczny w kraju o silnym nadzorze, działalność whistleblowera, praca dziennikarza śledczego przeciw lokalnym służbom – nawet najlepszy komercyjny VPN może być tylko jednym z elementów układanki. Potrzebny jest wtedy ostrzejszy model zagrożeń, który obejmuje m.in.:
segmentację tożsamości (odrębne konta, urządzenia, środki płatności),
korzystanie z dodatkowych warstw anonimizacji (np. Tor, mostki, łańcuchowanie VPN),
ostrożne zarządzanie metadanymi (np. unikanie korelowania godzin logowania z przewidywalną aktywnością offline),
minimalizację zaufania do pojedynczego dostawcy infrastruktury.
W takiej sytuacji polityka no‑logs jednego komercyjnego VPN to za mało, żeby uznać ryzyko za „akceptowalne”.
Jak czytać politykę prywatności i regulamin VPN krok po kroku
Gdzie szukać kluczowych informacji
Dokumenty prawne większości VPN są rozproszone. Zwykle obejmują:
politykę prywatności – opis kategorii danych, celów przetwarzania, podstaw prawnych, podmiotów trzecich;
regulamin (Terms of Service / Terms of Use) – zasady korzystania, ograniczenia, tryb współpracy z organami, wypowiedzenie;
politykę cookies – głównie dotyczy strony www, ale czasami zdradza narzędzia analityczne i marketingowe;
osobne strony typu „Privacy tools”, „No‑logs policy”, „Security overview” – tam często pojawiają się techniczne szczegóły.
Do oceny logowania istotne są wszystkie te źródła łącznie. Często zdarza się, że jasna deklaracja „no‑logs” widnieje na stronie marketingowej, a w polityce prywatności pojawiają się szerokie wyjątki i pojęcia-wytrychy.
Słowa-klucze i pojęcia-wytrychy
Przy lekturze polityki prywatności przydaje się prosty filtr: każdą ogólną kategorię należy próbować przekuć na konkret. Jeśli dokument mówi o „diagnostic data”, „service improvement” czy „abuse prevention”, trzeba sprawdzić, co się pod tym kryje.
Warto zwrócić szczególną uwagę na:
„usage data”, „service usage information” – czy to obejmuje godziny połączeń, adres IP użytkownika, identyfikatory urządzeń?
„connection logs” vs „activity logs” – niektórzy dostawcy twierdzą, że nie prowadzą „activity logs” (czyli historii odwiedzanych stron), ale przyznają się do „connection logs” (IP, timestampy, czas trwania połączenia);
„temporary logs”, „short-term logs” – czy podany jest konkretny okres retencji (np. „do 24 godzin”), czy raczej „tak długo, jak to konieczne”;
„troubleshooting data” – czy użytkownik musi się na nie aktywnie zgodzić (np. wysłanie raportu błędu), czy zbierane są domyślnie;
„aggregated or anonymized data” – czy opisano metodę anonimizacji, czy jedynie pada zapewnienie, że „nie identyfikują użytkownika”.
Im bardziej ogólnikowe kategorie i im mniej przykładów, tym większe ryzyko, że dostawca zostawił sobie szerokie pole interpretacji. Przyzwoicie przygotowana polityka prywatności opisuje wprost, jakie dokładnie dane są zbierane, w jakim celu i jak długo.
Jak zadawać sobie właściwe pytania podczas lektury
Metodyczne podejście pomaga uniknąć przeoczeń. Przy czytaniu polityki i regulaminu warto konsekwentnie odpowiadać na kilka pytań:
Czy dostawca zapisuje mój adres IP, gdy łączę się z serwerem VPN?
Szukać należy nie tylko słów „IP address”, ale również opisów typu „identifiers of your device” czy „network identifiers”. Jeżeli dokument przyznaje, że IP klienta jest logowane, trzeba sprawdzić, jak długo i w jakim celu.
Czy przechowywane są znaczniki czasu połączeń i informacje o transferze?
Frazy „connection time”, „session duration”, „bandwidth usage” to metadane, które w połączeniu z innymi źródłami potrafią zawęzić krąg podejrzanych.
Czy VPN gromadzi dane o odwiedzanych stronach lub wykorzystanych portach/protokołach?
Nawet jeśli nie ma wprost mowy o „browsing history”, czasem pojawiają się zapisy o „destination IPs” lub „traffic metadata” – to już wyraźny sygnał ostrzegawczy.
Czy jest opisany proces reagowania na nadużycia (abuse, DMCA, spam)?
Jeżeli VPN deklaruje ścisłą współpracę z podmiotami zgłaszającymi naruszenia i jednocześnie nie tłumaczy, jak identyfikuje użytkowników naruszających regulamin, można założyć, że opiera się na jakiejś formie logów.
Jaką kontrolę ma użytkownik nad swoimi danymi?
W szczególności: czy można zażądać ich usunięcia, jakie dane pozostają z konieczności (np. dane księgowe), czy przewidziano osobne ustawienia prywatności w aplikacji.
Odpowiedzi nie muszą być wprost, czasem trzeba je „wyciągnąć między wierszami”. Brak jasności w kluczowych punktach bywa równie mówiący, jak otwarte przyznanie się do logów.
Rozbieżności między dokumentami a marketingiem
Dość częsty scenariusz: strona główna krzyczy o „zero logs”, tymczasem w polityce prywatności pojawia się zapis o „storing IP addresses for a limited period for security and fraud prevention purposes”. Tego typu niespójności niekoniecznie oznaczają złą wolę, ale pokazują, że marketing i dział prawny nie rozmawiały ze sobą dostatecznie dokładnie.
Przy ocenie wiarygodności:
jeśli marketing jest bardziej restrykcyjny niż dokumenty prawne – realne ryzyko jest takie, jak wynika z dokumentów (górą jest prawnik, nie dział reklamy);
jeśli polityka prywatności jest bardzo konserwatywna („możemy przetwarzać wszystko, co konieczne”), a marketing milczy o no‑logs – zwykle oznacza to brak ambicji bycia „privacy-first”;
jeśli w polityce pojawiają się kategorie danych, które bezpośrednio przeczą hasłu „no‑logs” (np. zapisywanie IP i znaczników czasu), a jednocześnie dostawca posługuje się tym hasłem – to poważna czerwona flaga reputacyjna.
Użytkownik, który chce zminimalizować ryzyko, powinien ufać przede wszystkim temu, co jest zapisane w dokumentach mających skutki prawne, a nie w banerach reklamowych.
Klauzule o współpracy z organami ścigania
Regulaminy i polityki prywatności zawierają zwykle fragmenty dotyczące odpowiedzi na wnioski organów ścigania. Ustawodawstwa wielu państw wymagają takiej klauzuli. Z punktu widzenia prywatności istotne jest jednak jak jest ona skonstruowana.
Warto zwrócić uwagę na:
zakres jurysdykcji – czy dostawca odpowiada wyłącznie na wnioski z kraju swojej rejestracji, czy deklaruje „dobrowolną współpracę” z innymi państwami;
opis danych, które mogą być przekazane – e‑mail użytkownika, dane płatnicze, wewnętrzny identyfikator konta, czy także dane związane z ruchem (IP, czas połączenia);
obowiązek informowania użytkownika – czy w regulaminie przewidziano powiadamianie o wnioskach, gdy prawo na to pozwala, czy też firma zastrzega sobie prawo do pełnej tajemnicy;
jak często takie wnioski się pojawiają – część dostawców publikuje tzw. transparency reports z liczbą otrzymanych wniosków i zakresem wydanych danych.
Praktyczny test: jeżeli regulamin mówi o „przekazywaniu danych wymaganych prawem”, ale nigdzie nie precyzuje, jakie dane w ogóle istnieją w systemach, nie da się uczciwie ocenić skutków takiej współpracy dla użytkownika.
Źródło: Pexels | Autor: Dan Nelson
Jurysdykcja, prawo i obowiązki retencji danych
Dlaczego miejsce rejestracji ma znaczenie – i jakie ma ograniczenia
Jurysdykcja, czyli państwo (lub kilka państw), w których VPN ma siedzibę i faktycznie prowadzi działalność, wpływa na obowiązki prawne dotyczące danych. W szczególności na:
ewentualne ustawy o obowiązkowej retencji danych dla dostawców usług komunikacyjnych,
zakres i tryb dostępu służb do danych, w tym obowiązki utrwalania i przekazywania informacji,
standardy ochrony prywatności (np. RODO w UE) i związane z nimi obowiązki informacyjne.
Nie istnieje jednak „magiczna jurysdykcja”, która rozwiązuje wszystkie problemy. Popularne slogany o „poza zasięgiem 14 Eyes” są w dużej mierze skrótem myślowym. Nawet jeżeli dany kraj nie należy do formalnych sojuszy wywiadowczych, podlega innym mechanizmom współpracy międzynarodowej i presji politycznej.
Retencja danych a VPN – zarys problemu
W wielu państwach istnieją przepisy nakładające na operatorów telekomunikacyjnych obowiązek przechowywania danych o połączeniach (kto, kiedy, z jakiego numeru/IP, do kogo). Pytanie, czy i w jakim zakresie dotyczą one dostawców VPN, pozostaje często niejednoznaczne.
pośrednicy, platformy, usługi „value-added” – w niektórych krajach obejmowani obowiązkami pośrednio lub na podstawie szerokich definicji;
usługi VPN – często w szarej strefie regulacyjnej; wiele systemów prawnych nie wspomina o nich wyraźnie.
Dostawca, który uczciwie informuje o swojej sytuacji, zwykle wskazuje wprost, czy lokalne prawo:
nakłada na niego formalny obowiązek przechowywania określonych danych o połączeniach,
pozostawia mu swobodę i pozwala na politykę minimalizacji danych,
zostało przez niego zinterpretowane (po konsultacjach prawnych) jako nie dotyczące usług VPN wprost.
Przykładowo, część europejskich dostawców powołuje się na wyroki sądów unijnych ograniczające masową retencję danych i na tej podstawie utrzymuje model „no‑logs”. Inni, operujący w systemach z bardzo szerokimi definicjami usług łączności, podkreślają, że formalnie mogą być objęci żądaniami utrwalania danych dla konkretnych użytkowników.
W branży VPN często wskazuje się na kilka państw jako szczególnie przyjazne ochronie prywatności ze względu na brak obowiązkowej retencji dla VPN i stosunkowo wysokie standardy ochrony danych. W praktyce obejmuje to najczęściej:
kraje z brakiem ogólnej retencji danych lub z retencją ograniczoną i wielokrotnie kwestionowaną w sądach,
systemy z silną kontrolą sądową nad służbami i realnymi środkami zaskarżenia,
państwa o stosunkowo przejrzystym systemie prawnym, gdzie orzecznictwo jest dostępne publicznie i poddawane debacie.
Nie oznacza to, że VPN zarejestrowany w takim kraju w ogóle nie jest narażony na presję organów ścigania. Oznacza to raczej, że:
ma większą swobodę przyjmowania restrykcyjnej polityki no‑logs,
ryzyko potajemnego nakazu masowej retencji jest mniejsze (choć nigdy zerowe),
istnieje szansa na niezależną kontrolę sądową w razie sporu.
Przy ocenie jurysdykcji wypada też rozważyć, czy dostawca ogranicza się do jednego państwa, czy też ma biura, spółki-córki i kluczową infrastrukturę w wielu krajach. Różne systemy prawne mogą wówczas pozostawać wobec niego konkurencyjne, a czasem – sprzeczne.
Ukryta obecność w innych krajach
Nawet jeśli firma jest zarejestrowana w jednym, „bezpiecznym” kraju, jej realna obecność może być dużo szersza: biura wsparcia w innym państwie, kontrakty z operatorami centrów danych w kilku jurysdykcjach, pracownicy rozproszeni po świecie. To poszerza spektrum potencjalnych zobowiązań i punktów nacisku.
Praktyczne kroki przy analizie:
sprawdzenie stopki kontaktowej (adresy biur, kraj rejestracji spółki),
przejrzenie informacji dla prasy i stron „About us” – często wymieniane są lokalizacje kluczowych zespołów,
analiza listy centrów danych (czasem publikowanej jako mapa serwerów) wraz z informacją, czy są to serwery fizyczne czy wirtualne w publicznych chmurach.
Jeżeli krytyczne elementy infrastruktury znajdują się w krajach z agresywnymi przepisami nadzorczymi, formalna siedziba w „bezpiecznej” jurysdykcji nie rozwiązuje problemu. Liczy się to, gdzie faktycznie leżą dyski (lub pamięć RAM) i jakie przepisy obowiązują operatorów tych serwerowni.
Prawo a praktyka – co może, a czego nie może wymusić państwo
Często pojawia się pytanie, czy państwo może „zmusić” VPN do rozpoczęcia logowania danych na przyszłość. Odpowiedź zależy od jurysdykcji, lecz w wielu systemach prawnych takie żądanie jest możliwe – czy to wprost, poprzez nakaz sądowy, czy pośrednio, poprzez przepisy o retencji danych dla wskazanego podmiotu.
Przymusowe logowanie a model „no‑logs”
Jeżeli prawo pozwala na wydanie nakazu rozpoczęcia logowania, kluczowe są dwie kwestie: zakres takiego obowiązku oraz to, czy dostawca może o nim informować. Z perspektywy użytkownika różnica między „nie logujemy nic” a „od dziś logujemy wybrane dane dla wskazanych kont” jest zasadnicza, ale często niewidoczna z zewnątrz.
Typowe scenariusze:
nakaz dotyczący konkretnego użytkownika – sąd lub inny organ zobowiązuje dostawcę do utrwalania informacji o jednym koncie (np. IP wejściowe, znaczniki czasu, wybrane porty). W wielu krajach taki nakaz może być objęty tajemnicą;
nakaz o charakterze ogólnym – żądanie wprowadzenia stałego logowania na poziomie całej usługi; częściej spotykane w państwach o słabej kontroli sądowej nad służbami;
„dobrowolna współpraca” – presja polityczna lub nieformalne oczekiwanie, aby firma „tymczasowo” wprowadziła logowanie bez wyraźnej podstawy ustawowej.
Dostawcy, którym rzeczywiście zależy na modelu no‑logs, starają się minimalizować skutki takich sytuacji poprzez:
utrzymywanie architektury technicznej, w której stałe logowanie wymagałoby istotnej przebudowy systemu,
wprowadzanie warrant canaries lub raportów przejrzystości sygnalizujących, że pojawiły się żądania wykraczające poza standard,
ograniczanie ilości osób mających uprawnienia do wprowadzania zmian w logowaniu i konfiguracji serwerów.
Jeżeli usługa reklamuje się jako „no‑logs”, a jednocześnie technicznie działa na typowej infrastrukturze hostingu współdzielonego bez kontroli nad logami systemowymi i sieciowymi, zdolność do realnego oporu wobec przymusowego logowania jest mocno ograniczona.
Źródło: Pexels | Autor: Dan Nelson
Audyty, sprawy sądowe i incydenty jako twarde punkty odniesienia
Znaczenie niezależnych audytów „no‑logs”
Coraz więcej dostawców VPN zamawia niezależne audyty swoich systemów pod kątem logowania. Dla użytkownika nie chodzi tu tylko o sam fakt przeprowadzenia audytu, ale o jego zakres, metodologię i przejrzystość wyników.
Przy analizie audytu przydają się następujące pytania:
kto przeprowadził audyt – renomowana firma bezpieczeństwa, lokalny konsultant, czy nieznany podmiot bez historii podobnych badań,
jaki był formalny cel – weryfikacja polityki no‑logs, testy penetracyjne, zgodność z wytycznymi bezpieczeństwa, czy ogólne „sprawdzenie infrastruktury”,
jakie obszary objęto – tylko kilka serwerów z wybranych lokalizacji, czy też całą infrastrukturę (w tym panele administracyjne, systemy billingowe, logi chmurowe),
czy raport jest publiczny – pełny tekst, streszczenie, czy jedynie krótkie oświadczenie marketingowe typu „audyt potwierdził brak logów”.
Audyt ma większą wartość, gdy audytor opisuje konkretnie:
jakie kategorie danych mogłyby być zbierane na kolejnych etapach (aplikacja, serwer, system płatności) i czy faktycznie są gromadzone,
jak wygląda konfiguracja logowania na serwerach VPN (zarówno w warstwie aplikacji, jak i systemu operacyjnego),
jakie mechanizmy istnieją, by uniemożliwić nieautoryzowane włączenie logów.
Krótka notka prasowa bez szczegółów technicznych i bez podpisu konkretnego audytora to raczej element promocji niż mocny dowód. Nie przekreśla to usługi, lecz wymaga większej ostrożności przy wyciąganiu wniosków.
Sprawy sądowe i precedensy z udziałem dostawców VPN
Drugim istotnym źródłem informacji są publiczne sprawy sądowe, w których VPN występuje jako strona lub podmiot zobowiązany do przekazania danych. Choć nie każdy przypadek jest nagłaśniany, te, o których wiadomo, pozwalają oddzielić deklaracje od praktyki.
W szczególności znaczenie mają sytuacje, gdy:
dostawca został zmuszony do przekazania danych, które przeczą deklaracjom „no‑logs” – np. pojawiają się logi IP i dokładne znaczniki czasu,
sąd wprost odwołuje się do polityki prywatności lub materiałów marketingowych, wskazując na rozbieżności z rzeczywistym zakresem danych,
firma otwarcie informuje, że nie mogła przekazać żądanych danych, ponieważ ich nie przechowuje – i znajduje to odzwierciedlenie w aktach sprawy.
Dla użytkownika szczególnie cenne są orzeczenia i dokumenty, które:
zawierają opis techniczny (choćby skrótowy) sposobu działania usługi,
pokazują, czy dostawca informował o wnioskach służb i jak się do nich odnosił,
przedstawiają stanowisko sądu co do tego, czy model „no‑logs” jest zgodny z lokalnym prawem.
Jeżeli o danej usłudze VPN wiadomo, że w przeszłości dostarczyła dane użytkownika mimo publicznych deklaracji „nie logujemy niczego”, jest to poważny sygnał ostrzegawczy – nawet jeżeli od tamtej pory zmieniła właściciela, jurysdykcję czy infrastrukturę.
Incydenty bezpieczeństwa jako niezamierzone „testy” modelu no‑logs
Wycieki danych, przejęcie serwerów czy błędna konfiguracja paneli administracyjnych często ujawniają więcej niż oficjalne oświadczenia. W takich sytuacjach można zaobserwować, jakie informacje rzeczywiście „leżały na dysku”, a jakie istniały jedynie na poziomie hipotez.
Przy analizie takich incydentów istotne są m.in.:
rodzaj ujawnionych danych – logi systemowe, listy kont, pliki konfiguracyjne, klucze wewnętrzne,
zasięg zdarzenia – pojedynczy serwer wynajęty w zewnętrznym centrum danych czy cała platforma zarządzająca,
reakcja dostawcy – czy opublikowano szczegółowe techniczne wyjaśnienie, czy ograniczono się do ogólnego komunikatu o „izolowanym incydencie”.
Zdarzało się, że po przejęciu serwerów okazywało się, iż konfiguracja była zgodna z modelem no‑logs (brak logów ruchu, brak identyfikatorów wiążących konkretne sesje z kontem). Zdarzały się też przypadki przeciwne, gdzie odnaleziono szczegółowe logi, których istnieniu wcześniejsze deklaracje zaprzeczały. Tego rodzaju „testy w warunkach bojowych” bywają dla analityka prywatności bardziej wymowne niż najstaranniej zredagowany regulamin.
Jak interpretować brak audytów i głośnych spraw
Brak publicznie znanych incydentów ani audytów nie oznacza automatycznie, że dostawca jest idealny. Wiele firm działa w niszy, ma niewielką skalę i zwyczajnie nie znalazło się jeszcze w centrum poważnego sporu z organami ścigania czy grupami badawczymi.
W takiej sytuacji specyficzną rolę odgrywa:
konsekwencja komunikacji – czy język dotyczący logów jest spójny na stronie, w regulaminach i w odpowiedziach supportu,
poziom szczegółowości – czy dostawca potrafi opisać swój model techniczny i prawny, czy ogranicza się do ogólnikowego „dbamy o twoją prywatność”,
skala i model biznesowy – niewielka usługa nastawiona na prywatność i finansowana bezpośrednio z subskrypcji ma inne bodźce niż darmowy VPN utrzymujący się z reklam.
Jeżeli brak twardych danych z audytów czy spraw sądowych, pozostaje ostrożna interpretacja: nie da się potwierdzić ani skutecznego modelu no‑logs, ani jego braku. Decyzja o zaufaniu opiera się wówczas na ocenie ryzyka, potrzeb użytkownika i porównaniu z innymi dostawcami, u których materiału dowodowego jest więcej.
Testy techniczne od strony użytkownika: co da się sprawdzić samodzielnie
Co można realnie zweryfikować „od zewnątrz”
Użytkownik nie ma dostępu do wewnętrznych logów ani konfiguracji serwerów VPN, dlatego zakres możliwych testów jest ograniczony. Mimo to kilka prostych kroków pozwala ocenić, czy usługa zachowuje się w sposób zgodny z deklaracjami technicznymi i czy redukuje najbardziej oczywiste ryzyka wycieku danych.
Da się w szczególności sprawdzić:
czy rzeczywisty adres IP jest ukrywany i konsekwentnie zastępowany adresem serwera VPN,
czy nie dochodzi do wycieków DNS ani routingu poza tunel VPN,
czy połączenie używa silnych protokołów i algorytmów kryptograficznych,
czy aplikacja zachowuje się spójnie z deklaracjami (np. kill switch, brak ruchu poza tunelem, brak niepotrzebnych połączeń telemetrycznych).
Choć testy te nie odpowiadają wprost na pytanie „czy VPN nie loguje”, pozwalają przynajmniej ocenić, czy dostawca działa rzetelnie na tym poziomie, który jest dla użytkownika obserwowalny. Jeżeli usługa „oszukuje” przy prostych rzeczach, takich jak wycieki DNS czy brak działającego kill switcha mimo reklamy, trudno zakładać, że w obszarze logów jest wzorem konsekwencji.
Sprawdzanie adresu IP i geolokalizacji
Podstawowy test polega na porównaniu informacji o IP i lokalizacji przed włączeniem VPN i po jego uruchomieniu. Można to zrobić poprzez strony typu „what is my IP” czy „IP geolocation”.
Przydatne kroki:
zanotowanie adresu IP i kraju bez VPN,
włączenie wybranego serwera (np. w innym kraju) i ponowne sprawdzenie tych informacji,
porównanie wyników z różnych serwisów (czasem bazy geolokalizacyjne są nieaktualne).
Jeżeli po włączeniu VPN wciąż widoczne jest IP przydzielone przez lokalnego ISP, oznacza to poważną awarię lub błędną konfigurację aplikacji. W praktyce takie sytuacje zdarzają się rzadko, ale zdarzały się np. przy błędach aktualizacji klienta lub ręcznej konfiguracji w routerze.
Testy DNS i wycieki poza tunel
Znacznie bardziej subtelnym problemem są wycieki DNS – sytuacje, w których zapytania o nazwy domen (np. „example.com”) omijają tunel VPN i trafiają bezpośrednio do serwerów DNS operatora lub dostawcy systemu (np. Google, Cloudflare, lokalny ISP). Dla wielu analiz to właśnie zapis zapytań DNS jest cenniejszy niż sam adres IP.
Do testów można użyć publicznych serwisów do wykrywania przecieków DNS oraz narzędzi wbudowanych w system (np. nslookup, dig). W praktyce sprawdzenie wygląda tak:
włączony VPN, otwarty serwis testujący DNS leak,
kilkukrotne odświeżenie strony i obserwacja listy serwerów DNS, które widzi serwis,
porównanie ich z listą serwerów DNS ISP (często widocznych w konfiguracji routera).
Jeżeli w wynikach widać serwery powiązane z lokalnym operatorem lub krajem użytkownika, podczas gdy wybrany serwer VPN znajduje się w innej jurysdykcji, jest to czytelny sygnał, że konfiguracja DNS nie jest w pełni tunelowana. Zdarza się to zwłaszcza w instalacjach ręcznych (OpenVPN/WireGuard na routerze) i przy domyślnych ustawieniach systemu Windows.
Kill switch, wyciek przy zerwaniu połączenia i ruch poza aplikacją
Następny element to zachowanie systemu w momencie przerwania połączenia z serwerem VPN. Awarie połączenia zdarzają się zawsze; kluczowe jest to, czy w takich chwilach ruch wychodzi do Internetu bez ochrony.
Test można przeprowadzić w prosty sposób:
włączyć VPN wraz z funkcją kill switch (jeżeli jest dostępna),
uruchomić narzędzie do pomiaru ruchu sieciowego (np. wbudowany monitor systemu, tcpdump, Wireshark),
spowodować utratę połączenia z serwerem (np. zmiana sieci Wi‑Fi, wyłączenie interfejsu sieciowego na chwilę),
obserwować, czy jakikolwiek ruch do Internetu wychodzi poza interfejs tunelu VPN.
Jeżeli po zerwaniu tunelu połączenia nadal wychodzą z systemu przez zwykły interfejs sieciowy, kill switch w praktyce nie działa lub jest źle skonfigurowany. W takim układzie w razie awarii serwera część aktywności użytkownika może zostać powiązana z jego realnym IP, nawet jeśli większość sesji była chroniona.
Dodatkowo można przeanalizować ruch wychodzący z aplikacji VPN sam w sobie. Zdarzało się, że klienci wysyłali statystyki do zewnętrznych serwisów analitycznych, w tym identyfikatory urządzeń lub nazwy hosta. Choć nie są to klasyczne „logi ruchu”, tworzą kolejny punkt zaczepienia dla korelacji danych.
Testowanie aplikacji mobilnych i uprawnień
Najczęściej zadawane pytania (FAQ)
Co to dokładnie znaczy, że VPN jest „bez logów”?
Określenie „VPN bez logów” nie ma jednej, prawnej definicji. Zwykle oznacza, że dostawca nie zapisuje danych pozwalających powiązać Twoją aktywność w sieci z konkretnym kontem lub adresem IP. W praktyce chodzi przede wszystkim o brak logów metadanych połączeń (IP użytkownika, znaczniki czasu, przypisany IP serwera VPN) oraz logów treści (odwiedzane adresy URL, logi DNS).
Część firm mimo hasła „no-logs” nadal zbiera zanonimizowane logi eksploatacyjne, np. obciążenie serwerów czy łączną liczbę użytkowników online. Jeżeli z takich danych nie da się odtworzyć, kto i co robił w sieci, nie są one tak problematyczne z punktu widzenia prywatności.
Jak samodzielnie sprawdzić, czy VPN loguje mój adres IP i czas połączenia?
Od strony użytkownika nie da się „zajrzeć” do systemów logowania dostawcy, ale można ograniczyć niepewność. Podstawowy krok to dokładne przejrzenie polityki prywatności i regulaminu pod kątem sformułowań typu „we collect IP address”, „connection timestamps”, „session data”. Jeśli pojawia się tam Twój adres IP, czasy połączeń lub przypisany IP serwera VPN, to są to istotne logi.
Drugi poziom to sygnały zewnętrzne: czy firma przeszła niezależny audyt „no-logs” (i jak szczegółowo opisano jego zakres), jakie ma zaplecze prawne (jurysdykcja bez obowiązkowej retencji danych) oraz jak zachowuje się aplikacja w testach technicznych (brak wycieków IP/DNS/WebRTC, brak podejrzanych połączeń do zewnętrznych serwisów analitycznych). Te elementy nie dadzą 100% pewności, ale pomagają ocenić prawdopodobieństwo logowania.
Jakie logi VPN są najbardziej niebezpieczne dla mojej prywatności?
Najbardziej wrażliwe są logi, które pozwalają przejść pełną ścieżkę: „konkretny użytkownik – konkretne połączenie – konkretna aktywność”. Z reguły chodzi o połączenie kilku typów danych:
oryginalny adres IP użytkownika (od dostawcy internetu),
znaczniki czasu rozpoczęcia i zakończenia sesji VPN,
przypisany adres IP serwera VPN i jego lokalizację,
logi DNS lub adresy URL odwiedzanych stron.
Jeżeli któryś z tych elementów jest zapisywany w sposób umożliwiający połączenie z Twoim kontem (np. przez e-mail lub metodę płatności), Twoja anonimowość staje się w praktyce mocno ograniczona. Anonimowe, zagregowane statystyki techniczne są pod tym względem znacznie mniej ryzykowne.
Czy mogę w 100% upewnić się, że mój VPN nie prowadzi logów?
Nie. Z perspektywy zwykłego użytkownika osiągalny jest tylko poziom „wysokiego prawdopodobieństwa”, a nie absolutnej pewności. Nie masz dostępu do pełnej konfiguracji serwerów, systemów SIEM czy wewnętrznych procedur firmy; nie widzisz też, czy polityka nie zmieni się nagle po cichej aktualizacji dokumentów.
Możesz natomiast złożyć obraz z wielu elementów: spójnej i precyzyjnej polityki prywatności (wprost wykluczającej logowanie IP, timestampów i historii ruchu), niezależnych audytów, historii działania firmy (np. znane sprawy sądowe, w których nie przekazano logów) oraz testów technicznych aplikacji. Im więcej tych „klocków” wskazuje w jednym kierunku, tym rozsądniej jest uznać, że VPN prawdopodobnie nie loguje w sposób ryzykowny.
Na co zwrócić uwagę w polityce prywatności VPN przy haśle „no-logs”?
Kluczowe są konkretne sformułowania, a nie samo hasło marketingowe. W dokumentach szukaj jasnych, negatywnych deklaracji typu: „nie zbieramy i nie przechowujemy adresów IP użytkowników”, „nie zapisujemy znaczników czasu połączeń”, „nie logujemy historii odwiedzanych stron ani zapytań DNS”.
Z ostrożnością traktuj zwroty: „no traffic logs”, „no activity logs”, „diagnostic data”, „temporary logs for abuse prevention”, jeżeli nie są dokładnie doprecyzowane. Często oznaczają one, że część metadanych połączeń jest jednak zbierana. Jeżeli firma jednocześnie przyznaje, że przechowuje IP i timestampy przez określony czas, to z prawnego punktu widzenia ma logi, choć marketing może przedstawiać to inaczej.
Czy niezależny audyt „no-logs” gwarantuje, że VPN nie loguje?
Audyt zdecydowanie podnosi poziom zaufania, ale nie jest gwarancją absolutną. Zwykle ma charakter punktowy: audytor sprawdza infrastrukturę i procedury w określonym momencie, według ustalonego zakresu. To bardziej zdjęcie niż film – pokazuje stan na dzień badania, nie ciągły nadzór nad firmą.
Przy ocenie audytu warto zwrócić uwagę, kto go przeprowadził (renomowana firma czy anonimowy podmiot), jaki był jego zakres (czy obejmował realne logi na serwerach, czy tylko dokumentację) oraz czy opublikowano szczegółowy raport. Im bardziej konkretny i techniczny opis, tym większa szansa, że audyt realnie weryfikował brak logów, a nie tylko ogólne deklaracje marketingowe.
