English
Deutsch
PolskiCzas życia ciasteczka: trzy limity przeglądarek i jak sposób jego ustawienia je zmienia
Spis treści
Nagłówek ciasteczka to prośba, a nie polecenie. Max-Age=63072000 prosi o dwa lata, a to, co przeglądarka przyzna, zależy od czegoś, czego w nagłówku w ogóle nie ma: od tego, jak ciasteczko powstało. Ten sam wiersz daje raz dwa lata, a raz siedem dni, i nic w odpowiedzi nie mówi, który przypadek zachodzi.
Różnica sięga dalej niż porządek. Powracający odwiedzający powraca tylko tak długo, jak istnieje ciasteczko, które go rozpoznaje; gdy zniknie, liczy się jako nowy, a każde okno dłuższe niż życie ciasteczka liczy na danych, których już nie ma.
Trzy obcięcia
Safari skraca każde ciasteczko zapisane przez document.cookie do siedmiu dni. To reguła o największym skutku praktycznym, bo większość ciasteczek pomiarowych powstaje właśnie tak – przez tag działający w stronie.
Te same siedem dni Safari stosuje do ciasteczek przychodzących w odpowiedzi HTTP z hosta, który przez CNAME rozwiązuje się gdzie indziej. Chodzi o układ, w którym subdomena witryny wskazuje na dostawcę pomiarów; skutkiem jest to, że poprawnie ustawione ciasteczko własne traktowane jest jak obce.
Chrome i Firefox obcinają przy 400 dniach. Ta liczba rzadko boli – leży powyżej każdego rozsądnego okna pomiarowego – ale po cichu kończy dwuletnie ciasteczko, które tkwi w szablonie tagu od 2018 roku.
Dlaczego rozstrzyga droga, a nie atrybut
Dwa ciasteczka o identycznych atrybutach mogą mieć różny czas życia, a jedyną różnicą jest to, kto je zapisał. Ciasteczko ustawione przez skrypt w stronie zostaje skrócone; to samo ciasteczko w odpowiedzi własnego serwera nie.
Dlatego przeniesienie ciasteczka do odpowiedzi jest najskuteczniejszą pojedynczą zmianą: kosztuje jeden punkt końcowy na własnej domenie i stanowi różnicę między tygodniem rozpoznawania a rokiem. Tag wtedy ciasteczko czyta, zamiast je zapisywać.
Przenosiny mają drugi skutek wart wzmianki: ciasteczko zapisane w odpowiedzi może nieść HttpOnly, a ciasteczka z HttpOnly nie odczyta żaden skrypt strony – także żaden z tych, których nikt tam świadomie nie umieścił.
Co zmienia w tym CNAME
Subdomena wskazująca na dostawcę wygląda w pasku adresu na własną, a dla przeglądarki jest przezroczysta: łańcuch rozwiązywania leży otworem, a przeglądarka widzi, że host kończy się gdzie indziej. Właśnie tam zaczepia obrona.
Skutek warto zaplanować, zamiast go odkrywać: układ zbudowany po to, by uciec przed ograniczeniami dla podmiotów trzecich, dziedziczy w Safari obcięcie do siedmiu dni, a w zamian zyskuje subdomenę, której awaria zabiera ze sobą cały pomiar. Gdy punkt końcowy działa na własnej infrastrukturze, nie zachodzi ani jedno, ani drugie.
Atrybuty, na których ciasteczko przepada
| Zapisane tak | Co się dzieje |
|---|---|
SameSite=None bez Secure |
Odrzucane wprost przez każdą bieżącą przeglądarkę – ciasteczko nigdy nie zostaje zapisane. |
Zupełny brak SameSite |
Traktowane jak Lax, ciasteczka brakuje przy zapytaniach z obcych witryn. |
__Host- z Domain |
Odrzucone: przedrostek zabrania Domain i wymaga Secure oraz Path=/. |
| Nazwa i wartość powyżej 4096 bajtów | Odrzucane bez słowa – tak przestaje docierać rozrośnięty ciąg zgody. |
Max-Age i Expires razem |
Wygrywa Max-Age. Expires jest tylko dla przeglądarek, których nikt już nie ma. |
Wszystkie przepadają w ten sam sposób: odpowiedź jest w porządku, a ciasteczka po prostu potem nie ma. Jedyną wiarygodną kontrolą jest spojrzenie na to, co przeglądarka zapisała, a nie na to, co zostało wysłane.
Co z tego wynika dla pomiaru
Siedmiodniowe ciasteczko zamienia odwiedzającego wracającego po ośmiu dniach w nowego. W raporcie widać to jako udział powracających niższy w Safari niż wszędzie indziej i jako ścieżki konwersji krótsze niż cykl sprzedaży – nie dlatego, że podróż była krótka, lecz dlatego, że jej wcześniejsza część już do niej nie należy.
Tam, gdzie ciasteczka nie da się wydłużyć, uczciwą odpowiedzią jest skrócenie okna, a nie dalsze podawanie takiego, którego dane nie udźwigną. Trzydziestodniowe okno atrybucji nad siedmiodniowym ciasteczkiem opisuje okres, którego przeglądarka nie pamięta, a każda wyprowadzona z niego liczba dziedziczy tę lukę.
Pytania i odpowiedzi
Czy ciasteczko zapisane przez skrypt przedłuża się, gdy tag zapisuje je na nowo przy każdej wizycie?
Tak, ale tylko do pierwszej dłuższej przerwy. Każdy zapis przez document.cookie ustawia w Safari nowy termin siedmiu dni, liczony od tej chwili. Odwiedzający, który wraca w ciągu siedmiu dni, pozostaje więc rozpoznany, i to dowolnie długo; kto nie pojawi się przez osiem dni, wraca jako nowy, tak jak opisuje artykuł.
Czy wystarczy podpiąć subdomenę do własnego punktu końcowego pomiaru rekordem A zamiast CNAME?
Niekoniecznie. Od Safari 16.4 WebKit sprawdza oprócz łańcucha CNAME także adres IP: jeśli serwer odpowiadający na subdomenie leży w wyraźnie innym zakresie adresów niż sama witryna, Safari również skraca ciasteczka z jego odpowiedzi do siedmiu dni. Rekord A wskazujący na serwer u dostawcy chmury, podczas gdy główna witryna działa zupełnie gdzie indziej, omija więc regułę CNAME, a mimo to trafia na to samo obcięcie.
„Własna infrastruktura” w rozumieniu artykułu oznacza zatem, że punkt końcowy odpowiada z tego samego zakresu adresów co witryna, na przykład dlatego, że witryna i punkt końcowy stoją za tym samym serwerem lub tą samą siecią pośredniczącą, albo że punkt końcowy działa pod ścieżką głównej domeny, która wewnętrznie przekazuje żądanie dalej. Czy to się udało, pokazuje ta sama kontrola co przy atrybutach: data wygaśnięcia zapisana w Safari, a nie wysłany nagłówek.
Co przeniesienie ciasteczka do odpowiedzi serwera zmienia w kwestii zgody i jej wycofania?
W kwestii zgody nic. O tym, czy ciasteczko wymaga zgody, decyduje jego cel, a nie droga, którą powstaje; zapisywane na urządzeniu i odczytywane z niego jest tak czy inaczej. Ciasteczko pomiarowe z odpowiedzi serwera wymaga więc tej samej zgody co wcześniej, a punkt końcowy musi znać stan zgody, zanim je ustawi. Dłuższy czas życia należy też podać tam, gdzie mowa o okresie przechowywania: w banerze zgody i w polityce prywatności.
Przy wycofaniu zgody zmienia się natomiast coś konkretnego. Ciasteczka z HttpOnly nie usunie żaden skrypt strony, w tym skrypt banera zgody. Wycofanie musi więc wywołać żądanie do własnego serwera, który usunie ciasteczko odpowiedzią z Max-Age=0; w przeciwnym razie ciasteczko przetrwa wycofanie aż do końca swojego czasu życia, a ten może teraz wynosić rok.
Jak sprawdzić, jaki czas życia przeglądarka rzeczywiście przyznała ciasteczku?
Porównując dwa miejsca w narzędziach deweloperskich, osobno w każdej przeglądarce:
- Nagłówek Set-Cookie w panelu sieci pokazuje prośbę, czyli Max-Age lub Expires w postaci wysłanej przez serwer.
- Panel pamięci pokazuje to, co przyznano: datę wygaśnięcia faktycznie zapisaną przez przeglądarkę. Przy ciasteczku zapisanym przez skrypt z prośbą o dwa lata Safari pokazuje datę za siedem dni, a Chrome i Firefox datę za 400 dni.
- Jeśli ciasteczka w pamięci w ogóle nie ma, przepadło na jednym z atrybutów z tabeli. Chrome oznacza odrzucone ciasteczka w szczegółach danego żądania i podaje przyczynę.
Reguły siedmiu dni pochodzą z silnika WebKit i da się je zmierzyć tylko tam, czyli w Safari; test w Chrome na komputerze pokaże co najwyżej 400 dni. Spojrzenie w raport również nie zastępuje tej kontroli: niższy udział powracających w Safari jest skutkiem, a nie dowodem przyczyny.
Źródła
Powiązane artykuły
