Drittanbieter-Cookies haben viele Anwendungsbereiche, ermöglichen aber auch das websiteübergreifende Tracking.
Drittanbieter-Cookies können durch Browsereinschränkungen, Nutzereinstellungen, Entwickler-Flags oder Unternehmensrichtlinien blockiert werden.
Ihre Website oder Ihr Dienst muss allen Nutzern eine hervorragende Erfahrung bieten, unabhängig davon, ob Drittanbieter-Cookies verfügbar sind.
Auf dieser Seite finden Sie Informationen zu datenschutzfreundlichen Lösungen für eingebettete Szenarien, die bisher auf Drittanbieter-Cookies beruhten, sowie Strategien, die Ihnen bei der Auswahl der für Ihre Anforderungen am besten geeigneten Lösung helfen.
Eingebettete Dienste oder Einbettungen umfassen Inhalte von Drittanbietern (z. B. Videos, Karten), interaktive Komponenten (z. B. Chat-, Kommentarsysteme oder Zahlungsdienste), Anmeldedienste und mehr.
Die meisten Arbeiten für die Umstellung von Drittanbieter-Cookies müssen von Entwicklern von Einbettungen und nicht von Websites, auf denen Einbettungen gehostet werden, erledigt werden. In diesem Leitfaden werden hauptsächlich Lösungen für Entwickler behandelt, die eingebettete Dienste erstellen.
Wenn auf Ihrer Website ein Einbettungscode verwendet wird, der Drittanbieter-Cookies nutzt, sollten Sie die zugehörigen Nutzerpfade prüfen und testen. Wenden Sie sich an die Anbieter der Einbettungscodes, wenn Sie Probleme feststellen.
Einbettungsbezogene User Journeys prüfen und testen
Am besten lässt sich feststellen, ob Ihre Einbettungen von Drittanbieter-Cookies betroffen sind, indem Sie die Nutzerabläufe für Drittanbieter-Einbettungen mit aktiviertem Flag für das Testen von Drittanbieter-Cookies testen.
Nachdem Sie Drittanbieter-Cookies eingeschränkt haben, testen Sie die folgenden gängigen Einbettungsszenarien:
- Chat-Widgets:Können Sie eine Chatsitzung starten? Können Sie die Seite aktualisieren, ohne Ihre Sitzung zu verlieren? Können Sie zu anderen Seiten wechseln und Ihre Sitzung beibehalten?
- Eingebettete Inhalte:Können Sie Videoinhalte oder andere eingebettete Inhalte ansehen? Bleiben Nutzereinstellungen wie Sprache oder Untertitel erhalten? Werden Anzeigen wie erwartet angezeigt, z. B. nicht für Premium-Abonnenten?
- Anmeldung:Funktionieren Anmeldungen, einschließlich aller SSO-Anmeldungen (Single Sign-On), für Einbettungen, die sie unterstützen? Bleiben sie auch nach dem Neuladen der Seite und dem Aufrufen von Seiten, auf denen dieselben Einbettungen verwendet werden, erhalten?
- Kommentar-Widgets:Können Sie Kommentare hinterlassen, liken und hochwählen?
- Eingebettete Zahlungslösungen:Können Sie Zahlungen erfolgreich abschließen?
In den nächsten Abschnitten finden Sie genauere Informationen dazu, wie sich das auf die einzelnen Abläufe auswirken kann.
Gängige Anwendungsfälle
Es gibt eine Reihe von APIs, die für Einbettungen verwendet werden können, die traditionell auf Drittanbieter-Cookies angewiesen waren. In der folgenden Tabelle sind einige gängige Workflows und die empfohlenen APIs aufgeführt, die Sie verwenden sollten. In den folgenden Abschnitten wird die Begründung für diese Empfehlungen erläutert.
| Anwendungsfall | Empfohlene API für die Verwendung von Drittanbieter-Cookies |
|---|---|
| Chat-Widget | CHIPS |
| Eingebettete Karten | CHIPS |
| Sandbox-Domains für nicht vertrauenswürdige Nutzerinhalte (z. B. googleusercontent.com und githubusercontent.com), für die der Status pro Publisher festgelegt werden muss |
CHIPS |
| Eingebettete Anzeigen, für die der Status pro Publisher festgelegt werden muss | CHIPS |
| Über einen Identitätsanbieter anmelden | FedCM |
| Einbettung auf verschiedenen, aber verwandten Ursprüngen | Storage Access API mit Gruppen ähnlicher Websites |
| Eingebettete Inhalte mit anmeldebasierten Einstellungen (z. B. Videocontent ohne Anzeigen oder Einstellungen für Sprache/Untertitel) |
Storage Access API |
| Widget für Kommentare in sozialen Medien, für das eine Anmeldung erforderlich ist | Storage Access API |
Geeignete API für eingebettete Drittanbieter-Anwendungsfälle auswählen
In diesem Abschnitt wird beschrieben, wie Sie eine geeignete alternative API auswählen. Außerdem werden die empfohlenen APIs erläutert.
Das folgende Flussdiagramm hilft Ihnen bei der Auswahl der verfügbaren Optionen:
Das Flussdiagramm enthält drei Hauptfragen, die wir uns genauer ansehen werden. Außerdem werden wir erläutern, warum in den einzelnen Fällen eine bestimmte API empfohlen wird.
1. Sind die Cookies für die Einbettungswebsite spezifisch?
Viele Einbettungen von Drittanbietern werden unabhängig voneinander auf völlig unabhängigen Websites verwendet. Chat-Widgets für den Kundensupport benötigen beispielsweise häufig Cookies, aber diese Cookies müssen nicht zwischen zwei völlig unterschiedlichen Organisationen geteilt werden, die beide dieselbe Chat-Widget-Lösung verwenden. Tatsächlich wäre es in vielen dieser Fälle besser, das Teilen von Cookies gar nicht zuzulassen.
Wenn Sie anderen Websites einen Drittanbieter-Einbettungsdienst 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 er eingebettet ist. Werden sie jemals von Instanzen Ihres Embeds 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 dasselbe Drittanbieter-Embed verwenden. CHIPS lässt sich einfach implementieren, da nur ein zusätzliches Partitioned-Attribut zu den vorhandenen Cookies 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 Sie prüfen, ob Cookies aus den richtigen Gründen verwendet werden. Cookies sollten nur verwendet werden, wenn sie mit HTTP-Anfragen festgelegt oder gesendet werden müssen. Wenn dies nicht der Fall ist und Cookies nur als praktische Speicheroption verwendet werden, sollten stattdessen die verschiedenen Storage APIs in Betracht gezogen werden. Dadurch bleiben Daten lokal, wenn sie nicht gesendet werden müssen. Die Speicher-APIs sind in allen wichtigen Browsern bereits partitioniert, ähnlich wie CHIPS-Cookies partitioniert werden.
2. Sind die Cookies für einen externen Identitätsanbieter?
Eine häufige Verwendung von Drittanbieter-Cookies in Einbettungen ist die Bereitstellung von Anmeldefunktionen, die von einem Drittanbieter-Anmeldedienst wie Über Google anmelden verwaltet werden. 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 dazu, wie Sie die Auswirkungen von Drittanbieter-Cookies auf Anmeldeworkflows angehen können, finden Sie im Identity Guide.
3. Werden die Cookies auf einer kleinen Anzahl ähnlicher Websites verwendet?
Wenn keine der vorherigen Optionen als Ersatz für Cookies geeignet ist, müssen Sie den Zugriff auf Drittanbieter-Cookies für das Einbettungselement wieder aktivieren. Dies kann in bestimmten, kontrollierten Anwendungsfällen mit der Storage Access API aktiviert werden. Diese API ermöglicht wieder den vollständigen Zugriff auf Drittanbieter-Cookies (vorbehaltlich der Steuerelemente) und ist daher die leistungsstärkste Option. Daher wird empfohlen, sie zu vermeiden, wenn eine restriktivere Alternative ausreichen würde.
Für die Verwendung der Storage Access API gelten einige Anforderungen:
- Der Nutzer muss zuvor die Website des Embeds 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 freigegeben werden können. Das bedeutet, dass es möglicherweise nicht möglich ist, die vollständigen eingebetteten Inhalte vor der Nutzerinteraktion zu laden.
- Der Nutzer muss die Freigabe von Cookies möglicherweise über ein Browser-Pop-up genehmigen, insbesondere beim ersten Mal und danach in regelmäßigen Abständen.
- Auf der Einbettungswebsite müssen möglicherweise zusätzliche Sandbox-Attribute festgelegt werden.
Diese Einschränkungen sorgen dafür, dass das Reaktivieren von Drittanbieter-Cookies nur dann erfolgt, wenn der Nutzer und die Website dies erwarten. In bestimmten Szenarien werden die Nutzeraktionen jedoch möglicherweise übersprungen. Wenn der Nutzer beispielsweise vor Kurzem den Zugriff genehmigt hat, ist es möglicherweise für einen bestimmten Zeitraum (der vom Browser definiert wird) nicht erforderlich, ihn noch einmal dazu aufzufordern.
Ein weiteres Szenario, in dem Nutzer dies wahrscheinlich erwarten, sind verknüpfte Websites. Einige Organisationen verwenden beispielsweise eine Reihe verschiedener Ursprünge, die vom Browser als websiteübergreifend betrachtet werden. Die Verwendung von Cookies über diese Ursprünge hinweg wird daher als Drittanbieter-Cookie-Verwendung 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, in dem es nur wenige ähnliche Websites gibt, können Sie Gruppen ähnlicher Websites verwenden. Websites werden an Chrome gesendet, damit Chrome weiß, dass sie zusammengehören. Dadurch kann auf die Storage Access API nutzerfreundlicher zugegriffen werden, da weniger Nutzeraufforderungen erforderlich sind.
Bei nicht verwandten Websites, die tatsächlich Drittanbieter sind und bei denen ein vollständiger Zugriff auf Drittanbieter-Cookies erforderlich ist, weil die alternativen APIs nicht ausreichen, unterliegt die Verwendung der Storage Access API den vollständigen Anforderungen und Aufforderungen.
Vergleich der verschiedenen APIs
Jede der Lösungen 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 Gruppen ähnlicher Websites | Storage Access API | |
|---|---|---|---|---|---|
| Der Nutzer muss zuvor nicht als Website der obersten Ebene auf den eingebetteten Drittanbieter zugegriffen haben. | |||||
| Erfordert keine Nutzeraufforderung zur Genehmigung des Zugriffs | |||||
| Nutzer müssen nicht mit dem Einbettungscode 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/Ursprünge der obersten Ebene freizugeben | (Vorschlag in der Diskussion.) |
||||
| In Nicht-Chromium-Browsern verfügbar | (Falls back to Storage Access API.) |
Anwendungsfälle browserübergreifend 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 der APIs (CHIPS, FedCM, Gruppen ähnlicher Websites) sind nur in Chromium-Browsern verfügbar. Die einzigen beiden browserübergreifenden Lösungen sind derzeit APIs für partitionierten Speicher (wenn keine Cookies erforderlich sind) und die Storage Access API (wenn Cookies erforderlich sind).
Wie bereits erwähnt, unterliegt die Storage Access API jedoch einer 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 Erfahrung bieten wie mit Drittanbieter-Cookies. Daher empfiehlt es sich, die besten Optionen zu prüfen und diese als progressive Verbesserungen zu behandeln, mit einem Fallback zur Storage Access API für Browser, die sie nicht unterstützen.
Da Cookies aus verschiedenen Gründen blockiert werden können (z. B. durch Browsereinstellungen oder Erweiterungen), reicht die Funktionserkennung der API-Unterstützung möglicherweise nicht aus. Stattdessen sollten Sie testen, ob die erwarteten Cookies vorhanden sind. Wenn nicht, sollten Sie auf den Storage Access API-Ablauf zurückgreifen, um Zugriff auf Drittanbieter-Cookies anzufordern.
Jetzt aktiv werden!
Wenn Ihr Drittanbieter-Embed ohne Drittanbieter-Cookies nicht mehr funktioniert, gibt es mehrere Lösungen, die mögliche Auswirkungen berücksichtigen. Diese werden in diesem Vortrag ausführlich beschrieben. Prüfen Sie jetzt Ihren Dienst auf Drittanbieter-Cookies. Es ist an der Zeit.
Wenn Sie Probleme mit Ihren Einbettungen haben, weil Chrome die Entfernung von Drittanbieter-Cookies testet, gibt es eine Reihe von kurzfristigen Optionen, die Ihnen bei der Migration zu den in diesem Beitrag beschriebenen Alternativen helfen können. Weitere Informationen finden Sie in der Dokumentation zum Beibehalten wichtiger Nutzeraktionen.
Wenn Sie Fragen zu Anwendungsfällen für Einbettungen 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.