Introduzione ai token di attendibilità

Trust Tokens è una nuova API che consente a un sito web di trasmettere una quantità limitata di informazioni da un contesto di navigazione a un altro (ad esempio tra siti) per contribuire a contrastare le attività fraudolente, senza il monitoraggio passivo.

Sam Dutton



Riepilogo

I token attendibili consentono a un'origine di emettere token crittografici per un utente attendibile. I token vengono archiviati dal browser dell'utente. Il browser può quindi utilizzare i token in altri contesti per valutare l'autenticità dell'utente.

L'API Trust Token consente di trasmettere l'attendibilità di un utente in un contesto a un altro senza identificare l'utente o collegare le due identità.

Puoi provare l'API con la nostra demo e controllare i token nelle schede Rete e Applicazione di Chrome DevTools.

Screenshot che mostra i token di attendibilità nella scheda Rete di Chrome DevTools.
Considera attendibili i token nella scheda Rete di Chrome DevTools.
Screenshot che mostra i token di attendibilità nella scheda Applicazione Chrome DevTools.
Considera attendibili i token nella scheda Applicazione di Chrome DevTools.

Perché sono necessari i trust token?

Il web ha bisogno di sistemi per stabilire indicatori di attendibilità che dimostrino che un utente è chi dice di essere e non un bot che finge di essere un essere umano o una terza parte dannosa che froda una persona o un servizio reale. La protezione antifrode è particolarmente importante per inserzionisti, fornitori di annunci e CDN.

Sfortunatamente, molti meccanismi esistenti per valutare e propagare l'affidabilità (ad esempio per capire se un'interazione con un sito proviene da un essere umano reale) sfruttano tecniche che possono essere utilizzate anche per il fingerprinting.

L'API deve preservare la privacy, consentendo la propagazione dell'attendibilità tra i siti senza il monitoraggio dei singoli utenti.

Cosa c'è nella proposta Trust Tokens?

Il web fa affidamento sulla creazione di indicatori di attendibilità per rilevare attività fraudolente e spam. Un modo per riuscirci è monitorare la navigazione con identificatori globali per utente su più siti. Per un'API che tutela la privacy, non è accettabile.

Dalla proposta spiegazione:

Questa API propone una nuova area di archiviazione per origine per i token crittografici di tipo "Privacy Pass", accessibili in contesti di terze parti. Questi token non sono personalizzati e non possono essere utilizzati per monitorare gli utenti, ma sono firmati in modo crittografico, pertanto non possono essere falsificati.

Quando un'origine si trova in un contesto in cui l'utente è attendibile, può emettere al browser un batch di token, che possono essere "spesi" in un secondo momento in un contesto in cui l'utente sarebbe altrimenti sconosciuto o meno attendibile. Fondamentalmente, i token sono indistinguibili l'uno dall'altro, impedendo ai siti web di monitorare gli utenti tramite questi token.

Proponiamo inoltre un meccanismo di estensione per consentire al browser di firmare le richieste in uscita con chiavi associate a un particolare utilizzo di token.

Esempio di utilizzo dell'API

Quanto segue è stato adattato dal codice campione nel messaggio esplicativo dell'API.

Immagina che un utente visiti un sito web di notizie (publisher.example) che incorpora la pubblicità di una rete pubblicitaria di terze parti (foo.example). In precedenza, l'utente ha utilizzato un sito di social media che rilascia token trust (issuer.example).

La sequenza riportata di seguito mostra come funzionano i token di attendibilità.

1.L'utente visita issuer.example ed esegue azioni che portano il sito a credere che si tratti di una persona reale, ad esempio l'attività dell'account o il superamento di un test CAPTCHA.

2.issuer.example verifica che l'utente sia un essere umano ed esegue il seguente codice JavaScript per emettere un token di attendibilità al browser dell'utente:

fetch('https://issuer.example/trust-token', {
  trustToken: {
    type: 'token-request',
    issuer: 'https://issuer.example'
  }
}).then(...)

3.Il browser dell'utente archivia il token di attendibilità, associandolo a issuer.example.

4.Dopo un po' di tempo, l'utente visita publisher.example.

5.publisher.example vuole sapere se l'utente è un essere umano. publisher.example considera attendibile issuer.example, quindi controlla se il browser dell'utente dispone di token validi da quella origine:

document.hasTrustToken('https://issuer.example');

6.Se viene restituita una promessa che si risolve in true, significa che l'utente ha token di issuer.example, quindi publisher.example può tentare di utilizzare un token:

fetch('https://issuer.example/trust-token', {
trustToken: {
  type: 'token-redemption',
  issuer: 'https://issuer.example',
  refreshPolicy: {none, refresh}
}
}).then(...)

Con questo codice:

  1. L'utente che ha utilizzato la promozione publisher.example richiede un riscatto.

  2. Se l'utilizzo ha esito positivo, l'emittente issuer.example restituisce un record di utilizzo che indica che a un certo punto ha emesso un token valido al browser.

    7.Una volta risolta la promessa restituita da fetch(), il record di utilizzo può essere utilizzato nelle richieste di risorse successive:

