Was das Kürzen einer IP-Adresse wirklich anonymisiert

Das letzte Oktett zu verwerfen ist die übliche Antwort auf die IP-Frage, und sie ist vernünftig. Was fast nie folgt, ist der zweite Schritt: die Angabe, wie groß die Gruppe ist, in der ein Besucher nun verschwindet. Die Maßnahme wird wie ein Schalter behandelt – maskiert oder nicht maskiert – dabei ist sie ein Regler, und wo dieser Regler steht, entscheidet darüber, ob überhaupt etwas erreicht wurde.

Die Zahlen sind klein genug, um sie im Kopf zu behalten, und es lohnt sich, sie parat zu haben, wenn das nächste Mal jemand fragt, ob die Daten damit anonym sind. Meist sind sie es nicht, und das ist kein Argument gegen die Kürzung – nur gegen den Satz, der ihr gewöhnlich folgt.

Wie groß die verbleibende Gruppe wirklich ist

Gekürzt wird in Bit, und jedes verworfene Bit verdoppelt die Zahl der Adressen, die sich den gespeicherten Wert teilen. Ein ganzes Oktett zu verwerfen lässt 256 übrig, was nach Menge klingt, bis der Vergleich damit ansteht, wofür eine einzelne Adresse steht.

An der mittleren Zeile entzündet sich üblicherweise die Diskussion. 256 Adressen sind keine 256 Personen: ein Wohnblock beim Provider wird an einige Dutzend Anschlüsse zugleich vergeben, und hinter dem NAT einer Firma verlässt das ganze Gebäude das Netz über eine Adresse. In die eine Richtung ist die Gruppe kleiner, als die Zahl vermuten lässt, in die andere weit größer – und beides steht nicht in den Daten.

Deshalb lässt sich die Kürzung am besten als das beschreiben, was sie ist: eine in Bit bemessene Senkung der Genauigkeit, die das Risiko verringert, ohne den Personenbezug zu beenden. Ein /24, ein sekundengenauer Zeitstempel und eine Browserkennung sind zusammen eng genug, dass Aufsichtsbehörden die Kombination als personenbezogen behandelt haben, und daran ändert keine Maskierung des letzten Oktetts etwas.

Warum ein Hash keine Alternative ist

Der Vorschlag kommt in jeder zweiten Besprechung: statt der Adresse den Hash speichern, dann ist der Wert unlesbar. Unlesbar ist er, anonym ist er nicht – weil der Raum, aus dem er stammt, winzig ist.

IPv4 umfasst rund 4,3 Milliarden Adressen. Eine gewöhnliche Maschine rechnet SHA-256 in der Größenordnung von hunderten Millionen Hashes je Sekunde, die vollständige Tabelle aus Adresse und Hash entsteht also in Minuten und passt auf einen Laptop. Ein gehashtes IPv4 ist damit kein Pseudonym, sondern die Adresse in einem anderen Alphabet, und das Nachschlagen, das die Umwandlung aufhebt, ist ein Rundungsfehler an Aufwand.

Ein Salz je Ereignis zerstört die Tabelle, zerstört aber auch den einzigen Grund, aus dem der Wert aufbewahrt wurde: zwei Ereignisse desselben Besuchers passen nicht mehr zusammen. Ein festes Salz erhält die Zuordnung und macht aus der Tabelle lediglich eine etwas teurere, die einmal gerechnet und für jeden Datensatz desselben Bestandes wiederverwendet wird. Wirklich brauchbar bleibt der Hash über die bereits gekürzte Adresse – dann wird die Gruppe von 256 gehasht, und der Schutz kommt aus der Kürzung, nicht aus dem Hash.

IPv6 kürzt anders, als es aussieht

Die aus IPv4 übernommene Regel – das letzte Viertel verwerfen – bewirkt bei IPv6 fast nichts, weil die Adresse anders aufgebaut ist. Einem Anschluss wird üblicherweise ein ganzes /64 zugeteilt, und jedes Gerät dahinter denkt sich innerhalb dieses Blocks seinen eigenen Schwanz aus. Eine Adresse auf ihr /64 zu kürzen entfernt also das Gerät und behält den Anschluss – genau die Kennung, auf die es ankam.

Sinnvoll wird die Kürzung erst eine Stufe weiter links. Ein /56 oder /48 ist das, was ein Anbieter einem Standort zuweist, dort beginnt also eine Gruppe, die größer als ein Haushalt ist. Die Regel von Google für IPv6 – die letzten 80 Bit auf null zu setzen, womit ein /48 übrig bleibt – sitzt an dieser Stelle und nicht beim optisch entsprechenden Viertel.

Ein Fall übersteht das alles unbemerkt: eine IPv4-Adresse in IPv6-Schreibweise, notiert als ::ffff:203.0.113.45. Maskierungsregeln, die von rechts zählen, lassen die eingebettete Adresse deutlich länger stehen als erwartet, und ein Wert, der wie eine maskierte IPv6-Adresse aussieht, kann eine vollständige IPv4-Adresse tragen.

Wo im Datenfluss die Kürzung sitzt

Maskierung ist nur dann Maskierung, wenn sie geschieht, bevor die Adresse den eigenen Bereich verlässt, und diese Unterscheidung trennt zwei Fälle, die sonst mit denselben Worten beschrieben werden.

In einem serverseitigen Aufbau – einer Conversions API, einem Container auf eigener Infrastruktur – ist die Adresse ein Feld in einer Nutzlast. Was in client_ip_address geschrieben wird, ist das, was der Empfänger erfährt; vor dem Absenden zu kürzen entfernt das letzte Oktett also endgültig. Das ist der Fall, in dem die Maßnahme hält, was sie verspricht.

Bei einem Tag, das im Browser läuft, ist es umgekehrt. Die Anfrage geht unmittelbar zum Anbieter, und die Adresse, die er sieht, ist die der Verbindung und nicht die in der Nutzlast. Ein maskierter Wert in einem Parameter ändert, was im Bericht steht; er ändert nicht, was am Rand des Anbieternetzes ankam. Erst ein Proxy über die eigene Domain verschiebt diese Grenze – und dann sieht der Anbieter die Adresse des eigenen Servers.

Wofür die Kürzung tatsächlich gut ist

Der Zweck lässt sich leichter verteidigen, wenn er genau benannt wird. Ein /24 führt weiterhin auf eine Stadt und oft auf einen Stadtteil, und genau darum geht es: die geografische Auswertung, für welche die Adresse erhoben wurde, übersteht den Schnitt nahezu unverändert, während der Wert, der einen einzelnen Anschluss bezeichnet, verschwindet. Für diesen Tausch ist die Maßnahme gut gewählt und für die Behauptung, die Daten seien nun anonym, schlecht.

Die Dokumentation folgt aus demselben Satz. Ein Verzeichnis, das die Maskenlänge, die Stelle im Datenfluss und die daraus folgende Gruppengröße nennt, beschreibt etwas Überprüfbares. Eines, das „IP-Adressen werden anonymisiert” festhält, beschreibt einen Schalter, den es nicht gibt – und die erste Rückfrage bei jeder Prüfung ist die, mit der dieser Beitrag begonnen hat: wie groß ist die Gruppe.