Zusammenarbeit mit der Branche bei der Weiterentwicklung von CHIPS

Im Folgenden erfahren Sie, welche zwei Probleme das Chrome-Team bei der Implementierung von CHIPS überwinden musste und warum Feedback der Community eine wichtige Rolle bei der Entwicklung des Designs spielte.

Cookies Having Independent Partitioned State (CHIPS) ist eine Privacy Sandbox-Technologie, mit der Entwickler ein Cookie für den „partitionierten“ Speicher mit separaten Cookie-Jars pro Website der obersten Ebene aktivieren können.
Beispiele für Anwendungsfälle für CHIPS sind Szenarien, in denen für websiteübergreifende Unterressourcen ein Sitzungs- oder persistenter Status erforderlich ist, der auf die Aktivitäten eines Nutzers auf einer einzelnen Website der obersten Ebene beschränkt ist, z. B. Chat-Widgets von Drittanbietern, Karten-Embeds, CDN-Lastausgleich für Unterressourcen, Headless-CMS-Anbieter usw.

CHIPS wird mit dem Ziel entwickelt, ein offener Webstandard zu werden. Das Thema wird im PrivacyCG diskutiert und es gibt seit sieben Monaten einen Ursprungstest, in dessen Rahmen das Chrome-Team hilfreiches Feedback erhalten hat. Während der Entwicklung arbeitete das Team mit wichtigen Stakeholdern zusammen, um dieses Feedback zu untersuchen. Das Ergebnis war ein aktualisiertes Design, das dem Web-Ökosystem besser gerecht wird.

Sehen wir uns zwei Herausforderungen an, mit denen das Chrome-Team bei der Implementierung von CHIPS konfrontiert war, und wie das Feedback der Community eine wichtige Rolle bei der Entwicklung des Designs spielte.

Entfernen des Hostpräfixes und keine Domain-Anforderung

Um gute Sicherheitspraktiken zu fördern, müssen Cookies gemäß dem CHIPS-Design nur über sichere Protokolle gesetzt und gesendet werden. Partitionierte Cookies müssen mit Secure festgelegt werden.

Neben diesen Anforderungen war im ursprünglichen Vorschlag das Domain-Attribut für partitionierte Cookies nicht zulässig. Wenn Domain in Cookies fehlte, konnten sie nicht zwischen verschiedenen Drittanbieter-Subdomains innerhalb einer Partition freigegeben werden.

Während des Ursprungstests erfuhr das Chrome-Team von Partnern und anderen Stakeholdern, dass die Anforderung, dass keine Domain vorhanden sein darf, die Implementierung von CHIPS für Websites mit Subdomains erschwert. So wäre es beispielsweise schwieriger für shop.example.com und pay.example.com, geteilte Keksdosen zu teilen. In anderen Fällen hat es die Authentifizierung in eingebetteten Kontexten erschwert.

Diagramm mit den Websites pay.beispiel.de und shop.beispiel.de

Das Chrome-Team hat dieses Feedback ausgewertet und ist zu dem Schluss gekommen, dass das Entfernen der Domainanforderung keine Datenschutzprobleme verursachen, sondern die Nutzerfreundlichkeit verbessern würde. Daraufhin hat das CHIPS-Produktteam eine Diskussion auf GitHub gestartet und um weiteres Feedback zur Entfernung dieser Anforderung gebeten. Mehrere Unternehmen, die CHIPS getestet haben, haben reagiert und öffentlich über die Bedeutung dieser Änderung für ihren Anwendungsfall kommentiert.

Das Chrome-Team hat das Feedback an die Privacy Community Group des W3C berücksichtigt und den aktualisierten Vorschlag vorgelegt. Firefox und Edge haben die Änderung genehmigt und Safari hat keine Bedenken geäußert. Am nächsten Tag aktualisierte das Chrome-Team Blink-Dev und stellte den Plan zum Entfernen der Anforderung im CHIPS-GitHub-Repository vor.

Das CHIPS-Team hat diese Anforderung ursprünglich vorgeschlagen, um sicherzustellen, dass Websites keine websiteübergreifenden Cookies von schädlichen oder manipulierten Subdomains erhalten, und die Möglichkeit zu verringern, Domain-Cookies als Kanal für Datenlecks zwischen Subdomains zu verwenden.

Das bot zwar zusätzliche Sicherheitsvorteile, Tableau hob jedoch hervor, dass es Herausforderungen bei der Einführung von CHIPS gab, da einige aktuelle Anwendungsarchitekturen auf der Freigabe von Cookies zwischen Subdomains basieren.

Nach dieser Änderung in Chrome teilte Tableau, das Unternehmen hinter der Visual Analytics-Plattform, das jetzt zu Salesforce gehört, Folgendes mit:

