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

Ciąg TC przechowuje sygnały przejrzystości i zgody w zwartej postaci. Dekodowanie ujawnia zapisane wartości: bity celów, decyzje dotyczące dostawców i wersję listy dostawców. Sam odczyt nie dowodzi poprawności banera, ważności zgody ani respektowania decyzji przez dostawcę.

Format jest kodowany, a nie szyfrowany. Odczyt nie wymaga tajnego klucza. Ciąg nie jest również podpisanym dziennikiem audytu. Rzetelna kontrola łączy więc sygnały z rzeczywistym dialogiem, właściwą Global Vendor List (GVL) i obserwowanymi żądaniami.

Stały początek: 213 bitów wraz z celami

Każdy segment używa alfabetu Base64url, a jeden znak reprezentuje sześć bitów. Segmenty oddzielają kropki. Pierwsze sześć bitów zawiera wersję formatu: wartość 2 daje 000010, czyli znak C. Początkowe C wskazuje tę wartość pola wersji, ale nie potwierdza poprawności całego ciągu.

Segment główny zaczyna się od poniższych pól w podanej kolejności. Pozycje bitów liczone są od zera: pozycja 0 oznacza pierwszy bit. Stałe 213 bitów obejmuje już bity celów. Dane dostawców zaczynają się na pozycji 213, czyli od 214. bitu.

Stały początek kończy się po pierwszych trzech bitach 36. znaku Base64url. Pozostałe trzy bity należą już do danych dostawców. Pierwszych 35 znaków nie wystarcza; 36 pełnych znaków zawiera więcej niż stały początek.

Osobna interpretacja dat i wersji

Pola czasu nadal mają 36 bitów i wyrażają dziesiąte części sekundy od epoki Uniksa. Zgodnie z aktualną specyfikacją Created i LastUpdated zawierają jednak tę samą datę aktualizacji z dokładnością do dnia UTC. Pomnożenie przez 100 daje milisekundy JavaScript. Jednostka zapisu nie oznacza rejestracji czynności wyrażenia zgody z dokładnością do jednej dziesiątej sekundy.

Stara data aktualizacji uzasadnia sprawdzenie odnawiania wyborów i przypomnień. Aktualna data nie dowodzi świeżej zgody, a porównanie z okresem trzynastu miesięcy nie odtwarza historii zgód. Specyfikacja techniczna odwołuje się do przypomnień co najmniej raz na trzynaście miesięcy. Ciąg nie zastępuje związanych z tym dowodów.

Wersja formatu 2, wersje frameworka takie jak TCF 2.3 lub 2.4, wersja polityki i wersja GVL to różne identyfikatory. Wartość polityki 4 wprowadzono wraz z TCF 2.2. Wartość co najmniej 4 nie dowodzi wdrożenia wszystkich aktualnych wymagań. VendorListVersion wskazuje wykorzystaną wersję GVL, a nie faktyczne pokazanie w dialogu wszystkich dostawców z tej listy.

Sekcje dostawców: długość nie mierzy zgody

Sekcja dostawców zaczyna się od 16-bitowego maksymalnego identyfikatora i jednobitowego oznaczenia kodowania. Przy polu bitowym następuje po jednym bicie na każdy identyfikator do tej granicy. Kodowanie zakresami dodaje 12-bitową liczbę wpisów. Każdy wpis zawiera flagę zakresu oraz 16-bitowy identyfikator początkowy lub pojedynczy. Kolejne 16 bitów z końcem występuje tylko przy zakresie.

Dla maksymalnego identyfikatora 800 pole bitowe wraz z początkiem sekcji zajmuje 817 bitów. Pięćdziesiąt pojedynczych identyfikatorów zapisanych zakresami wymaga 879 bitów: 17 + 12 + 50 × 17. Jeden ciągły zakres wymaga tylko 62 bitów: 17 + 12 + 33. Przy wyborze krótszej reprezentacji w pierwszym przypadku wygrywa pole bitowe, a w drugim zakres. Zgoda na wszystko nie gwarantuje zatem zawsze krótkiego ciągu.

Zgody dostawców i sygnały uzasadnionego interesu znajdują się w odrębnych sekcjach. Ograniczenia wydawcy i dodatkowe segmenty również wpływają na długość. Długi ciąg sam w sobie nie oznacza szerokiej zgody, uszkodzenia ani dużej liczby wybranych dostawców.

Aktualne reguły poza układem bitów

TCF 2.2 usunęło uzasadniony interes jako dopuszczalną podstawę dla celów 3–6. Dla celu 1 już wcześniej przewidziana była zgoda; zależna od jurysdykcji flaga PurposeOneTreatment dotyczy innej kwestii. Cele specjalne mają osobną przestrzeń numerów i nie należą do zwykłych bitów celów.

Przy obecnie zdefiniowanych celach 1–11 zarezerwowane pozycje 12–24 nie oznaczają dodatkowych wyborów. Nieoczekiwanie ustawione bity wymagają porównania z właściwą specyfikacją i GVL. Taki wynik wskazuje niespójność, a nie autora implementacji. Same sygnały celu nie uprawniają też każdego dostawcy do przetwarzania: znaczenie mają sygnały dostawcy, ujawnienie, zadeklarowane cele i ograniczenia wydawcy.

TCF 2.3 wprowadziło obowiązkowy segment DisclosedVendors dla ciągów tworzonych od 1 marca 2026 r. Starsze ciągi bez tego segmentu zachowują wyjątek przejściowy; brak segmentu nie jest więc identycznym ustaleniem dla każdego historycznego ciągu. Typ segmentu 1 oznacza ujawnionych dostawców, a opcjonalny typ 3 cele wydawcy. Dawny typ 2, dotyczący dozwolonych dostawców, usunięto w TCF 2.2.

TCF 2.4 wprowadziło następnie zaktualizowane informacje o funkcjach. Oficjalny termin wdrożenia dla środowisk WWW upłynął 23 października 2026 r., a dla aplikacji mobilnych i CTV upływa 23 lutego 2027 r. Nie zmienia to sześciobitowego pola wersji formatu na 2.4. Dekoder bitów nie sprawdza wymaganych tekstów ani sposobu prezentacji dialogu.