Tracking Methoden für Beginner

HTTP – Cookies waren lange Zeit die Wahl aus dem Fundus der Tracking Methoden um verschiedenste Aufgaben zu bewältigen: Markieren bzw. Wiederfinden von Usern im Netz, die Differenzierung verschiedener Usergruppen in der Webanalyse, das korrekte Tracking und somit um die korrekte Salezuweisung im Affiliate Marketing oder das Markieren von Kaufabbrechern im Retargeting. HTTP – Cookies wurden für diese und noch mehr Aufgaben eingesetzt.
Aber spätestens seit der Ankündigung von Mozilla im Februar 2013 3rd Party Cookies im Firefox 22 per Default Einstellungen zu blockieren, haben sich viele Leute Gedanken darum gemacht, ob HTTP- Cookies überhaupt noch notwendig sind und ob es nicht eventuell andere Lösungen gibt. Aber existiert aktuell überhaupt eine technische Umsetzung, die es ermöglicht ganz ohne HTTP Cookies auszukommen?
Dieser Artikel soll die aktuellen cookiebasierten und cookieless Tracking Methoden technisch durchleuchten und erklären wie welche Methode funktioniert. Bei einigen Tracking Methoden versuche ich Code Beispiele hinzuzufügen, einfach um aufzuzeigen, dass Tracking kein Rocket Science ist und das Markieren von User im Netz grundsätzlich simple ist.

Ich möchte an dieser Stelle aber erwähnen, dass mit Sicherheit einige Methoden datenschutzrechtlich äußerst schwierig sind bzw. aus datenschutzrechtlicher Perspektive einfach schlicht weg nicht erlaubt sind. Dieser Artikel dient lediglich der Dokumentation und vor dem Einsatz dieser Tracking Methoden ist eine datenschutzrechtliche Prüfung unbedingt notwendig!

Tracking Methoden - Cookiebased und Cookieless Tracking

Cookiebased und Cookieless Tracking

Einleitung „Tracking Methoden“

Seitdem sich Menschen durch das Internet bewegen, versuchen andere Menschen eben diese erste Gruppe irgendwie zu erfassen und deren Spuren im Netz zu verfolgen, meistens zu Marketing- Zwecken. Wie schon eingangs erwähnt passierte dies in der Regel durch das Setzen eines HTTP – Cookies auf dem Client des Users.
Wobei hier erwähnt werden muss, dass teilweise auch schon sehr früh andere Tracking Methoden zum Einsatz kamen: Es wurden Session-IDs generiert und in URL Parametern weitergetragen, es wurden IP Adressen gespeichert, in der Hoffnung anhand dieser den User wiederzufinden und auch erste Fingerprint Techniken wurden umgesetzt, in dem die IP Adresse in Kombination mit dem User Agent des Browsers gespeichert wurden. Trotz aller Kreativität vieler Coder hielt sich aber das HTTP – Cookie eine sehr lange Zeit als Standard im Bereich Tracking.

Mich persönlich traf die Frage nach der Notwendigkeit von HTTP – Cookies wieder einmal im Februar 2013, als Mozilla verkündete im nächsten Release des Firefox 3rd Party Cookies per Default Setting zu blockieren. Ich hatte mich zwar schon vorher hier und da mit cookieless Tracking Methoden auseinander gesetzt, aber da ich zu dieser Zeit als Head of Technical Account Management in einer Affiliate Agentur gearbeitet habe, zwang uns diese Nachricht zum Handeln. Zu dieser Zeit hatte der Firefox grob eine 30% Marktanteil unter den deutschen Internet-Usern und im Endeffekt bedeutete diese Nachricht, dass wir bei 30% der Internet-User keine 3rd Party Cookies mehr setzen könnten. Denn es war davon auszugehen, dass der Otto-Normal-User da draußen diese Default Einstellung nicht aktiv ändern würde und der Firefox auch nicht an Beliebtheit und somit an Prozentwerten im Marktanteil verlieren würde.

