Meistens kein Banner.Aber nicht wegen der Cookies.

Cookiefrei, also einwilligungsfrei, also kein Banner. Diese Kette steht bei fast jedem datenschutzfreundlichen Analyse-Tool. Das Ergebnis stimmt in vielen Fällen, der Weg dorthin nicht, und wer sich auf die falsche Begründung stützt, merkt das erst, wenn jemand nachfragt.

§ 25 Abs. 1 TDDDG knüpft nicht an Cookies an, sondern an zwei Vorgänge: das Speichern von Informationen im Endgerät und den Zugriff auf Informationen, die dort bereits gespeichert sind. Ein Cookie ist nur der bekannteste Fall des ersten. Kein Cookie zu setzen erledigt damit die eine Hälfte der Frage, nicht beide.

Die zweite Hälfte entscheidet über den Banner: wird auf etwas zugegriffen, das im Endgerät gespeichert ist? Für Minimal und Standard lautet unsere Antwort nein, weil dort nur Statuswerte gelesen werden, die der Browser im Moment des Seitenaufrufs selbst erzeugt. Für den Modus Full lautet sie ja, weil dort eine Kennung geschrieben wird.

Wir stellen beides dar, auch die strengere Auffassung, die zu einem anderen Ergebnis kommt. Verantwortlich für die Einbindung bist du, nicht wir. Eine Behauptung in einer Feature-Liste hilft dir in einem Verfahren nicht, eine nachvollziehbare Herleitung schon.

Zwei Tatbestände, ein Wort dazwischen: oder. Speichern reicht, Zugriff reicht, beides muss nicht zusammenkommen. Ob die Informationen personenbezogen sind, spielt für § 25 keine Rolle. Die Norm schützt das Endgerät, nicht die Daten.

Speichern: in Minimal und Standard tun wir es nicht. Kein Cookie, kein localStorage, kein sessionStorage. Der Schreibpfad wird beim Build aus dem ausgelieferten Bundle entfernt, ist also im Browser nicht vorhanden und nicht bloß abgeschaltet.

Zugriff: hier steht das entscheidende Wort im Gesetz, nämlich Informationen, die „bereits in der Endeinrichtung gespeichert sind“. Was unser Skript liest, lag vorher nirgends. Die Timings entstehen während des Seitenaufbaus, window.innerWidth ist der aktuelle Fensterzustand, navigator.connection eine laufende Schätzung des Browsers. Das sind Abfragen an die Laufzeitumgebung, nicht an einen Speicher.

Grenzwertig wird es, wenn aus solchen Abfragen ein Wiedererkennungsmerkmal wird, also Fingerprinting. Deshalb übermitteln wir vom Viewport nur eine von sechs Klassen statt des Pixelwerts. Die Entropie sinkt dadurch so weit, dass eine Wiedererkennung aus dieser Kombination praktisch ausgeschlossen ist. Im Modus Full liegt der Fall anders: dort wird eine Kennung in den sessionStorage geschrieben, und ein Schreibvorgang ist unstreitig erfasst. Die Ausnahmen in § 25 Abs. 2 tragen dafür nicht: Nr. 1 erfasst nur die reine Übertragung einer Nachricht, und Nr. 2 verlangt, dass der Zugriff unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten Dienst bereitstellen kann. Eine Performance-Messung ist dieser Dienst nicht.

§ 25 TDDDG regelt den Zugriff auf das Gerät, die DSGVO die Verarbeitung danach. Beide werden getrennt geprüft, und die Antworten dürfen auseinanderfallen: kein Zugriff nach TDDDG, aber DSGVO anwendbar, ist genau unser Fall.

Die Payload-Werte selbst halten wir für nicht personenbeziehbar: nur das Land statt der IP, Klassen statt Rohwerten, Pfad ohne Query-String, keine User-ID, keine langlebige Wiedererkennung. Anwendbar ist die DSGVO trotzdem, und zwar wegen eines Datums, das wir gar nicht abfragen. Die IP-Adresse wird bei jeder Anfrage im HTTP-Header mitgesendet, und sie ist nach dem EuGH-Urteil Breyer ein personenbezogenes Datum.

Rechtsgrundlage ist die Interessenabwägung nach Art. 6 Abs. 1 lit. f DSGVO, nicht die Einwilligung. Auf der einen Seite stehen Stabilität, Performance-Messung, Basisstatistik und Fehlersuche, auf der anderen das Schutzinteresse des Besuchers. Das Risiko für ihn ist gering: kein Cross-Site-Tracking, keine Profilbildung, kein Fingerprinting. Diese Abwägung würde kippen, sobald es um eine Analyse des Nutzerverhaltens im Sinne einer Profilbildung geht. Dafür verlangt die Rechtsprechung durchgängig eine Einwilligung, von Planet49 über die BGH-Entscheidung zur Cookie-Einwilligung bis zum EuGH-Urteil zu Meta. Sie trägt hier gerade deshalb, weil fastmon kein Profil baut.

Diese Abwägung trägt nur unter Bedingungen, und die halten wir ein: IP und User-Agent werden ausschließlich zur Entgegennahme der Anfrage verarbeitet und in unter einer Sekunde verworfen, in den gespeicherten Analysedaten steht keine wiederherstellbare IP, und wir geben die Daten nicht an Dritte weiter.

Die Geschichte des Web-Trackings ist eine Kette aus Technik und Urteil. Erst wurde einfach gemessen. Dann verlangten Gerichte einen Opt-out in der Datenschutzerklärung. Dann einen Hinweis-Banner. Dann kippte „wer weitersurft, stimmt zu“. Dann kam der Consent-Banner, den wir heute kennen.

Wir gehen davon aus, dass die Anforderungen weiter steigen. Deshalb bauen wir so, dass eine Verschärfung uns nicht kalt erwischt: das Beacon lässt sich vollständig hinter eine Einwilligung schieben, die Presets nach unten schalten, und die Datenbasis ist schmal genug, dass sie auch nach einer Verschärfung noch trägt.

Restrisiko bleibt trotzdem, und zwar bei jedem Tool. Wer moderne IT einsetzt, akzeptiert es an vielen Stellen gleichzeitig, meist ohne darüber zu sprechen: Standardvertragsklauseln für US-Dienste, Transfer-Folgenabschätzungen, deren Grundlage sich ändern kann, Office-Pakete, die kein Unternehmen morgen abschaltet. Die ehrliche Frage ist nicht, ob du Restrisiko trägst, sondern welches, wie groß es ist, und ob du es bewusst getragen hast.

Unser Beitrag dazu ist Nachvollziehbarkeit. Kein Anbieter mit US-Jurisdiktion im Datenpfad, damit die Transfer-Frage bei uns gar nicht erst entsteht. Rohdaten, die die Anwendung nie erreichen. Und eine Seite wie diese, auf der die Gegenauffassung im Wortlaut steht.