Privacy Sandbox po wycofaniach: które technologie Chrome zachowuje i co to oznacza dla pomiaru

Privacy Sandbox nie jest pojedynczym przełącznikiem prywatności ani reklamy. Google rozwija część technologii, wycofuje inne i rezygnuje z kolejnych propozycji. Strona stanu sprawdzona 24 października 2026 r. podaje datę aktualizacji 14 sierpnia 2026 r. Dawny skrót „osiem usuniętych, trzy pozostałe” nie opisuje poprawnie tego zestawienia.

Podsumowanie wymienia osiem pozycji w kategorii „Deprecate and remove”: Aggregation Service, Attribution Reporting, Fenced Frames, Private Aggregation, Protected Audience, Related Website Sets wraz z requestStorageAccessFor(), Shared Storage wraz z Select URL oraz Topics. IP Protection znajduje się natomiast obok Partitioned Popins i Related Website Partition w kategorii „Discontinue”. Kolejne propozycje oznaczono jako „Do not launch”. Taki status nie potwierdza, że każda zainstalowana wersja Chrome już usunęła dany interfejs.

CHIPS, Storage Access i FedCM pozostają ważnymi elementami

CHIPS, Storage Access i FedCM należą do nadal wspieranych technologii, ale nie stanowią pełnej listy pozostałych rozwiązań. Zestawienie wymienia również między innymi Private State Tokens, Storage and Network State Partitioning, User-Agent Client Hints oraz frame-ancestors. Trzy poniższe API służą różnym celom; numery wersji oznaczają pierwotną dostępność w Chrome, a nie zakres wszystkich późniejszych rozszerzeń.

Sama granica techniczna nie wyjaśnia decyzji

W ogłoszeniu z 17 października 2025 r. Google wskazuje opinie ekosystemu, oczekiwaną wartość i niewielkie wykorzystanie jako przyczyny wycofania kilku rozwiązań. Komunikat Chromium dotyczący Related Website Sets odwołuje się dodatkowo do utrzymanej strategii cookies i niewielkiego lub malejącego użycia. Ogólna zasada „partycjonowanie nie potrzebuje zaufania, a listy wymagają zbyt wiele” nie jest więc udokumentowaną przyczyną tych decyzji.

Related Website Sets miało ułatwiać ograniczony dostęp do niepartycjonowanych cookies między powiązanymi witrynami. Wymagało to uznanego zestawu i wywołań API; dowolna samodzielnie opublikowana lista nie otwierała automatycznie nieograniczonego dostępu między domenami. Usunięcie Related Website Sets dotyczy także document.requestStorageAccessFor(), ale nie zastępuje nadal wspieranego ogólnego Storage Access API.

Chrome nie zlikwidował również powszechnie cookies stron trzecich. 22 kwietnia 2025 r. Google potwierdziło dotychczasowy wybór w ustawieniach i zrezygnowało z nowego osobnego okna pytania. W trybie incognito cookies stron trzecich są domyślnie blokowane. Inne przeglądarki, ustawienia i zasady mogą wprowadzać odmienne ograniczenia.

CHIPS rozdziela cookies według witryny najwyższego poziomu

Atrybut Partitioned dodaje witrynę najwyższego poziomu do przypisania cookie w magazynie. Witryna oznacza połączenie schematu i rejestrowalnej domeny, a nie każdy adres URL ani koniecznie każdą subdomenę. Dwie strony HTTPS pod tą samą rejestrowalną domeną mogą zatem należeć do tej samej witryny.

Set-Cookie: __Host-widget=example-value; Path=/; Secure; HttpOnly; SameSite=None; Partitioned; Max-Age=2592000