Im Mai 2013 kam dann doch die Erlösung und Mozillas CTO Brendan Eich verkündete, daß aufgrund technischer Probleme der Firefox 22 ohne dieses Feature releast wird. Wobei inoffiziell eher davon ausgegangen wurde, dass der Druck der Werbetreibenden Industrie Mozilla zum Umdenken veranlasst hat.
Zu diesem Zeitpunkt hatten sich aber schon zu viele Leute mit diesem Thema befasst und meiner Meinung nach war damit die „Post-HTTP-Cookie Ära“ bereits eingeläutet. Eine weitere Beobachtung trug ebenfalls dazu bei: Wir konnten nämlich beobachten, dass es zu einem zunehmenden Cookie-Lost kam, was so viel heißt, dass immer mehr User aktiv ihre Browsercookies löschten.

Anhand der aktuellen Diskussion in den Medien zum Thema „Canvas Fingerprint“ kann man sehen, dass dieses Thema bereits aus dem „Beta Stadium“ heraus ist und großflächig cookieless Tracking zum Einsatz kommt.
Alle deutschsprachigen Internet-News Portale wie heise, golem oder t3n nahmen sich zuletzt dem Thema „Canvas Fingerprint“ an und sogar auf Spiegel Online konnte man einen Artikel zum Thema finden.

Im Folgenden versuche ich die aktuellen Tracking Methoden einmal gegeneinander aufzustellen und technisch zu durchleuchten…

HTTP-Cookies

Ein Cookie ist eine Textdatei, die eine angesurfte Webseite durch den Webbrowser auf dem Rechner des Benutzers hinterlegt. Dieses einmal gesetzte Cookie kann später von dieser Domain wieder ausgelesen werden. HTTP Cookies sind von sich aus nicht cross-domain fähig, ein Cookie kann also nur von der Domain ausgelesen werden, die es auch vorher gesetzt hat.

Grundlegend wird zwischen 1st Party und 3rd Part Cookies unterschieden. Ein 1st Party Cookie wird bei dem User von der Seite gesetzt auf der er sich auch gerade befindet. Ein 3rd Party Cookie wird von einer anderen Domain beim User gesetzt, als auf der er sich gerade befindet. 3rd Party Cookies kommen besonders im Bereich des Retargetings zum Einsatz. Hier werden beispielweise Besucher eines Onlineshops mit Cookies eines Retargeting Anbieters (Drittanbieter) markiert, damit diesem User zu einem späteren Zeitpunkt zielgerichtet Werbung angezeigt werden kann.

Ein Cookie bei einem Besucher deiner Seite zu setzen ist nun wirklich kein Hexenwerk. Beispielsweise sieht das Setzen eines Cookies in PHP so aus:

1
2
3
<?php
    setcookie("tracking","userid 123456789",time()+(3600*24));
?>

Ein Cookie hat einen Namen, einen Wert und eine Laufzeit. In dem PHP Beispiel heißt das Cookie „tracking“, hat den Wert „userid 123456789“ und eine Laufzeit von 24 Stunden.

Später kann ich dieses Cookie auch ohne Probleme beim User wieder auslesen, in eine Variable speichern und weiterverarbeiten. Um bei unserem Beispiel zu bleiben, sieht das Ganze so aus:

1
2
3
<?php
    $a = $_COOKIE["tracking"];
?>

Ein HTTP Cookie beim User zu setzen funktioniert natürlich auch mit JavaScript. In diesem Fall schaut da ganze so aus:

1
2
3
4
5
6
<script type="text/javascript">
    var a = new Date();
    a.setTime(a.getTime() + (30*24*60*60*1000)); //30 Tage Cookielifetime
    var expires = "expires="+a.toUTCString();
    document.cookie = "tracking=userid 123456789; " + expires;
</script>

Auch in diesem Fall ist das Auslesen des Cookies völlig simpel:

1
2
3
4
5
6
7
8
9
10
<script type="text/javascript">
    var name = "tracking=";
    var ca = document.cookie.split(';');
    for(var i=0; i<ca.length; i++) {
        var c = ca[i];
        while (c.charAt(0)==' ') c = c.substring(1);
        if (c.indexOf(name) == 0) return c.substring(name.length,c.length);
    }
    return "";
</script>

Grundlegend ist das Setzen und das nachträgliche Auslesen von HTTP Cookies einfach, erzielt aber eine große Wirkung. Es ermöglicht dir zum Beispiel, User die bereits auf deiner Seite waren gezielt anders anzusprechen, als User die noch nicht auf deiner Seite waren und so weiter… Mit ein bisschen Kreativität lässt sich hier einiges anstellen.
Pro Domain müssen Browser standardmäßig 20 Cookies mit einer Größe von 4 KB pro Cookie zulassen.

