Markus Baersch

Software · Beratung · Lösungen

Start » Blog » Analytics / Trackingschutz

11.10.2019

Gleich vorab: Eine definitive Antwort auf alle Fragen in diesem Zusammenhang habe ich (noch) nicht. Aber zumindest genug für einen ersten und vergleichsweise kurzen Blogpost. Spät genug, denn Safari 13 mit ITP 2.4 - dem weiter verschärften Trackingschutz - ist schon seit Ende September verfügbar. Darin geht es vor allem wieder um bekannte Tracking Domains und das, was sie tun dürfen. Neben dem "Verstümmeln" des Referrers bei solchen Domains (was nachvollziehbare Gründe hat) geht es erstmals unter bestimmten Umständen neben Cookies auch localStorage und IndexedDB an den Kragen. Welche Werte sind betroffen und unter welchen Umständen? Hier gibt es erste Ergebnisse meiner Tests... ("fertig" bin ich aber noch nicht).

Alles weg im localStorage nach 7 Tagen?

Das ist die offensichtliche Annahme, wenn man nicht genau hinsieht. Auf den zweiten Blick sieht man zwei große Einschränkungen:

  1. Es muss ein Besuch stattfinden, der von einer bekannten Tracker-Domain (sagen wir ab hier einfach: "Facebook" als Stellvertreter) stammt und wo die URL der Zielseite mit einem Parameter oder Fragment versehen ist, das der Weitergabe der Identität dient (also der "fbclid" zum Beispiel).
  2. Die Domain (nicht nur die betreffende Zielseite) darf  7 Tage nicht mehr besucht werden nach diesem Ereignis.

Dann - und nur dann - wird etwas gelöscht. Aber was genau? Das kann ja unterschiedlich übel ausfallen:

  • Alles, was bis dahin im localStorage stand?
  • Nur das, was bei diesem Besuch geschrieben oder aktualisiert wurde?
  • Nur die Einträge, die durch Scripts der bekannten Tracker-Domain in (dieser Session) gesetzt wurden?

Gerade der letzte Fall wäre ja deutlich weniger... naja... störend als der erste. Nach meinem bisherigen Ergebnis sieht es so aus, als sei der mittlere Ernstfall eingetreten und es verschwindet nach 7 Tagen ohne Besuch alles, was in der Session erstellt oder neu geschrieben wurde. Der Rest - was also schon da war - bleibt nach meinem jetzigen Kenntnisstand erhalten.

Wie sicher ist das?

"Etwas sicher". Weil ich es zumindest in einem zweiten Test (der gestern beendet war) so beobachtet habe. Er war aber aus verschiedenen Gründen eher unübersichtlich und es war außerdem der zweite. Weil ich den ersten versaut habe, indem ich die Domain zwischenzeitlich besucht hatte (hatte Punkt 2 der Liste oben nicht genau genug gelesen, Sorry).

Daher habe ich neue Tests aufgesetzt, die sich noch einmal genau auf diesen Fall konzentrieren und in einem sauberen Setup nachstellen. Ergebnisse gibt es - und das ist an dieser Stelle eine Ankündigung - in einer Woche in diesem Beitrag. Weil ich Safari nun eine Woche nicht anrühren kann, während ich auf Ergebnisse warte.

Was ist mit allen anderen Sessions?

Wenn jemand nicht von einer solchen Trackerdomain kommt, scheint nach meinem jetzigen Stand nichts zu passieren nach Ablauf von 7 Tagen. Aber auch das werde ich noch in einem späteren Test nachprüfen. So oder so gibt es keine Entwarnung für die Zuverlässigkeit von localStorage und IndexedDB (so unzuverlässig Browserspeicher ohnehin schon ist). Weil ein solcher Besuch mit "TIP 2.3 Bedingungen" jederzeit stattfinden kann. Wenn dann (neue oder geänderte) Werte entstehen, ist der Spaß nach einer Woche vorbei. Wie genau es bei IndexedDB aussieht, habe ich mir zudem auch noch nicht angesehen - localStorage ist schlichtweg einfacher.

Sollte man also Opt Out oder Cookie-Workarounds mit localStorage weiter betreiben?

Ich würde sagen, lieber nicht. Selbst wenn nichts an bestehenden Werten passiert, wäre z. B. ein Opt Out Marker im localStorage, der in einer Facebook Session gesetzt wird, nach 7 Tagen ohne Besuch wieder weg. Um "ITP sicher" zu sein, bleiben vermutlich nur serverseitig gesetzte oder "gehärtete" (erneuerte) Cookies. Ich werde entsprechende auf localStorage verweisende Anleitungen hier und auf gandke.de etc. noch anpassen, wenn meine Ergebnisse auf mehr als nur einem Testbein stehen - beides braucht noch etwas Zeit.

Kann ich selbst testen?

Vermutlich reicht es, eine "saubere" eigene Domain ohne bestehende Cookies und localStorage (oder eben je nach Testszenario auch mit solchen Angaben) via Link in Facebook zu besuchen, dort auf verschiedene Weise per JS oder manuell (meine ersten Tests zeigten da keine im Setup noch nachvollziehbaren - Unterschiede) localStorage Einträge zu erzeugen und dann erst an Tag 8 zurückzukehren, um zu sehen, was noch übrig ist.

Ich habe mir die Mühe gemacht, zur Differenzierung sogar eine eigene "bekannte Trackerdomain" aufzusetzen, die unter die verschärften ITP Regeln fällt (Anleitung findet sich im Blogpost zur Ankündigung von TIP 2.3, der oben verlinkt ist), um speziell von da aus ein Script zu laden, welches localStorage Einträge anlegt... aber die Mühe kann man sich sparen, wenn meine bisherige Beobachtung stimmt, dass ohnehin alles gelöscht wird, was in dieser Sitzung an Schlüsseln und Werten entstanden ist.

Der ITP Debugger (siehe ebenfalls Post zur Ankündigung) hilft übrigens auch nur wenig bis gar nicht. Er verrät zwar, welche Domains als Thirdparty betrachtet werden (und ob z. B. die eigene Testdomain dabei ist - siehe Abbildung), aber über generelle Einträge hinaus findet sich leider nichts Konkretes zu den zum Löschen markierten Einträgen, Cookies oder sonstwas. Man sieht, dass "cookie blocking" stattfindet und ggf. auch, dass Daten entfernt wurden. Mehr Details  - welche Schlüssel und Cookies, wann und warum - leider nicht.

ITP Debugger: leider keine Schwatzbacke

Da localStorage (anders als Cookies) leider nicht anzusehen ist, ob und wann ein Eintrag verschwinden wird, hilft leider nur: testen, eine Woche warten, Ergebnisse sehen. Daher wird dieser Beitrag noch ein paarmal aktualisiert werden müssen. Ich wollte nur nicht noch länger warten, bevor es zumindest diesen ersten Stand gibt 😉

© 2001 - 2019 Markus Baersch