Ciasteczka serwerowe z Cloudflare i ssGTM: zgoda i ograniczenia ITP

Cloudflare Worker może ustawiać ciasteczka przez odpowiedzi HTTP i przekazywać żądania pomiarowe do kontenera serwerowego. Zapewnia to kontrolę nad ścieżkami danych i atrybutami ciasteczek. Nie gwarantuje jednak obejścia Intelligent Tracking Prevention (ITP) w Safari, stałego czasu przechowywania ani zgodności z prawem.

Rzeczywiste ograniczenia ITP

WebKit opisuje usuwanie pamięci dostępnej do zapisu przez skrypty po siedmiu dniach używania Safari bez interakcji z witryną. Liczone są dni korzystania z Safari, a nie po prostu siedem dni kalendarzowych. Wykryte dekorowanie linków może narzucić limit 24 godzin dla ciasteczek utworzonych przez JavaScript na stronie docelowej. Nie każdy parametr adresu URL spełnia warunki takiego wykrycia.

Ciasteczka HTTP również mogą podlegać limitowi siedmiu dni po wykryciu maskowania zewnętrznego dostawcy przez CNAME lub adres IP. Znaczenie ma konkretna relacja ze stroną główną, a nie samo korzystanie z CDN. Wykrywanie adresów IP jest heurystyczne i może się zmieniać. Zgodna nazwa hosta ani udzielona zgoda nie zapewniają wyjątku od reguł przeglądarki.

Max-Age określa żądany czas ważności. Limity przeglądarki, sesje prywatne, czyszczenie i ręczne usuwanie mogą skrócić rzeczywiste przechowywanie. Jeżeli brak identyfikatora powoduje wygenerowanie nowego UUID, powstaje nowa identyfikacja, a nie odtworzenie poprzedniej tożsamości.

Atrybuty ciasteczek bez fałszywych gwarancji

Jawny cykl życia ciasteczka

Dla identyfikatora analitycznego wymagającego zgody zezwolenie musi zostać sprawdzone przed utworzeniem i odpowiednim przetwarzaniem. Dowolnie przekazany parametr żądania o wartości „granted” nie jest wiarygodnym dowodem zgody. Integracja CMP musi uwzględniać aktualny wybór, cel i wycofanie zgody.

1. Dedykowany punkt końcowy obsługuje tylko przewidziany typ żądania i sprawdzone pochodzenie. Zmiany stanu wymagają właściwego zabezpieczenia przed wywołaniami inicjowanymi z zewnątrz.
2. Bez ważnej zgody nie powstaje nowy identyfikator analityczny. Wycofanie zgody usuwa istniejące ciasteczko z pasującym zakresem i kończy dalsze wykorzystanie.
3. Przy zgodzie możliwe jest użycie istniejącej prawidłowej wartości. Brak wartości prowadzi do nowego losowego identyfikatora tylko przy dozwolonym utworzeniu.
4. Odpowiedź indywidualna jawnie wyłącza buforowanie. Współdzielone bufory stron nie mogą ponownie wykorzystywać identyfikatorów z odpowiedzi dla innych odwiedzających.
5. Klient serwerowy i każdy tag docelowy wymagają udokumentowanego powiązania uwzględniającego zgodę, brak identyfikatora i wycofanie zgody.

Poniższe nagłówki opisują nowe ciasteczko związane z hostem, z przykładowym okresem 30 dni. W miejsce symbolu zastępczego potrzebna jest bezpiecznie wygenerowana wartość losowa. Przykład nie zawiera weryfikacji CMP, punktu końcowego ani proxy i nie jest gotowym Workerem.

Cache-Control: private, no-store
Set-Cookie: __Host-fp_id=RANDOM_IDENTIFIER; Max-Age=2592000; Path=/; Secure; HttpOnly; SameSite=Lax

W obsługujących przeglądarkach prefiks __Host- wymaga Secure, Path=/ i braku Domain. Wycofanie na tym samym hoście wykorzystuje:

Cache-Control: private, no-store
Set-Cookie: __Host-fp_id=; Max-Age=0; Path=/; Secure; HttpOnly; SameSite=Lax

Istniejące ciasteczka o innych nazwach, domenach lub ścieżkach wymagają osobnych, zgodnych operacji usunięcia. Kolejne żądanie po wycofaniu zgody nie może natychmiast tworzyć nowego identyfikatora. Rzeczywista zawartość pamięci przeglądarki i żądania wyjściowe są silniejszym dowodem niż sam nagłówek usuwający.

Pierwsze żądanie nie zawiera nowego ciasteczka

