Serverseitiges Tracking: Unterschied zum Client Side Tracking und Datenschutzaspekte

Kategorien: Datenschutz und Tracking

Im Gegensatz zum clientseitigen Tracking oder Tagging finden Aufzeichnungen über Nutzer beim server side tracking indirekt statt. Vom Browser des Nutzers wird dabei ein Tracking-Ereignis zu einem eigenen Server geschickt und von dort weiter zum eigentlichen Ziel. Daraus ergeben sich spannende Datenschutzfragen.

Einleitung

Das serverseitige Tracken oder server side tracking wird gelegentlich auch als serverseitiges Tagging bezeichnet. Dieses Synonym kommt wohl daher, dass Google mit einem sogenannten Tagging Tool den Server-Ansatz des Trackens unterstützt. Tagging heißt soviel wie mit Informationen anreichern. Tracking hingegen bezeichnet das Nachverfolgen von Nutzern, um deren Verhalten kennenzulernen.

Im Gegensatz dazu steht das klassische Tracking, welches auch als clientseitiges Tracking bezeichnet wird. Der Client ist beispielsweise der Browser des Besuchers einer Webseite. Es kann sich auch um eine App handeln.

Beim Server Side Tracking wird üblicherweise ein Tracking-Event von der eigenen Webseite zum eigenen Server geschickt und von dort mehr oder weniger unverändert an den eigentlichen Endpunkt. Beim Tagging hingegen werden die Informationen aus dem Tracking-Event auf dem eigenen Server zunächst angereichert, bevor das Event an einen oder mehrere Endpunkte weitergeleitet werden.

Client- und Server side Tracking

Server side tracking war schon immer möglich, wurde aber bisher nicht besonders thematisiert und wurde aufgrund bisherige Möglichkeiten auch nicht populär. Die wachsende Bedrohung durch Sanktionen für Datensünder wie Google (und alle, die Dienste Dritter unreflektiert einsetzen) hat für einen Paradigmenwechsel gesorgt.

Die folgenden Schaubilder zeigen die Unterschiede zwischen herkömmlichem und neuartigem Tracking und die verschiedenen Möglichkeiten. Als Beispiel dient der Google Tag Manager (GTM), der verwendet wird, um Google Analytics (GA) nachzuladen. Dies ist ein häufiger Fall auf Webseiten. Statt Google Analytics werden oft auch andere Tools vom Tag Manager nachgeladen.

Das herkömmliche Tracking basiert auf dem Laden von GTM und GA jeweils von einem speziellen Google Server. Dieser Ansatz wird clientseitiges Tracking genannt.

Grün hinterlegt ist der datenschutzrechtlich eher unkritische Server, nämlich der Server, auf dem die gerade besuchte Webseite betrieben wird. Die gelb hinterlegten Server sind Drittpartei-Server (Third-Party), hier Google-Server. Google ist nur als plakatives Beispiel genannt. Denkbar sind Server von allen möglichen Anbietern.

Die roten Pfeile zeigen die Datentransfers an. Das Laden des GTM erfordert zwei Datentransfers. Der erste ist ein Abruf, also eine Anfrage. Der zweite Transfer ist die Antwort auf die Anfrage. Bei Google Analytics ist es analog. Somit kommen für den Abruf von GTM und GA zusammen vier Datentransfers zustande. Der fünfte dargestellte Datentransfer ist die Protokollierung einer Nutzeraktion durch Google Analytics.

Das clientseitige Tracking ist bekanntlich leicht nachweisbar. Dafür muss man sich nur anschauen, zu welchen Servern (Adressen) eine Webseite eine Verbindung aufbaut. Jeder sieht sofort, dass ein Aufruf zur Adresse google-analytics.com irgendwas mit Google Analytics zu tun hat.

Nun kann man einen sogenannten Tunnel oder Proxy verwenden, um Google Analytics indirekt zu laden und/oder Tracking-Ereignisse an Google Analytics abzuschicken. Der Vorteil hierbei ist, dass das letztendliche Tracking für alle Endgeräte und Plattformen (Apps, Webseiten) gleich sein kann. Technisch sieht das ganze so aus:

