Supercookies und E-Tags werden uns alle töten

Cookies! Cookies!

Eine neue Schreckensmeldung von unsterblichen "Zombie-Cookies", allumfassender, heimlicher Netzkontrolle, der man sich nicht entziehen kann und die einen, bis hin zur Blutgruppe, Kontonummer und Länge der durchschnittlichen Bremsspur in der Unterhose identifizierbar macht. Was mir ein klein wenig merkwürdig -und typisch für Fälle sommerlicher Netzhysterie- vorkam, ist die Tatsache, dass zwar allenortens mehr oder weniger wild über die möglichen Auswirkungen spekuliert wird, sich aber fast niemand auf die technischen Details einliess, wie denn nun das böse "Cookie" auf den Rechner kommt. Lediglich die Verwendung von Etags und die myiteriöse "Wiederauferstehung" gelöschter Cookies wurde mehrfach erwähnt, ich vermute mal, haupsäcjlich deshalb, weil niemand so recht weiss, was ein "Etag" eigentlich so treibt. Weshalb in einschlägigen Foren sogleich Diskussionen ausbrachen, wie Etags aufzuspüren und am besten zu blockieren wären...Erst mal vorneweg: es hat keinen Sinn, HTTP-Requests oder den Quellcode von Websiten nach Etags abzusuchen, um damit "Beweise" für verwendetes Usertracking zu finden. Genaus wenig, wie AdBlock oder dergleichen mit Filtern gegen Etags zu füttern. Diese Tags sind einfach nur Kennungen für bestimmte Objekte im Cache von Server und Browser und allem möglichen (wie zB Content Delivery Networks) dazwischen. Grob gesagt, entscheiden die, ob ein Objekt neu vom Server geholt, oder aus dem Cache des Browsers gelesen wird. Wenn ich zB den Wetterbericht von irgendwo gebookmarkt habe, trägt der einen Etag. Wenn ich ihn neu laden möchte und der Etag stimmt mit dem überein, den ich schon habe, dann ist er noch nicht aktualisiert und braucht nicht neu angefordert zu werden. Wenn das ein paar Leute mehr machen -was bei so einem Dienst anzunehmen ist- dann werden so ca. 99% aller Anfragen den Server nicht mit Arbeit belegen, sondern einfach aus dem Cache des Servers, des Browsers, oder evtl. dem Proxy geholt, was die Antwortzeiten gewaltig verkürzt und Bandbreite spart. Das ist der normale Zweck von Etags. natürlich kann man sie auch missbrauchen, indem man sie mit anderen Daten verknüpft und dafür sorgt, dass die persistent bleiben - und da fängt die Sache mit dem Usertracking erst an.

  Ganz habe ich das Forschungspapier aus Berkeley noch nicht gelesen, aber einige Dinge denke ich schon darüber begriffen zu haben, wie die von KISSmetrics praktizierte Methode zum Usertracking funktioniert. Erstmal wird eine User- und Session ID geberiert. Das ist nichts Ungewöhnliches. Ungewöhnlich wird es erst in dem Moment, wo diese IDs auch Objekten mitgegeben werden, die nichts mit der ursprünglichen Seite, wo sie generiert wurden, zu tun haben. Auf diese Art und Weise lassen sich nicht nur Benutzer über mehrere Websites hinwegverfolgen, sondern auch die diese IDs an Orten speichern, wo man sie nicht vermuten würde. Wenn ich also die Cookies von Seite A lösche, aber auf Seite B eingeloggt bleibe, erkennt mich -wieder über einige Tricks- Seite A beim nächstenmal trotzdem an der SessionID von von Seite B wieder und schickt mir das gelöschte Cookie erneut. Wenn da ein paar beliebte Seiten dort mitmachen, stehen die Chancen gut, dass ich stets identifizierbar bin. Dazu braucht es aber einiges mehr, als nur Cookies, Etags oder mysteriöse "HTML 5-Objekte". Nämlich, neben den auch für das altbekannte und nah verwandte "History Stealing" benutzten CCS-Stylesheets, trickreich angewandtes JavaScript (Flash, .net oder unter Umständen Java würde wohl auch gehen, aber in den Beispielen von KISSmetrics , die ich gesehen habe, wurde ausschliesslich JavaScript benutzt). Das heisst klipp und klar: führt nicht Javascript oder sonstigen Kram von jedem Hinz und Kunz aus, sondern benutzt entweder NoScript, oder schaltet  Javascript&Co. aus.  - und akzepiert, natürlich, keine ewig haltbaren Cookies von jedem, der eines setzen möchte. Dann klappt's auch diesmal nicht mit dem Spionieren.

Zwar benutzen KISSmetrics ein ausgebufftes Netzwerk von Kreuzreferenzen und Methoden, an allen möglichen Orten deanonymisierende Informationen zu speichern und zu verküpfen, aber ohne eine gewisse Leichtfertigkeit (und JavaScript) kommt auch das nicht aus.