Cookiesterben, Trackingmöglichkeiten und GAFA-Requests, mein begrenzter Wissensstand

Folgendes wird wieder so eine Balance zwischen „Oh Gott, das versteht keiner“ und „Da outest du dich mal wieder mit allenfalls Basiswissen und genierst dich nicht mal“, aber nun. Es geht um Tracking, Personalisierung und Cookies, und wie das aktuell funktioniert (bzw. nicht), seit alle ernsthaften Browser 3rdParty- und überhaupt Trackingcookies blocken. Ich vereinfache eingangs vieles sehr bewusst und später stoße ich an eigene Wissensgrenzen, bitte ersteres hinnehmen und mir bei zweiteren bitte gerne auf weitere Sprünge helfen, danke. Ebenfalls sinnvoll zu erwähnen: IANAL.

Die gute alte Zeit

Früher(tm) hat man in eine Seite einfach Trackingpixel eingebunden – Dateien, die von Trackingdienstleistern geladen wurden und die dann ihr Cookie abgesetzt haben. Prinzip: Ruppsel geht auf example.com, example.com ruft ein Pixel von Google und eines von facebook über ihre Seite auf, die Ruppsel deswegen wacker und unbesehen mitlädt. Beide Pixel schauen, ob es von google bzw. facebook bei Ruppsel ein Cookie gibt. Es gibt keins, also setzen sie ein Cookie (drin steht ne eindeutige ID).
Ruppsel surft weiter zu example.net, die, wie es das Schicksal so will, auch von Google und facebook ein Trackingpixel haben. Beide werden geladen, gucken, obs ein Cookie gibt – hurra, da ist eins. Google und facebook wissen nun, dass ich auf example.com und example.net war.

Nun melde ich mich bei YouTube an und hoppla, schon kann Google das mit den vorhandenen Cookiedaten verknüpfen und mir demnächst Werbespots von example.org einblenden, weil die Kunden der beiden Wettbewerber erreichen wollen und Google dafür Geld geben.

DSGVO und Cookieblocker

Diese beiden Faktoren haben das Prinzip nachhaltig verändert: die DSGVO setzt eine aktive Einwilligung in entsprechende Datenweitergaben voraus, gängige Browser blockieren alle Cookies, die nicht von der Domain kommen, die vom Browser selber aufgerufen wurde: wenn Ruppsel auf example.com ist, kann da noch so viel von google.com geladen werden, ein Cookie setzen dürfen sie trotzdem nicht. Bzw., doch, je nach Browser kommen da noch teils einzelne Cookies durch, in der Regel explizit die, die dem (anonymisierten) Tracking des Seitenbesuchs dienen, nicht dem seitenübergreifenden Nachverfolgen und -profilen. Allein, selbst da kann man sich nicht wirklich drauf verlassen (looking at you, Safari).

Was passiert? Es werden bei einem großen und weiter wachsenden Teil von Webseitenbesuchern keine Cookies beispielsweise von Google Analytics mehr gesetzt. Nun ist HTTP aber im Grunde ein „zustandloses Protokoll“, ein Webserver weiss nicht, wer ihn da vor fünf Minuten genervt hat, er gibt eben immer das raus, was vom Nutzer angefragt wird. Es erkennt niemanden von sich aus wieder, dafür braucht es… Cookies. Oder ähnliches. Auf der Webseite selber mag das kein Problem sein – man ruft Seite A auf und kriegt Seite A. Man ruft Seite B auf und kriegt B, und wenn man Seite C nur kriegen kann, wenn man vorher einen Haken auf B gesetzt hat, dann setzt die Seite dabei ein „Haken auf B steht“ – Cookie und wenn das da ist, wird C ausgeliefert und wenn nicht, nicht. Weil das Cookie von der im Browser aufgerufenen Domain kommt, funktioniert das alles auch. Nun kommen aber „von extern“ gesetzte Cookies nicht mehr zuverlässig an.

Google Analytics, haben wir Sitzungen?