Cookie Sync

Wie bereits weiter oben erwähnt sind HTTP – Cookies von sich aus nicht „Cross-Domain“ fähig. Das heißt, nur die Domain, die das Cookie geschrieben hat, kann dieses Cookie auch auslesen. Es kann aber durchaus von Vorteil sein, die Cookie Information an eine andere Domain weiterzugeben.

Im Grunde beinhaltet ein Cookie lediglich eine ID, die dann wieder ausgelesen wird und für weitere Informationen mit einer Datenbank abgeglichen wird.

Um diese ID an eine andere Domain weiterzugeben, könnte man wie folgt vorgehen:

Der Client ruft die Domain A auf. In diesem Aufruf ist das Cookie der Domain A enthalten, sagen wir mal mit dem Wert „userid123“.
Die Domain A leitet dann zu Domain B weiter und ruft in der Weiterleitungs – URL den Cookie-Value in einem Parameter auf: b.de/?domain=a&cookie_value=userid123
Damit übergebe ich den von Domain A gesetzen Cookiewert an Domain B, die dann ebenfalls ein Cookie setzen kann und weiss, dass der User bei der Domain A den Wert „userid123“ hat.

HTML5 Cookies (localStorage)

Eine etwas andere Art Daten auf dem Client des Users zu schreiben, bietet das HTML5 Objekt localStorage. Hier werden die Daten dauerhaft und nicht wie bei Cookies mit einer bestimmten Laufzeit gespeichert. Ein Beispielcode via localStorage Daten auf dem Client des Users zu schreiben sieht so aus:

1
2
3
<script type="text/javascript">
    localStorage.setItem("tracking", "user 123456789");
</script>

In diesem Beispiel wird einfach ein Key (tracking) mit dem Wert „user 123456789“ auf den Client geschrieben. Das Schöne an dieser Sache ist, dass es kein Cookie ist und deswegen wie schon oben erwähnt keine Laufzeit hat und auch nicht vom User über die Browserfunktion „Cookies löschen“ entfernt werden kann.

Im Nachhinein kann dieser Wert einfach wieder ausgelesen werden:

1
2
3
<script type="text/javascript">
    a = localStorage.getItem("tracking");
</script>

Hierdurch wird der Wert des Keys „tracking“ in die Variable a geschrieben und kann dadurch weiterverarbeitet werden.
Leider ist das Objekt nicht in allen Browsern da draußen verfügbar, weswegen sich ein vorheriges Testing lohnt um ggf. auf eine andere Trackingart zu wechseln. Bei der Prüfung ob das Objekt localStorage verfügbar ist oder nicht, sollte diese Funktion weiterhelfen:

1
2
3
4
5
6
7
8
9
10
11
12
<script type="text/javascript">
    function lsavailable(){
        var test = 'test';
        try {
            localStorage.setItem(test, test);
            localStorage.removeItem(test);
            return true;
        } catch(e) {
            return false;
        }
    }
</script>

Flash Cookies (Local Shared Objects)

Einen Schritt weiter gehen die sogenannten „Flash Cookies“. Die Scriptsprache ActionScript bietet innerhalb von Flash Movies die Möglichkeit sogenannte SharedObjects auf dem Client des Users anzulegen. Diese SharedObejcts werden von dem Flash Player Plugin verwaltet und haben zwei Vorteile:

a) sie funktionieren browser-übergreifend
b) sie sind nicht ohne Weiteres vom User zu entfernen

Die Daten werden in das Dateisystem des Betriebssystems geschrieben und bleiben auch durch das Löschen des Caches unangetastet. Beispielsweise findet der User seine Flash Cookies bei Windows 7 hier:

1
%AppData%\Roaming\Macromedia\Flash Player\#SharedObjects

Die ActionScript Klasse „SharedObject“ ist für das Anlegen dieser Daten verantwortlich. Um ein SharedObejct mit dem Namen „tracking“ und dem Inhalt „user 123456789“ anzulegen, sieht das ActionScript einfach umschrieben so aus:

1
2
3
mySharedObject=SharedObject.getLocal("tracking");
mySharedObject.data.value="user 123456789";
mySharedObject.flush();

Und über dieses ActionScript kann der Wert wieder ausgelesen werden:

1
2
mySharedObject=SharedObject.getLocal("tracking");
a = mySharedObject.data.value;

