Drittanbieter-Cookies haben viele Verwendungsmöglichkeiten, sind aber auch ein wichtiger Faktor für websiteübergreifendes Tracking.
Chrome bietet Nutzern eine neue Möglichkeit, die Verwendung von Drittanbieter-Cookies zu steuern. Sie müssen Ihre Website für Nutzer vorbereiten, die ohne Drittanbieter-Cookies surfen möchten.
Auf dieser Seite finden Sie Informationen zu datenschutzfreundlichen Lösungen für eingebettete Szenarien, die bisher auf Drittanbieter-Cookies basierten, sowie Strategien, mit denen Sie die für Ihre Anforderungen am besten geeignete Lösung auswählen können.
Zu den eingebetteten Diensten gehören unter anderem Inhalte von Drittanbietern (z. B. Videos, Karten), interaktive Komponenten (z. B. Chat, Kommentarsysteme oder Zahlungsdienste) und Anmeldedienste.
Der Großteil der Arbeit bei der Umstellung von Drittanbieter-Cookies muss von den Entwicklern der eingebetteten Inhalte erledigt werden, nicht von den Websites, auf denen sie gehostet werden. In diesem Leitfaden werden hauptsächlich Lösungen für Entwickler behandelt, die eingebettete Dienste erstellen.
Wenn auf Ihrer Website eingebettete Inhalte mit Drittanbieter-Cookies verwendet werden, sollten Sie die entsprechenden Nutzerpfade prüfen und testen. Wenden Sie sich an den Anbieter, wenn Sie Probleme feststellen.
Einbettungsbezogene User Journeys analysieren und testen
Am besten lässt sich feststellen, ob Ihre Einbettungen von Drittanbieter-Cookies betroffen sind, indem Sie die Nutzerflüsse für Drittanbieter-Einbettungen testen, wobei die entsprechende Testflag aktiviert ist.
Nachdem Sie Drittanbieter-Cookies eingeschränkt haben, sollten Sie die folgenden gängigen Einbettungsszenarien testen:
- Chat-Widgets:Können Sie eine Chatsitzung starten? Können Sie die Seite aktualisieren, ohne die Sitzung zu verlieren? Können Sie zu anderen Seiten wechseln und die Sitzung beibehalten?
- Eingebettete Inhalte:Können Sie sich Videoinhalte oder andere eingebettete Inhalte ansehen? Werden Nutzereinstellungen wie Sprache oder Untertitel beibehalten? Werden dir Anzeigen wie erwartet angezeigt, z. B. nicht als Premium-Abonnent?
- Anmeldung:Funktionieren Anmeldungen, einschließlich SSO-Anmeldungen (Single Sign-On), für Einbettungen, die sie unterstützen? Bleiben sie bei Seitenaktualisierungen und beim Aufrufen von Seiten mit denselben Einbettungen erhalten?
- Kommentar-Widgets:Kann ich Kommentare hinterlassen, sie mit „Mag ich“ bewerten und ihnen eine positive Stimme geben?
- Eingebettete Zahlungslösungen:Können Sie Zahlungen erfolgreich abschließen?
In den folgenden Abschnitten finden Sie genauere Informationen dazu, wie sich diese Änderungen auf diese Zugriffe auswirken könnten.
Gängige Anwendungsfälle
Es gibt eine Reihe von APIs, die für eingebettete Inhalte verwendet werden können, für die bisher Drittanbieter-Cookies erforderlich waren. In der folgenden Tabelle sind einige gängige Workflows und die empfohlenen APIs als allgemeine Zusammenfassung aufgeführt. In den folgenden Abschnitten wird erläutert, warum diese Empfehlungen gegeben werden.
| Anwendungsfall | Empfohlene API für die Nutzung von Drittanbieter-Cookies |
|---|---|
| Chat-Widget | CHIPS |
| Eingebettete Karten | CHIPS |
| Sandbox-Domains für nicht vertrauenswürdige von Nutzern erstellte Inhalte (z. B. googleusercontent.com und githubusercontent.com), die pro Publisher auf Statusebene benötigt werden |
CHIPS |
| Eingebettete Anzeigen, die auf Ebene des Bundesstaats pro Publisher erforderlich sind | CHIPS |
| Über einen Identitätsanbieter anmelden | FedCM |
| Einbetten von Inhalten, die auf verschiedenen, aber verwandten Ursprüngen gehostet werden. | Storage Access API mit Sets ähnlicher Websites |
| Eingebettete Inhalte mit nutzerspezifischen Einstellungen (z. B. Videoinhalte ohne Werbung oder Sprach-/Untertiteleinstellungen) |
Storage Access API |
| Kommentar-Widget für soziale Medien, für das eine Anmeldung erforderlich ist | Storage Access API |
API für eingebettete Drittanbieter-Anwendungsfälle auswählen
In diesem Abschnitt wird beschrieben, wie Sie eine geeignete alternative API auswählen, und die empfohlenen APIs werden erläutert.
Das folgende Flussdiagramm hilft bei der Auswahl der verfügbaren Optionen:
Im Flussdiagramm werden drei Hauptfragen gestellt. Wir werden uns diese genauer ansehen und erläutern, warum in jedem Fall eine bestimmte API empfohlen wird.
1. Sind die Cookies spezifisch für die Website, auf der sie eingebettet sind?
Viele Drittanbieter-Embeds werden unabhängig voneinander auf völlig verschiedenen Websites verwendet. Für Chat-Widgets für den Kundensupport sind beispielsweise häufig Cookies erforderlich, die aber nicht zwischen zwei völlig verschiedenen Organisationen geteilt werden müssen, die beide dieselbe Chat-Widget-Lösung verwenden. In vielen Fällen sollte das Teilen von Cookies sogar nicht erlaubt werden.
Wenn Sie anderen Websites einen Einbettungsservice von Drittanbietern zur Verfügung stellen, der auf Cookies basiert, sollten Sie prüfen, ob diese Cookies spezifisch für den Dienst auf der Website sind, auf der sie eingebettet sind. Werden sie jemals über Instanzen deiner Einbettung auf anderen Websites geteilt?
Wenn die Cookies nicht freigegeben werden müssen, ist die Partitionierung von Cookies mit CHIPS die einfachste Option. Diese API verknüpft Drittanbieter-Cookies mit der Website der obersten Ebene, anstatt zuzulassen, dass sie von allen Websites geteilt werden, die dasselbe Drittanbieter-Embed verwenden. CHIPS ist einfach zu implementieren, da den vorhandenen Cookies nur ein zusätzliches Partitioned-Attribut hinzugefügt werden muss. So können die eingebetteten Dienste weiterhin den Status speichern, aber der freigegebene websiteübergreifende Speicher wird entfernt, der websiteübergreifendes Tracking ermöglichen würde.
Außerdem sollten Websites prüfen, ob Cookies aus den richtigen Gründen verwendet werden. Cookies sollten nur verwendet werden, wenn sie gesetzt werden oder mit HTTP-Anfragen gesendet werden müssen. Ist dies nicht der Fall und werden Cookies nur als praktische Speicheroption verwendet, sollten stattdessen die verschiedenen Speicher-APIs in Betracht gezogen werden. So bleiben Daten lokal, wenn sie nicht gesendet werden müssen. Die Speicher-APIs sind in allen gängigen Browsern bereits partitioniert, ähnlich wie CHIPS Cookies partitioniert.
2. Geht es um Cookies für einen externen Identitätsanbieter?
Eine gängige Verwendung von Drittanbieter-Cookies in Einbettungen besteht darin, Anmeldefunktionen bereitzustellen, die von einem Drittanbieter-Anmeldeanbieter verwaltet werden, z. B. Über Google anmelden. Partitionierte Cookies sind in diesem Fall keine Option.
Federated Credential Management (FedCM) ist eine spezielle API für diesen Anwendungsfall, die ohne Drittanbieter-Cookies funktioniert. Wenn FedCM vom Identitätsanbieter unterstützt wird, sind möglicherweise keine Drittanbieter-Cookies mehr erforderlich.
Weitere Informationen zur Behebung der Auswirkungen von Drittanbieter-Cookies auf Anmeldeabläufe finden Sie im Leitfaden zu Identitäten.
3. Werden die Cookies auf einer kleinen Anzahl ähnlicher Websites verwendet?
Wenn keine der vorherigen Optionen für Cookies geeignet ist, musst du den Zugriff auf Drittanbieter-Cookies für das eingebettete Element wieder aktivieren. Dies kann in bestimmten, kontrollierten Anwendungsfällen mit der Storage Access API aktiviert werden. Mit dieser API wird der vollständige Zugriff auf Drittanbieter-Cookies wieder aktiviert (vorbehaltlich der Kontrollen). Sie ist daher die leistungsstärkste Option. Daher wird empfohlen, sie zu vermeiden, wenn eine restriktivere Alternative ausreicht.
Für die Verwendung der Storage Access API gelten einige Voraussetzungen:
- Der Nutzer muss die Website des Embeds zuvor auf oberster Ebene besucht haben. Wenn Sie beispielsweise ein Kommentarsystem einbetten, muss der Nutzer auch die Website dieses Kommentarsystems besuchen.
- Der Nutzer muss mit dem eingebetteten Inhalt interagieren, bevor Cookies weitergegeben werden können. Das bedeutet, dass es möglicherweise nicht möglich ist, die eingebetteten Inhalte vollständig zu laden, bevor der Nutzer interagiert.
- Der Nutzer muss die Freigabe von Cookies möglicherweise in einem Browser-Pop-up genehmigen, insbesondere beim ersten Mal und in regelmäßigen Abständen danach.
- Möglicherweise müssen auf der Website, auf der die Einbettung erfolgt, auch zusätzliche Sandbox-Attribute festgelegt werden.
Diese Einschränkungen sorgen dafür, dass Drittanbieter-Cookies nur dann wieder aktiviert werden, wenn der Nutzer und die Website dies erwarten. In bestimmten Fällen können die Nutzeraktionen jedoch übersprungen werden. Wenn der Nutzer beispielsweise vor Kurzem den Zugriff genehmigt hat, ist es möglicherweise nicht erforderlich, ihn für einen bestimmten Zeitraum (wie vom Browser definiert) noch einmal aufzufordern.
Ein weiteres Szenario, in dem Nutzer dies wahrscheinlich erwarten, sind ähnliche Websites. Einige Organisationen verwenden beispielsweise eine Reihe verschiedener Ursprünge, die vom Browser als websiteübergreifend betrachtet werden. Die Cookie-Nutzung wird dann als Drittanbieter-Nutzung behandelt. Beispiele sind Marken mit länderspezifischen Websites (z. B. example.com und example.co.uk) oder markenspezifischen Websites (z. B. example.car und example.house).
In diesem Fall, wenn es nur wenige ähnliche Websites gibt, können Sie Gruppen ähnlicher Websites verwenden. Websites werden an Chrome gesendet, damit Chrome weiß, dass sie miteinander verknüpft sind. So ist der Zugriff auf die Storage Access API nutzerfreundlicher und es werden weniger Nutzeraufforderungen angezeigt.
Für nicht zueinander gehörende Websites, die tatsächlich Drittanbieter sind, und bei denen der vollständige Zugriff auf Drittanbieter-Cookies erforderlich ist, weil die alternativen APIs nicht ausreichen, gelten für die Verwendung der Storage Access API die vollständigen Anforderungen und Aufforderungen.
Vergleich der verschiedenen APIs
Jede Lösung hat leicht unterschiedliche Eigenschaften und Einschränkungen, die sie für bestimmte Anwendungsfälle besser geeignet machen. In der folgenden Tabelle sind die wichtigsten Unterschiede zusammengefasst:
| CHIPS | Partitionierter Speicher | FedCM | Storage Access API mit zugehörigen Website-Sets | Storage Access API | |
|---|---|---|---|---|---|
| Der Nutzer muss nicht zuvor auf die eingebettete Website als Top-Level-Website zugegriffen haben. | |||||
| Erfordert keine Nutzeraufforderung zur Genehmigung des Zugriffs | |||||
| Der Nutzer muss nicht mit der Einbindung interagieren | (Kann auch für eingebettete Websites mit Zugriff auf oberster Ebene gelten.) |
||||
| Implementierungsaufwand | Sehr niedrig | Niedrig | Hoch | Mittel | Mittel |
| Kann verwendet werden, um Cookies für mehrere Websites/Quellen der obersten Ebene freizugeben | (Vorschlag wird derzeit diskutiert.) |
||||
| Verfügbar in Browsern, die nicht auf Chromium basieren | (Fällt auf die Storage Access API zurück.) |
Browserübergreifende Anwendungsfälle unterstützen
Die Browserkompatibilität ist einer der wichtigsten Faktoren bei der Entscheidung für eine Lösung, wie in der letzten Zeile der Tabelle erwähnt. Einige APIs (CHIPS, FedCM, Related Website Sets) sind nur in Chromium-Browsern verfügbar. Die einzigen beiden plattformübergreifenden Lösungen sind derzeit partitionierte Speicher-APIs (wenn keine Cookies erforderlich sind) oder die Storage Access API (wenn Cookies erforderlich sind).
Wie bereits erwähnt, hat die Storage Access API jedoch eine Reihe von Einschränkungen, die sich auf die Nutzerfreundlichkeit Ihrer Website auswirken können. Das Chrome-Team hat daran gearbeitet, die anderen APIs hinzuzufügen. Diese sind für bestimmte Anwendungsfälle konzipiert und bieten eine ähnliche Funktionalität wie Drittanbieter-Cookies. Daher empfehlen wir, die besten Optionen zu berücksichtigen und diese als progressive Verbesserungen zu behandeln. Für nicht unterstützte Browser sollte ein Fallback auf die Storage Access API erfolgen.
Da Cookies aus verschiedenen Gründen blockiert werden können (z. B. Browsereinstellungen, Erweiterungen), ist die Funktionserkennung der API-Unterstützung möglicherweise nicht ausreichend. Stattdessen sollten Sie testen, ob die erwarteten Cookies vorhanden sind, und andernfalls den Workflow der Storage Access API zum Anfordern des Zugriffs auf Drittanbieter-Cookies verwenden.
Jetzt aktiv werden!
Wenn Ihr eingebetteter Drittanbieterinhalt ohne Drittanbieter-Cookies nicht mehr funktioniert, gibt es mehrere Lösungen, die die möglichen Auswirkungen abmildern, wie in diesem Vortrag beschrieben. Prüfen Sie jetzt Ihren Dienst auf Drittanbieter-Cookies. Es ist höchste Zeit!
Wenn bei dir derzeit Probleme mit deinen Einbettungen auftreten, weil in Chrome die Entfernung von Drittanbieter-Cookies getestet wird, gibt es eine Reihe von kurzfristigen Optionen, die dir bei der Migration zu Alternativen helfen können. Sie werden in diesem Beitrag beschrieben. Weitere Informationen finden Sie in der Dokumentation Wichtige Funktionen für Nutzer erhalten.
Wenn Sie Fragen zu Anwendungsfällen für eingebettete Inhalte von Drittanbietern haben, die in diesem Leitfaden nicht behandelt werden, können Sie in unserem Entwicklersupport-Repository ein neues Problem mit dem Tag „Einstellung von Drittanbieter-Cookies“ melden.