Wir untersuchen zwei Herausforderungen, mit denen das Chrome-Team bei der Implementierung von CHIPS konfrontiert war, und die Bedeutung von Feedback der Community zur Entwicklung des Angebotsdesigns.
Cookies Having Independent Partitioned State (CHIPS) ist eine Privacy Sandbox-Technologie, mit der Entwickler Cookies für „partitionierten“ Speicher mit separaten Cookie-JAR-Dateien pro Website der obersten Ebene aktivieren können.
Anwendungsbeispiele für CHIPS sind z. B. Szenarien, in denen websiteübergreifende Unterressourcen eine Art Sitzungs- oder dauerhaften Status erfordern, der sich auf die Aktivität eines Nutzers auf einer einzelnen Website auf oberster Ebene bezieht. Dazu gehören Chat-Widgets von Drittanbietern, Karteneinbettungen, CDN-Load-Balancing für Unterressourcen, monitorlose CMS-Anbieter und mehr.
CHIPS wird mit dem Ziel entwickelt, ein offener Webstandard zu werden. Sie wird in der PrivacyCG diskutiert und das Chrome-Team hat seit sieben Monaten einen Ursprungstest durchgeführt, in dem das Chrome-Team hilfreiches Feedback erhalten hat. Während der Entwicklung arbeitete das Team mit den wichtigsten Stakeholdern zusammen, um dieses Feedback auszuwerten. Daraus entstand ein aktualisiertes Design, das dem Web-Ökosystem besser dient.
Sehen wir uns zwei Herausforderungen an, mit denen das Chrome-Team bei der Implementierung von CHIPS konfrontiert war, und erläutern wir, warum das Feedback der Community eine wichtige Rolle bei der Entwicklung des Angebotsdesigns gespielt hat.
Hostpräfix wird entfernt und es ist keine Domain-Anforderung erforderlich
Aus Sicherheitsgründen müssen beim CHIPS-Design Cookies nur über sichere Protokolle gesetzt und gesendet werden. Außerdem müssen partitionierte Cookies mit Secure gesetzt werden.
Zusammen mit diesen Anforderungen hat das erste Angebot das Attribut Domain für partitionierte Cookies nicht zugelassen. Durch das Weglassen von Domain in Cookies wurde die Freigabe zwischen verschiedenen Drittanbieter-Subdomains innerhalb einer Partition verhindert.
Während des Ursprungstests hat das Chrome-Team von Partnern und anderen Stakeholdern erfahren, dass es für Websites mit Subdomains aufgrund der Nicht-Domain-Anforderung schwierig ist, CHIPS zu implementieren. Beispielsweise wird es für shop.example.com und pay.example.com schwieriger, partitionierte Cookie-JAR-Dateien freizugeben. In anderen Fällen wurden die Authentifizierungsabläufe in eingebetteten Kontexten dadurch erschwert.
Das Chrome-Team wertete dieses Feedback aus und kam zu dem Schluss, dass das Entfernen der Nicht-Domain-Anforderung keine datenschutzrechtlichen Herausforderungen mit sich bringt, sondern die Nutzerfreundlichkeit verbessern würde. Als Reaktion darauf startete das CHIPS-Produktteam eine Diskussion auf GitHub und bat um weiteres Feedback zur Entfernung dieser Anforderung. Mehrere Unternehmen, die CHIPS testen, antworteten und öffentlich darüber, wie wichtig diese Änderung für ihren Anwendungsfall ist.
Chrome leitete das Feedback an die Privacy Community Group des W3C weiter und präsentierte den aktualisierten Vorschlag: Firefox und Edge haben die Änderung genehmigt und Safari hat keine Bedenken geäußert. Am folgenden Tag aktualisierte das Chrome-Team Blink-Dev und präsentierte im CHIPS-GitHub-Repository den Plan, die Anforderung zu entfernen.
Das CHIPS-Team schlug ursprünglich mit dieser Anforderung vor, um sicherzustellen, dass Websites keine websiteübergreifenden Cookies von schädlichen oder manipulierten Subdomains erhalten, und um die Wahrscheinlichkeit zu minimieren, dass Domain-Cookies als Kanal zum Datenleck über die Subdomain verwendet werden.
Das brachte zwar zusätzliche Sicherheitsvorteile mit sich, Tableau betonte jedoch, dass es Herausforderungen für die Einführung von CHIPS mit sich bringt, da einige aktuelle Anwendungsarchitekturen auf der Freigabe von Cookies zwischen Subdomains basieren.
Nach dieser Änderung in Chrome teilte Tableau, das Unternehmen hinter der visuellen Analyseplattform, die jetzt Salesforce gehört, Folgendes:
Durch das Entfernen der Namensänderung wird die Anforderung an die vorherigen Änderungen, das Attribut „SameSite=None“ hinzuzufügen, und damit eine „bekanntere“ Menge vorgenommen. Wir wissen es zu schätzen, dass Google das Feedback angeht, die Auswirkungen untersucht und die Änderungen so umgesetzt hat, um die Umstellung zu erleichtern. Lee Graber, Software Engineering Architect, Tableau
Durch diesen Prozess wurde die Implementierung von CHIPS für Stakeholder erleichtert und gleichzeitig die Privatsphäre der Nutzer respektiert.
Umstellung von einem statischen auf ein dynamisches Cookie-Limit
Die andere Herausforderung bei der Implementierung von CHIPS war das Limit für statische Cookies.
Um einen großen Speicherbedarf für Cookies zu vermeiden, wurde im ursprünglichen Design eine numerische Begrenzung von 10 Cookies pro Website und Partition vorgeschlagen.
Akamai hat öffentliches Feedback erhalten, dass das vorgeschlagene Limit für partitionierte Cookies möglicherweise nicht für Dienste wie CDNs ausreicht, die Top-Level-Domains zum Hosten der Inhalte ihrer Kunden anbieten (z. B. customer.cdn.xyz). Beispielsweise könnten sowohl customer1.cdn.xyz als auch customer2.cdn.xyz Drittanbieterinhalte bereitstellen und jeweils mehrere eigene Cookies setzen. Wenn mehrere Kundenwebsites wie diese auf einer anderen Website eingebettet sind, können sie die Obergrenze von 10 Cookies pro Partition erreichen.
Das Chrome-Team hörte ähnliches Feedback in anderen Foren, bei Partnermeetings und in W3C-Diskussionen. Es suchten also nach Möglichkeiten, das Problem der Cookie-Begrenzung in diesen Anwendungsfällen am besten zu lösen.
Nachdem Chrome über die Einbeziehung des Feedbacks der Community nachgedacht hatte, präsentierte Chrome beim TPAC 2022 eine aktualisierte Idee, in der CHIPS basierend auf dem Arbeitsspeicher von einem statischen Limit von 10 Cookies auf ein_dynamisches Limit von 10 KB umgestellt werden sollte. Die Analyse ergab, dass diese Änderung 99% der Anwendungsfälle im Web abdecken sollte und die Datenschutzprinzipien, die Chrome zu erreichen versuchte, beibehalten dürfte (zu viele Informationen über Nutzer zwischen Websites geteilt werden), während die Schlüsselverwendungen weiterhin beibehalten werden sollten.
Andere Browseranbieter gaben an, dass sie der aktualisierten Lösung zugestimmt haben. Diese war wichtig, um sicherzustellen, dass CHIPS die browserübergreifende Unterstützung in der PrivacyCG aufrechterhalten konnte.
Infolgedessen hat Chrome das neue Limit akzeptiert und die Lösung in das CHIPS-Design integriert.
Branchenweite Zusammenarbeit
Während der Entwicklung von CHIPS haben wir von vielen Partnern gehört, dass die Zusammenarbeit zur Verbesserung des Datenschutzes im Web von entscheidender Bedeutung ist.
Akamai pflegt in mehreren Bereichen kooperative Beziehungen mit anderen Branchenführern wie Google. Das Feedback, das wir im Rahmen des CHIPS-Programms gegeben haben, mag wie ein kleines Detail erscheinen, aber die Änderung wird maßgeblich dazu beitragen, negative Auswirkungen auf gute Anwendungsfälle zu minimieren und gleichzeitig das Endziel zu erreichen. Unsere jeweiligen Organisationen arbeiten daran, das Internet auf unsere eigene Weise schneller und sicherer zu machen, und das gesamte Internet ist besser, 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 Webkonversationen in GitHub, W3C-Meetings und die kontinuierliche Zusammenarbeit mit dem Chrome-Team haben direkt zu den Änderungen beigetragen, die jetzt in der stabilen Version von Chrome eingeführt wurden. Das Chrome-Team ist gespannt auf dieses Feedback zu einer Reihe von Vorschlägen, was entscheidend für die Entwicklung und Einführung von Technologien im Web ist.