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 di attendibilità consentono a un'origine di emettere token crittografici per un utente che considera attendibile. I token vengono memorizzati 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 la fiducia 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 Trust Tokens nella scheda Rete di Chrome DevTools.
Considera attendibili i token nella scheda Rete di Chrome DevTools.
Screenshot che mostra Trust Tokens nella scheda Applicazione Chrome DevTools.
Autorizza i token nella scheda Applicazione di Chrome DevTools.

Perché sono necessari i token attendibili?

Il web ha bisogno di modi per stabilire indicatori di attendibilità che dimostrino che l'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 della fiducia tra i siti senza il monitoraggio dei singoli utenti.

Cosa contiene la proposta Trust Token?

Il web si basa sulla creazione di indicatori di attendibilità per rilevare attività fraudolente e spam. Un modo per farlo è monitorare la navigazione con identificatori globali tra siti per utente. Questo non è accettabile per un'API che tutela la privacy.

Dalla spiegazione della proposta:

Questa API propone una nuova area di archiviazione per origine per i token crittografici in stile "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, quindi non possono essere falsificati.

Quando un'origine si trova in un contesto in cui l'utente si fida dell'utente, 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 non sono distinguibili l'uno dall'altro, impedendo ai siti web di monitorare gli utenti tramite i 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 è adattato dal codice campione nell'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). L'utente ha precedentemente utilizzato un sito di social media che emette token di attendibilità (issuer.example).

La sequenza seguente mostra come funzionano i token di attendibilità.

1.L'utente visita issuer.example ed esegue azioni che inducono il sito a credere che sia un essere umano reale, ad esempio attività dell'account o superare un test CAPTCHA.

2.issuer.example verifica che l'utente sia una persona ed esegue il seguente codice JavaScript per inviare un token attendibile 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.Qualche tempo dopo, l'utente visita publisher.example.

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

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

6.Se viene restituita una promessa che si risolve true, significa che l'utente ha token da 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 publisher.example richiede l'utilizzo dell'offerta.

  2. Se l'utilizzo va a buon fine, l'emittente issuer.example restituisce un record di utilizzo che indica che a un certo punto ha emesso un token valido per questo 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 di utilizzo e può analizzare il record per stabilire se issuer.example ritiene che l'utente sia un essere umano.
  3. foo.example risponde di conseguenza.
Come fa un sito web a capire se fidarsi di te?

Potresti avere una cronologia degli acquisti con un sito di e-commerce, controlli su una piattaforma di una sede o cronologia dell'account di una banca. Gli emittenti potrebbero anche prendere in considerazione altri fattori, come il periodo di tempo durante il quale 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 attendibili

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

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

Questo richiama un'estensione del protocollo di emissione di Privacy Pass utilizzando una nuova primitiva crittografica:

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

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

  3. Invia una richiesta POST all'endpoint fornito.

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

Utilizzo dei token di attendibilità

Un sito di un editore (come publisher.example nell'esempio precedente) 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 di utilizzo:

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

L'editore può includere record di utilizzo nelle richieste che richiedono un token di attendibilità, come la pubblicazione di un commento, la selezione di Mi piace su una pagina o la votazione 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 all'utilizzo: quando un utente utilizza un token, l'emittente non può distinguere il token dagli altri token creati. Tuttavia, al momento i token attendibili non esistono in contesti isolati: esistono altri modi in cui un emittente, in teoria, potrebbe unirsi all'identità di un utente su più siti, come cookie di terze parti e tecniche di monitoraggio nascosto. È 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, quindi non più approfondito qui.

Considerazioni sulla sicurezza

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

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

Meccanismi di richiesta

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

Per ribadire: questa proposta richiede il tuo feedback. Se hai commenti, crea un problema nel repository esplicativo del token di attendibilità.

Scopri di più

Grazie a tutti coloro che hanno contribuito a scrivere e recensire questo post.

Foto di ZSun Fu su Unsplash.