Uproszczone przypisanie partycji (bez nazwy/ścieżki):
(widget.example, https://shop.example)
(widget.example, https://blog.example)
Osobne magazyny cookies dla dwóch witryn najwyższego poziomu.

Przykład pokazuje jeden nagłówek odpowiedzi HTTP, a poniżej uproszczone przypisanie. Pełny klucz cookie obejmuje dalsze cechy, na przykład nazwę i ścieżkę. Przykładowa wartość nie jest produkcyjnym tokenem sesji. CHIPS wymaga Secure; prefiks __Host- dodatkowo wymaga Path=/ i braku atrybutu Domain. HttpOnly blokuje dostęp przez document.cookie.

Max-Age=2592000 oznacza 30 dni i stanowi jedynie przykładowy czas życia. CHIPS nie ogranicza się do jednej wizyty. Czas życia i zapisana treść muszą odpowiadać funkcji. Czat lub ramka płatności może zachowywać stan w obrębie jednej witryny, natomiast istniejący proces obejmujący kilka witryn może wymagać zmian.

Partycjonowanie zapobiega automatycznemu współdzieleniu tego cookie między różnymi witrynami najwyższego poziomu. Nie gwarantuje anonimowości ani braku innych dozwolonych powiązań kont. Przeglądarka nie generuje też automatycznie różnych wartości cookies: rozdzielenie dotyczy obszarów przechowywania.

Storage Access: uprawnienie i aktywacja to różne kroki

Osadzenie może przez document.requestStorageAccess() poprosić o dostęp do inaczej blokowanych niepartycjonowanych cookies albo obsługiwanych rodzajów pamięci. Przeglądarka może zezwolić na dostęp lub odrzucić żądanie. Początkowy dostęp wymagający zatwierdzenia często potrzebuje interakcji z osadzoną treścią.

Nowy gest i nowe okno zatwierdzenia nie są jednak obowiązkowe przy każdym wywołaniu. Chrome może ponownie wykorzystać istniejące uprawnienie; dokumentacja opisuje 30 dni, przedłużanych przez dalszą interakcję. Przy określonych warunkach aktywne logowanie FedCM może także działać jako sygnał zaufania. Uprawnienie i aktywacja dostępu w konkretnym dokumencie pozostają różnymi krokami. Implementacje przeglądarek różnią się szczegółami.

Po zniknięciu skrótu RWS integracja potrzebuje właściwego alternatywnego procesu, na przykład bezpośredniego żądania z osadzonego dokumentu. Brak uprawnienia i odrzucone żądanie wymagają obsługi jako zwykłe przypadki. Stwierdzenie „od teraz za każdym razem kolejne kliknięcie” nie opisuje poprawnie API.

FedCM pośredniczy w logowaniu, nie daje ogólnej zgody na przetwarzanie

FedCM pośredniczy między witryną i dostawcą tożsamości przez przeglądarkę oraz może umożliwiać logowanie bez cookies stron trzecich. Tradycyjne logowanie federacyjne nie zawsze zależy od takich cookies: proces z przekierowaniem może używać cookies w kontekście pierwszej strony. FedCM wymaga odpowiednich punktów końcowych dostawcy tożsamości i integracji w witrynie.

Przy pierwszym powiązaniu lub logowaniu może pojawić się wybór konta. Dla wcześniej powiązanych kont FedCM obsługuje automatyczne ponowne uwierzytelnienie przy określonych warunkach. Stan wylogowania może wymagać procesu logowania u dostawcy tożsamości; ogólne twierdzenie „brak istniejącego logowania oznacza brak wyniku” jest zbyt wąskie. Inne ścieżki logowania pozostają potrzebne dla nieobsługiwanych przeglądarek i błędów.

Uprawnienie przeglądarki lub wybór konta nie jest automatycznie prawną zgodą na dodatkowe przetwarzanie. Google wyraźnie zaznacza, że ewentualna wymagana zgoda na cele wykraczające poza uwierzytelnianie musi zostać uzyskana osobno.

Skutki dla istniejących pomiarów i osadzeń

Nowe zależności od wycofywanych API zwiększają ryzyko utrzymania. Istniejące integracje wymagają inwentaryzacji: jaki interfejs jest faktycznie wywoływany, jakie pomiary znikną i jaki sprawdzony wariant zastępczy jest dostępny? Usuwanie i migracja powinny uwzględniać konkretną wersję Chrome, wskazówki dostawcy i testy aplikacji.

Nie każde osadzenie zachowujące stan koniecznie wymaga Partitioned. Zależnie od funkcji możliwe są partycjonowane cookies lub inne partycjonowane magazyny, Storage Access, FedCM albo integracja w kontekście pierwszej strony. Łączenie identyfikatorów na serwerze także nie jest uniwersalnym zamiennikiem, a przeniesienie przetwarzania na serwer samo w sobie nie zapewnia zgodności z prawem.

Google wprost wymienia dalsze prace nad interoperacyjnym standardem Attribution. Nie oznacza to ani natychmiast dostępnego zamiennika, ani końca każdego pomiaru wspomaganego przez przeglądarkę. Dalsze wsparcie API również nie gwarantuje niezmienionej dostępności w długim okresie.