Datenschutzrechtlich ist nicht viel passiert, denn der Tunnel, über den Google Analytics angesteuert wird, befindet sich auf einem Dritt-Server. Google bietet derartige Server aktuell kostenfrei in der Google Cloud an. Der Nutzen der Google Cloud Platform (GCP) dürfte für die wenigsten gegeben sein, weil die Implementierung nicht ganz einfach ist. Der Tag Manager wird in dieser Variante zunächst auf herkömmliche Weise geladen, was ohne Einwilligung übrigens eher nicht erlaubt ist.

Mit dem Transport-Tunnel könnte der Aufruf von Google Analytics bis zu einem gewissen Grad verschleiert werden. Man sollte sich dabei nur nicht erwischen lassen. Die Gefahr der Enttarnung ist jedenfalls recht groß. Auch der Tag Manager könnte über diesen Tunnel geladen werden. Im Beispiel habe ich dies nicht berücksichtigt. Weiter unten wird dieser Fall betrachtet.

Nun folgt eine Variante zum eben genannten Modell. Hier ist alles identisch, nur ist der Transport-Tunnel ein eigener Server. Idealerweise hat der Transport-Tunnel die gleiche Adresse wie die gerade besuchte Webseite.

Google Analytics wird hier komplett über einen eigenen Tunnel-Server angesteuert.

In diesem Modell kann das Google Analytics-Script entweder von einem Google-Server oder einem Server eines anderen Anbieters oder von einem eigenen Server abgerufen werden. Dargestellt ist die erstgenannte Variante. Nach außen hin macht es keinen Unterschied. Datenschutzrechtlich wäre die erste Variante schlechter, aber von der zweiten oder dritten Variante für einen Außenstehenden nicht unterscheidbar und somit nicht direkt nachweisbar.

Die Implementierung dieses Szenarios ist komplex, weil ein eigener Transport-Tunnel installiert werden muss. Mögliche Änderungen an Schnittstellen sind zu berücksichtigen und erhöhen den Wartungsaufwand.

Der datenschutzrechtliche Nachweis der Aktivitäten in diesem Szenario ist nicht mehr so gut möglich wie im vorigen Fall. Der Ladevorgang des eigentlichen Google Analytics Scripts kann von außen nicht nachvollzogen werden. Wird das Script auf die Webseite durchgereicht, ist jedenfalls nachweisbar, dass das Script geladen wurde, aber nicht von wo. Man kann auch eine eigene Logik verwenden, um über den Transport-Tunnel Google Analytics anzusteuern. Das ist mit etwas Aufwand verbunden und erfordert eine regelmäßige Prüfung der Funktionsfähigkeit, weil sich die Analytics Schnittstelle ändern kann. So kann eine maximal mögliche Verschleierung erreicht werden, die aber immer noch in wesentlichen Teilen aufgedeckt werden kann.

Im letzten Szenario werden sämtliche Datentransfers über einen eigenen Proxy-Server abgewickelt.

An der Anzahl der Datentransfers erkennt man schon die hohe technische Komplexität dieses Szenarios. Alle Datentransfers laufen über einen eigenen Server. Denkbar sind natürlich auch mehrere eigene Server. Hat der Tunnel-Server dieselbe Domäne wie die gerade besuchte Webseite, fallen Tracking-Ereignisse nicht so schnell auf wie bisher.

In diesem Szenario ist es möglich, zu versuchen, sämtliche Datentransfers zu verschleiern. Es kann letztendlich (zum Glück) nur ein Versuch sein, da jede Client-seitige Verschleierung aufgedeckt werden kann. Weiter unten folgt mehr dazu.

Die folgende Tabelle zeigt noch einmal die verschiedenen Varianten in einer Übersicht:

Konfiguration eines Tunnels für den Google Tag Manager

Google bietet nicht ganz uneigennützig mit dem Google Tag Manager neue Möglichkeiten an, um serverseitiges Tracking abzuwickeln. Weil der Google Tag Manager ein prominentes Beispiel für diesen Ansatz ist, wird oft auch der Begriff serverseitiges Tagging verwendet.

