English
Deutsch
PolskiEinen 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.
Fragen und Antworten
Worauf ist zu achten, wenn ein TC-String ohne Bibliothek von Hand dekodiert wird?
Auf drei Stellen, an denen gewöhnliche Werkzeuge stolpern. Die erste ist das Alphabet: Websicheres Base64 verwendet Bindestrich und Unterstrich, wo viele Standarddecoder Plus und Schrägstrich erwarten. Beide Zeichen sind dann vorher zu ersetzen, und eine fehlende Auffüllung mit „=“ ist zu ergänzen, bis die Länge durch vier teilbar ist.
Die zweite ist die Einheit. Ein Base64-Decoder liefert Bytes, die Felder des Strings halten sich aber nicht an Bytegrenzen: Die Version belegt sechs Bit, die beiden Zeitstempel je 36. Bequemer ist es deshalb, jedes Zeichen über seine Stelle im Alphabet direkt in sechs Bit zu übersetzen, denn so ist der String gebaut; Ersetzen und Auffüllen entfallen dann. Die Felder werden anschließend der Reihe nach in einer langen Folge aus Nullen und Einsen abgezählt.
Die dritte ist die Grenze des Kopfes. 213 Bit sind 35,5 Zeichen, der Kopf endet also mitten im 36. Zeichen, und dessen letzte drei Bit gehören schon zum Anbieterteil. Wer nach 35 Zeichen abschneidet, verliert das Ende des Kopfes; wer 36 nimmt, liest drei Bit zu viel. Punkte trennen zudem die Segmente und gehören nicht zum Base64, jedes Segment wird für sich dekodiert.
Was, wenn auf einer Seite kein Cookie euconsent-v2 zu finden ist?
Dann liegt der String woanders oder heißt anders. Das Framework schreibt den Speicherort nicht vor, euconsent-v2 ist nur der verbreitete Name. Verlässlich ist die Schnittstelle, die jedes TCF-CMP im Browser bereitstellen muss: Der Aufruf __tcfapi('getTCData', 2, d => console.log(d.tcString)) in der Konsole liefert den aktuellen String im Feld tcString, gleich wo das CMP ihn aufbewahrt.
Woran lässt sich ein abgeschnittener String erkennen, bevor ein Segment unlesbar wird?
An einer Rechnung, die der String selbst erlaubt. Nach Bit 213 folgt im Kernsegment zuerst die höchste Anbieternummer, die der Abschnitt abdeckt, und dann das Kennzeichen, ob ein Bitfeld oder Bereiche folgen. Beim Bitfeld steht damit fest, wie viele Bit der Abschnitt belegt: eines je Anbieter bis zu dieser Nummer. Ist der Rest des Strings kürzer, fehlt etwas. Bei Bereichen nennt eine Anzahl vorab, wie viele Einträge folgen, und auch dann zeigt sich beim Durchgehen, ob der String vor dem letzten Eintrag endet.
Als Ursache kommen zwei Grenzen infrage. Browser müssen nach RFC 6265 mindestens 4096 Byte je Cookie unterstützen, gemessen an Name, Wert und Attributen; Server und vorgeschaltete Dienste begrenzen zudem die Größe der Header einer Anfrage, in denen alle Cookies einer Domain gemeinsam reisen. Ein String, der knapp an einer solchen Grenze endet, ist verdächtig, auch wenn sich das Kernsegment noch vollständig liest.
Passend dazu