Przy przekazywaniu przez fetch(request) żądanie do backendu jest już wysłane, zanim dodany nagłówek odpowiedzi Set-Cookie dotrze do przeglądarki. Nowa wartość z odpowiedzi nie pojawia się zatem wstecznie w pierwszym żądaniu do backendu. Integracja musi jawnie uwzględniać tę kolejność zamiast zakładać automatyczne mapowanie.

Własne fp_id lub __Host-fp_id nie jest też automatycznie identyfikatorem klienta GA4 albo Google Ads. Weryfikacji wymagają odpowiedzialny klient serwerowy, schematy odbiorców i wpływ na liczbę użytkowników oraz sesji. Równoległy identyfikator może zmienić dotychczasowy model tożsamości.

Google Tag Gateway jest osobnym elementem

Google Tag Gateway (GTG) dostarcza skrypty Google i obsługuje żądania pomiarowe przez skonfigurowane ścieżki własnej infrastruktury WWW. Cloudflare oferuje osobną integrację; własny Worker do ciasteczek nie jest warunkiem ani automatyczną częścią tej integracji.

GTG i kontener ssGTM wykonują różne zadania. Zgodny origin może umożliwić ponowne użycie połączenia, ale nie gwarantuje dokładnie tego samego IP dla wszystkich żądań ani określonego opóźnienia. Przekazywanie i przetwarzanie nadal wymagają dodatkowej pracy. Według Google GTG przetwarza ciasteczka First-Party Google, a inne przekazane ciasteczka First-Party odrzuca. Samo włączenie GTG nie udostępnia więc własnego identyfikatora.

Obsługa istniejącego ciasteczka _ga

Oddzielne odnawianie _ga przez HTTP wymaga sprawdzonej współpracy z tagiem Google. Skrypt musi mieć dostęp do tego ciasteczka, dlatego HttpOnly nie pasuje do zwykłej konfiguracji _ga odczytywanej przez skrypt. Nazwa, domena i ścieżka muszą odpowiadać istniejącemu ciasteczku; w przeciwnym razie mogą powstać kolejne ciasteczka zamiast odnowienia.

cookie_domain: 'auto' i cookie_update wpływają na działanie tagu Google. cookie_update: false zapobiega bieżącemu odnawianiu przez tag, ale nie zapewnia wyjątku od ITP. Dodatkowe odnowienie nie może pomijać wcześniejszej decyzji ani świadomego usunięcia. Udokumentowany domyślny czas ważności Google również nie gwarantuje czasu w przeglądarce.

Pytania i odpowiedzi

Czy ciasteczko automatycznie psuje cache Cloudflare?

Nie. Udokumentowany domyślny klucz bufora nie zawiera wszystkich wartości cookie. Niestandardowe klucze i reguły pomijania bufora mogą uwzględniać ciasteczka, a odpowiedzi z Set-Cookie osobno wpływają na możliwość buforowania. Ignorowanie ciasteczka jest właściwe tylko po potwierdzeniu niezależności treści i uprawnień dostępu od tej wartości.

Czy MISS dowodzi problemu z ciasteczkiem?

Nie. Znaczenie mają także puste lub wygasłe bufory, reguły cache i nagłówki odpowiedzi. Powtarzane żądania i obowiązująca konfiguracja wymagają wspólnej analizy.

Czy nagłówek Cookie ujawnia datę wygaśnięcia?

Nie. Zawiera nazwy i wartości, a nie pierwotne atrybuty takie jak Max-Age. Okno odnowienia wymaga osobno ustalonego mechanizmu czasowego; sama kontrola obecności nie wystarcza.

Co wymaga testów przed wdrożeniem?

Akceptacja, odmowa, wycofanie zgody, kolejne wywołania, pierwsze żądanie bez identyfikatora, żądania równoległe, zakres cookie i izolacja cache należą do testów przeglądarkowych oraz integracyjnych. Potrzebne są faktyczne wersje Safari i Chrome oraz konkretna konfiguracja GTG/ssGTM. Nie wynika z tego ogólna gwarancja czasu przechowywania ani zgodności z prawem.

Źródła

• Tracking Prevention in WebKit
• WebKit CNAME defense
• WebKit Private Browsing 2.0
• WebKit Tracking Prevention Policy
• Cloudflare default cache behavior
• Cloudflare cache keys
• Cloudflare Workers Cache API
• Cloudflare Google Tag Gateway
• Google Tag Gateway cookie handling
• Google first-party script serving
• Google cookie configuration
• MDN Set-Cookie
• Full Third-Party Cookie Blocking (WebKit)
• Cloudflare Workers documentation
• Google Analytics: Wykorzystanie ciasteczek w witrynach
• Chrome for Developers: Cookie Expires and Max-Age attributes now have upper limit
• RFC 6265: HTTP State Management Mechanism, Section 5.3
• Dyrektywa 2002/58/WE (dyrektywa o prywatności i łączności elektronicznej)