Der GTM wird als Zwischenschicht benutzt, um Daten sowohl an Google Analytics als auch an andere Google Dienste oder auch an Dienste Dritter zu senden. Somit bekommt Google Daten von mehr Diensten als bisher und kann somit Datenverluste aufgrund von Datenschutzgesetzen ausgleichen.

Konkret sieht die Konfiguration des Tag Managers so aus:

Damit kann der GTM angewiesen werden, dass Google Analytics Ereignisse nicht mehr zu google-analytics.com, sondern zur Tunnel-Adresse analytics.example.com geschickt werden.

Google verspricht damit eine Erleichterung beim Nachverfolgen von Nutzern über mehrere Endgeräte hinweg.

Damit ein Server Daten weiterleiten kann, die er von der gerade besuchten Webseite erhält, muss dieser Server entsprechend vorbereitet werden. Im Wesentlichen muss eine neue Funktionalität bereitgestellt werden, damit der Server als Vermittler zwischen Client und Tracking-Anbieter fungieren kann. Ein Tagging Server kann selbst betrieben werden, was datenschutzfreundlicher ist. Alternativ kann ein solcher Server von einem Anbieter wie Google in der Google Cloud bezogen werden, was von Anfang an Datenschutzfragen aufwirft.

Betriebsmodi

Grundsätzlich gibt es zwei Arten, ein serverseitiges Tagging abzubilden. Technisch sind diese vergleichbar, aber datenschutzrechtlich ergeben sich andere Fragen.

Der erste Modus ist das Nutzen eines Dritt-Servers. Praktisch kann dieser Server auch einem selbst gehören. Die Server-Adresse ist hier aber ungleich der eigenen Webseite und zeigt auf eine Adresse, die auf einen Dritten hindeutet. Als Beispiel sei die von Google Cloud bereitgestellte Server-Instanz genannt, die URLs wie die folgenden produziert: https://sturdy-pier-xyz.ab.r.appspot.com

Eine solche Adresse sieht datenschutzrechtlich erst einmal verdächtig aus. A priori kann von einem einwilligungspflichtigen Vorgang ausgegangen werden. Näheres ist im Einzelfall zu untersuchen.

Den zweiten Modus nenne ich Proxy-Modus. Eine Proxy ist ein Stellvertreter, der Daten durchschleust. Auch ein Dritt-Server, der als Tunnel dient, ist technisch gesehen ein Proxy-Server. Allerdings ist der Dritt-Server datenschutzrechtlich eben keine echte Proxy. Eine Proxy ist in diesem Kontext nach meiner Definition also ein eigener Server.

Der Proxy-Modus verwendet eine Server-Adresse, die in derselben Domäne wie die gerade besuchte Webseite liegt. Ruft ein Nutzer beispielsweise die Webseite eine-webseite-081516.de auf, so könnte die Adresse für den Tagging-Server eine-webseite-081516.de/tagging lauten. Weil auf einer Webseite oft Aufrufe zu sich selbst stattfinden, verschwindet der Aufruf zum serverseitigen Tagging oder Tracking in der Masse der harmlosen Aufrufe.

Im Proxy-Modus können einwilligungspflichtige Aufrufe halbwegs gut versteckt werden. Wird eine Seite aufgerufen, fällt ein Tracking Aufruf auf die eigene Domäne zunächst nicht wirklich auf. Bewegt sich der Nutzer hingegen auf einer schon geladenen Seite, etwa, indem er das Fenster scrollt, und findet hierbei ein Server-Aufruf statt, kann schon recht gut auf ein Tracking geschlussfolgert werden.

Tracking ist ein nicht näher bestimmter Begriff, der im Einzelfall mit Leben gefüllt werden muss. Beim Proxy-Modus kommt es im Wesentlichen auf zwei Fragen an:

1. Findet ein technisch nicht notwendiger Aufruf statt, der nicht mit dem berechtigten Interesse gerechtfertigt werden kann?
2. Werden beim Aufruf Cookies übertragen oder gar erzeugt?

