Czytanie ciągu TC: co stoi w 213 bitach nagłówka

Spory o zgody toczą się zwykle na twierdzeniach: baner jest tak skonfigurowany, lista dostawców jest aktualna, ciąg jest świeży. Wszystkie trzy są zapisane, w ciasteczku o nazwie euconsent-v2, i o żadne z nich nie trzeba się spierać – bo ciąg nie jest zaszyfrowany. Jest upakowany, a jego rozpakowanie nie wymaga klucza.

Poniżej opisana jest budowa tego pakunku. Warto ją znać nie dla niej samej, lecz dlatego, że odczytanie ciągu wyjaśnia w pół minuty to, co inaczej zamienia się w pytanie do dostawcy: czy CMP zapisało to, co obiecywał dialog, kiedy zrobiło to ostatnio i wobec której wersji listy dostawców.

Jak ciąg jest upakowany

Ciąg TC to sekwencja pól o stałej długości bitowej, zapisanych jedno po drugim, bez separatorów, a następnie zakodowanych w Base64 w wariancie bezpiecznym dla sieci – tym, który używa myślnika i podkreślenia zamiast dwóch znaków wymagających maskowania w adresie. Każdy znak niesie dokładnie sześć bitów.

Dlatego każdy napotkany ciąg TC zaczyna się literą C: pierwszym polem jest wersja o szerokości sześciu bitów, a wersja 2 zapisana na sześciu bitach to 000010, czyli znak na pozycji 2 alfabetu. Ciąg zaczynający się inaczej albo nie jest ciągiem TC, albo nie jest wersją 2 – i jedno, i drugie warto zauważyć, zanim odczyta się cokolwiek innego.

213 bitów nagłówka

Wszystko aż do dostawców leży w stałej kolejności i właśnie to czyni ciąg czytelnym bez biblioteki.

Wraz z numerem ekranu zgody, dwuliterowym językiem, znacznikiem specyfiki usługi i krajem wydawcy daje to 213 bitów. Od bitu 214 zaczynają się dostawcy i tam stała długość się kończy.

Dlaczego jeden ciąg jest krótki, a następny bez końca

Dostawcy zapisywani są na jeden z dwóch sposobów, a ciąg wybiera to osobno dla każdej sekcji. Albo jako pole bitowe, jeden bit na dostawcę aż do najwyższego numeru – co kosztuje 1200 bitów, jeśli lista tak daleko sięga, niezależnie od tego, ilu faktycznie udzielono zgody. Albo jako zakresy: liczba, a potem dla każdego zakresu początek i koniec po szesnaście bitów.

Kto zgadza się na wszystko, tworzy ciąg zwarty, bo cała lista zapada się w garść zakresów. Kto wybiera pięćdziesięciu dostawców z ośmiuset, tworzy ten długi, bo każdy pojedynczy wybór staje się własnym zakresem. Długość ciasteczka mówi więc coś o kształcie decyzji, a nic o tym, jak hojna ona była.

Co TCF 2.2 zamieniło w błąd

Trzy rzeczy warto sprawdzić w każdym ciągu, a wszystkie trzy wraz z wersją polityki 4 przeszły z kwestii wykładni w twarde reguły.

Uzasadniony interes nie jest już dopuszczalny dla celów 1, 3, 4, 5 i 6. Ciąg niosący te bity pochodzi albo sprzed tej zmiany, albo od CMP, które jej nie uwzględniło – a bit nie jest niewinny, bo dostawcy czytają go jako podstawę przetwarzania.

Cele od 12 do 24 istnieją w formacie, ale nie w specyfikacji. Ustawione tam bity oznaczają, że CMP zapisuje do pól, których nikt nie definiuje – to najwyraźniejszy znak wdrożenia zrobionego na własną rękę.

I wiek: znacznik zmiany stoi w ciągu, zgodę starszą niż trzynaście miesięcy da się więc rozpoznać po samym ciasteczku. Razem z wersją listy dostawców odpowiada to na pytanie, czy dialog prowadzi dostawców, o których odwiedzającego nigdy nie zapytano – bo lista rośnie, a ciąg zapisany wobec starszej wersji po prostu nie ma nic do powiedzenia o nowo dodanych.

Segmenty za segmentem głównym

Ciąg może nieść więcej niż jeden segment, rozdzielony kropkami, a każdy kolejny zaczyna się trzema bitami nazywającymi jego rodzaj. Rodzaj 1 wymienia dostawców ujawnionych na urządzeniu, rodzaj 3 niesie własne cele wydawcy – te, które witryna może dodać dla siebie. Rodzaj 2 był segmentem dostawców dozwolonych i w 2.2 odpadł.

Wszystko za pierwszą kropką jest zatem dobrowolne, a jego brak nie jest usterką. Usterką jest drugi segment, którego nie da się zdekodować, bo pośrednicząca usługa obcięła ciasteczko na granicy długości – to zwykłe wyjaśnienie ciągu, który czyta się czysto do pewnego miejsca, a potem się urywa.

Co da się dzięki temu wyjaśnić w praktyce

Trzy pytania pojawiają się niemal w każdej kontroli, a ciąg odpowiada na wszystkie trzy bez niczyjego udziału. Czy CMP zapisało to, co obiecywał dialog – przez porównanie bitów celów z podjętymi decyzjami. Czy układ jest aktualny – po wersji polityki i wersji listy dostawców. I czy odwiedzający prowadzony jest na decyzji z innej epoki – po znaczniku zmiany.

Odczyt ciągu nie zastępuje sprawdzenia samego dialogu i nie mówi, czy dostawca respektuje zapisaną decyzję. Pozwala jednak zastąpić trzy twierdzenia trzema informacjami, które można bezpośrednio odczytać. Zwykle wystarcza to do wyjaśnienia tej części sporu, która opierała się dotąd wyłącznie na twierdzeniach.