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

Skracanie odbywa się w bitach: każdy odrzucony bit podwaja liczbę adresów, które mają tę samą zapisaną wartość. Po odrzuceniu całego oktetu wspólną wartość ma 256 adresów. Żeby ocenić znaczenie tej liczby, trzeba też uwzględnić, co reprezentuje pojedynczy adres.

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ż wynikałoby z 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.