Kann eine der beiden Fragen mit Ja beantwortet werden, liegt eine Einwilligungspflicht, also quasi ein Tracking vor, wenn man etwas verkürzt ausdrücken möchte.

Cookies lassen sich nicht tarnen. Wer ohne Cookies tracken möchte, verliert gewisse Vorzüge von Cookies. Einer dieser Vorzüge ist die leichte Wiedererkennung eines Nutzers innerhalb eines Endgeräts und Browsers, wenn er Tage später die gleiche Webseite erneut aufruft. Dies kann ohne Cookies nur mithilfe eines digitalen Fingerabdrucks bewerkstelligt werden. Theoretisch gibt es auch die Möglichkeit, sogenannte Sitzungsidentifikatoren (Session IDs) zu nutzen, die in der Adresse der gerade besuchten Seite kodiert sind. Dies ist aber aus Gründen der Sicherheit und der Suchmaschinenoptimierung nicht empfehlenswert.

Ein Aufruf zum eigenen Server kann halbwegs verschleiern, dass ein Nachverfolgen eines Nutzers stattfindet. Beispielsweise ist folgendes Szenario mit seinen verschiedenen Varianten möglich:

1. Nutzer A ruft die Webseite zum ersten Mal auf
2. Für Nutzer A wird ein Fingerabdruck gezogen, der zu seiner IP-Adresse gespeichert wird
3. Einige Tage vergehen
4. Nutzer A ruft die Webseite aus dem gleichen Browser erneut auf
   1. Fall: IP-Adresse ist gleich und kann mit dem Fingerabdruck in Einklang gebracht werden
   2. Fall: IP-Adresse ist leicht anders und kann ggf. mit dem Fingerabdruck in Einklang gebracht werden
   3. Fall: IP-Adresse ist ganz anders und kann nicht mit dem Fingerabdruck in Einklang gebracht werden

In den ersten beiden Fällen unter Punkt 4 kann der Nutzer wiedererkannt werden. Das ist das, was man klassischerweise unter einwilligungspflichtigem Tracking versteht. Je länger die Zeitspanne ist, nach der ein Wiedererkennen noch möglich ist und aktiv versucht wird, desto eher liegt eine Einwilligungspflicht vor. Meine persönliche Meinung ist, dass 24 Stunden ein akzeptabler Wert für ein berechtigtes Interesse sind. Alles, was über vier Wochen liegt, ist meiner Meinung nach in jedem Fall einwilligungspflichtig. Alles zwischen einem Tag und vier Wochen ist je nach Einzelfall zu beurteilen. Die vier Wochen hatte ich mal von einem Landesdatenschutzbeauftragten in Zusammenhang mit Tracking-Cookies gehört, halte diese aber selbst für zu hoch. Als Grenze für eine halbwegs vertretbare Dauer im Rahmen einer Risiko-Nutzen-Abwägung sehe ich nur wenige Tage, auch wenn ich glaube, dass dies rechtlich zu beanstanden wäre.

Die Frage ist außerdem, welche Daten zum eigenen Server geschickt werden, um einen Nutzer nachzuverfolgen. Theoretisch reicht eine leere Anfrage, weil auf dem Server mit jeder Anfrage aufgrund des Internet-Protokolls unter anderem folgende Daten landen:

• Adresse (URL) der aktuellen Seite
• Zeitpunkt
• Browser-Kennung (User Agent)
• IP-Adresse des Nutzers

Weitere Daten, die interessant sind, um Nutzer wiederzuerkennen, können und müssen mit dem Aufruf explizit mitgeschickt werden und sind somit von außen erkennbar. Diese Daten sind vor allem:

• Bildschirmauflösung und Fenstergröße
• Spracheinstellungen
• Installierte Plugins und Schriften
• Sonstige Merkmale, etwa, ob ein Touch Screen vorhanden ist

Der folgende Aufruf zum eigenen Tracking Server wäre sehr auffällig:

https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes

Kodiert man die Tracking-Daten allerdings, wird es schon etwas schwieriger, ein Tracking zu erkennen. Der eben genannte Aufruf könnte beispielsweise dieselben Informationen kodiert absenden (fiktives Beispiel):

