In der Vergangenheit wurden Drittanbieter-Cookies verwendet, um Informationen zum Status eines Nutzers zu speichern und zu übermitteln, z. B. Anmeldestatus, Informationen über das Gerät, das er verwendet, oder ob die Nutzer bekannt und vertrauenswürdig sind. z. B. ob der Nutzer sich über SSO angemeldet hat, ob er ein bestimmtes kompatibles Gerät hat oder ob er bekannt und vertrauenswürdig ist. Da die Unterstützung für Drittanbieter-Cookies eingestellt wird, müssen viele dieser Anwendungsfälle auf andere Weise unterstützt werden.
Private State Tokens bieten eine Möglichkeit, Informationen im Web zu teilen, jedoch auf datenschutzfreundliche Weise durch Kontrollen über die Datenmenge, die tatsächlich weitergegeben werden kann.
Private State Tokens (früher als Trust Tokens bezeichnet) ermöglichen es, das Vertrauen in die Echtheit eines Nutzers von einem Kontext zum anderen zu vermitteln. Gleichzeitig helfen Websites dabei, Betrug zu bekämpfen und Bots von echten Menschen zu unterscheiden – ohne passives Tracking.
In diesem Dokument werden die technischen Details für die Implementierung von Private State Tokens (PST) beschrieben. Einen groben Überblick finden Sie in der PST-Übersicht.
Wie funktionieren Private State Tokens?
Die Hauptbeziehung, die in PST zu verstehen ist, ist zwischen Ausstellern und Einlösungsanbietern. Aussteller und Einlösungsberechtigte können zum selben Unternehmen gehören.
- Aussteller – Diese Entitäten haben ein gewisses Signal zu einem Nutzer (z. B. ob dieser Nutzer ein Bot ist oder nicht) und betten dieses Signal in ein Token ein, das auf dem Nutzergerät gespeichert wird (weitere Informationen in den nächsten Abschnitten).
- Einlösen: Diese Entitäten haben möglicherweise kein Signal zu einem Nutzer, müssen jedoch etwas über sie wissen (z. B. ob dieser Nutzer ein Bot ist oder nicht) und bitten, ein Token vom Aussteller einzulösen, um die Vertrauenswürdigkeit dieses Nutzers zu ermitteln.
Bei jeder PST-Interaktion müssen Aussteller und Einlösungsgeber zusammenarbeiten, um Signale im Web zu teilen. Diese Signale sind grobe Werte, die nicht detailliert genug sind, um einzelne Personen zu identifizieren.
Sind Private State Tokens die richtige Wahl für mich?
Unternehmen, die Vertrauensentscheidungen treffen und möchten, dass diese Informationen kontextübergreifend verfügbar sind, können von PSTs profitieren. Weitere Informationen zu möglichen Anwendungsfällen von PSTs finden Sie in unserer Dokumentation zu PST-Anwendungsfällen.
Tokens ausstellen und einlösen
Die PST-Implementierung erfolgt in drei Phasen:
- Tokens ausstellen
- Tokens einlösen
- Weiterleitung von Einlösungsdaten
In der ersten Phase werden Tokens an einen Browser ausgegeben (normalerweise nach einer Art von Validierung). In der zweiten Phase stellt eine andere Entität eine Anfrage zum Einlösen des ausgegebenen Tokens zum Lesen des Werts in diesem Token. In der letzten Phase erhält die einlösende Partei einen Einlösungsdatensatz (RR) mit dem Wert, der im Token enthalten war. Diese einlösende Partei kann diesen Datensatz dann für verschiedene Zwecke als Attestierung dieses Nutzers verwenden.
Tokenstrategie definieren
Zum Definieren Ihrer Tokenstrategie müssen Sie die Schlüsselkonzepte der PST (Tokens und Einlösungseinträge), Variablen, Verhaltensweisen und Einschränkungen kennen, um deren mögliche Verwendung für Ihren Anwendungsfall einschätzen zu können.
Tokens und Einlösungsdatensätze: In welcher Beziehung stehen sie?
Auf jedem Gerät können pro Website der obersten Ebene und Aussteller bis zu 500 Tokens gespeichert werden. Außerdem enthält jedes Token Metadaten, die angeben, welchen Schlüssel der Aussteller zur Ausgabe verwendet hat. Diese Informationen können verwendet werden, um zu entscheiden, ob ein Token während des Einlösungsvorgangs eingelöst wird oder nicht. PST-Daten werden vom Browser intern auf dem Gerät des Nutzers gespeichert und können nur über die PST API abgerufen werden.
Beim Einlösen eines Tokens wird der Einlösungsdatensatz (RR) auf dem Gerät gespeichert. Dieser Speicher dient als Cache für zukünftige Einlösungen. Es gibt ein Limit von zwei Tokens alle 48 Stunden pro Gerät, Seite und Aussteller. Neue Einlösungsaufrufe verwenden nach Möglichkeit im Cache gespeicherte RRs, anstatt eine Anfrage an den Aussteller zu senden.
- Es werden neue Tokens ausgestellt (max. 500 pro Aussteller, Website und Gerät).
- Alle Tokens werden im Tokenspeicher auf dem Gerät gespeichert (ähnlich wie im Cookiespeicher).
- Wenn keine aktiven RRs gefunden werden, können nach der Ausstellung neue RRs generiert werden (maximal zwei alle 48 Stunden).
- RRs gelten bis zum Ablauf als aktiv und werden als lokaler Cache verwendet.
- Neue Einlösungsaufrufe erfolgen im lokalen Cache (keine neuen RRs werden generiert).
Nachdem Sie den Anwendungsfall definiert haben, müssen Sie die Lebensdauer Ihrer RR sorgfältig definieren, da dadurch bestimmt wird, wie oft Sie sie in Ihrem Fall verwenden können.
Machen Sie sich mit den folgenden kritischen Verhaltensweisen und Variablen vertraut, bevor Sie eine Strategie definieren:
| Variable / Verhalten | Beschreibung | Potenzielle Nutzung |
|---|---|---|
| Metadaten des Tokenschlüssels | Jedes Token kann mit genau einem kryptografischen Schlüssel ausgestellt werden. In PST ist es auf sechs Schlüssel pro Aussteller beschränkt. | Eine Möglichkeit, diese Variable zu verwenden, besteht darin, auf der Grundlage Ihrer kryptografischen Schlüssel einen Vertrauensbereich für Ihre Tokens zu definieren (z. B. Schlüssel 1 = hohes Vertrauen, Schlüssel 6 = kein Vertrauen). |
| Ablaufdatum des Tokens | Das Ablaufdatum des Tokens entspricht dem Ablaufdatum des Schlüssels. | Schlüssel können mindestens alle 60 Tage rotiert werden. Alle Tokens, die mit ungültigen Schlüsseln ausgestellt wurden, werden ebenfalls als ungültig betrachtet. |
| Limit für die Einlösung von Tokens | Pro Gerät und Aussteller können alle 48 Stunden maximal zwei Tokens eingelöst werden. | Hängt von der geschätzten Anzahl der für Ihren Anwendungsfall erforderlichen Einlösungen alle 48 Stunden ab. |
| Maximale Anzahl von Ausstellern pro Ursprung der obersten Ebene | Die maximale Anzahl von Ausstellern pro Ursprung der obersten Ebene ist derzeit zwei. | Definieren Sie die Aussteller jeder Seite sorgfältig. |
| Tokens pro Aussteller auf einem Gerät | Die maximale Anzahl von Tokens pro Aussteller auf einem bestimmten Gerät beträgt derzeit 500. | Die Anzahl der Tokens pro Aussteller muss unter 500 liegen. Behandeln Sie Fehler auf Ihrer Webseite, wenn Sie versuchen, Tokens auszugeben. |
| Rotation von Schlüsselzusicherungen | Jeder PST-Aussteller muss einen Endpunkt mit Schlüsselzusicherungen bereitstellen, die alle 60 Tage geändert werden können. Eine schnellere Rotation wird ignoriert. | Wenn Ihre Schlüssel in weniger als 60 Tagen ablaufen, müssen Sie Ihre Schlüsselzusicherungen vor diesem Datum aktualisieren, um Unterbrechungen zu vermeiden (siehe Details). |
| Laufzeit des Einlösungseintrags | Die Lebensdauer von RR kann definiert werden, um ein Ablaufdatum zu bestimmen. Da RRs im Cache gespeichert werden, um unnötige neue Einlösungsaufrufe an den Aussteller zu vermeiden, ist es wichtig, dafür zu sorgen, dass genügend Einlösungssignale vorhanden sind. | Da es ein Limit für die Einlösungsrate von zwei Tokens alle 48 Stunden gibt, ist es wichtig, die Lebensdauer Ihres RR zu definieren, damit Einlösungsaufrufe mindestens diesen Zeitraum erfolgreich ausgeführt werden können (die RR-Lebensdauer sollte entsprechend festgelegt werden). Es wird empfohlen, diese Lebensdauer in der Reihenfolge von Wochen festzulegen. |
Beispielszenarien
Szenario 1: Die RR-Lebensdauer beträgt weniger als 24 Stunden (t=t) und die Einlösung wird während des 48-Stunden-Zeitraums mehrmals durchgeführt.
Szenario 2: Die RR-Lebensdauer beträgt 24 Stunden und die Einlösung wird während des 48-Stunden-Zeitraums mehrmals durchgeführt.
Szenario 3: Die RR-Lebensdauer beträgt 48 Stunden und die Einlösung wird innerhalb dieses 48-Stunden-Fensters mehrmals durchgeführt.
Demo ausführen
Bevor Sie das PST verwenden, empfehlen wir Ihnen, zuerst die Demo einzurichten. Wenn Sie die PST-Demo testen möchten, müssen Sie Chrome mit Flags ausführen, um die Schlüsselzusicherungen des Demoausstellers zu aktivieren. Folgen Sie dazu der Anleitung auf der Demoseite.
Wenn Sie diese Demo ausführen, verwendet Ihr Browser die Demoaussteller- und Einlösungsserver, um Tokens bereitzustellen und zu verbrauchen.
Technische Aspekte
Die Demo funktioniert am besten, wenn Sie die folgenden Schritte implementieren:
- Stoppen Sie alle Chrome-Instanzen, bevor Sie Chrome mit Flags ausführen.
- Wenn Sie mit einem Windows-Computer arbeiten, lesen Sie diese Anleitung zur Übergabe von Parametern an die ausführbare Chrome-Binärdatei.
- Öffnen Sie die Chrome-Entwicklertools unter Applications > Storage > Private State Tokens (Anwendungen > Speicher > Private State Tokens) und verwenden Sie die Demo-App, um die Tokens zu sehen, die vom Demoaussteller ausgestellt/eingelöst wurden.
Zur Akzeptanz einrichten
Aussteller werden
Aussteller spielen beim PST eine wichtige Rolle. Sie weisen den Tokens Werte zu, um festzustellen, ob ein Nutzer ein Bot ist oder nicht. Wenn Sie PST als Aussteller verwenden möchten, müssen Sie sich über den Registrierungsprozess des Ausstellers registrieren.
Um Aussteller zu werden, muss der Betreiber der Ausstellerwebsite ein neues Problem im GitHub-Repository mit der Vorlage „New PST Issuer“ (Neuer PST-Aussteller) eröffnen. Folgen Sie der Anleitung im Repository, um das Problem auszufüllen. Sobald ein Endpunkt verifiziert wurde, wird er mit diesem Repository zusammengeführt und die serverseitige Infrastruktur von Chrome beginnt, diese Schlüssel abzurufen.
Ausstellerserver
Aussteller und Einlösen sind die Hauptakteure für die PST; Server und Tokens sind die wichtigsten Tools für PST. Wir haben bereits einige Details zu Tokens und in der GitHub-Dokumentation bereitgestellt. Nun möchten wir weitere Details zu den PST-Servern bereitstellen. Für die Einrichtung als Aussteller von PST müssen Sie zuerst einen ausstellenden Server einrichten.
Umgebung bereitstellen: Ausstellerserver
Zum Implementieren des Tokenausstellerservers müssen Sie Ihre eigene serverseitige Anwendung erstellen, die HTTP-Endpunkte verfügbar macht.
Die Ausstellerkomponente besteht aus zwei Hauptmodulen: (1) dem Ausstellerserver und (2) dem Tokenaussteller.
Wie bei allen webbasierten Anwendungen empfehlen wir auch hier eine zusätzliche Sicherheitsebene für den Ausstellerserver.
Ausstellerserver: In unserer Beispielimplementierung ist der ausstellende Server ein Node.js, der das Express-Framework zum Hosten der Aussteller-HTTP-Endpunkte verwendet. Sie können sich Beispielcode auf GitHub ansehen.
Tokenaussteller: Die kryptografische Komponente des Ausstellers benötigt keine bestimmte Sprache. Aufgrund der Leistungsanforderungen dieser Komponente stellen wir jedoch als Beispiel eine C-Implementierung zur Verfügung, in der Tokens mit der Bibliothek Boring SSL verwaltet werden. Das Beispiel mit dem Ausstellercode und weitere Informationen zur Installation findest du auf GitHub.
Schlüssel: Die Tokenausstellerkomponente verwendet benutzerdefinierte EC-Schlüssel, um Tokens zu verschlüsseln. Diese Schlüssel müssen geschützt und in einem sicheren Speicher aufbewahrt werden.
Technische Anforderungen für Ausstellerserver
Gemäß Protokoll musst du mindestens zwei HTTP-Endpunkte auf deinem Ausstellerserver implementieren:
- Key Commitment (z. B.
/.well-known/private-state-token/key-commitment): An diesem Endpunkt können Browsern die Details Ihres öffentlichen Schlüssels zur Verschlüsselung zur Verfügung gestellt werden, um zu prüfen, ob Ihr Server legitim ist. - Tokenausstellung (z. B.
/.well-known/private-state-token/issuance): Der Endpunkt, der Tokens ausstellt, an dem alle Tokenanfragen verarbeitet werden. Dieser Endpunkt ist der Integrationspunkt für die Komponente des Tokenausstellers.
Aufgrund des zu erwartenden hohen Traffics, der auf diesem Server verarbeitet werden kann, empfehlen wir wie bereits erwähnt, ihn mit einer skalierbaren Infrastruktur (z. B. in einer Cloud-Umgebung) bereitzustellen, damit Sie Ihr Back-End je nach schwankender Nachfrage anpassen können.
Aufruf an den Ausstellerserver senden
Implementieren Sie einen Websiteabrufaufruf für Ihren Ausstellerstack, um neue Tokens auszugeben.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Hier finden Sie ein Codebeispiel.
Server der Einlösung
Sie müssen den Token-Einlösungsdienst implementieren, indem Sie Ihre eigene serverseitige Anwendung erstellen. Auf diese Weise können Sie die Tokens lesen, die ein Aussteller sendet. In den folgenden Schritten wird beschrieben, wie Tokens eingelöst und die mit diesen Tokens verknüpften Einlösungseinträge gelesen werden.
Du kannst festlegen, dass der Aussteller und der Einlösende auf demselben Server (oder einer Gruppe von Servern) ausgeführt werden sollen.
Technische Anforderungen für Einlösungsserver
Gemäß Protokoll musst du mindestens zwei HTTP-Endpunkte für deinen Einlösungsserver implementieren:
/.well-known/private-state-token/redemption: Endpunkt, an dem die gesamte Tokeneinlösung erfolgt. An diesen Endpunkt wird die Token-Einlösungskomponente eingebunden.
Anruf an den Server des Einlösers senden
Zum Einlösen von Tokens musst du einen Website-Abrufaufruf in deinem Einlösungsstapel implementieren, um zuvor ausgegebene Tokens einzulösen.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Hier finden Sie ein Codebeispiel.
Nach dem Einlösen eines Tokens können Sie den Einlösungseintrag (RR) mit einem weiteren Abrufaufruf senden:
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
Hier finden Sie ein Codebeispiel.
Implementierung bereitstellen
Zum Testen der Implementierung rufen Sie zuerst die Webseite auf, auf der der Aufruf ausgeführt wird, und bestätigen Sie, dass die Tokens gemäß Ihrer Logik erstellt wurden. Überprüfen Sie in Ihrem Back-End, ob die Aufrufe gemäß der Spezifikation ausgeführt wurden. Rufen Sie dann die Webseite auf, auf der der Einlösungsaufruf erfolgt ist, und bestätigen Sie, dass die RRs gemäß Ihrer Logik erstellt wurden.
Implementierung in der Praxis
Wir empfehlen, Zielwebsites auszuwählen, die Teil Ihres spezifischen Anwendungsfalls sind:
- Geringe Anzahl monatlicher Besuche (ca. < 1 Million Besuche/Monat): Sie sollten die API zuerst für eine kleine Zielgruppe bereitstellen.
- Sie sind der Inhaber und steuern sie: Bei Bedarf können Sie die Implementierung schnell und ohne komplexe Genehmigungen deaktivieren.
- Nicht mehr als ein Aussteller: Begrenzen Sie die Anzahl der Tokens, um die Tests zu vereinfachen.
- Nicht mehr als zwei Einlöser: Sie müssen die Fehlerbehebung bei Problemen vereinfachen.
Fehlerbehebung
Sie können PST-Dateien auf den Tabs „Netzwerk“ und „Anwendung“ in den Chrome-Entwicklertools einsehen.
Auf dem Tab „Network“ (Netzwerk)
Auf dem Tab „Anwendung“:
Weitere Informationen zu dieser Einbindung der Entwicklertools
Best Practices für Server und Fehlerbehebung
Damit der Aussteller- und Einlösungsserver effektiv funktioniert, empfehlen wir die Implementierung der folgenden Best Practices, um sicherzustellen, dass Sie in Bezug auf das PST auf keine Probleme in Bezug auf Zugriffs-, Sicherheits-, Logging- oder Traffic-Probleme stoßen.
- Ihre Endpunkte müssen eine starke Kryptografie mit TLS 1.3 oder 1.2 anwenden.
- Ihre Infrastruktur muss auf schwankende Trafficvolumen (einschließlich Spitzen) vorbereitet sein.
- Achten Sie darauf, dass Ihre Schlüssel geschützt und sicher sind und Ihrer Zugriffssteuerungsrichtlinie, Ihrer Schlüsselverwaltungsstrategie und Ihren Geschäftskontinuitätsplänen entsprechen.
- Fügen Sie Ihrem Stack Beobachtbarkeitsmesswerte hinzu, um die Nutzung, Engpässe und Leistungsprobleme nach der Produktion nachvollziehen zu können.
Weitere Informationen
- Entwicklerdokumentation ansehen:
- Lesen Sie zuerst die Übersicht, um sich mit PST und seinen Funktionen vertraut zu machen.
- Sehen Sie sich das PST-Einführungsvideo an.
- Probieren Sie die PST-Demo aus.
- Weitere Informationen finden Sie auch in der Erläuterung zur API.
- Weitere Informationen zur aktuellen Spezifikation der API
- Sie können über GitHub-Probleme oder W3C-Anrufe zur Unterhaltung beitragen.
- Weitere Informationen zu dieser Terminologie finden Sie im Privacy Sandbox-Glossar.
- Weitere Informationen zu Chrome-Konzepten wie „Ursprungstest“ oder „Chrome-Flags“ finden Sie in den kurzen Videos und Artikeln unter goo.gle/cc.