Dieser Vorgang läuft allerdings innerhalb des Flash Movies ab. Interessant wird die ganze Sache wenn via JavaScript noch Werte an den Flash Movie übergeben werden bzw. empfangen werden.

Hierzu solltet ihr euch einmal die folgenden Scripte auf github.com anschauen: https://github.com/nfriedly/Javascript-Flash-Cookies

Evercookies (Zombiecookies)

Richtig schön dreckig wird es jetzt mit den sogenannten „Evercookies“ oder auch „Zombiecookies“. Und hier ist der Name definitiv Programm. Das Ganze funktioniert so, dass sich Trackinginformationen über bis zu 17 verschiedene Arten auf den Client des Users schreiben. Hier eine kleine Auswahl der verwendeten Methoden, die wir oben teilweise schon erläutert haben oder auf die wir weiter unten noch eingehen werden:

  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Silverlight Isolated Storage
  • HTTP ETags
  • Internet Explorer userData storage
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite
  • HTML5 IndexedDB

Aber hiermit nicht genug: Sollte der findige User einige dieser Trackinginfomationen von seinem Client entfernen, werden diese einfach wieder durch die anderen noch existierende Methode erneuert.
Jedem sollte aber klar sein, dass diese Tracking Methode mit absoluter Sicherheit datenschutzrechtliche Probleme aufwirft!

Wer dennoch reges Interesse an dieser Methode hat wird auch hier unter github.com fündig: https://github.com/samyk/evercookie

Browser Fingerprint

Die oben erwähnten Tracking Methoden würde ich alle unter dem Begriff „aktive Tracking Methoden“ zusammenfassen, da aktiv eine Information auf dem Client des User geschrieben wird.
Beim Browser Fingerprint hingegen handelt es sich eher um eine „passive Tracking Methode“ da keine Informationen bei dem User abgelegt werden, sondern lediglich Informationen ausgelesen werden.
Welche Informationen ausgelesen werden, wie viele Informationen und wie diese gewichtet in den Fingerprint einfließen, entscheiden über die Qualität des Fingerprints. Wie schon in der Einführung erwähnt, gab es schon relativ früh Fingerprints aus der IP Adresse und dem User – Agents des Clients, wohin gegen aktuell viel mehr Parameter zum Einsatz kommen.
Hier eine kleine Auswahl der Parameter, die bei Client abgefragt werden könnten:

  • IP – Adresse
  • TCP – Quellcode
  • Http Referrer
  • Http User Agent
  • Http Accept
  • Http Accept Charset
  • Http Accept Encoding
  • Http Accept Language
  • Document Referrer
  • Navigator AppCodeName
  • Navigator AppName
  • Navigator AppVersion
  • Navigator CookieEnabled
  • Navigator Language
  • Navigator Platform
  • Navigator UserAgent
  • Screen Width
  • Screen Height
  • Screen Avail Width
  • Screen Avail Height
  • Color Depth
  • Plugins
  • Mimetypes
  • Systemfonts

Diese Parameter werden beispielsweise via JaveScript / PHP abgefragt. Da es aber eher keinen Sinn ergibt abgefragte Browser – Plugins oder Systemfonts als Rohdaten abzuspeichern, werden aus den Einzeldaten Hash – Werte generiert, die dann abgespeichert oder weiterverarbeitet werden. Aus der Summe der Hash- Werte kann beispielsweise wiederum ein Hash – Wert generiert werden, der dann die eindeutige UserID darstellen könnte.

Eine schöne Demonstration findet ihr unter https://panopticlick.eff.org/.

Eine sehr umfangreiche Abfrage von Fingerprint Parametern findet ihr unter http://noc.to/.

Betrachtet man sich die einzelnen Abgefragten Parameter einmal genau, wird relativ schnell klar worum es bei dem Thema „Gewichtung“ geht. Zum Beispiel ist die IP Adresse zwar eine unique Information, die aber aufgrund des 24h – Reconnects vieler Provider nicht gerade persistent ist. Die Bildschirmauflösung ist eine sehr persistente Information, aber leider absolut nicht uinique. Wohingegen eine Abfrage der Browser – Plugins nicht nur die Plugin – Namen enthält, sondern auch die Plugin – Versionsnummer ausgibt. Die verschiedenen Pluginversionen und die Pluginkombinationen ergeben dann schon einen relativ eindeutigen Wert. Aus diesem Grund ist die Kombination und Gewichtung der einzelnen Fingerprint Parameter extrem wichtig und führt zu einer Genauigkeit in der Identifizierung der Clients.

