Einen TC-String lesen: was in den 213 Kopfbits steht
Inhalt
Auseinandersetzungen über Einwilligungen laufen meist über Behauptungen: der Banner sei so eingerichtet, die Anbieterliste sei aktuell, der String sei frisch. Alle drei stehen geschrieben, in einem Cookie namens euconsent-v2, und über keine davon muss gestritten werden – denn der String ist nicht verschlüsselt. Er ist gepackt, und ihn auszupacken braucht keinen Schlüssel.
Was folgt, ist der Aufbau dieser Packung. Sie zu kennen lohnt nicht um ihrer selbst willen, sondern weil das Lesen eines Strings in einer halben Minute klärt, was sonst zur Rückfrage beim Anbieter wird: ob das CMP geschrieben hat, was der Dialog versprochen hat, wann es das zuletzt tat und gegen welche Fassung der Anbieterliste.
Wie der String gepackt ist
Ein TC-String ist eine Folge von Feldern fester Bitlänge, hintereinander geschrieben, ohne Trennzeichen, und anschließend in websicherem Base64 kodiert – jener Spielart, die Bindestrich und Unterstrich verwendet statt der beiden Zeichen, die in einer Adresse maskiert werden müssten. Jedes Zeichen trägt genau sechs Bit.
Deshalb beginnt jeder TC-String, der einem begegnet, mit dem Buchstaben C: das erste Feld ist die Version, sechs Bit breit, und die Version 2 in sechs Bit geschrieben lautet 000010, also das Zeichen an Position 2 des Alphabets. Ein String, der anders anfängt, ist entweder keiner oder nicht Version 2 – beides ist bemerkenswert, bevor irgendetwas anderes gelesen wird.
Die 213 Bit des Kopfes
Alles bis zu den Anbietern liegt in fester Reihenfolge, und genau das macht es ohne Bibliothek lesbar.
| Feld | Bit | Was es klärt |
|---|---|---|
| Version | 6 | In der Praxis immer 2; alles andere gehört nicht zu diesem Format. |
| Erstellt, zuletzt geändert | je 36 | Zehntelsekunden seit 1970 – das Alter der Einwilligung, sekundengenau. |
| CMP-Nummer, CMP-Version | je 12 | Welches CMP den String geschrieben hat, in welchem Stand. |
| Version der Anbieterliste | 12 | Die Fassung der Liste, aus welcher der Dialog gebaut wurde. |
| TCF-Richtlinienversion | 6 | Ab 4 folgt der String den Regeln von TCF 2.2. |
| Sondermerkmale | 12 | Genauer Standort und Geräteabfrage, als zwei von zwölf möglichen Bits. |
| Zwecke, Zwecke mit Interesse | je 24 | Elf vergebene Zwecke, zweimal: Einwilligung und berechtigtes Interesse. |
Zusammen mit der Nummer des Einwilligungsdialogs, der zweibuchstabigen Sprache, dem Kennzeichen für Dienstspezifik und dem Land des Verlags ergibt das 213 Bit. Ab Bit 214 beginnen die Anbieter, und dort hört die feste Länge auf.
Warum ein String kurz und der nächste endlos ist
Anbieter werden auf eine von zwei Arten abgelegt, und der String entscheidet das je Abschnitt. Entweder als Bitfeld, ein Bit je Anbieter bis zur höchsten Nummer – was 1200 Bit kostet, wenn die Liste so weit reicht, ganz gleich wie vielen tatsächlich zugestimmt wurde. Oder als Bereiche: eine Anzahl, danach je Bereich ein Anfang und ein Ende zu je sechzehn Bit.
Wer allem zustimmt, erzeugt einen kompakten String, weil die ganze Liste in eine Handvoll Bereiche zusammenfällt. Wer fünfzig Anbieter aus achthundert auswählt, erzeugt den langen, weil jede einzelne Wahl zu einem eigenen Bereich wird. Die Länge des Cookies sagt damit etwas über die Form der Entscheidung aus und nichts darüber, wie großzügig sie war.
Was TCF 2.2 zum Fehler gemacht hat
Drei Dinge lohnt es in jedem String zu prüfen, und alle drei sind mit der Richtlinienversion 4 von Auslegungsfragen zu festen Regeln geworden.
Berechtigtes Interesse ist für die Zwecke 1, 3, 4, 5 und 6 nicht mehr zulässig. Ein String, der diese Bits trägt, stammt entweder aus der Zeit davor oder von einem CMP, das die Änderung nicht nachvollzogen hat – und das Bit ist nicht harmlos, denn Anbieter lesen es als Verarbeitungsgrundlage.
Die Zwecke 12 bis 24 gibt es im Format, aber nicht in der Spezifikation. Gesetzte Bits dort bedeuten, dass ein CMP in Felder schreibt, die niemand definiert – das deutlichste Zeichen einer selbst gebauten Umsetzung.
Und das Alter: der Änderungszeitpunkt steht im String, eine Einwilligung älter als dreizehn Monate lässt sich also allein am Cookie erkennen. Zusammen mit der Version der Anbieterliste beantwortet das die Frage, ob ein Dialog Anbieter führt, nach denen der Besucher nie gefragt wurde – denn die Liste wächst, und ein gegen eine ältere Fassung geschriebener String hat zu den Hinzugekommenen schlicht nichts zu sagen.
Die Segmente nach dem Kern
Ein String kann mehr als ein Segment tragen, durch Punkte getrennt, und jedes weitere beginnt mit drei Bit, die seine Art benennen. Art 1 führt die auf dem Gerät offengelegten Anbieter, Art 3 trägt die eigenen Zwecke des Verlags – jene, die eine Seite für sich ergänzen darf. Art 2 war das Segment der erlaubten Anbieter und ist in 2.2 entfallen.
Alles hinter dem ersten Punkt ist damit freiwillig, und sein Fehlen ist kein Mangel. Ein Mangel ist ein zweites Segment, das sich nicht entschlüsseln lässt, weil ein zwischengeschalteter Dienst das Cookie an einer Längengrenze abgeschnitten hat – die übliche Erklärung für einen String, der sich bis zu einer Stelle sauber liest und dann aufhört.
Was sich damit in der Praxis klären lässt
Drei Fragen kommen in fast jeder Prüfung vor, und der String beantwortet sie alle drei ohne fremdes Zutun. Ob das CMP geschrieben hat, was der Dialog versprach – durch den Vergleich der Zweckbits mit den getroffenen Entscheidungen. Ob der Aufbau aktuell ist – an Richtlinienversion und Version der Anbieterliste. Und ob ein Besucher auf einer Entscheidung aus einer anderen Zeit mitgeführt wird – am Änderungszeitpunkt.
Nichts davon ersetzt einen Blick in den Dialog selbst, und der String sagt nichts darüber, ob ein Anbieter sich daran hält. Aber er macht aus drei Behauptungen drei Ablesungen, und das genügt meist, um jenen Teil der Diskussion zu beenden, in dem es nie um Tatsachen ging.
Passend dazu
