Osiem usuniętych, trzy zostały
Spis treści
Na stronie stanu Privacy Sandbox 14 sierpnia 2026 to samo zdanie stoi osiem razy: zamiar wycofania i usunięcia. Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage, Fenced Frames, Related Website Sets, IP Protection. Trzy wpisy noszą inne – domyślnie wspierane, z numerem wersji Chrome obok.
Czytana jako lista strat mówi niewiele ponad to, co oczywiste. Czytana jako lista uporządkowana mówi coś, co warto zabrać ze sobą: osiem i trzy różnią się w jednym punkcie, i nie jest to ten, który podsuwa nazwa przedsięwzięcia.

Co zostało i co każdy element robi
Trzy techniki wyszły z przedsięwzięcia i zostały w przeglądarce. Żadna nie jest nowa, żadna nie była sporna, a wszystkie trzy rozwiązują problem istniejący niezależnie od tego, czy ktokolwiek sprzedaje reklamę.
| Technika | Rozwiązuje | Nie robi | Domyślnie od |
|---|---|---|---|
| CHIPS | Stan osadzenia przetrwający zmianę strony | Rozpoznanie między stronami osadzającymi | Chrome 114 |
| Storage Access API | Dostęp do nierozdzielonego ciasteczka po udzieleniu zgody | Dostęp bez gestu i bez decyzji | Chrome 119 |
| FedCM | Logowanie federacyjne bez ciasteczek zewnętrznych | Cokolwiek poza logowaniem | Chrome 108 |
Linia nie biegnie między pierwszą a trzecią stroną
Nasuwające się odczytanie brzmi: przeglądarka odrzuciła to, co służyło reklamie, a zachowała to, co służy witrynie. Sześć z ośmiu pasuje do tego gładko. Topics tworzyło profile zainteresowań, Protected Audience prowadziło aukcję, Fenced Frames wyświetlało jej wynik, Attribution Reporting liczyło konwersje, Private Aggregation zwracało liczby, a Shared Storage trzymało stan, którym pozostałe się dzieliły. IP Protection stoi nieco z boku, bo ukrywa adres zamiast zastępować ciasteczko – ale i to jest obroną przed tą samą wymianą.
Related Website Sets nie pasuje wcale. Powstało dla jednego operatora prowadzącego kilka domen – sklep na jednej, obsługa klienta na drugiej, logowanie na trzeciej – i mimo to odeszło z resztą. Powód leży w mechanizmie, nie w celu: przyznawało dostęp między witrynami na podstawie listy, którą operator deklarował sam o sobie. Przeglądarka miała uznać tę deklarację za wystarczającą.
Właśnie tam biegnie linia. Rozdzielanie nie wymaga zaufania w ogóle, bo nic nie przechodzi. Pytanie też go nie wymaga, bo odpowiedź pochodzi od pytanej strony. Zadeklarowana lista wymaga go bardzo dużo, a wykłada je przeglądarka w imieniu kogoś, kogo przy stole nie ma.
CHIPS daje każdej stronie osadzającej własne ciasteczko
Atrybut Partitioned zmienia to, co stoi w kluczu magazynu. Bez niego osadzenie ustawia jedno ciasteczko i odnajduje je wszędzie, gdzie się pojawia – dokładnie ta własność, która czyniła ciasteczka zewnętrzne użytecznymi i kosztowała je życie. Z nim do klucza wchodzi strona nadrzędna, więc to samo osadzenie na dwóch witrynach trzyma dwa ciasteczka bez związku.
Set-Cookie: __Host-widget=7f3a9c; Path=/; Secure; HttpOnly;
SameSite=None; Partitioned; Max-Age=2592000
bez Partitioned klucz = (widget.example)
jedno ciasteczko, to samo na kazdej stronie
z Partitioned klucz = (widget.example, shop.example)
(widget.example, blog.example)
jedno ciasteczko na strone, bez mostu
Dla okienka czatu, odtwarzacza wideo albo ramki płatności, która musi pamiętać coś tylko przez czas jednej wizyty, nie kosztuje to nic. Dla wszystkiego, co po cichu używało tego samego ciasteczka do rozpoznawania powrotu między witrynami, zdolność znika bezpowrotnie i żadne zestawienie atrybutów jej nie przywróci.
Storage Access API pyta, a jego skrót odszedł razem z listą
Gdy osadzenie naprawdę potrzebuje nierozdzielonego ciasteczka – zwykle chodzi o zalogowane konto w ramce – droga wiedzie przez Storage Access API. Ramka wywołuje po geście document.requestStorageAccess(), przeglądarka decyduje, a decyzja może obejmować zapytanie. Dostęp obowiązuje w bieżącym kontekście i później trzeba go poprosić na nowo.
Istniał skrót. Przez document.requestStorageAccessFor() strona nadrzędna mogła poprosić o dostęp w imieniu osadzenia, co oszczędzało zapytania w ramce, z którą nikt jeszcze nie pracował. Sens miało to wyłącznie z zadeklarowanym zbiorem pokrewnych domen w tle i zostało wycofane razem z Related Website Sets. Każde oparte na tym osadzenie musi znów pytać samo, wraz z gestem.
FedCM zastępuje łańcuch przekierowań, nie zgodę
Logowanie federacyjne działało dotąd tak, że przeglądarka szła przez dostawcę tożsamości i z powrotem, niosąc stan w przekierowaniach i ciasteczkach zewnętrznych. FedCM zastępuje mechanikę: przeglądarka sama rozmawia z dostawcą, pokazuje wybór konta jako własny interfejs, a nie treść strony, i zwraca token.
Czego nie zastępuje, to decyzja. Wybór pozostaje zapytaniem, konto nadal wskazuje się świadomie, a dostawca bez istniejącego zalogowania nie zwraca niczego. To lepiej ułożona wersja przebiegu, który i tak wymagał zgody, a nie sposób na jej ominięcie.
Co to znaczy dla toru pomiarowego
Wszystko, co zaprojektowano wokół Topics, Protected Audience czy Attribution Reporting, nie ma już celu. Taki plan nie jest spóźniony, jest bezprzedmiotowy, a rozsądną odpowiedzią jest zaprzestanie utrzymywania tej gałęzi, a nie czekanie na ogłoszenie zastępcze.
Osadzenie trzymające stan potrzebuje Partitioned i musi przyjąć, co to znaczy: identyfikator obowiązuje teraz osobno dla każdej strony osadzającej. Dla osadzenia mierzącego nie jest to wada do obejścia, lecz cały sens tego atrybutu.
Rozpoznawanie między domenami wróciło tam, gdzie stało przed przedsięwzięciem. Identyfikator pierwszej strony na domenę, łączony na serwerze, o ile istnieje ku temu podstawa prawna, a w przeciwnym razie po prostu niełączony – co i tak było zawsze uczciwą odpowiedzią, a teraz jest też jedyną. Za darmo przeglądarka nadal oferuje rozdzielanie i sposób, by zapytać. Obydwa są proste w użyciu i obydwa zapewne przetrwają następną rundę, bo są dokładnie tym, co zostawiła poprzednia.