Das schöne an dieser Tracking Methode ist die Tatsache, dass wir auf dem Client des Users keine Spuren hinterlassen und lediglich Daten auslesen. Somit gibt es auch keine Information, die der User löschen könnte um sich so dem Tracking zu entziehen.

Wer sich hiefür interessiert, sollte sich einmal das Fingerprint Script von Valentin Vasilyev anschauen: https://github.com/Valve/fingerprintjs.

Henning Tillmann hat zu dem Thema „Browser Fingerprint“ seine Diplomarbeit geschrieben. Er stellt auf seiner Seite die komplette Arbeit inklusive der verwendeten Scripte für die Erhebung der Daten bzw. der Auswertung zur Verfügung: https://www.henning-tillmann.de/2013/10/browser-fingerprinting-93-der-nutzer-hinterlassen-eindeutige-spuren/

HTTP ETag

Eine weitere Tracking Methode bietet die HTTP Header Information ETag. Fragt der Client – Browser bei dem Webserver eine Datei (beispielsweise ein PNG Bild) an, wird neben dem eigentliche Bild auch die Header Daten übertragen. Ein Feld in diesen Header Daten ist das sogenannte ETag, welches eigentlich dem Caching dient. Fragt der Client – Browser nämlich dieses Bild noch einmal an, sendet der Client den ETag an den Webserver zurück um anzufragen ob diese Ressource sich geändert hat. Hat sich das Bild nicht geändert schickt der Webserver einen 304 „Not Modified“ Code zurück, so dass dieses Bild nicht mehr übertragen werden muss.

Tracking Methoden - Cookiebased und Cookieless Tracking

HTTP ETag

Jetzt könnten wir per .htaccess eine Anfrage vom Client einfach so umzubiegen, dass zwar ein Bild beim Webserver angefragt wird, aber beispielweise eine PHP Datei zurückgegeben wird. Darüber lässt sich dann ohne weiteres ein Bild generieren inklusive selbstgenerierter Header Daten. ETag Anfragen vom Client an den Webserver lassen sich ebenfalls auslesen und damit erhalten wir eine wunderbare Möglichkeit eine Information bei dem User zu hinterlegen und wieder auszulesen. Auch hier bietet github folgende Scripte: https://github.com/lucb1e/cookielesscookies

Zum Tracking via HTTP ETag muss abschließend noch erwähnt werden, dass sich eher um eine transiente Methode handelt, da die Informationen verschwinden sobald der User seinen Cache löscht.

Canvas Fingerprinting

Canvas Fingerprint Tracking wird aktuell als „der neue heiße Scheiß“ unter den Tracking Methoden gehandelt. Canvas ist ein Element innerhalb von HTML5 welches auf der Webseite eine Fläche definiert, auf der dann wiederum via JavaScript gezeichnet werden kann. Die Idee, die hinter Canvas Fingerprint steckt, besagt, dass abhängig vom Browser, dem System und der Hardware des Clients das generierte Bild innerhalb des Canvas immer ein „bisschen“ unterschiedlich ist. Und genau diese Eigenschaft kann ich mir zunutze machen:

Zuerst erstellen wir uns eine Canvas Fläche im HTML Dokument:

1
<canvas id="textcanvas" width"250" height="100"></canvas>

Erstellen dann via JavaScript innerhalb des Canvas Elements ein Bild:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<script type="text/javascript">
    var canvas = document.getElementById('textcanvas');
    var trx = canvas.getContext('2d');
    var txt = "janberens.de 1.0";
    trx.textBaseline = "top";
    trx.font = "14px 'Arial'";
    trx.textBaseline = "alphabetic";
    trx.fillStyle = "#f60";
    trx.fillRect(125,1,62,20);
    trx.fillStyle = "#069";
    trx.fillText(txt, 2, 15);
    trx.fillStyle = "rgba(102, 204, 0, 0.7)";
    trx.fillText(txt, 4, 17);
</script>

Und dann lesen wir den Canvas Inhalt via toDataURL() Methode als base64-encoded String wieder aus:

1
2
3
<script type="text/javascript">
    var a = canvas.toDataURL();
</script>

