Tracking Cookie

Ein HTTP-Cookie, auch Browser-Cookie genannt ([ˈkʊki]; engl., „Plätzchen“, „Keks“), bezeichnet Informationen, die ein Webserver zu einem Browser sendet oder die clientseitig durch JavaScript erzeugt werden. Der Client sendet die Informationen in der Regel bei späteren Zugriffen an denselben Webserver im Hypertext-Transfer-Protocol-Header an den Server. Cookies sind clientseitig persistente/gespeicherte Daten.

HTTP-Cookies sind eine spezielle Form der allgemeinen Magic Cookies. Sie ermöglichen das clientseitige Speichern von Information, die auch vom Server stammen können und die bei weiteren Aufrufen für den Benutzer transparent an den Server übertragen werden. Dadurch erleichtern Cookies die Benutzung von Webseiten, die auf Benutzereinstellungen reagieren oder den Aufbau von Sitzungen. Dieses Konzept wurde ursprünglich von Netscape entwickelt und in RFC 2109 spezifiziert.

Funktionsweise

Cookies werden in den Kopfzeilen (Header) von Anfragen und -Antworten via HTTP übertragen. Cookies entstehen, wenn bei einem Zugriff auf einen Webserver neben anderen HTTP-Kopfzeilen in der Antwort zusätzlich eine Cookie-Zeile übertragen wird (siehe Aufbau). Diese Cookie-Informationen werden dann lokal auf dem Endgerät gespeichert, üblicherweise in einer Cookie-Textdatei. Bei nachfolgenden weiteren Zugriffen auf den Webserver wird der eigene Browser alle Cookies in dieser Datei heraussuchen, die zum Webserver und Verzeichnispfad des aktuellen Aufrufs passen, und schickt diese Cookie-Daten im Header des HTTP-Zugriffs mit zurück, womit die Cookies jeweils an jenen Webserver zurückgehen, von dem sie einst stammten.

Ein Cookie kann beliebigen Text enthalten, kann also neben einer reinen Identifikation auch beliebige Einstellungen lokal speichern, jedoch sollte seine Länge 4 KB nicht überschreiten, um mit allen Browsern kompatibel zu bleiben. Die Cookies werden mit jeder übermittelten Datei übertragen, also auch mit Bilddateien oder jedem anderen Dateityp; dieses gilt insbesondere für eingebettete Elemente wie Werbebanner, die von anderen Servern eingebunden werden als dem Ursprung einer angezeigten HTML-Datei. So kann eine einzelne Webseite zu mehreren Cookies führen, die von verschiedenen Servern kommen und an diese jeweils wieder zurückgeschickt werden; mit einer Anfrage des Browsers werden alle den Server betreffenden Cookies gesendet.

Cookies werden ausschließlich vom Client verwaltet. Somit entscheidet der Client, ob z. B. ein Cookie gespeichert wird oder die vom Webserver gewünschte eingeschränkte Lebensdauer des Cookies durch Löschung ausgeführt wird.

Gängige Browser erlauben dem Nutzer meist einschränkende Einstellungen zum Umgang des Client mit Cookies, z. B.:

• Keine Cookies annehmen.
• Nur Cookies des Servers der aufgerufenen Seite annehmen (keine Cookies von Drittservern wie bei Werbebannern).
• Benutzer bei jedem Cookie fragen.
  • hier kann dann meist zwischen „erlauben“ (bleibt), „für diese Sitzung erlauben“ (wird immer angenommen, aber nach dem Schließen des Browsers gelöscht) und „ablehnen“ (nicht akzeptieren) gewählt werden, wobei die gewählte Option gespeichert wird.
• Alle Cookies bei Beendigung des Client löschen („Sitzungs-Cookie“).

Dazu erlauben einige Browser verwaltende Aktionen wie:

• Daten im Cookie ansehen.
• Einzelne oder alle Cookies löschen.

Ob ein Cookie angenommen (clientseitig gespeichert) wurde, muss die serverseitige Anwendung in weiteren HTTP-Anfragen erkennen, da vom Client keine Rückmeldung erfolgt.

Der Server kann ein Cookie durch Überschreiben mit leeren Daten löschen.

Verwendung

Eine typische Anwendung von Cookies ist das Speichern persönlicher Einstellungen auf Websites, zum Beispiel in Foren. Es ist eine Möglichkeit eine Webseite zu besuchen, ohne jedes Mal die Einstellungen erneut vornehmen zu müssen.

