{"id":10502,"date":"2026-09-03T15:15:00","date_gmt":"2026-09-03T13:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10502"},"modified":"2026-08-31T15:19:50","modified_gmt":"2026-08-31T13:19:50","slug":"acht-entfernt-drei-geblieben","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/data-privacy-de\/acht-entfernt-drei-geblieben\/","title":{"rendered":"Acht entfernt, drei geblieben"},"content":{"rendered":"

Auf der Statusseite der Privacy Sandbox steht am 14. August 2026 achtmal derselbe Satz: Absicht zur Abk\u00fcndigung und Entfernung. Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage, Fenced Frames, Related Website Sets, IP Protection. Drei Eintr\u00e4ge tragen einen anderen – standardm\u00e4\u00dfig unterst\u00fctzt, mit einer Chrome-Version daneben.<\/p>\n

Als Verlustliste gelesen sagt das wenig \u00fcber das Offensichtliche hinaus. Als sortierte Liste gelesen sagt es etwas, das im Ged\u00e4chtnis bleiben sollte: Die acht und die drei unterscheiden sich in einem Punkt, und es ist nicht der, den der Name des Vorhabens nahelegt.<\/p>\n

\n\"Zwei
Acht Eintr\u00e4ge tragen denselben Status, drei eine Versionsnummer. Sortiert ist nach dem, was jeder dem Browser abverlangte.<\/figcaption><\/figure>\n

Was \u00fcbrig ist und was jedes St\u00fcck leistet<\/h2>\n

Drei Techniken sind aus dem Vorhaben hervorgegangen und im Browser geblieben. Keine davon ist neu, keine war strittig, und alle drei l\u00f6sen ein Problem, das auch dann besteht, wenn niemand Werbung verkauft.<\/p>\n\n\n\n\n\n\n\n
Technik<\/th>\nL\u00f6st<\/th>\nLeistet nicht<\/th>\nStandard seit<\/th>\n<\/tr>\n<\/thead>\n
CHIPS<\/td>\nZustand einer Einbettung \u00fcber einen Seitenwechsel hinweg<\/td>\nWiedererkennung \u00fcber einbettende Seiten hinweg<\/td>\nChrome 114<\/td>\n<\/tr>\n
Storage Access API<\/td>\nZugriff auf das ungetrennte Cookie nach erteilter Erlaubnis<\/td>\nZugriff ohne Geste und ohne Entscheidung<\/td>\nChrome 119<\/td>\n<\/tr>\n
FedCM<\/td>\nF\u00f6derierte Anmeldung ohne Drittanbieter-Cookies<\/td>\nAlles au\u00dferhalb der Anmeldung<\/td>\nChrome 108<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Die Linie verl\u00e4uft nicht zwischen Erst- und Drittanbieter<\/h2>\n

Die naheliegende Lesart lautet, der Browser habe fallen lassen, was der Werbung diente, und behalten, was der Seite dient. Sechs der acht passen sauber dazu. Topics erstellte die Interessenprofile, Protected Audience f\u00fchrte die Auktion, Fenced Frames stellte deren Ergebnis dar, Attribution Reporting z\u00e4hlte die Abschl\u00fcsse, Private Aggregation lieferte die Zahlen zur\u00fcck, und Shared Storage hielt den Zustand, den die anderen teilten. IP Protection steht etwas abseits, weil es eine Adresse verbirgt statt ein Cookie zu ersetzen – aber auch das ist eine Abwehr gegen denselben Handel.<\/p>\n

Related Website Sets passt \u00fcberhaupt nicht dazu. Es war f\u00fcr einen einzigen Betreiber mit mehreren Domains gedacht – Shop auf der einen, Kundendienst auf der zweiten, Anmeldung auf der dritten – und ging trotzdem mit. Der Grund liegt im Verfahren, nicht im Zweck: Es gew\u00e4hrte seiten\u00fcbergreifenden Zugriff auf eine Liste hin, die der Betreiber \u00fcber sich selbst erkl\u00e4rte. Der Browser sollte diese Erkl\u00e4rung als hinreichend nehmen.<\/p>\n

Genau dort verl\u00e4uft die Linie. Trennen braucht \u00fcberhaupt kein Vertrauen, weil nichts hin\u00fcbergeht. Fragen braucht ebenfalls keins, weil die Antwort von der gefragten Seite kommt. Eine erkl\u00e4rte Liste braucht sehr viel davon, und aufgebracht wird es vom Browser stellvertretend f\u00fcr jemanden, der nicht am Tisch sitzt.<\/p>\n

CHIPS gibt jeder einbettenden Seite ihr eigenes Cookie<\/h2>\n

Das Merkmal Partitioned<\/code> \u00e4ndert, was im Speicherschl\u00fcssel steht. Ohne es setzt eine Einbettung ein Cookie und findet es \u00fcberall wieder, wo sie auftaucht – genau die Eigenschaft, die Drittanbieter-Cookies n\u00fctzlich machte und sie das Leben kostete. Mit ihm kommt die \u00fcbergeordnete Seite in den Schl\u00fcssel, dieselbe Einbettung auf zwei Seiten h\u00e4lt also zwei Cookies ohne Zusammenhang.<\/p>\n

Set-Cookie: __Host-widget=7f3a9c; Path=\/; Secure; HttpOnly;\n            SameSite=None; Partitioned; Max-Age=2592000\n\nohne Partitioned   Schlüssel = (widget.example)\n                   ein Cookie, auf jeder einbettenden Seite dasselbe\n\nmit Partitioned    Schlüssel = (widget.example, shop.example)\n                               (widget.example, blog.example)\n                   ein Cookie je einbettender Seite, keine Brücke<\/code><\/pre>\n
F\u00fcr ein Chatfenster, einen Videospieler oder einen Bezahlrahmen, der sich nur f\u00fcr die Dauer eines Besuchs etwas merken muss, kostet das nichts. F\u00fcr alles, was dasselbe Cookie stillschweigend zur Wiedererkennung \u00fcber Seiten hinweg benutzt hat, entf\u00e4llt die F\u00e4higkeit ersatzlos, und keine Merkmalskombination holt sie zur\u00fcck.<\/p>\n
Die Storage Access API fragt, und ihre Abk\u00fcrzung ging mit der Liste<\/h2>\n
Wo eine Einbettung das ungetrennte Cookie wirklich braucht – ein angemeldetes Konto in einem Rahmen ist der \u00fcbliche Fall -, f\u00fchrt der Weg \u00fcber die Storage Access API. Der Rahmen ruft nach einer Geste document.requestStorageAccess()<\/code> auf, der Browser entscheidet, und die Entscheidung kann eine R\u00fcckfrage einschlie\u00dfen. Der Zugriff gilt f\u00fcr den laufenden Zusammenhang und muss sp\u00e4ter erneut erbeten werden.<\/p>\n
Es gab eine Abk\u00fcrzung. Mit document.requestStorageAccessFor()<\/code> konnte die \u00fcbergeordnete Seite den Zugriff stellvertretend f\u00fcr eine Einbettung anfordern, was die R\u00fcckfrage in einem Rahmen ersparte, mit dem noch niemand gearbeitet hatte. Sinn ergab das nur mit einer erkl\u00e4rten Menge verwandter Domains dahinter, und es wurde zusammen mit Related Website Sets abgek\u00fcndigt. Jede darauf gebaute Einbindung muss wieder selbst fragen, Geste eingeschlossen.<\/p>\n
FedCM ersetzt die Weiterleitungskette, nicht die Einwilligung<\/h2>\n
F\u00f6derierte Anmeldung lief bisher so, dass der Browser \u00fcber den Anmeldedienst und zur\u00fcck geschickt wurde und den Zustand in Weiterleitungen und Drittanbieter-Cookies trug. FedCM ersetzt die Mechanik: Der Browser spricht selbst mit dem Anmeldedienst, zeigt die Kontoauswahl als Browseroberfl\u00e4che statt als Seiteninhalt und reicht ein Token zur\u00fcck.<\/p>\n
Was es nicht ersetzt, ist die Entscheidung. Die Auswahl bleibt eine R\u00fcckfrage, das Konto wird weiterhin bewusst gew\u00e4hlt, und ein Dienst ohne bestehende Anmeldung liefert gar nichts. Es ist die gesittetere Fassung eines Ablaufs, der ohnehin eine Einwilligung verlangte, und kein Weg daran vorbei.<\/p>\n
Was das f\u00fcr eine Messstrecke bedeutet<\/h2>\n
Alles, was um Topics, Protected Audience oder Attribution Reporting herum entworfen wurde, hat kein Ziel mehr. Ein solcher Plan ist nicht versp\u00e4tet, er ist gegenstandslos, und die vern\u00fcnftige Antwort ist, den Zweig nicht weiter zu pflegen, statt auf eine Ersatzank\u00fcndigung zu warten.<\/p>\n
Eine Einbettung, die Zustand h\u00e4lt, braucht Partitioned<\/code> und muss hinnehmen, was das hei\u00dft: Die Kennung gilt jetzt je einbettender Seite. F\u00fcr eine messende Einbettung ist das kein Mangel, um den herumzuarbeiten w\u00e4re, sondern der ganze Zweck des Merkmals.<\/p>\n
Wiedererkennung \u00fcber Domains hinweg steht wieder dort, wo sie vor dem Vorhaben stand. Eine Erstanbieter-Kennung je Domain, auf einem Server zusammengef\u00fchrt, sofern es daf\u00fcr eine Rechtsgrundlage gibt, und andernfalls eben nicht zusammengef\u00fchrt – was die ehrliche Antwort ohnehin immer war und jetzt auch die einzige ist. Umsonst bietet der Browser weiterhin das Trennen und eine M\u00f6glichkeit zu fragen. Beides ist einfach zu bedienen, und beides d\u00fcrfte die n\u00e4chste Runde \u00fcberstehen, denn es ist genau das, was die letzte \u00fcbrig gelassen hat.<\/p>\n
\n
Quellen<\/h2>\n