Diesen base64-encoded String könnte man dann in einen MD5 Hash umwandeln, mit dem wir dann weiterverarbeiten können.

Keaton Mowery and Hovav Shacham vom Department of Computer Science and Engineering der University of California haben einen 12 – seitigen Artikel mit dem Titel „Pixel Perfect: Fingerprinting Canvas in HTML5“ geschrieben. Ihr findet diesen Artikel hier: http://cseweb.ucsd.edu/~hovav/dist/canvas.pdf [Mirror]

Ein weitere Abhandlung zu persistenten Tracking Methoden findet ihr hier: https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf [Mirror]

Ich hatte weiter oben bei der Methode „Browser Fingerprint“ das Script von Valentin Vasilyev angegeben. Wer sich dieses Script genauer anschaut, wird feststellen, dass dort ebenfalls Canvas Fingerprint enthalten ist: https://github.com/Valve/fingerprintjs.

301 Redirect Tracking

Eine etwas exotische bzw. unbekannte aber dennoch interessante Art User bzw. Clients zu tracken ist die Tracking Methode via „301 Redirect“.

Ein 301er Redirect dient eigentlich dazu, dem anfragenden Client mitzuteilen, dass die angefragte Ressource dauerhaft verschoben wurde (Move Permanently) und unter einer neuen Adresse zu finden ist. Nun ist es so, dass sich der Browser diesen Redirect in seinem Cache merkt, also beim nächsten Aufruf direkt die neue Adresse der Ressource anfragt. Und genau diese Tatsache kann ich mir jetzt einfach für mein Tracking zunutze machen.

Nehmen wir einmal an, es wird beim Aufbau einer Seite eine Ressource via iframe bei dem Server angefragt. Nennen wir die Ressource einmal xyz.php. Der Server aber antwortet mit einem 301er Redirect und teilt dem Client mit, das sich diese Ressource nicht mehr unter /xyz.php befindet, sondern unter /xyz.php?userid=123.
Das PHP Script müsste einfach den Parameter userid abfragen, ist dieser Parameter nicht vorhanden, wird einfach ein 301er ausgeben:

1
2
3
4
<?php
    header("HTTP/1.1 301 Moved Permantly");
    header("Location:/xyz.php?userid=123");
?>

Die neue Location sollte natürlich dynamisch generiert werden, um jedem User seinen eigenen Parameter auszuspielen.

Der Client cachen sich diesen Redirect und ruft beim nächsten mal /xyz.php?userid=123 auf. Dadurch erhalten wir die Möglichkeit eine unique Information bei dem Client zu hinterlegen und sind in der Lage diese sowohl dynamisch auszusteuern, als auch wieder auszulesen…

Auch hier sollte man im Hinterkopf behalten, dass es sich um eine cache – basierte Geschichte handelt. Löscht der User seinen Cache, sind die Daten auch wieder verloren.

HSTS (HTTP Strict Transport Security) – Tracking

Die Tracking Methode via HSTS (HTTP Strict Transport Security) ist weniger verbreitet und war lange Zeit nur wenigen Auserwählten überhaupt bekannt.
Seit neustem wird aber auch diese Methode heiss in den Medien disktuiert: golem.de, heise.de, t3n.de und techworm nahmen sich dem Thema an und veröffentlicheten entsprechende Artikel.

Aber worum geht es genau beim HSTS-Tracking?
HTTP Strict Transport Security (HSTS) ist eine HTTP Header Methode über die der Client Browser vom Server angewiesen wird, sich über einen bestimmten Zeitraum nur via HTTPS zu verbinden. Das heisst also, dass dem Client Browser eine Information mitgeteilt wird, dass die angeforderte Seite auf jeden Fall via HTTPS aufgerufen wird, selbst dann wenn der Aufruf vom User via HTTP war. Die entsprechende HTTP Header Information sieht so aus:

1
Strict-Transport-Security: max-age=31536000
HSTS-Tracking Header Informationen

HSTS-Tracking Header Informationen

Diese Header Information kann ganz einfach via PHP gesetzt werden:

1
2
3
<?php
    header("Strict-Transport-Security:max-age=31536000");
?>

