Drittanbieter-Cookies haben viele Verwendungsmöglichkeiten, sind aber auch ein wichtiger Faktor für websiteübergreifendes Tracking.
Chrome bietet Nutzern eine neue Möglichkeit, Drittanbieter-Cookies zu aktivieren oder zu deaktivieren. 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 Ihre Website auf ein eingebettetes Element mit Drittanbieter-Cookies angewiesen ist, sollten Sie die entsprechenden Nutzerpfade prüfen und testen. Wenden Sie sich an den Anbieter des eingebetteten Elements, 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 das Flag für den Test von Drittanbieter-Cookies 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 (Einmalanmeldung), für Einbettungen, die sie unterstützen? Bleiben sie bei Seitenaktualisierungen und beim Wechsel zu Seiten mit denselben Einbettungen erhalten?
- Kommentar-Widgets:Kannst du Kommentare hinterlassen, mit „Mag ich“ bewerten und hochstimmen?
- 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önnen.
Gängige Anwendungsfälle
Es gibt eine Reihe von APIs, die für Einbettungen verwendet werden können, die bisher auf Drittanbieter-Cookies angewiesen waren. In der folgenden Tabelle sind einige gängige Workflows und die empfohlenen APIs als allgemeine Zusammenfassung aufgeführt. In den folgenden Abschnitten werden die Gründe für diese Empfehlungen erläutert.
| 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 erfahren Sie, wie Sie eine geeignete alternative API auswählen, und es werden die empfohlenen APIs 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 Einbettungen von Drittanbietern 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 dieser Fälle sollte die Freigabe 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 sie für alle Websites freizugeben, die denselben 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 gemeinsame 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 zur Identitätsverwaltung.
3. Werden die Cookies auf einer kleinen Anzahl ähnlicher Websites verwendet?
Wenn keine der vorherigen Optionen für dich infrage kommt, 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 Einstellungen). Sie ist daher die leistungsfähigste 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 die eingebetteten Inhalte möglicherweise nicht vollständig geladen werden können, bevor eine Nutzerinteraktion erfolgt.
- 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 werden die Nutzeraktionen jedoch möglicherweise übersprungen. 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 daher als Drittanbieter-Nutzung behandelt. Beispiele sind Marken mit länderspezifischen Websites (z. B. example.com und example.co.uk) oder markenspezifische 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 Aufforderungen angezeigt.
Für nicht zueinander gehörende Websites, die tatsächlich Drittanbieter sind, und bei denen ein vollständiger 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 anderen Browsern als Chromium | (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 browserü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, die für bestimmte Anwendungsfälle entwickelt wurden und eine ähnliche Funktionalität wie Drittanbieter-Cookies bieten. Daher sollten Sie die besten Optionen ermitteln und diese als progressive Verbesserungen 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 prüfen, ob die erwarteten Cookies vorhanden sind, und bei Bedarf 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 erläutert. Jetzt ist der richtige Zeitpunkt, Ihren Dienst auf Drittanbieter-Cookies zu prüfen.
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 helfen können, während du zu den in diesem Beitrag beschriebenen Alternativen migrierst. Weitere Informationen finden Sie in der Dokumentation zum Achten auf wichtige Nutzererfahrungen.
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.