Największy operator telekomunikacyjny — Vodafone — planuje wdrożyć system śledzenia aktywności swoich klientów na poziomie własnej infrastruktury. Aktualnie do projektu TrustPid dołączył Deutsche Telekom (największy operator w Unii Europejskiej) oraz trwają rozmowy z innymi dostawcami. Technicznie nie wygląda to szczególnie skomplikowanie i właściwie każdy ISP mógłby to zastosować w każdej chwili, aczkolwiek opis nie jest niestety dokładny. Zgodnie z komentarzem na digismak.com klientom końcowym będą przydzielane zmienne adresy IP (co już jest standardem, ale u niektórych operatorów stały adres IP to dodatkowy koszt), następnie zarejestrowana aktywność będzie przypisywana do każdego z klientów.
TrustPid: super-ciasteczko
Na dedykowanej witrynie trustpid.com (już blokowanej przez uBlock Origin) również nie zamieszczono bardziej szczegółowego opisu działania. Dowiadujemy się jednak, że jako klienci dostawców (dostęp do panelu jest ograniczony) mamy pełny wgląd do uzyskanych o nas danych, jak również możemy nimi zarządzać, w tym całkowicie wyłączyć rejestrowanie naszej aktywności w ramach TrustPid:
VPN nabiera nowego znaczenia
Skuteczną metodą zapobiegania gromadzeniu danych przez dostawców Internetu jest korzystanie z sieci VPN. W ten sposób tworzy się „wirtualny tunel” do serwerów danego operatora VPN i ruch jest obsługiwany w całości przez te serwery. W związku z tym zmienia się nasz wyjściowy adres IP, co niektórym służy do omijania pewnych restrykcji, np. ograniczenia zasobu dla wybranego państwa. Oczywiście dostawcy VPN także zbierają różne dane, bo w ten sposób wykrywa się nawet problemy w działaniu. Tutaj pojawia się pytanie, czy wolimy, aby dane zbierał nasz (często lokalny) czy zagraniczny operator.
Jak wspomniałem, nie jest to żadna nowość w temacie działania dostawców Internetu. Operatorzy muszą logować aktywność – i w „normalnej” sytuacji jest to właśnie adres IP + odwiedzane domeny.
W przypadku ruchu HTTP można dodatkowo odczytywać przesyłane dane, natomiast zdecydowana większość serwisów, szczególnie tam, gdzie jest dostępne logowanie, stosuje protokół HTTPS, czyli „cały” ruch jest szyfrowany.
Rozwinę jeszcze kwestię braku pełnego szyfrowania przy HTTPS. Aby przeciwdziałać obniżeniu poziomu protokołu stosuje się mechanizm HSTS. Dla przykładu do konfiguracji serwera dodaje się przekierowanie ruchu z HTTP na HTTPS, tak aby dany serwis był dostępny wyłącznie szyfrowanym ruchem „po HTTPS”, co można to zrobić w ten sposób np. dla serwera WWW (NGINX):
server {
listen 80;
server_name avlab.pl;
return 301 https://avlab.pl$request_uri; }
server {
listen 443 ssl;
server_name avlab.pl;
… (należy wskazać certyfikat + dalsza konfiguracja dla serwisu)Odwiedzenie http://avlab.pl generuje pojedyncze nieszyfrowane żądanie, zwracające w nagłówku Location https://avlab.pl:
HTTP/1.1 301 Moved Permanently
Date: Mon, 06 Jun 2022 16:09:01 GMT
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Mon, 06 Jun 2022 17:09:01 GMT
Location: https://avlab.pl/
…
Zatem zabezpieczeniem przed „downgrade HTTPS” jest lista HSTS Preload, która informuje przeglądarki, że daną domenę należy pobierać wyłącznie z wykorzystaniem HTTPS.
Globalne śledzenie
Opisywany projekt może budzić wątpliwości, mimo wszystko nie wydaje mi się on wyjątkowym zagrożeniem dla prywatności. Skupiłbym się raczej na treściach, jakie udostępniamy w Internecie, bo wielokrotnie mówią one o nas więcej niż dane zebrane przez różne skrypty do profilowania. Oczywiście skrypty warto blokować (np. poprzez rozszerzenie uBlock Origin czy na poziomie DNS jako Pi-hole). Zwrócę też uwagę, że dostawca Internetu „widzi” ruch ze wszystkich urządzeń w naszej sieci jako pojedynczy adres IP, który przypisał do swojego abonenta.