Springen wir zu Google Analytics. Wenn ich wissen will, wo sich Nutzer auf meiner Seite rumtreiben, nutze ich Google Analytics, weil es so ziemlich das beste ist, was man dazu nehmen kann. Wie oft werden welche Seiten aufgerufen, kommen die Nutzer über Anzeigen, über Links, über die Suche, wie lange bleiben sie auf Seite X, wieviele Seiten schauen sie sich an usw., und wer bei „wie viele Seiten schauen sie sich an“ am Kopf kratzte, hat mitgedacht. Woher soll Google wissen, dass der User auf Seite A derselbe ist wie der, der kurz darauf Seite B aufrief? Denn der Trackingcode wird nach wie vor über jede Seite aufgerufen, aber wie kann Google zuordnen, dass es immer derselbe Nutzer ist?

Bis vor einiger Zeit: klar, übers Cookie. Inzwischen kann man sich darauf schlicht nicht verlassen. Schau ich in Analytics, sehe ich aber unverändert, dass in diesem wie auch im letzten Jahr sich die Leute im Schnitt 1,3 Seiten hier anschauen, bevor sie woandershingehen. Oder dass sie eben auch mal sechs Blogeinträge durchblättern, damals wie heute. Es gibt nun die Leute, die sagen, klar, Google almighty kann eh alles und auch in unser Hirn und durch unsere Webcam gucken, aber wenn ich das einem Kunden sage, wird der mich für bekloppt erklären und sein Geld woanders ausgeben. Wir brauchen schon was handfesteres.

1st Party-Cookies und Browser-Requests

Google und auch Facebook behelfen sich (unter anderem) damit, Cookies via Javascript über die aufgerufene Seite auszuliefern: Der Trackingcode wird aufgerufen und sagt, jemand hat Seite A auf example.com aufgerufen, jemand hat Seite B auf example.com aufgerufen usw. Ein Cookie wird von example.com gesetzt, in dem eine ID steht.

Es wird aber vor allem auch ein Request an Google geschickt, in dem… oh wunder, genau diese ID auch steht. Das Ganze hat Serge Egelman auf Twitter recht gut beschrieben, (unroll), ich kanns nicht ganz verifizieren, sein Focus ist auf Tracking für Ads/Remarketing und meines auf Analytics, aber ungefähr sowas läuft da wie dort.

Funktioniert das?

Mein Eindruck: Bedingt, aber meist, und es kommt auf einige Faktoren an. Die korrupt.biz ist recht dankbar, weil da ist recht wenig Traffic drauf und ich kann mich in Analytics einfach selber livetracken. Was passiert da?

Recht klar: der Tagmanager setzt Google-Cookies direkt über die korrupt.biz. Beachten wir mal _ga: GA1.2.1459289514.1409218132 und _gid: GA1.2.1705700330.1575293184. Ich bin nebenbei aktuell mit meinem Google-Account angemeldet unterwegs und hab kein Inkognito-Fenster an, aber den Standard-Firefox-Trackingblocker.

Spätere Aufrufe an Google-Seiten lesen oder setzen auch keine Cookies, dort wird dann tatsächlich direkt über den URL-Request die ID mit übergeben – da steht dann im Request die cid=1459289514.1409218132 (identisch zu _ga) und die gid=1705700330.1575293184 kennen wir auch schon bereits.

Ich geh auf eine andere Seite. Was wird dort via 1st Party gesetzt? _ga: GA1.2.1438534812.1574969443 und _gid: GA1.2.165465452.1575483044. Das ist offenkundig nicht dasselbe.

Auch hier aber der folgende Browser-Request mit cid=1438534812.1574969443 (identisch zu _ga) und _gid=165465452.1575483044 (same).