fetch('https://foo.example/get-content', {
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['https://issuer.example', ...]
  }
});

Con questo codice:

  1. I record di utilizzo sono inclusi come intestazione della richiesta Sec-Redemption-Record.
  2. foo.example riceve il record relativo all'utilizzo e può analizzarlo per determinare se issuer.example pensava che questo utente fosse una persona.
  3. foo.example risponde di conseguenza.
Come può un sito web stabilire se fidarsi di te?

Potresti avere la cronologia degli acquisti con un sito di e-commerce, i check-in su una piattaforma di localizzazione o la cronologia dell'account presso una banca. Gli emittenti potrebbero anche esaminare altri fattori, come il tempo in cui hai un account o altre interazioni (come CAPTCHA o l'invio di moduli) che aumentano la fiducia dell'emittente nella probabilità che tu sia un essere umano.

Emissione di token di attendibilità

Se l'utente è ritenuto affidabile da un emittente di token di attendibilità come issuer.example, l'emittente può recuperare token trust per l'utente effettuando una richiesta fetch() con un parametro trustToken:

fetch('issuer.example/trust-token', {
  trustToken: {
    type: 'token-request'
  }
}).then(...)

Questa operazione richiama un'estensione del protocollo di emissione Privacy Pass che utilizza una nuova primitiva crittografica:

  1. Genera un insieme di numeri pseudo-casuali noti come nonce.

  2. Nascondi i nonce (codificali in modo che l'emittente non possa visualizzarne i contenuti) e associali alla richiesta in un'intestazione Sec-Trust-Token.

  3. Invia una richiesta POST all'endpoint fornito.

L'endpoint risponde con token blinded (firme sui non ciechi), quindi i token vengono sbloccati e archiviati internamente insieme ai nonce associati dal browser come token di attendibilità.

Utilizzo di un token attendibile

Il sito di un editore (come publisher.example nell'esempio sopra) può verificare se sono disponibili token di attendibilità per l'utente:

const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');

Se sono disponibili token, il sito dell'editore può utilizzarli per ottenere un record relativo all'utilizzo.

fetch('issuer.example/trust-token', {
  ...
  trustToken: {
    type: 'token-redemption',
    refreshPolicy: 'none'
  }
  ...
}).then(...)

L'editore può includere record relativi all'utilizzo nelle richieste che richiedono un token di attendibilità, ad esempio la pubblicazione di un commento, il Mi piace su una pagina o il voto in un sondaggio, utilizzando una chiamata fetch() come la seguente:

fetch('https://foo.example/post-comment', {
  ...
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['issuer.example/trust-token', ...]
  }
  ...
}).then(...);

I record di utilizzo sono inclusi come intestazione della richiesta Sec-Redemption-Record.

Considerazioni sulla privacy

I token sono progettati per essere "non collegabili". Un emittente può apprendere informazioni aggregate sui siti visitati dagli utenti, ma non può collegare l'emissione con l'utilizzo: quando un utente utilizza un token, l'emittente non può distinguere il token dagli altri token che ha creato. Tuttavia, al momento i token attendibili non esistono: esistono altri modi in cui un emittente potrebbe attualmente (in teoria) unire l'identità di un utente su più siti, come i cookie di terze parti e le tecniche di monitoraggio nascoste. È importante che i siti comprendano questa transizione dell'ecosistema mentre pianificano il loro supporto. Questo è un aspetto generale della transizione per molte API Privacy Sandbox, di cui non parleremo più in dettaglio.

Considerazioni sulla sicurezza

Attendi l'esaurimento dei token: un sito dannoso potrebbe deliberatamente esaurire la fornitura di token di un determinato emittente da parte di un utente. Esistono diverse mitigazioni contro questo tipo di attacco, ad esempio la possibilità per gli emittenti di fornire molti token contemporaneamente, in modo che gli utenti abbiano una scorta adeguata di contenuti per garantire che i browser utilizzino sempre un solo token per visualizzazione di pagina di primo livello.

Prevenzione della doppia spesa: il malware potrebbe tentare di accedere a tutti i token attendibili di un utente. Tuttavia, i token si esauriscono nel tempo, poiché ogni utilizzo viene inviato allo stesso emittente di token, che può verificare che ogni token venga utilizzato una sola volta. Per ridurre il rischio, gli emittenti potrebbero anche firmare meno token.

Meccanismi di richiesta

Potrebbe essere possibile consentire l'invio di record relativi all'utilizzo al di fuori di fetch(), ad esempio con le richieste di navigazione. I siti potrebbero anche includere i dati dell'emittente nelle intestazioni delle risposte HTTP per consentire l'utilizzo del token in parallelo al caricamento della pagina.

Ribadiamo che questa proposta richiede il tuo feedback. Se hai commenti, crea un problema nel repository esplicativo del trust Token.

Scopri di più

Grazie a tutte le persone che hanno contribuito a scrivere e recensire questo post.

Foto di ZSun Fu su Unsplash.