Co naprawdę anonimizuje skracanie adresu IP

Odrzucenie ostatniego oktetu to typowa odpowiedź na pytanie o adresy IP i jest to odpowiedź rozsądna. Prawie nigdy nie następuje po niej krok drugi: podanie, jak duża jest grupa, w której odwiedzający teraz znika. Środek traktuje się jak przełącznik – zamaskowane albo niezamaskowane – podczas gdy jest on suwakiem, a to, gdzie ten suwak stoi, rozstrzyga, czy w ogóle cokolwiek osiągnięto.

Liczby są na tyle niewielkie, że da się je zapamiętać, i warto mieć je pod ręką, gdy następnym razem ktoś zapyta, czy dane są już anonimowe. Zwykle nie są, i nie jest to argument przeciwko skracaniu – tylko przeciwko zdaniu, które zwykle po nim pada.

Jak duża jest naprawdę pozostała grupa

Skraca się w bitach, a każdy odrzucony bit podwaja liczbę adresów dzielących zapisaną wartość. Odrzucenie całego oktetu zostawia 256, co brzmi jak tłum, dopóki nie zestawi się tego z tym, co odpowiada pojedynczemu adresowi.

To przy środkowym wierszu zwykle wybucha dyskusja. 256 adresów to nie 256 osób: blok mieszkaniowy u operatora rozdziela się na kilkadziesiąt łączy naraz, a za NAT firmy cały budynek wychodzi do sieci przez jeden adres. W jedną stronę grupa jest mniejsza, niż sugeruje liczba, w drugą znacznie większa – i żadnej z tych rzeczy nie widać w samych danych.

Dlatego skracanie najlepiej opisywać tym, czym jest: mierzonym w bitach obniżeniem dokładności, które zmniejsza ryzyko, nie znosząc powiązania z osobą. Zakres /24, znacznik czasu z dokładnością do sekundy i identyfikator przeglądarki są razem na tyle wąskie, że organy nadzorcze traktowały tę kombinację jako dane osobowe, a maskowanie ostatniego oktetu niczego w tym nie zmienia.

Dlaczego hasz nie jest alternatywą

Propozycja pada na co drugim spotkaniu: zapisać hasz zamiast adresu, wtedy wartość będzie nieczytelna. Nieczytelna jest, anonimowa nie – bo przestrzeń, z której pochodzi, jest maleńka.

IPv4 obejmuje około 4,3 miliarda adresów. Zwykła maszyna liczy SHA-256 w tempie rzędu setek milionów haszy na sekundę, pełna tablica adresów i ich haszy powstaje więc w kilka minut i mieści się na laptopie. Zahaszowany adres IPv4 nie jest zatem pseudonimem, lecz adresem zapisanym w innym alfabecie, a wyszukanie, które ten zapis odwraca, to błąd zaokrąglenia w nakładzie pracy.

Sól na każde zdarzenie niszczy tablicę, ale niszczy też jedyny powód, dla którego wartość zachowano: dwa zdarzenia tego samego odwiedzającego przestają do siebie pasować. Sól stała zachowuje przypisanie i zamienia tablicę jedynie w nieco droższą, policzoną raz i używaną ponownie dla każdego rekordu tego samego zbioru. Naprawdę użyteczny pozostaje hasz z adresu już skróconego – wtedy haszowana jest grupa 256 adresów, a ochrona pochodzi ze skrócenia, a nie z hasza.

IPv6 skraca inaczej, niż wygląda

Reguła przeniesiona z IPv4 – odrzucić ostatnią ćwiartkę – przy IPv6 nie daje prawie nic, bo adres zbudowany jest inaczej. Łączu przydziela się zwykle całe /64, a każde urządzenie za nim wymyśla sobie własne zakończenie wewnątrz tego bloku. Skrócenie adresu do jego /64 usuwa więc urządzenie, a zachowuje łącze – dokładnie ten identyfikator, o który chodziło.

Sensowne skracanie zaczyna się dopiero o stopień dalej w lewo. Zakres /56 albo /48 to tyle, ile dostawca przydziela lokalizacji, tam więc zaczyna się grupa większa niż jedno gospodarstwo. Reguła Google dla IPv6 – wyzerowanie ostatnich 80 bitów, po którym zostaje /48 – leży właśnie w tym miejscu, a nie przy optycznie odpowiadającej ćwiartce.

Jeden przypadek przechodzi przez to wszystko niezauważony: adres IPv4 w zapisie IPv6, notowany jako ::ffff:203.0.113.45. Reguły maskowania liczące od prawej pozostawiają osadzony adres znacznie dłużej, niż można oczekiwać, a wartość wyglądająca jak zamaskowany adres IPv6 może nieść pełny adres IPv4.

W którym miejscu przepływu leży skracanie

Maskowanie jest maskowaniem tylko wtedy, gdy następuje, zanim adres opuści własny obszar, a to rozróżnienie dzieli dwa przypadki opisywane skądinąd tymi samymi słowami.

W układzie serwerowym – w Conversions API, w kontenerze na własnej infrastrukturze – adres jest polem w ładunku. To, co zostanie wpisane w client_ip_address, jest tym, czego dowie się odbiorca; skrócenie przed wysłaniem usuwa więc ostatni oktet ostatecznie. To przypadek, w którym środek dotrzymuje obietnicy.

Przy tagu działającym w przeglądarce jest odwrotnie. Zapytanie idzie wprost do dostawcy, a adres, który on widzi, to adres połączenia, a nie ten z ładunku. Zamaskowana wartość w parametrze zmienia to, co znajdzie się w raporcie; nie zmienia tego, co dotarło na brzeg sieci dostawcy. Dopiero proxy przez własną domenę przesuwa tę granicę – i wtedy dostawca widzi adres własnego serwera.

Do czego skracanie naprawdę służy

Cel łatwiej obronić, gdy nazwie się go dokładnie. Zakres /24 nadal prowadzi do miasta, a często do dzielnicy, i właśnie o to chodzi: analiza geograficzna, dla której adres zebrano, przechodzi przez cięcie niemal bez zmian, podczas gdy wartość wskazująca pojedyncze łącze znika. Do tej wymiany środek jest dobrze dobrany, a do twierdzenia, że dane są już anonimowe – źle.

Dokumentacja wynika z tego samego zdania. Rejestr podający długość maski, miejsce w przepływie i wynikającą z tego wielkość grupy opisuje coś sprawdzalnego. Taki, który odnotowuje „adresy IP są anonimizowane”, opisuje przełącznik, którego nie ma – a pierwszym pytaniem przy każdej kontroli będzie to, od którego zaczął się ten tekst: jak duża jest grupa.