Durch die Entfernung der Namensänderung ist die Anforderung viel besser mit den vorherigen Änderungen zum Hinzufügen des Attributs „SameSite=None“ in Einklang zu bringen und daher eine bekanntere Größe. Wir sind froh, dass Google unser Feedback berücksichtigt, die Auswirkungen geprüft und die Änderung vorgenommen hat, um die Umstellung zu erleichtern. Lee Graber, Software Engineering Architect, Tableau

Durch diesen Prozess wurde die Implementierung von CHIPS für die Stakeholder vereinfacht und gleichzeitig der Datenschutz für die Nutzer gewahrt.

Die andere Herausforderung bei der Implementierung von CHIPS war das Limit für statische Cookies.
Um einen großen Arbeitsspeicherbedarf für Cookies zu vermeiden, wurde im ursprünglichen Design eine numerische Beschränkung von 10 Cookies pro Website und Partition vorgeschlagen.

Akamai hat öffentliches Feedback geäußert, dass das vorgeschlagene Limit für partitionierte Cookies für Dienste wie CDNs, die Top-Level-Domains zum Hosten der Inhalte ihrer Kunden anbieten (z. B. customer.cdn.xyz), möglicherweise nicht ausreicht. So könnten beispielsweise „customer1.cdn.xyz“ und „customer2.cdn.xyz“ beide Drittanbieterinhalte bereitstellen und jeweils mehrere eigene Cookies setzen. Wenn mehrere Kundenwebsites dieser Art auf einer anderen Website eingebettet sind, wird möglicherweise das Limit von 10 Cookies pro Partition erreicht.

Das Chrome-Team hat ähnliches Feedback in anderen Foren, bei Partnertreffen und in W3C-Diskussionen erhalten. Daher hat es nach der besten Lösung für die Herausforderung gesucht, die das Cookie-Limit in diesen Anwendungsfällen darstellt.

Diagramm mit der maximalen Anzahl von SameSite=None-Cookies, die eine einzelne Domain auf den Computern von Kunden hat
Diagramm mit der maximalen Anzahl von SameSite=None-Cookies, die eine einzelne Domain auf den Computern von Clients hat

Nachdem wir uns überlegt hatten, wie wir das Feedback der Community einbinden können, haben wir auf der TPAC 2022 eine aktualisierte Idee vorgestellt. Dabei wurde vorgeschlagen, dass CHIPS von einem statischen Limit von 10 Cookies zu einem _dynamischen_ Limit von 10 KB auf Grundlage des Arbeitsspeichers wechseln sollte. Die Analyse ergab, dass diese Änderung 99% der Anwendungsfälle im Web abdecken und die Datenschutzgrundsätze, die mit Chrome angestrebt wurden, einhalten würde (einschränkende Weitergabe zu vieler Informationen über Nutzer über Websites hinweg), während wichtige Anwendungsfälle beibehalten werden.

Andere Browseranbieter äußerten sich und erklärten, dass sie mit der aktualisierten Lösung einverstanden waren. Dies war wichtig, um sicherzustellen, dass CHIPS die browserübergreifende Unterstützung in der PrivacyCG beibehält.

Daher wurde das neue Limit in Chrome implementiert und die Lösung in das CHIPS-Design aufgenommen.

Zusammenarbeit mit der Branche

Während der Entwicklung von CHIPS haben wir uns mit vielen Partnern ausgetauscht. Diese Zusammenarbeit war entscheidend für die Verbesserung des Datenschutzes im Web.

Akamai arbeitet auf verschiedenen Gebieten mit anderen Branchenführern wie Google zusammen. Das Feedback, das wir im Fall des CHIPS-Programms gegeben haben, mag wie ein unwichtiges Detail erscheinen, aber die Änderung trägt wesentlich dazu bei, negative Auswirkungen auf gute Anwendungsfälle zu minimieren und gleichzeitig das Endziel zu erreichen. Unsere jeweiligen Organisationen arbeiten daran, das Internet auf ihre eigene Weise schneller und sicherer zu machen. Das gesamte Internet profitiert davon, wenn wir zusammenarbeiten. Martin Meyer, Senior Architect bei Akamai Technologies

CHIPS hat gezeigt, dass Feedback aus der Branche für die Verbesserung der Technologien in der Privacy Sandbox unerlässlich ist. Offene Webunterhaltungen auf GitHub, W3C-Treffen und die kontinuierliche Zusammenarbeit mit dem Chrome-Team haben direkt zu Änderungen geführt, die jetzt in der stabilen Chrome-Version eingeführt wurden. Das Chrome-Team freut sich über Feedback zu einer Vielzahl von Vorschlägen. Es hat einen großen Einfluss darauf, wie Technologien entwickelt und im Web eingeführt werden.