Interne (eigene) Zugriffe
von Google Analytics ausschließen

IP-Filter sind nutzlos in einer Cross / Multi Device Welt

Smartphones, Tablets, Notebooks, PC’s oder gar Smart-TV’s – Sie und die Mitarbeiter Ihrer Firma greifen über unterschiedliche Geräte auf Ihre Webseite zu. Kleine wie große Firmen können sich daher nicht mehr auf die Filterung internen Zugriffe via IP-Filter verlassen.

Selbst wenn Sie sich eine Standleitung leisten, führt die Anonymisierung der IP-Adresse, welche laut Telemediengesetz (TMG) Pflicht ist, zu gewissen „Unstimmigkeiten“.

AnonymizeIP kann auch reale Nutzer ausschließen

Das TMG erfordert zur Einhaltung des Datenschutzes die Nutzung von AnonymizeIP. Durch die Maskierung des letzten der vier Oktetts – die letzten drei Stellen einer IPv4 mit welchen man eine Person identifizieren kann – besteht die Möglichkeit auch reale Nutzer auszuschließen.

Zugegeben, die Wahrscheinlichkeit lässt sich nicht genau beziffern, doch steigt diese mit der Anzahl an Zugriffen sicherlich auf ein nicht mehr zu vernachlässigendes Niveau.

Datenchaos durch AnonymizeIP

Beim Schreiben dieses Artikels entdeckte ich das meine eigenen Zugriffe trotz DoNotTrack, dazu gleich mehr, in Google Analytics aufgezeichnet werden. Dadurch das die letzten drei Stellen der IP genullt werden, führt dies auch dazu das die Dimension „Stadt“ in Google Analytics nicht korrekt ermittelt werden kann.

DoNotTrack funktioniert nicht (immer)

Alle gängigen (und aktuellen) Browser bieten die Möglichkeit mit der Einstellungen DoNotTrack pauschal das Auslesen von Cookies zu verhindern. Um auf Seiten meiner Kunden und meiner eigenen die Statistiken nicht zu verfälschen habe ich DoNotTrack immer aktiviert.

Zu meiner Enttäuschung stellte ich aber fest, das diese Einstellung scheinbar ignoriert wird. Vermutlich in Verbindung mit dem Google Tag Manager. Aber das ist ein anderes Thema. Rechts jedenfalls der Beweis. Somit fällt DoNotTrack als Möglichkeit eigene / interne Zugriffe zu filtern ebenfalls aus.

Wenn mit AnonymizeIP auch reale Nutzer ausgeschlossen werden können und DoNotTrack scheinbar nicht immer funktioniert. Welche Möglichkeiten bleiben dann noch interne Zugriffe korrekt zu erkennen und auszuschließen?

Das vollständige Blockieren von Google Analytics? Sicherlich simpel aber nicht der Weisheit letzter Schluss. Denn würden alle Nutzer Analytics blockieren hätten wir außer Usability-Laboren keine Möglichkeit Webseiten an die Bedürfnisse der Nutzer anzupassen. Welche Informationen werden also noch gesendet anhand dieser man eigene / interne Zugriffe erkennen könnte?

Google Analytics ISP-Filter

Die Filter in Google Analytics zum Ausschluss interner Zugriffe sind ein guter Ansatz. Leider ist es aber nicht möglich die Filter zu kombinieren um die Genauigkeit zu verbessern. Denn der ISP (Internet-Service-Provider) Filter wäre noch gröber als via AnonymizeIP.

Cookies zum Ausschluss eigener Website-Zugriffe

Cookies haben ein, wenn auch beliebig ausdehnbares, Verfallsdatum. Über den Aufruf einer eigens erstellten Seite kann man einen Cookie automatisch setzten um die internen Zugriffe über den Google Tag Manager gar nicht erst an Google Analytics übermitteln zu lassen und somit zu filtern.

Führt die IT-Abteilung Wartungsarbeiten durch oder sorgt einfach dafür das Cookies automatisch gelöscht werden (Stichwort AdBlocker), muss der Cookie immer wieder neu gesetzt werden. Gibt es also keinen bequemeren und verlässlicheren Weg ohne die IT-Abteilung mit einzubeziehen?

Super-Cookies zum Filtern eigener Website-Zugriffe

Herkömmliche Cookies sind in ihren Möglichkeiten stärker eingeschränkt als Super-Cookies – auch bekannt als DOM-/Web-Storage. Super-Cookies sind wie eine Art USB-Stick für Webseiten. In ihnen können bis zu 10 MB an Daten gespeichert werden. Die Speicherung erfolgt aber ausschließlich durch JavaScript (fehleranfällig) und es werden nicht bei jedem Seitenaufruf Daten übermittelt. Der Browser-Support von Web-Storage liegt bei 92.79% und besteht bereits ab Internet Explorer 8.

Flash-Cookies

Der Vollständigkeit halber seien noch Flash-Cookies, die ebenfalls zu den LSO „Local Shared Objects“ zählen, erwähnt. Abgesehen davon das iOS seit jeher Flash nicht unterstützt, aber auch wegen zahlreicher und gravierender Sicherheitslücken und sowie schlechter Performance, flammte häufiger eine Diskussion über ein End of Live Datum (EoF-Date) auf. Mozilla entschied sich mit einem letzten Firefox eben aus Sicherheitsgründen Flash standardmäßig zu deaktivieren. Flash-Blocker (Firefox, Chrome, Safari) – welche ich jedem empfehle zu nutzen – werden zudem zahlreich genutzt!

PS: „Flash is dead“!

Zombie- und Ever-Cookies

Nicht ganz so elegant wie ein Phoenix aus der Asche, können Cookies wie Zombies wiederauferstehen. Ever-Cookies sind eine OpenSource Variante von Zombie-Cookies welche die Speicherung der Daten mit unterschiedlichen Methoden kombiniert und somit das Löschen erschwert. Werden diese Cookies also nicht vollständig gelöscht, können sie beim nächsten Besuch wiederhergestellt werden.

Anwendung fanden Zombi Cookies nach Angabe von Edward Snowden durch die NSA was scheinbar für deren Zuverlässigkeit spricht. In den „geheimen“ Dokumenten über die NSA-Praktiken veröffentlicht von Edward Snowden, wurden Zombie Cookies genutzt um Nutzer des „anonymen“ Browser-Netzwerkes TOR, auch als Dark Web, Deep Web oder Darknet bekannt, zu identifizieren.

Mit Canvas- oder WebGL-Fingerprinting (unlöschbaren Cookies) interne Zugriffe aus Google Analytics filtern

Unlöschbar? Aktuell, ja … aber nichts ist (in Zukunft) 100% sicher! Canvas Fingerprinting ist wie die Technik der Ever-/Zombie-Cookies für Datenschützer ein Alptraum. Unserem Ziel der Identifikation und dem verlässlichen Ausschluss interner Zugriffe ist Canvas- und WebGL-Fingerprinting aber zuträglich. Mit einem Browseranteil von 95,87% wird das HTML 5 Canvas-Element bereits ab Internet Explorer 9 unterstützt.

Was spricht also gegen die Nutzung des Canvas-Fingerabdrucks? Der Datenschutz ist womöglich die größte Hürde da zur Identifikation der Canvas-Fingerabdruck mit jedem Aufruf ermittelt werden muss. Um die internen Zugriffe zudem ausschließen zu können ist eine Datenbank eben jener „interner“ Browser-Fingerabdrücke und JavaScript erforderlich.

Und zu guter Letzt scheint es auch keine 100% verlässliche Methode zu sein. Auf der Seite browserleaks.com oder amiunique.org kann man seinen Canvas-Fingerabdruck testen. Zudem wird er abgeglichen mit den bereits bekannten. Bei mehreren Browsern war mein Canvas-Fingerabdruck bereits bekannt.

Cookieless Cookies dank eTags

Cookies die keine sind? Jetzt wird’s technisch. Ein eTag dient zur Vermeidung unnötiger Übertragung von Daten. Die erstmalig von Server gesendeten Daten werden dabei mit einem eTag, einer Prüfsumme, versehen. Wie können wir nun eTags zur Identifikation von internen Zugriffen nutzen?

Angenommen wir haben eine spezielle Seite „Block interne Zugriffe“. Beim Aufruf dieser Seite wird, sofern noch keine „Blockier-Datei“ mit eTag auf dem Endgerät vorhanden ist, eine neue Datei mit eTag gespeichert. Um zu verhindern das diese Datei aus dem Browser-Cache gelöscht wird, wird sie im lokalen DOM-/Web-Storage (siehe Super-Cookies) gespeichert.

Auf der Webseite von lucb1e demonstriert er das Beispiel sehr anschaulich. Das Tracking ist zwar im Incognito-Modus möglich, jedoch wurde bereits bestätigt das die Firefox-Erweiterung „SecretAgent“ – welche von Firefox offiziell nicht angeboten wird – die Identifizierung via eTag-Overwrite bereits erfolgreich verhindert.

Jeder Browser sendet einen User-Agent-String (UA-String) der wie eine Art Typenschild Informationen über Typ und Version des Browser, des Betriebssystems sowie dem CPU-Typ übermittelt. Der User-Agent-String kann ohne großen Aufwand den eigenen Wünschen nach angepasst werden.

Da der vollständige UA-String nicht in Google Analytics zur Verfügung steht, kann man diesen im Google Tag Manager ermitteln. Die Filterung sollte in Google Analytics selbst erfolgen um das Senden eines Pageviews nicht zu verzögern.

JavaScript wird grundlegend zur Analyse von Website-Benutzern benötigt (Server Statistiken ausgenommen). Mit Zuhilfenahme von fingerprintjs2 kann man auf, möglichst unveränderliche, Systemeigenschaften wie folgende zurück greifen:

• Browser-Typ
• System-Sprache
• Browser-Sprache
• Farbtiefe
• Bildschirm Auflösung
• Zeitzone

• CPU Typ
• Systemtyp
• DoNotTrack
• Installierte Schriften
• Plugins
• AdBlock

Basierend auf diesen und weiteren System-Merkmalen kann ein interner Nutzer sehr genau erkannt werden. Eine simple Lösung stellt das leider auch nicht dar. Aus den ermittelten Daten muss entweder ein eindeutiger Wert wie etwa ein veränderter UA-String erkennbar sein oder eine Datenbank mit Hilfe einer „Block Page“ diese initial aufgerufen werden muss erstellt werden.

Ergänzend möchte ich noch das passive und aktive Device-Fingerprinting erwähnen was aber eher in der Netzwerkanalyse Anwendung findet.

Um zu verhindern das Cookies zur Identifizierung interner Zugriffe unbeabsichtigt entfernt werden sind Zombi Cookies vermutlich die verlässlichste Methode. Um aber dem Datenschutz gerecht zu werden muss eine „Block-Seite“ erstellt werden diese initial aufgerufen werden muss und die „Block-Cookies“ zu speichern.

Mittels Google Tag Manager kann dann die Überprüfung auf vorhandene Block-Cookies erfolgen. Wurden Zombie Cookies welche die internen Zugriffe filtern sollen gefunden, werden diese auf Vollständigkeit geprüft und ggf. wieder komplettiert.

Zum Ausschluss der internen Zugriffe kann dann das 1st-Party-Cookie genutzt werden um die Übermittlung nach Google Analytics zu verhindern. Ergänzend kann noch eine Custom Dimension oder ein Event an Google Analytics bei Wiederherstellung der Zombie Cookies übermittelt werden um die internen Zugriffe doppelt filtern zu können.

Vergleich der Möglichkeiten eigene Zugriffe zu filtern

* Tracking mit Google Tag Manager und Filtern in Google Analytics