https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg

Dennoch kann auch hier wahrscheinlich eine Tracking-Absicht nachgewiesen werden. Zum ersten ist der Wert am Ende der URL auffällig lang. Da fällt es schon schwer, sich eine Ausrede zurechtzulegen, warum gerade eine solch lange Zeichenfolge zum eigenen Server übertragen werden muss.

Zum zweiten muss der Wert im Browser des Nutzers aus den Echtdaten kodiert werden. Diese Kodierung wiederum kann nachgewiesen werden. Auch hier kann der Bösewicht dem Datenschnüffler die Erkennung erschweren, etwa durch Unkenntlich machen des Quellcodes. Das heißt Obfuskation. Wie immer gilt, dass jeder Verschlüsselungsvorgang rückgängig gemacht werden kann, so auch die Verfremdung von Quellcode. Redet sich jemand wegen des o.g. langen Wertes raus und kann ihm über Entschlüsselung des Quellcodes etwas Gegenteiliges nachgewiesen werden, wird es schnell sehr peinlich.

Vor- und Nachteile des serverseitigen Trackings

Welche Vorteile und Nachteile existieren, hängen von der Perspektive ab. Aus Sicht von Google eröffnet sich eine neue Möglichkeit, datenschutzrechtlich fragwürdige Praktiken durch ähnlich fragwürdige Praktiken zu ersetzen, die aber schwerer nachweisbar sind. Außerdem erhält Google potentiell mehr Daten von anderen Tools, die neuerdings über die Google Server integriert, anstatt direkt geladen zu werden.

Vorteile

Aus Datenschutzsicht ist es nun möglich, weniger personenbezogene Daten über den Besucher einer Webseite an Google und andere Anbieter zu senden.

Das serverseitige Tracking basiert an sich nicht auf Cookies, was zunächst vorteilhaft im Sinne des Datenschutzes erscheint.

Für Betreiber von Webseiten und Apps ist ein Nutzer-Tracking über Geräte- und Anwendungsgrenzen hinweg nun besser möglich.

Für Google gleicht der Ansatz einer Kompensation für an anderer Stelle verlorenen Datenlieferungen durch die sich aktuell verschärfende Rechtslage.

Nachteile

Es ist möglich, Cookies zu missbrauchen und ein Tracking von Nutzern zu verschleiern. Ebenso lässt sich ein Protokollieren von IP-Adressen verschleiern, weil das Tracking-Ereignis im Hintergrund stattfindet. Dies sind Nachteile aus Sicht des Datenschutzes.

Nutzt eine Webseite den Google Tag Manager für das serverseitige Tracking, dann erhält Google beim Ladevorgang des Tag Managers automatisch die gleichen Daten wie bisher vom Nutzer. Hierzu gehört die personenbezogene IP-Adresse. Der Google Tag Manager ist einwilligungspflichtig, was ihn aus meiner Sicht uninteressant macht. Daran ändert auch der Google Consent Mode nichts. Verantwortliche müssen sich zudem der Datenschutzkomplexität von Google und von deren Tagging-Lösung unterwerfen. Eine populäre Lösung ist prinzipiell angreifbarer als weniger bekannte Anbieter.

Sollte der Google Tag Manager zum Ansprechen von Google Analytics verwendet werden, ist wieder Google der lachende Dritte. Der Nutzer wird somit immer noch nachverfolgt und der Betreiber einer Webseite muss eine potentiell schlechtere Datenqualität in Kauf nehmen, sofern keine Cookies oder ähnliche Konstrukte zum Einsatz kommen. Allerdings schlägt Google sogar eine Möglichkeit vor, dem Nutzer eine Identifikation zuzuweisen, die in einem Cookie gespeichert wird. Im Google-Beispiel dazu hat das Cookie sogar eine Lebensdauer von zwei Jahren. Dies wäre einwilligungspflichtig. Für die meisten Webseitenbetreiber und Nutzer wäre kein Vorteil feststellbar, dafür aber ein höherer Aufwand und eine größere Abhängigkeit von Google.

Die Implementierung wird beim Betreiber einer Webseite zunächst schwieriger. Nur wenn ein Betreiber eine gewisse Größe oder Relevanz erreicht hat, lohnt sich die Implementierung meines Erachtens, weil dann der Vorteil für den Betreiber relevant wird, Daten von mehreren Endpunkten (App, Webseite etc.) einheitlich einsammeln zu können.

Kontingente

Die zahlreichen Einzelendpunkte bei den Usern sind deren Browser. Jeder Browser arbeitet über eine eigene Netzwerkadresse. Diese Nutzer-Endpunkte werden durch einen einzelnen Endpunkt abgelöst, nämlich die Proxy. Die Proxy hat nur eine Netzwerkadresse.

Daraus ergibt sich oft ein Problem mit Kontingenten. Nehmen wir an, die Kosten für einen Dienst bemessen sich an der Anzahl der Aufrufe. Ein Aufruf kann über die Netzwerkadresse des Aufrufers gezählt werden. Das ist nicht immer so, diesen Fall gibt es aber. Ruft nun eine einzige Netzwerkadresse den Dienst auf, entstehen beim Einzelnen schnell sehr viele Aufrufe. Bisher wären pro einzelnem Nutzer und dessen Netzwerkadresse jeweils nur wenige Aufrufe entstanden.

Weiterhin könnte eine Sperre beim Aufrufziel einsetzen, weil zu viele Aufrufe von der Proxy als einzigem Aufrufer festzustellen sind. Auch dies wäre beim Aufruf durch jeden einzelnen Nutzer nicht problematisch gewesen.

Fazit

Das serverseitige Tracking ist meiner Ansicht nach für die meisten nicht relevant. Es wird für viele funktionell irrelevant bleiben. Ich vermute, dass Google diesen Ansatz vorantreibt, um zukünftig Datenverluste durch fehlende Nutzereinwilligungen u. ä. zu kompensieren.

Der Nachweis von einwilligungspflichtigen Vorgängen ist beim serverseitigen Tracking schwieriger als bisher. Werden Cookies verwendet, ändert sich am Nachweis kaum etwas. Cookies können nicht verschleiert werden. Es spielt hierbei keine Rolle, ob sogenannte First Party oder Third Party Cookies verwendet werden, denn fachlich handelt es sich immer um Third Party Daten, wenn Google eingebunden wird.

Werden Daten nicht kodiert, ist der Nachweis, dass Tracking stattfindet, wahrscheinlich auch recht einfach möglich. Werden Daten kodiert, hat der Webseitenbetreiber zunächst mehr Aufwand zu betreiben. Er wird dann seltener erwischt, kann aber immer noch enttarnt werden.

Das insgeheime Abgleichen von IP-Adressen mit Tracking-Daten, welches auf einem eigenen Server im Hintergrund stattfinden kann, wird meiner Ansicht nach wahrscheinlicher. Dies ist aber heute auch schon möglich und wird von manchen sicher auch schon betrieben.

Die folgende Tabelle zeigt ganz grob, welche Datenerhebungen durch serverseitiges Tracking in welchem Maße verschleiert werden können. Ich werde dem einen eigenen Artikel widmen und hier nicht näher auf die Feinheiten eingehen.

Google versucht, mit Ansätzen wie FloC (Federated learning of Cohorts) Cookies zu vermeiden. Dies ist unabhängig vom serverseitigen Tracking. Hier finden Sie Beiträge von mir zu Google FloC:

• Grundlagen zu Google FloC
• Google FloC ist genauso einwilligungspflichtig wie Cookies

Ich sehe das server side Tracking recht entspannt. Wer seine Nutzer intensiv ausspionieren will, nutzt nicht nur Google Analytics, sondern viele andere Tools und Mechanismen. Der Aufwand, all diese Vorgänge zu verschleiern, erfordert eine gehörige Mühe und auch kriminelle Energie. Das Verschleiern von Tatbeständen jedenfalls würde vor Gericht sicher nicht positiv beurteilt werden.