Zwischenstand: mehrere Seitenaufrufe eines Nutzers können cookiefrei auch diesem einen Nutzer zugeordnet werden. Analytics erkennt mich auch als wiederkehrenden Nutzer auf meiner Seite. Angemeldet mit meinem Google-Account kriege ich aber bei mir eine andere ID wie auf einer anderen Seite, auf der ich ebenso angemeldet unterwegs bin. Was nichts heißen will in Bezug auf andere Tracker – mich interessiert in diesem Kontext an sich nur Analytics. Was auch nichts heißen will in Bezug auf mögliche Zusammenführungen auf unbekannter Datenbasis (Fingerprinting, whatever). Was ich hier sehe, wirkt auf mich wie aktuell (noch, man beachte den Hinweis auf die Möglichkeit restriktiverer Einstellungen im Browser) zuverlässig messbare Sessions. Wiederkehrende Nutzer auch wiederzuerkenne könnte schon schwieriger werden, wobei ich hier davon ausgehe, dass das 1st-Party-Cookie ja die ID schrieb und bei einem erneuten Besuch auch wieder erkannt wird. Die Verknüpfung von 1stParty-ID zu Google-IDs, die das Aggregieren von Daten über Sessions, Domains etc. hinweg ermöglichen, springt mir hier ebenso noch nicht ins Gesicht, bzw. wenn sie stattfindet, dann weiss ich nicht, wie.

Ich wüsste im Analytics-Kontext aber auch und vor allem nicht, warum das überhaupt passieren sollte: der Seitenbetreiber nutzt Analytics für *seine* Seite. Google tut sehr gut daran, die hier anfallenden Daten eben nicht zu aggregieren und nicht mit anderen zu verknüpfen, das scheint mir ohnehin die einzige Möglichkeit zu sein, GA in irgend einer Form rechtssicher zu halten bzw. zu kriegen.

Interessante Beobachtung am Rande: Adsense schreibt eine Menge Ad-Optimierungswerte in die Local Storage (die ansonsten gern für persistente Cookies genutzt wurde, aber rein rechtlich analog zu Cookies eben nicht mehr ohne weiteres für potentiell personenbezogene Daten genutzt werden kann). Letzteres scheint mir aus bereits genannten Gründen für Analytics vollkommen irrelevant.

Alternativen zu 1stParty-Cookies und Browserrequests

In einer gestrigen Twitterunterhaltung zum Thema warf ich die spontane Frage auf, ob man analog zu den DNS-Umbiegereien für Newsletter-Trackingdomains nicht ähnliches für Cookies machen könnte. Heute kam ich zum Nachstöbern und stellte fest, die Idee hatten (natürlich, haha) schon andere und die Gegenmaßnahmen waren bereits Tickerthema. Mir kommt das sehr deutlich von hinten durch die Brust ins Auge vor. Anders gesagt: es fällt mir schwer, offensichtlicher die Botschaft „Wir machen was rechtlich fragwürdiges und wissen das auch genau, bitte stellt keine Auskunftsersuche oder schaltet gar juristische Apparate ein“ zu kicken.

Bauchgefühle und widrige Umstände

„Gefühlt“ hab ich den Eindruck, dass die Zahlen bezüglich wiederkehrender Nutzer in Analytics durchgehend zu niedrig sind bzw. früher ™ höher waren. Grundsätzlich misst GA seit jeher etwas „vorsichtiger“: z.B. Verkaufszahlen via GA über Abschlusseiten gemessen fallen in der Regel etwas niedriger aus als das, was in den Warenwirtschaftssystemen tatsächlich an Netzbestellungen aufschlägt. Interessant ist, dass sich diese „feinen Unterschiede“ in unterschiedlichen Dimensionen unterschiedlich auswirken. Besagte Quote wiederkehrender Nutzer scheint mir niedriger geworden zu sein. Andere Metriken wie Verweildauern, Seiten/Sitzung usw. scheinen mir messbedingt über die Zeit hingegen nicht groß verändert bzw. verzerrt. Faktoren, die reinspielen können, sind zahlreich und schwer unterschiedlich.