Der Client Browser merkt sich diesen Wert über den angegebenen Zeitraum (max-age). Wir der Wert max-age auf 0 gesetzt, vergisst der Client Browser diese Information umgehend wieder. Und genau an dieser Stelle greift das HSTS-Tracking. Werden während des Aufrufs der eigentlichen Seite beispielweise 25 Subdomains im Stil von 01.janberen.de – 25.janberens.de nachgeladen und bei jedem User eine andere Variation bezüglich der HTTPS oder HTTP Verteilung ausgegeben, ergibt sich für jeden Besucher ein uniquer Fingerprint. Kehrt der User wieder auf die Seite zurück, ruft sein Browser gemäss der gespeicherten HSTS Informationen einige der Sub-Domains über HTTPS auf und andere über HTTP, worüber dann der unique Fingerprint rekonstruiert werden kann.

Das Nette an dieser Tracking Methode: Sie funktioniert ohne Weiteres auch im Inkognito-Modus des Browsers.

HSTS-Tracking radicalresearch.co.uk

HSTS-Tracking radicalresearch.co.uk

Wer sich das mal im Live Betreib anschauen will, kan die Seite http://www.radicalresearch.co.uk/lab/hstssupercookies/ anschauen, auf der diese Methode zum Einsatz kommt. Im HTTPFox kann man sehr schön die Aufrufe der Subdomains sehen, die während des Aufrufs der eigentlichen Seite nachgeladen werden.

HSTS Tracking HTTPFox

HSTS Tracking HTTPFox

Fazit

Heutzutage User zu tracken ist, wie oben dargestellt absolut kein Rocket Science und mit ein bisschen Hirnschmalz lässt sich dies auch ohne weiteres ohne HTTP – Cookies bewerkstelligen. Es gibt zahlreiche Methoden, die entweder alleine oder besser in Kombination ein lückenloses User – Tracking ermöglichen. Und ich bin mir auch abolut sicher, dass mit diesen oben erwähnten Tracking Methoden noch lange nicht das Ende der Fahnenstange erreicht ist. Was bleibt ist die Frage nach dem Datenschutz und welche Tracking Methoden überhaupt mit eben diesem vereinbar sind…

Jan Berens ist seit über 12 Jahren im Online Marketing tätig und schreibt auf seinem Blog www.janberens.de über aktuelle Online Marketing Themen und die Technischen Details dahinter. Zu seinen Stationen in den 12 Jahren gehören unter anderem die Fliks GmbH, die ad-cons GmbH und die douglas Holding. Jan Berens ist Speaker auf zahlreichen SEO Stammtischen und Online Marketing Events und hält Vorträge und Workshops zu den Themen "Technical SEO" und "Tracking Methoden".





5 Comments

  1. Antworten

    […] Jan Berens hat einen schönen Überblicksartikel verfasst, in dem er erklärt, wie genau das mit dem Tracking eigentlich funktioniert. Der folgende Beitrag zeigt aktuelle cookiebasierte-Tracking-Methoden auf und erklärt, was sich wofür am besten eignet. Dabei werden Code-Beispiele zu den jeweiligen Tracking-Methoden vorgestellt, um zu verdeutlichen, dass das Thema Tracking und Markieren von Usern im Netz grundsätzlich nicht schwer ist. Vor dem Einsatz der folgenden Methoden muss jeder selbst jedoch erst einmal eine datenschutzrechtliche Prüfung vornehmen: Tracking Methoden für Beginner. […]

  2. Antworten

    […] Cookies bis hin zum 301 Redirect Tracking erklärt Jan Berens in seinem Artikel diese Woche, welche Tracking-Methoden es aktuell gibt und wie sie technisch […]

  3. Antworten

    […] Berens hat sich diese Woche dem Thema ausführlich angenommen und stellt verschiedene Cookie-basierte und Cookie-freie Tracking-Methoden vor. Dazu zählen unter […]

  4. Antworten

    […] In einem umfangreichen Blog-Beitrag geht Jan Berens darauf ein welche Tracking Methoden es aktuell gibt, welche Mehthode für welchen Anwendungsfall am besten geeignet ist und wie “Tracking” eigentlich grundlegend funktioniert. Ein insgesamt sehr hilfreicher Guide der mit einigen Code-Beispielen das Thema greifbarer bzw. nachvollziehbarer erscheinen lässt. […]

  5. Antworten
    Was sind eigentlich Cookies? 20. Dezember 2014

    […] Wer weitere Informationen braucht, Jan Berens hat zum Thema Tracking einen umfangreichen Blogbeitrag veröffentlicht. […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *