In passato, i cookie di terze parti sono stati usati per archiviare e trasmettere informazioni sullo stato di un utente, ad esempio lo stato di accesso, le informazioni sul dispositivo in uso o se sono noti e attendibili. ad esempio se l'utente ha eseguito l'accesso con SSO, se ha un determinato tipo di dispositivo compatibile o se l'utente è noto e attendibile. Poiché il supporto dei cookie di terze parti verrà ritirato, molti di questi casi d'uso dovranno essere supportati con altri mezzi.
I token di stato privati consentono di condividere informazioni sul web, ma nel rispetto della privacy mediante controlli sulla quantità di dati che possono effettivamente essere condivisi.
I token di stato privati (noti in precedenza come Trust Token) consentono di trasmettere la fiducia nell'autenticità di un utente da un contesto a un altro, aiutando i siti a contrastare le attività fraudolente e a distinguere i bot da quelli umani, senza monitoraggio passivo.
Questo documento illustra i dettagli tecnici per l'implementazione dei token di stato privati (PST). Per un quadro più generale, consulta la panoramica PST.
Come funzionano i token di stato privati?
La relazione fondamentale da comprendere in PST è tra emittenti e utilizzatori. Gli emittenti e i riscattatori possono trovarsi all'interno della stessa azienda.
- Emittenti: queste entità hanno un indicatore che riguarda un utente (ad esempio se si tratta di un bot o meno) e lo incorpora in un token archiviato sul dispositivo dell'utente (maggiori dettagli nelle sezioni successive).
- Utilizzatori: queste persone giuridiche potrebbero non avere un indicatore relativo a un utente, ma avere bisogno di sapere qualcosa in merito (ad esempio se l'utente è un bot o meno) e chiedere di utilizzare un token all'emittente per comprendere l'affidabilità dell'utente.
Ogni interazione PST richiede che gli emittenti e i riscattatori collaborino per condividere gli indicatori sul web. Si tratta di valori approssimativi che non sono sufficientemente dettagliati da identificare i singoli individui.
I token di stato privati sono adatti al mio caso?
Le aziende che prendono decisioni basate sulla fiducia e vogliono che le informazioni siano disponibili in più contesti possono trarre vantaggio dai PST. Per ulteriori informazioni sui potenziali casi d'uso dei PST, consulta la nostra documentazione sui casi d'uso dei PST.
Emettere e utilizzare i token
L'implementazione del PST avviene in tre fasi:
- Emissione di token
- Utilizzo dei token
- Inoltro record di utilizzo
Nella prima fase, i token vengono emessi al browser (di solito dopo un qualche tipo di convalida). Nella seconda fase, un'altra entità richiederà di riscattare il token che era stato emesso per leggere il valore in quel token. Nella fase finale, la parte che ha utilizzato il riscatto riceve un record del riscatto (RR) con il valore contenuto nel token. La parte che ha riscattato i contenuti può quindi utilizzare quel record come attestazione dell'utente per vari scopi.
Definisci la strategia token
Per definire la tua strategia relativa ai token, devi comprendere i concetti chiave del PST (token e record di utilizzo), le variabili, i comportamenti e le limitazioni, in modo da poter pensare al loro potenziale utilizzo per il tuo caso d'uso.
Token e record relativi all'utilizzo: qual è la relazione tra loro?
Ogni dispositivo può archiviare fino a 500 token per sito web di primo livello e emittente. Inoltre, ogni token contiene metadati che indicano quale chiave è stata utilizzata dall'emittente. Queste informazioni possono essere utilizzate per decidere se utilizzare o meno un token durante la procedura di utilizzo. I dati PST vengono archiviati internamente dal browser sul dispositivo dell'utente e sono accessibili solo dall'API PST.
Quando viene utilizzato un token, il record di riscatto (RR) viene memorizzato sul dispositivo. Tale spazio di archiviazione funge da cache per utilizzi futuri. Esiste un limite di utilizzo di due token ogni 48 ore per dispositivo, pagina ed emittente. Le nuove chiamate di riscatto utilizzeranno RR memorizzate nella cache, ove possibile, anziché causare una richiesta all'emittente.
- Vengono emessi nuovi token (massimo 500 per emittente, sito e dispositivo).
- Tutti i token sono memorizzati sul dispositivo (simile all'archivio dei cookie).
- Se non viene trovato alcun RR attivo, è possibile generare nuovi RR dopo l'emissione (massimo 2 ogni 48 ore).
- Gli RR sono considerati attivi fino alla scadenza e verranno utilizzati come cache locale.
- Le nuove chiamate di utilizzo raggiungeranno la cache locale (non vengono generati nuovi RR).
Dopo aver definito il caso d'uso, devi definire attentamente la durata del RR, in quanto questo definirà quante volte potrai utilizzarlo nel tuo caso.
Assicurati di comprendere i seguenti comportamenti critici e variabili prima di definire la tua strategia:
| Variabile / comportamento | Descrizione | Utilizzo potenziale |
|---|---|---|
| Metadati della chiave token | Ogni token può essere emesso utilizzando una sola chiave di crittografia e nel PST esiste un limite di sei chiavi per emittente. | Un modo per utilizzare questa variabile è definire un intervallo di attendibilità per i token in base alle chiavi di crittografia (ad esempio, chiave 1 = attendibilità elevata, mentre chiave 6 = nessuna attendibilità). |
| Data di scadenza del token | La data di scadenza del token corrisponde alla data di scadenza della chiave. | Le chiavi possono essere ruotate almeno ogni 60 giorni e tutti i token emessi con chiavi non valide sono considerati non validi. |
| Limite al tasso di utilizzo dei token | Esiste un limite di due utilizzi di token per dispositivo e emittente ogni 48 ore. | Dipende dal numero stimato di utilizzi richiesti dal tuo caso d'uso ogni 48 ore. |
| Numero massimo di emittenti per origine di primo livello | Al momento, il numero massimo di emittenti per origine di primo livello è due. | Definisci attentamente gli emittenti di ogni pagina. |
| Token per emittente su un dispositivo | Il numero massimo di token per emittente su un dispositivo specifico è attualmente 500. | Assicurati di mantenere il numero di token inferiore a 500 per emittente. Assicurati di gestire gli errori della pagina web quando provi a emettere token. |
| Rotazione degli impegni chiave | Ogni emittente PST è tenuto a esporre un endpoint con impegni per le chiavi che possono essere modificati ogni 60 giorni e qualsiasi rotazione più rapida di questa data verrà ignorata. | Se le tue chiavi scadranno tra meno di 60 giorni, è obbligatorio aggiornare gli impegni chiave prima di questa data per evitare interruzioni (vedi i dettagli). |
| Durata del record di utilizzo | La durata del RR può essere definita per determinare una data di scadenza. Poiché gli RR vengono memorizzati nella cache per evitare nuove chiamate di riscatto inutili all'emittente, è importante assicurarsi di disporre di indicatori di utilizzo sufficientemente aggiornati. | Poiché esiste un limite per il tasso di riscatto di due token ogni 48 ore, è importante definire la durata del tuo RR in modo da poter eseguire chiamate di riscatto con successo almeno in questo periodo di tempo (la durata del RR deve essere impostata di conseguenza). Si consiglia di impostare la durata in settimane. |
Scenari di esempio
Scenario 1: la durata di RR è inferiore a 24 ore (t=t) e il riscatto viene eseguito più volte nell'arco di 48 ore.
Scenario 2: la durata di RR è di 24 ore e il riscatto viene eseguito più volte nell'arco di 48 ore.
Scenario n. 3: la durata di RR è di 48 ore e il riscatto viene eseguito più volte durante il periodo di 48 ore.
Esegui la demo
Prima di adottare PST, ti consigliamo di eseguire la configurazione con la demo. Per provare la demo PST , devi eseguire Chrome con i flag per attivare gli impegni relativi alla chiave emittente della demo (segui le istruzioni disponibili nella pagina demo).
Se esegui questa demo, il tuo browser utilizza i server emittente della demo e riscattatore per fornire e utilizzare token.
Considerazioni tecniche
La demo funziona meglio se implementi i seguenti passaggi:
- Assicurati di arrestare tutte le istanze di Chrome prima di eseguire Chrome con i flag.
- Se utilizzi un computer Windows, consulta questa guida su come passare parametri al file binario eseguibile di Chrome.
- Apri Chrome DevTools in Applicazioni > Archiviazione > Token di stato privati mentre utilizzi l'applicazione demo per visualizzare i token emessi/utilizzati dall'emittente della demo.
Configura per l'adozione
Diventa emittente
Gli emittenti svolgono un ruolo chiave nel formato PST. Assegnano valori ai token per determinare se un utente è un bot. Se vuoi iniziare a utilizzare PST come emittente, devi registrarti completando la procedura di registrazione dell'emittente.
Per richiedere di diventare un emittente, l'operatore del sito web dell'emittente deve aprire un nuovo problema sul repository GitHub utilizzando il modello "Nuovo emittente PST". Segui le indicazioni sul repository per risolvere il problema. Una volta verificato un endpoint, questo verrà unito a questo repository e l'infrastruttura lato server di Chrome inizierà a recuperare le chiavi.
Server emittente
Emittenti e redentori sono gli attori principali di PST; i server e i token sono gli strumenti chiave per il PST. Abbiamo già fornito alcuni dettagli sui token e nella documentazione di GitHub, ma volevamo offrire maggiori dettagli sui server PST. Per configurarti come emittente di PST, devi prima configurare un server emittente.
Esegui il deployment del tuo ambiente: server emittente
Per implementare il server emittente del token, devi creare una tua applicazione lato server che espone gli endpoint HTTP.
Il componente emittente è composto da due moduli principali: (1) il server emittente e (2) l'emittente del token.
Come con tutte le applicazioni per il web, consigliamo un ulteriore livello di protezione per il tuo server emittente.
Server emittente: nella nostra implementazione di esempio, il nostro server emittente è un server Node.js che utilizza il framework Express per ospitare gli endpoint HTTP dell'emittente. Puoi dare un'occhiata al codice campione su GitHub.
Emittente di token: il componente crittografico dell'emittente non richiede una lingua specifica ma, per via dei requisiti delle prestazioni di questo componente, forniamo un'implementazione C come esempio, che utilizza la libreria Boring SSL per gestire i token. Puoi trovare l'esempio di codice dell'emittente e ulteriori informazioni sull'installazione su GitHub
Chiavi: il componente emittente del token utilizza chiavi EC personalizzate per criptare i token. Queste chiavi devono essere protette e archiviate in uno spazio di archiviazione sicuro.
Requisiti tecnici per i server dell'emittente
In base al protocollo, dovrai implementare almeno due endpoint HTTP nel tuo server emittente:
- Impegno per la chiave (ad esempio,
/.well-known/private-state-token/key-commitment): questo endpoint è il luogo in cui i dettagli della chiave pubblica di crittografia saranno disponibili ai browser per confermare che il server è legittimo. - Emissione del token (ad esempio,
/.well-known/private-state-token/issuance): l'endpoint di emissione del token in cui verranno gestite tutte le richieste di token. Questo endpoint sarà il punto di integrazione per il componente emittente del token.
Come accennato in precedenza, a causa dell'elevato traffico previsto che verrà potenzialmente gestito da questo server, ti consigliamo di eseguirne il deployment utilizzando un'infrastruttura scalabile (ad esempio in un ambiente cloud) in modo da poter regolare il backend in base a una domanda variabile.
Invia una chiamata al server emittente
Implementa una chiamata di recupero del sito web allo stack dell'emittente per emettere nuovi token.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Server di riscatto
Dovrai implementare il servizio di riscatto dei token creando la tua applicazione lato server. Ciò ti consentirà di leggere i token inviati da un emittente. I passaggi seguenti spiegano come utilizzare i token e come leggere i record relativi all'utilizzo associati a questi token.
Puoi scegliere di eseguire l'emittente e il riscatto sullo stesso server (o gruppo di server).
Requisiti tecnici per i server di riscatto
In base al protocollo, dovrai implementare almeno due endpoint HTTP per il tuo server redattore:
/.well-known/private-state-token/redemption: endpoint in cui verrà gestito l'utilizzo di tutti i token. Su questo endpoint verrà integrato il componente relativo all'utilizzo del token.
Invia una chiamata al server del redattore
Per utilizzare i token, devi implementare una chiamata di recupero del sito web allo stack di riscattatori al fine di riscattare i token emessi in precedenza.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Vedi un esempio di codice.
Dopo aver utilizzato un token, puoi inviare il record di riscatto (RR) effettuando un'altra chiamata di recupero:
// 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>]
}
});
Vedi un esempio di codice.
Esegui il deployment dell'implementazione
Per testare l'implementazione, vai prima alla pagina web in cui viene effettuata la chiamata emittente e conferma che i token vengano creati seguendo la tua logica. Verifica nel backend che le chiamate siano state effettuate in base alle specifiche. Poi, vai alla pagina web in cui viene effettuata la chiamata per riscattare l'offerta e conferma che i RR siano stati creati, seguendo la tua logica.
Implementazione nel mondo reale
Ti consigliamo di scegliere i siti web di destinazione che fanno parte del tuo caso d'uso specifico:
- Numero ridotto di visite mensili (circa < 1 milione di visite/mese): devi iniziare eseguendo il deployment dell'API per un pubblico ristretto
- Sei il proprietario e lo controlli: se necessario, puoi disabilitare rapidamente l'implementazione senza approvazioni complesse,
- Non più di un emittente: per limitare la quantità di token per semplificare i test.
- Non più di due utenti: devi semplificare la risoluzione dei problemi in caso di problemi.
Risolvere i problemi
Puoi esaminare i PST dalle schede Rete e Applicazione di Chrome DevTools.
Nella scheda Rete:
Nella scheda Applicazione:
Scopri di più su questa integrazione di DevTools.
Best practice e risoluzione dei problemi per il server
Per un corretto funzionamento del server emittente e del server di riscatto, ti consigliamo di implementare le seguenti best practice per evitare problemi di accesso, sicurezza, logging o traffico per PST.
- Gli endpoint devono applicare una crittografia efficace utilizzando TLS 1.3 o 1.2.
- L'infrastruttura deve essere pronta per gestire volumi di traffico variabili (inclusi i picchi).
- Assicurati che le tue chiavi siano protette e sicure, in linea con i criteri di controllo dell'accesso, la strategia di gestione delle chiavi e i piani di continuità aziendale.
- Aggiungi metriche di osservabilità al tuo stack per assicurarti di avere visibilità per comprendere utilizzo, colli di bottiglia e problemi di prestazioni dopo il passaggio in produzione.
Maggiori informazioni
- Esamina la documentazione per gli sviluppatori:
- Inizia leggendo la panoramica per acquisire dimestichezza con PST e le sue funzionalità.
- Guarda il video introduttivo su PST.
- Prova la demo di PST.
- Inoltre, leggi la spiegazione dell'API per maggiori dettagli.
- Scopri di più sulle specifiche attuali dell'API.
- Contribuisci alla conversazione tramite problemi GitHub o chiamate W3C.
- Per comprendere meglio la terminologia, leggi il glossario di Privacy Sandbox.
- Per scoprire di più sui concetti di Chrome, ad esempio "prova dell'origine" o "flag di Chrome", consulta i brevi video e gli articoli disponibili all'indirizzo goo.gle/cc.