Mit Cookies können auch Sitzungen realisiert werden. Das HTTP ist per Definition ein zustandsloses Protokoll, daher ist für den Webserver jeder Zugriff völlig unabhängig von allen anderen. Eine Webanwendung, die sich über einen längeren Zeitraum hinzieht, muss mit Zusätzen auf der Anwendungschicht (im Browser) arbeiten, um den Teilnehmer über mehrere Zugriffe hinweg identifizieren zu können. Dazu wird in einem Cookie vom Server eine eindeutige Session-ID gespeichert, um genau diesen Client bei weiteren Aufrufe wieder zu erkennen und damit nicht bei jedem Aufruf einer Unterseite das Passwort erneut eingegeben werden muss.

Auch Online-Shops können Cookies verwenden, um sitzungslose virtuelle Einkaufskörbe zu ermöglichen. Der Kunde kann damit Artikel in den Einkaufskorb legen und sich weiter auf der Website umschauen, um danach die Artikel zusammen online zu kaufen. Die Artikel-Kennungen werden in einem Cookie gespeichert und erst beim Bestellvorgang serverseitig ausgewertet.

Damit bei Webanwendungen Benutzeraktionen und -eingaben, die für den Server bestimmt sind, bei Abbrüchen der Verbindung zum Server zum Beispiel in Mobilfunknetzen nicht verloren gehen, können Cookies zur Zwischenspeicherung eingesetzt werden. Sie werden dann bei Wiedererrichtung der Verbindung automatisch zum Server geschickt. Die Webanwendung erkennt dabei die Reihenfolge, in der die Cookies erzeugt wurden, und markiert bereits verarbeitete Cookies oder löscht deren Inhalt. Weil bei dieser Verwendung unter Umständen viele Cookies erzeugt werden, die frühestens beim Schließen des Browsers gelöscht werden, der Speicherplatz des Browsers für Cookies aber beschränkt ist, muss die Webanwendung Vorkehrungen gegen einen Cookie-Überlauf treffen.^[1]

Gefahren

Die eindeutige Erkennung kann für Zwecke eingesetzt werden, die von vielen Benutzern als missbräuchlich angesehen werden. Cookies werden z. B. dafür verwendet, Benutzerprofile über das Surfverhalten eines Benutzers zu erstellen. Ein Online-Shop kann z. B. diese Daten mit dem Namen des Kunden verknüpfen und zielgruppenorientierte Werbemails schicken. Jedoch kann der Online-Shop nur das Surfverhalten innerhalb seiner eigenen Webseite verfolgen.

Server, die nicht identisch mit dem Server der aufgerufenen Webpage sind, können z. B. mit Bilddateien (Werbebanner oder auch Zählpixel) auch so genannte „serverfremde“ Cookies setzen. Diese werden aufgrund ihrer Verwendung auch als „tracking cookies“ bezeichnet (englisch für Verfolgen). Gegebenenfalls kann so der Besuch unterschiedlicher Websites einem Benutzer zugeordnet werden. Es entsteht eine „serverübergreifende“ Sitzung. Daraus kann auf die Interessen des Besuchers geschlossen und Websites entsprechend angepasst („personalisiert“) werden. Bei einer Bestellung in einem Webshop etwa werden die angefallenen Daten naturgemäß einer konkreten Person zugeordnet.

Denkbar wäre ein potentieller Missbrauch bei einer möglichen Kooperation zwischen dem Webshop und dem Werbeunternehmen; diese kann verhindert werden durch eine entsprechende Browser-Einstellung, die nur Cookies des Servers der aufgerufenen Seite (Webshop) annimmt, nicht die der fremden Server, die die Werbung einblenden. Wirbt der Webshop allerdings selber, könnte diese zielgerichtete Werbung so nicht verhindert werden, aber sogar nützlich sein. Amazon wertet bekanntlich die Bestellhistorien der Käufer systematisch aus, um auch unbekannten Besuchern konkrete Vorschläge zu machen.

Noch nicht zu übersehen sind die Gefahren, die dadurch entstehen, daß Großunternehmen wie Google, deren Dienste praktisch jedermann ständig nutzt, sich vorbehalten, die dadurch entstehenden Daten auf unbegrenzte Zeit zu bevorraten und auszuwerten. Um Daten über das Nutzerverhalten zu sammeln, ist man nicht auf Cookies angewiesen. Das Problem ist also wesentlich allgemeinerer Natur.

In Umgebungen, in denen sich mehrere Nutzer denselben Rechner teilen, etwa in Schulen oder Internet Cafés, besteht allerdings die ganz konkrete und offensichtliche Gefahr, dass ein noch gültiger Sitzungs-Cookie vom nächsten Nutzer des Rechners verwendet wird, um diese Sitzung fortzusetzen. Dieses Risiko kann verhindert werden, indem man grundsätzlich alle Cookies vor dem Beenden des Browsers löscht oder eine entsprechende Browser-Einstellung nutzt. Das wäre die Aufgabe des Administrators. Infolgedessen kann man an öffentlichen Plätzen, etwa Bibliotheken oder Universitäten, üblicherweise keine permanenten Cookies hinterlassen.

Erlauben oder Sperren?

Ein Kompromiss zwischen den Vor- und Nachteilen von Cookies kann erzielt werden, indem man seinen Browser so konfiguriert, dass persistente Cookies nicht oder nur gegen Rückfrage zugelassen werden, was z. B. die Erstellung von Benutzerprofilen erschwert, und Sitzungs-Cookies automatisch zugelassen werden, z. B. für Webeinkäufe, Passwörter. Außerdem bieten die meisten Browser die Möglichkeit, Cookies selektiv für bestimmte Domänen zu erlauben bzw. zu sperren oder nach dem Surfen automatisch zu löschen, wie es automatisch bei Sitzungs-Cookies geschieht. Auch ist es möglich, serverfremde Cookies automatisch abzuweisen, über die ein Dritter, etwa ein Werbepartner der Internet-Seite, das eigene Verhalten über mehrere Server hinweg aufzeichnen könnte.

Es ist auch möglich, Cookies automatisch beim Schließen des Browsers durch diesen löschen zu lassen. Damit werden Probleme mit Mehrbenutzersystemen weitgehend vermieden und die Überwachung des Benutzers durch Cookies wird zumindest eingeschränkt. Zugleich verzichtet der Benutzer damit auf alle Vorteile, die Cookies gewähren; er muß sich also zwangsweise bei der nächsten Sitzung überall wieder neu einloggen. Das führt aber zu neuen Sicherheitsproblemen, denn die Benutzer neigen dazu, überall dasselbe Passwort zu verwenden, da sich niemand eine Vielzahl von Passworten merken kann. Selbst die Benutzung von mehreren Passworten führt dazu, daß der Benutzer gegebenenfalls alle ausprobiert und sie damit gegenüber der betreffenden Webseite preisgibt.

Des Weiteren bieten moderne Browser die Möglichkeit, Funktionen über kleine Zusatzprogramme (Add-Ons) nachzurüsten. So ist es beispielsweise bei Firefox nach Installation eines auf diese Funktion ausgelegten Add-Ons per Klick auf eine Schaltfläche möglich, Internetseiten die Erlaubnis zu geben, Cookies zu speichern^[2][3][4] bzw. sogar selbst den Inhalt der Cookies zu manipulieren^[5]. Das ermöglicht es, dass man die Cookies generell deaktiviert lassen kann und sie nur dann zu erlauben, wenn die Internetseite nicht richtig funktioniert oder man sich bei einem Onlinedienst anmelden will.

Aufbau

Ein Cookie besteht aus einem Namen und einem Wert sowie mehreren erforderlichen oder optionalen Attributen mit oder ohne Wert. Einige Attribute sowie deren Einschließen in Hochkommas werden empfohlen.

Name - erforderlich – Beliebiger Name und Wert aus ASCII-Zeichen die vom Server übergeben werden
Version - erforderlich – Gibt die Cookie-Management-Spezifikation in einer Dezimalzahl an (derzeit immer 1).
Expires - optional – Ablaufdatum, Zeitpunkt der automatischen Löschung in UTC für HTTP/1.0
Max-age - optional – Ablaufzeit in Sekunden – 0 für sofortige Löschung. Der Client darf den Cookie auch nach dieser Zeit benutzen, der Server kann sich also nicht darauf verlassen, dass der Cookie nach dieser Ablaufzeit gelöscht wird.
Domain - optional – Domain oder Bestandteil des Domainnamens, für den der Cookie gilt
Path - optional – Gültigkeits-Pfad (Teil der Anfrage-URI), um die Gültigkeit des Cookies auf einen bestimmten Pfad zu beschränken
Port - optional – Beschränkung des Ports auf den aktuell verwendeten oder auf eine Liste von Ports
Comment - optional – Kommentar zur näheren Beschreibung des Cookies
CommentURL- optional – URL unter welcher eine Beschreibung zur Funktionsweise zu finden ist
Secure - optional – Rücksendung des Cookie nur „geschützt“ (wie ist nicht weiter spezifiziert). Die meisten HTTP-Clients senden einen „sicheren“ Cookie nur über eine HTTPS-Verbindung. Das Attribut hat keinen Wert.
Discard - optional – Unbedingt Löschung des Cookies bei Beendigung des Webbrowsers.