· der Cookieschwund bzw. die Standard-Blockeinstellungen der Browser scheinen das „Wiederkehren“-Erkennen zu erschweren
· Session-Erkennen scheint aber technisch nach wie vor gut zu funktionieren
· einzelne Seitenaufrufe, Verweildauern etc. sind vollkommen unproblematisch, abgesehen von den
· Totalausfällen, die gar nicht mehr auftauchen: Inkognito-Sessions seh ich in GA beim Livetest überhaupt nicht mehr, ich schätze, ein restriktiver Trackingblocker taucht auch nicht auf. Verbreitung aus naheliegenden Gründens schwer einzuschätzen und wahrscheinlich je nach Branche/Themenfeld vollkommen unterschiedlich.
· Mobile Safari blockt sehr restrikiv, trotzdem steigt der Mobile-Traffic über alle Plattformen seit Jahren: ist der trotz Wachstum und Mobile Only unterschätzt?

Zu guter Letzt: der allgemeine Cookiewahn

Ich beobachte mit einem gewissen Unbehagen, wie die öffentliche und auch teils die technische Debatte an den Cookies klebt. Sobald es in Richtung konkreter Gerichtsentscheide geht, wird oft der Fokus etwas geweitet, spricht man auch von „gleichwertigen Techniken“ usw., die üblichen Einverständniserklärungen etc. reden aber sehr überwiegend von Cookies der Parteien X, Y, Z usw., dabei geht es nicht mehr nur um diese heutzutage bzw. ist ein eingeholtes Einverständnis, das sich explizit auf Cookies bezieht, in meinen Augen irgendwie am Sachverhalt vorbei, um den es geht.

Ums nicht vollkommen ausufern zu lassen: verkürzt scheinen mir die relevanten Sachverhalte 1) Onpage-Tracking und 2) Profiling/Targeting zu sein, und bei beiden sind entscheidende Faktoren a) (potentieller) Personenbezug und b) Datenweitergabe. Anonymisiertes 1) in Bezug auf Analytics zu gewährleisten scheint mir dabei die Herausforderung, und ich würde mich nicht wundern, wenn genau das auch die Zielsetzung Googles bei eben den Analytics-Lösungen ist, denn schließlich geht 1) Onpage-Tracking (via Analytics) nicht ohne b) Datenweitergabe (an Google).

Diesbezüglich scheint mir die aktuelle Situation an sich eigentlich als ein Fortschritt: dadurch, dass die entsprechenden Cookie-IDs nur von der eigenen Seite gesetzt, gelesen und an Google übermittelt werden können, und eben nicht ohne weiteres auch identisch bei und auf anderen Seiten. Verknüpfungen und potentielle Deanonymisierungen sind so deutlich erschwert, und ganz egoistisch aus meiner Perspektive gedacht: UDIAGS.

Notwendige Disclaimer und weitere Fragestellungen

Ich bin kein Techie und Javascript ist, nun, das, was man überfliegt, wenn man sich die Sourcen angucken muss wegen irgendwas. Mich interessieren keine Blackhat-Kisten („Ey, Ruppsel, cloake dir doch einfach nen Proxy und binde Yandex Metrika via localhost ein“) und eigentlich auch nicht die üblichen „Im Hintergrund verknüpfen die eh alles“- Schwurbler. Mich stört es aber irgendwann, wenn was funktioniert, aber ich nicht mehr so ganz genau sagen kann, warum. Hinweise, die diesen Zustand zum Besseren verändern, erfreuen mein Herz.

Nachtrag: Die EFF erklärt und warnt vor Trackern

Kaum versuch ich mich als Erklärbär, kommen die großen Fische: die EFF kloppte gestern direkt ein fettes Whitepaper zum Thema Tracking raus. Naturgemäß einiges massiv detailierter wie ich hier. Die Lektüre ist empfohlen, allein, ich rate dazu, die beschriebenen totalen Erkennungs- und Zuordnungsraten mit einem Körnchen Salz zu genießen. Wenn Fingerprinting, TLS-SessionIDs und Konsorten so eineindeutig sind: würdet ihr über eine entsprechende Library, die euch so zuverlässig identifizieren soll, den Netflix-Zugang abwickeln? Den Login zu eurem Blog? Den Zugang zum Onlinebanking? Ich bin raus, ich hab kein Netflix, aber bei den anderen beiden würde ich zu einem sehr sehr nachdrücklichen „Nein“ neigen.