English
Deutsch
PolskiOdczytywanie zapisanych zgód na cookies: znaczenie ciągu TC
Management Summary
Ciąg TC to zwarty zapis, za pomocą którego baner zgody przekazuje wybory dotyczące celów przetwarzania i dostawców. Odczyt zamienia niezrozumiały sygnał w informacje o tym, co system banera faktycznie zapisał. Pomaga to oceniać zgody reklamowe i analityczne na witrynie. Artykuł wyjaśnia zawartość zapisu oraz jego granice: same utrwalone sygnały nie dowodzą ważnej zgody ani tego, że podłączone usługi zastosowały się do decyzji.
Spis treści
Ciąg Transparency and Consent (TC) przechowuje sygnały przejrzystości i zgody w zwartej postaci. Platforma zarządzania zgodami (CMP) obsługuje baner i decyzje. 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. GVL zawiera zarejestrowanych dostawców i zadeklarowane cele przetwarzania.
Stały początek: 213 bitów wraz z celami
Bit może mieć wartość 0 lub 1. 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.
| Pole | Pozycje bitów | Długość |
|---|---|---|
Version |
0–5 | 6 |
Created |
6–41 | 36 |
LastUpdated |
42–77 | 36 |
CmpId |
78–89 | 12 |
CmpVersion |
90–101 | 12 |
ConsentScreen |
102–107 | 6 |
ConsentLanguage |
108–119 | 12 |
VendorListVersion |
120–131 | 12 |
TcfPolicyVersion |
132–137 | 6 |
IsServiceSpecific |
138–138 | 1 |
UseNonStandardTexts |
139–139 | 1 |
SpecialFeatureOptIns |
140–151 | 12 |
PurposesConsent |
152–175 | 24 |
PurposesLITransparency |
176–199 | 24 |
PurposeOneTreatment |
200–200 | 1 |
PublisherCC |
201–212 | 12 |
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, czyli 1 stycznia 1970 r. o 00:00 UTC. 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.
Pytania i odpowiedzi
Czy euconsent-v2 jest obowiązkowe?
Nie. CMP wybiera mechanizm przechowywania; możliwa jest inna nazwa ciasteczka albo zapis bez ciasteczek. Brak tego ciasteczka nie dowodzi ani braku, ani poprawności zarządzania zgodami.
Który interfejs przeglądarki jest właściwy?
getTCData jest przestarzałe od TCF 2.2. Wspierane rozwiązanie używa addEventListener, sprawdza powodzenie wywołania zwrotnego, stan CMP i zdarzenia, a następnie odczytuje dostępny tcString. Pierwsze wywołanie podczas ładowania CMP może zawierać niepełne dane. Jednorazowy odczyt diagnostyczny powinien usunąć nasłuch przez removeEventListener z otrzymanym identyfikatorem po uzyskaniu zamierzonego obrazu stanu. Aplikacja obserwująca późniejsze zmiany musi nadal odbierać aktualizacje przez odpowiedni aktywny nasłuch.
Jak wykrywać niepełne dane?
Dekoder sprawdza alfabet, długości pól, liczby wpisów, zakresy i typy segmentów. Samo dekodowanie Base64 nie weryfikuje zgodności z polityką. Przy dekoderach bajtowych zamiana alfabetu i ewentualne dopełnienie dotyczą każdego segmentu osobno. Bezpośrednia zamiana znaku na sześć bitów pozwala uniknąć błędnych założeń o granicach bajtów.
Brakujące bity mogą wynikać z błędów kopiowania, zapisu, kodowania albo transportu. Limit długości jest możliwą przyczyną, nie diagnozą. RFC 6265 zaleca obsługę co najmniej 4096 bajtów na ciasteczko w przeglądarkach ogólnego zastosowania, łącznie z nazwą, wartością i atrybutami; używa SHOULD, a nie MUST. Zbyt duże ciasteczko lub nagłówek może zostać odrzucony zamiast po cichu obcięty. Porównanie zapisanego ciągu, wyniku CMP API i wartości przesłanej pomaga zlokalizować różnicę.
Co obejmuje praktyczna kontrola?
Powtarzalna kontrola zapisuje decyzję testową, odpowiadający stan dialogu, odczytane sygnały celów i dostawców, istotne ograniczenia oraz właściwą wersję GVL. Obserwacja sieci pozwala następnie sprawdzić zgodność przetwarzania z oczekiwaną decyzją. Żadna pojedyncza kontrola nie potwierdza pełnej zgodności z prawem.
Powiązane artykuły