Funktionsweise – ein Beispiel

Szenario: Eine Webseite bietet eine Suchfunktion an, die sich an den zuletzt eingegebenen Suchbegriff erinnern kann, selbst wenn der Benutzer zwischenzeitlich den Browser beendet. Dieser Suchbegriff kann nicht auf dem Server gespeichert werden, da der Server dazu den Besucher eindeutig identifizieren müsste, und das geht mit reinem HTTP nicht. Deshalb soll der zuletzt eingegebene Suchbegriff vom Browser des Besuchers (in einem Cookie) gespeichert werden.

Wenn der Besucher die Suchfunktion zum ersten Mal aufruft (hier mit dem Suchbegriff „cookie aufbau“), schickt er folgende Anfrage an den Server:

GET /cgi/suche.py?q=cookie+aufbau HTTP/1.0

Der Server antwortet mit dem Suchergebnis und bittet den Browser mit der „Set-Cookie“-Zeile, sich den letzten Suchbegriff zu merken:

HTTP/1.0 200 OK
Set-Cookie: letzteSuche="cookie aufbau";
            expires=Tue, 29-Mar-2005 19:30:42 GMT;
            Max-Age=2592000;
            Path=/cgi/suche.py;
            Version="1"

(Normalerweise stehen alle Eigenschaften des Cookies in einer einzigen Zeile. Zur besseren Lesbarkeit steht hier jedoch nur ein Attribut pro Zeile.) Der Cookie hat die folgenden Eigenschaften:

• Nutzdaten (letzteSuche): Der letzte Suchbegriff
• Ablaufdatum (expires): Der Cookie wird nur in Anfragen mitgeschickt, die vor dem 29. März 2005 passieren.
• Maximalalter (Max-Age): Der Cookie wird nur in den folgenden 30 Tagen mitgeschickt, später nicht mehr.
• Teilbereich der Webseite (Path): Der Cookie wird nur an die Suchmaschine (/cgi/suche.py) geschickt, da alle anderen Teile der Webseite die Information nicht brauchen.

Zusätzlich zu der Pfad-Einschränkung wird der Cookie auch nur an den Server zurückgeschickt, von dem er gekommen ist. Dies wird durch die fehlende „Domain“-Variable erreicht.

Bei jeder weiteren Suchanfrage schickt der Browser nun, wenn er den Cookie akzeptiert, diesen an den Server zurück. Das sieht dann so aus:

GET /cgi/suche.py?q=12345 HTTP/1.0
Cookie: letzteSuche="cookie aufbau"; $Path=/cgi/suche.py; $Version="1";

Allen Eigenschaften des Cookies ist ein „$“ vorangestellt, mit Ausnahme der Nutzdaten (hier: letzteSuche). Der Server hat jetzt also die Information über den aktuellen Suchbegriff (12345) und den letzten (cookie aufbau). Zwischen diesen beiden Suchanfragen kann eine Zeit von bis zu 30 Tagen (Ablaufdatum) liegen.

Browseranforderungen

Nach RFC 2965 soll ein Browser Folgendes unterstützen:

• Es sollen insgesamt mindestens 300 Cookies gespeichert werden können.
• Es sollen pro Domain mindestens 20 Cookies gespeichert werden können.
• Ein Cookie soll mindestens 4096 Bytes enthalten können.

Manche Browser können mehr Cookies und/oder auch Cookies mit längeren Zeichenketteninhalten verarbeiten, garantiert ist dies aber nicht. Umgekehrt halten sich aber auch nicht alle Browser an alle Anforderungen.

Quellen

1. ↑ Carsten Bormann: Panic-mode: A Disconnection-tolerant AJAX Library O'Reilly Emerging Technology März 2006
2. ↑ https://addons.mozilla.org/de/firefox/addon/2497
3. ↑ https://addons.mozilla.org/de/firefox/addon/1247
4. ↑ https://addons.mozilla.org/de/firefox/addon/4703
5. ↑ https://addons.mozilla.org/de/firefox/addon/573

Siehe auch

• Cookie
• Cross-Site-Cooking
• Logdateianalyse

Weblinks

• www.cookiecentral.com – umfangreiche Seite über Cookies (englisch)
• www.web-analytics.org – Einsatz von Cookies im Marketing.
• RFC 2965 HTTP State Management Mechanism – Festlegung des Cookies-Standards
• Super-Cookies (DOM Storage)