Auparavant, des cookies tiers ont été utilisés pour stocker et transmettre des informations sur l'état d'un utilisateur, telles que son état de connexion, des informations sur l'appareil qu'il utilise, ou s'il est connu et fiable. Par exemple, si l'utilisateur s'est connecté avec SSO, s'il possède un certain type d'appareil compatible, ou s'il est connu et de confiance. Avec l'abandon de la compatibilité avec les cookies tiers, un grand nombre de ces cas d'utilisation devront être pris en charge par d'autres moyens.
Les jetons d'état privés permettent de partager des informations sur le Web, mais en protégeant la confidentialité grâce à des contrôles sur la quantité de données pouvant être réellement partagées.
Les jetons d'état privés (anciennement "jetons de confiance") permettent de transmettre la confiance à l'authenticité d'un utilisateur d'un contexte à un autre tout en aidant les sites à lutter contre la fraude et à distinguer les robots des vrais humains, sans suivi passif.
Ce document décrit les détails techniques de la mise en œuvre des jetons d'état privés (PST). Pour une présentation plus générale, consultez la présentation des fichiers PST.
Comment fonctionnent les jetons d'état privés ?
Dans PST, la principale relation à comprendre est la relation entre les émetteurs et les acheteurs. Les émetteurs et les utilisateurs peuvent appartenir à la même entreprise.
- Émetteurs : ces entités possèdent des signaux sur un utilisateur (par exemple, s'il est un robot ou non) et les intègrent dans un jeton stocké sur l'appareil de l'utilisateur (plus de détails dans les sections suivantes).
- Rédempteurs : ces entités n'ont peut-être pas de signal sur un utilisateur, mais ont besoin d'en savoir plus à son sujet (par exemple, s'il s'agit d'un robot ou non) et de demander à utiliser un jeton de l'émetteur pour déterminer la fiabilité de cet utilisateur.
Chaque interaction PST exige que les émetteurs et les utilisateurs qui partagent des signaux sur le Web travaillent ensemble. Ces signaux sont des valeurs approximatives qui ne sont pas suffisamment détaillées pour identifier des individus.
Les jetons d'état privés me conviennent-ils ?
Les entreprises qui prennent des décisions liées à la confiance et qui souhaitent que ces informations soient disponibles dans différents contextes peuvent tirer parti des fichiers PST. Pour en savoir plus sur les cas d'utilisation potentiels des fichiers PST, consultez notre documentation sur les cas d'utilisation de PST.
Émettre et utiliser des jetons
L'implémentation des fichiers PST se déroule en trois phases:
- Émettre des jetons
- Utiliser des jetons
- Transfert d'enregistrements d'offres
Au cours de la première phase, les jetons sont envoyés à un navigateur (généralement après un certain type de validation). Au cours de la deuxième phase, une autre entité envoie une demande d'utilisation du jeton émis afin de lire sa valeur. Au cours de la phase finale, la partie qui a utilisé l'offre reçoit un enregistrement d'utilisation (RR) contenant la valeur contenue dans le jeton. Cette partie réclamant l'autorisation peut ensuite utiliser cet enregistrement comme attestation de cet utilisateur à diverses fins.
Définir votre stratégie de jetons
Pour définir votre stratégie de jetons, vous devez comprendre les concepts clés des PST (jetons et enregistrements d'utilisation), les variables, les comportements et les limites afin de pouvoir réfléchir à leur utilisation potentielle pour votre cas d'utilisation.
Jetons et enregistrements d'offres: quelle est la relation entre eux ?
Chaque appareil peut stocker jusqu'à 500 jetons par site Web de premier niveau et par émetteur. En outre, chaque jeton possède des métadonnées indiquant la clé utilisée par l'émetteur pour l'émettre. Ces informations peuvent servir à décider d'utiliser ou non un jeton au cours du processus d'utilisation. Les données PST sont stockées en interne par le navigateur sur l'appareil de l'utilisateur et ne sont accessibles que via l'API PST.
Lorsqu'un jeton est utilisé, l'enregistrement d'utilisation est stocké sur l'appareil. Cet espace sert de cache pour les utilisations ultérieures. Deux jetons peuvent être utilisés toutes les 48 heures, par appareil, page et émetteur. Dans la mesure du possible, les nouveaux appels d'utilisation utilisent les RR mis en cache, plutôt que d'envoyer une requête à l'émetteur.
- De nouveaux jetons sont émis (500 maximum par émetteur, site et appareil).
- Tous les jetons sont stockés sur un magasin de jetons stocké sur l'appareil (comme le stockage des cookies).
- Si aucun RR actif n'est trouvé, de nouveaux RR peuvent être générés après l'émission (deux maximum toutes les 48 heures).
- Les RR sont considérés comme actifs jusqu'à leur expiration et sont utilisés comme cache local.
- Les nouveaux appels d'utilisations frappent le cache local (aucun nouvel appel d'offres n'est généré).
Après avoir défini votre cas d'utilisation, vous devez définir soigneusement la durée de vie de votre serveur RR, car elle va déterminer le nombre de fois que vous pourrez les utiliser dans votre cas.
Assurez-vous de bien comprendre les comportements et les variables critiques suivants avant de définir votre stratégie:
| Variable / Comportement | Description | Utilisation potentielle |
|---|---|---|
| Métadonnées de clé de jeton | Chaque jeton peut être émis à l'aide d'une seule clé cryptographique. Dans PST, la limite est de six clés par émetteur. | Pour utiliser cette variable, vous pouvez définir une plage de confiance pour vos jetons en fonction de vos clés cryptographiques (par exemple, clé 1 = confiance élevée alors que clé 6 = aucune confiance). |
| Date d'expiration du jeton | La date d'expiration du jeton est identique à la date d'expiration de la clé. | Les clés peuvent être alternées au moins tous les 60 jours, et tous les jetons émis avec des clés non valides sont également considérés comme non valides. |
| Limite du taux d'utilisation des jetons | L'utilisation de jetons est limitée à deux fois par appareil et par émetteur toutes les 48 heures. | Dépend du nombre estimé d'utilisations requises par votre cas d'utilisation toutes les 48 heures. |
| Nombre maximal d'émetteurs par origine de niveau supérieur | Actuellement, le nombre maximal d'émetteurs par origine de niveau supérieur est de deux. | Définissez soigneusement les émetteurs de chaque page. |
| Jetons par émetteur sur un appareil | Le nombre maximal de jetons par émetteur sur un appareil spécifique est actuellement de 500. | Veillez à ce que le nombre de jetons soit inférieur à 500 par émetteur. Assurez-vous de gérer les erreurs sur votre page Web lorsque vous essayez d'émettre des jetons. |
| Rotation des engagements de clé | Chaque émetteur PST est tenu d'exposer un point de terminaison avec des engagements de clé pouvant être modifiés tous les 60 jours. Toute rotation plus rapide sera ignorée. | Si vos clés expirent dans moins de 60 jours, vous devez mettre à jour vos engagements de clés avant cette date pour éviter toute interruption (voir les détails). |
| Durée de validité du certificat d'utilisation | La durée de vie de RR peut être définie afin de déterminer une date d'expiration. Étant donné que les RR sont mis en cache pour éviter de nouveaux appels d'utilisation inutiles à l'émetteur, il est important de s'assurer de disposer de signaux d'utilisation suffisamment récents. | Étant donné qu'il y a un taux d'utilisation limité de deux jetons toutes les 48 heures, il est important de définir la durée de vie de votre RR pour pouvoir exécuter les appels d'utilisation réussis au moins sur cette période (la durée de vie RR doit être définie en conséquence). Il est recommandé de définir cette durée de vie sur l'ordre de plusieurs semaines. |
Exemples de cas de figure
Scénario 1: la durée de vie RR est inférieure à 24 heures (t=t) et l'utilisation est effectuée plusieurs fois au cours de la période de 48 heures.
Scénario 2: la durée de vie d'un enregistrement RR est de 24 heures, et l'utilisation est effectuée plusieurs fois au cours de cette période de 48 heures.
Scénario 3: la durée de vie RR est de 48 heures et l'utilisation est effectuée plusieurs fois au cours de cette période.
Lancer la démonstration
Avant d'adopter PST, nous vous recommandons de commencer par réaliser la démonstration. Pour tester la démonstration PST , vous devez exécuter Chrome avec des indicateurs pour activer les engagements de clés d'émetteur de la démonstration (suivez les instructions disponibles sur la page de démonstration).
Si vous exécutez cette démonstration, votre navigateur utilise les serveurs d'émetteur et d'émetteur de la version de démonstration pour fournir et consommer des jetons.
Considérations techniques
La démonstration fonctionnera mieux si vous mettez en œuvre les étapes suivantes:
- Veillez à arrêter toutes les instances Chrome avant d'exécuter Chrome avec des indicateurs.
- Si vous utilisez un ordinateur Windows, consultez ce guide pour savoir comment transmettre des paramètres au binaire de l'exécutable Chrome.
- Ouvrez les outils pour les développeurs Chrome sous Applications > Stockage > Jetons d'état privés tout en utilisant l'application de démonstration pour afficher les jetons émis ou utilisés par l'émetteur de la démonstration.
Configurer pour l'adoption
Devenir émetteur
Les émetteurs jouent un rôle clé dans PST. Ils attribuent des valeurs aux jetons pour déterminer si un utilisateur est un robot ou non. Si vous souhaitez utiliser PST en tant qu'émetteur, vous devez vous enregistrer en suivant le processus d'enregistrement de l'émetteur.
Pour demander à devenir émetteur, l'opérateur du site Web de l'émetteur doit ouvrir un nouveau problème sur le dépôt GitHub à l'aide du modèle "Nouvel émetteur PST". Suivez les instructions du dépôt pour résoudre le problème. Une fois qu'un point de terminaison a été validé, il est fusionné avec ce dépôt et l'infrastructure Chrome côté serveur commence à récupérer ces clés.
Serveurs de l'émetteur
Les émetteurs et les acheteurs sont les acteurs clés de PST. Les serveurs et les jetons sont les principaux outils de PST. Nous avons déjà fourni des détails sur les jetons et dans la documentation GitHub, mais nous voulions vous donner plus de détails sur les serveurs PST. Pour être défini en tant qu'émetteur de fichiers PST, vous devez d'abord configurer un serveur émetteur.
Déployer votre environnement: serveurs d'émetteurs
Pour implémenter le serveur d'émetteur de jetons, vous devez créer votre propre application côté serveur exposant les points de terminaison HTTP.
Le composant d'émetteur se compose de deux modules principaux: (1) le serveur de l'émetteur et (2) l'émetteur du jeton.
Comme pour toutes les applications Web, nous vous recommandons d'ajouter une couche de protection supplémentaire à votre serveur d'émetteur.
Serveur d'émetteur: dans notre exemple de mise en œuvre, notre serveur émetteur est un serveur Node.js qui utilise le framework Express pour héberger les points de terminaison HTTP de l'émetteur. Vous pouvez consulter un exemple de code sur GitHub.
Émetteur de jeton: le composant cryptographique de l'émetteur ne nécessite pas de langage spécifique. Toutefois, en raison des exigences de performances de ce composant, nous fournissons à titre d'exemple une implémentation C, qui utilise la bibliothèque Boring SSL pour gérer les jetons. Vous trouverez l'exemple de code d'émission et d'autres informations sur l'installation sur GitHub.
Clés: le composant d'émetteur de jetons chiffre les jetons à l'aide de clés EC personnalisées. Ces clés doivent être protégées et stockées dans un espace de stockage sécurisé.
Exigences techniques pour les serveurs d'émetteurs
Conformément au protocole, vous devez mettre en œuvre au moins deux points de terminaison HTTP sur votre serveur d'émetteur:
- Engagement clé (par exemple,
/.well-known/private-state-token/key-commitment) : ce point de terminaison est l'endroit où les détails de votre clé publique de chiffrement sont mis à la disposition des navigateurs pour confirmer la légitimité de votre serveur. - Émission de jetons (par exemple,
/.well-known/private-state-token/issuance) : point de terminaison d'émission de jetons où toutes les requêtes de jeton seront traitées. Ce point de terminaison sera le point d'intégration du composant d'émetteur de jetons.
Comme indiqué précédemment, en raison du trafic élevé attendu par ce serveur, nous vous recommandons de le déployer à l'aide d'une infrastructure évolutive (par exemple, dans un environnement cloud) afin de pouvoir ajuster votre backend en fonction d'une demande variable.
Envoyer un appel au serveur de l'émetteur
Implémentez un appel de récupération de site Web à votre pile d'émetteur afin d'émettre de nouveaux jetons.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Serveurs du rédacteur
Vous devrez implémenter le service d'utilisation de jetons en créant votre propre application côté serveur. Cela vous permettra de lire les jetons envoyés par un émetteur. Les étapes suivantes expliquent comment utiliser des jetons et comment lire les enregistrements d'utilisation associés à ces jetons.
Vous pouvez choisir d'exécuter l'émetteur et l'émetteur sur le même serveur (ou groupe de serveurs).
Exigences techniques concernant les serveurs de l'utilisateur
Conformément au protocole, vous devez mettre en œuvre au moins deux points de terminaison HTTP pour votre serveur réclameur:
/.well-known/private-state-token/redemption: point de terminaison où l'utilisation de l'ensemble des jetons sera gérée. Ce point de terminaison sera l'endroit où le composant d'émetteur de jetons sera intégré.
Envoyer un appel au serveur de l'acheteur
Pour utiliser des jetons, vous devez implémenter un appel de récupération de site Web sur votre pile d'utilisateurs afin d'utiliser les jetons émis précédemment.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Consultez un exemple de code.
Après avoir utilisé un jeton, vous pouvez envoyer l'enregistrement d'utilisation (RR) en effectuant un autre appel de récupération:
// 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>]
}
});
Consultez un exemple de code.
Déployer votre implémentation
Pour tester votre implémentation, accédez d'abord à la page Web sur laquelle l'appel est effectué et vérifiez que le ou les jetons sont créés selon votre logique. Vérifiez dans le backend que les appels ont été effectués conformément à la spécification. Ensuite, accédez à la page Web sur laquelle l'appel d'utilisation est effectué et vérifiez que les RR sont créés, en suivant votre logique.
Déploiement concret
Nous vous recommandons de choisir des sites Web cibles faisant partie de votre cas d'utilisation spécifique:
- Faible nombre de visites mensuelles (environ moins d'un million de visites par mois): commencez par déployer l'API auprès d'une petite audience.
- Vous en êtes le propriétaire: si nécessaire, vous pouvez rapidement désactiver l'implémentation sans approbations complexes.
- Un émetteur maximum: pour limiter le nombre de jetons afin de simplifier les tests.
- Deux utilisateurs au maximum: vous devez simplifier le dépannage en cas de problème.
Dépannage
Vous pouvez inspecter des fichiers PST à partir des onglets "Réseau des outils pour les développeurs Chrome" et "Application".
Dans l'onglet "Réseau" :
Dans l'onglet "Application" :
Apprenez-en plus sur l'intégration des outils de développement.
Bonnes pratiques concernant les serveurs et dépannage
Pour que votre serveur d'émetteur et d'émetteur fonctionne efficacement, nous vous recommandons d'appliquer les bonnes pratiques suivantes afin de vous assurer que vous ne rencontrez aucun problème d'accès, de sécurité, de journalisation ou de trafic pour PST.
- Vos points de terminaison doivent appliquer une cryptographie renforcée à l'aide de TLS 1.3 ou 1.2.
- Votre infrastructure doit être prête à gérer des volumes de trafic variables (y compris les pics).
- Assurez-vous que vos clés sont protégées et sécurisées, et conformes à votre stratégie de contrôle des accès, votre stratégie de gestion des clés et vos plans de continuité de l'activité.
- Ajoutez des métriques d'observabilité à votre pile pour être sûr de pouvoir comprendre l'utilisation, les goulots d'étranglement et les problèmes de performances après le passage en production.
Plus d'informations
- Consultez la documentation pour les développeurs :
- Commencez par lire la présentation pour vous familiariser avec PST et ses fonctionnalités.
- Regardez la vidéo de présentation des fichiers PST.
- Essayez la démonstration PST.
- Lisez également l'explication de l'API pour en savoir plus.
- En savoir plus sur les spécifications actuelles de l'API.
- Participez à la conversation via les problèmes GitHub ou les appels W3C.
- Pour mieux comprendre la terminologie, consultez le glossaire de la Privacy Sandbox.
- Pour en savoir plus sur les concepts de Chrome, tels que la "phase d'évaluation" ou les "indicateurs Chrome", consultez de courtes vidéos et des articles disponibles sur goo.gle/cc.