Private Access Tokens: Apple stabilisce già se un client è legittimo

Ha destato non poca preoccupazione la proposta di Google che mira a introdurre a livello di browser Web un meccanismo “inedito” per l’attestazione della “legittimità” del client in uso. Si tratta delle Web Integrity API che hanno iniziato il processo di integrazione in Chromium e Chrome. In realtà Apple sta già facendo qualcosa di molto simile da circa un anno con Private Access Tokens. E non ce ne siamo neppure accorti.

Cosa significa in soldoni? Che l’accesso a funzionalità specifiche oppure a interi siti Web è vincolato all’approvazione del client da parte di un soggetto ritenuto affidabile. Leggasi Google, Microsoft o Apple.

Apple ha già sviluppato e implementato il sistema Private Access Tokens

In questi giorni la soluzione predisposta da Google ha sollevato un vespaio di polemiche. In realtà, come abbiamo accennato in apertura, Apple ha già progettato e implementato qualcosa di molto simile almeno da un anno.

Il sistema Private Access Tokens è parte integrante di macOS 13, iOS 16 e Safari: la ratio, come spiega Apple, è fornire un potente strumento capace di verificare quando le richieste HTTP/HTTPS provengono da dispositivi legittimi, senza rivelare l’identità dell’utente finale.

L’obiettivo, in questo caso, è quello di evitare la comparsa delle “sfide” tipicamente presentate dai CAPTCHA. Superare i CAPTCHA diventa fattibile verificando appunto la “bontà” di ciascun dispositivo client con un processo automatizzato, in grado di escludere l’impiego di procedure automatizzate e, in generale, di bot. Cloudflare e Fastly, ad esempio, utilizzano i Private Access Tokens come meccanismo per rilevare client “reali”.

Come funzionano i Private Access Tokens

Il sistema su cui poggia Private Access Tokens sfrutta semplici chiamate HTTP ed è gestito attraverso le API (Application Programming Interfaces) integrate a livello di browser Web. Queste ultime, a loro volta, dialogano con il sistema operativo per confermare che il browser e in generale la piattaforma utilizzati dall’utente siano “legittimi”. La definizione esatta (eventualmente utilizzata al posto della parola “legittimi”) è lasciata all'”attestatore“, ovvero al soggetto che certifica il dispositivo client. In questo caso ad Apple.

Il flusso dei dati nel caso di Private Access Tokens è più o meno il seguente:

• Il browser effettua una richiesta HTTP a un server Web.
• Il server Web, di primo acchito, rifiuta la richiesta e restituisce una risposta HTTP 401 con una challenge PrivateToken.
• Il browser rileva la challenge e invia alcuni dati salienti, oltre ai dettagli del dispositivo forniti dal sistema operativo, al soggetto attestatore. Quest’ultimo verifica che il dispositivo sia “legittimo” e non sia stato modificato in maniera non autorizzata: sia Android che iOS utilizzano componenti di sistema utili al fini del controllo. L’attestatore, inoltre, collabora con un emittente di token per la restituzione al client di un token firmato. L’ottenimento e il possesso di quest’ultimo dimostra che il dispositivo è verificato.
• A questo punto il browser invia nuovamente la richiesta, inserendo il token firmato nell’intestazione Authorization. Il server ora è certo che il client è verificato da un provider attendibile e può trattare le richieste dell’utente con fiducia.

In HTTP/HTTPS, il termine “challenge” si riferisce a una procedura utilizzata per verificare l’identità o l’autorizzazione di un utente o di un’applicazione che sta tentando di accedere a una risorsa protetta.

Quali sono i problemi intrinseci?

Meccanismi di attestazione come Private Access Tokens oppure Web Integrity API, implicano che gli utenti possano usare solo client approvati per accedere e utilizzare determinati servizi.

Senza usare troppi giri di parole, questi sistemi sono da molti valutati come una minaccia per la concorrenza e l’innovazione. Di fatto potrebbero tagliare le gambe agli sviluppatori che creano un nuovo browser o un nuovo sistema operativo. Se fosse accaduto ai tempi di Internet Explorer 6, questi meccanismi si sarebbero tramutati in un serio ostacolo per la diffusione di Firefox, prima e di Chrome, poi.

Allo stesso modo, uno smartphone sottoposto a rooting è di fatto un dispositivo considerato come “non legittimo”. Così come non può ottenere alcuna approvazione un dispositivo in qualche modo modificato dall’utente. Si pensi alle tante ROM Android di terze parti che oggi è possibile utilizzare in sostituzione di quella originariamente inserita dal produttore.

Le forme di attestazione del dispositivo client come quelle descritte, potrebbero in futuro rendere ancora più intransigenti le posizioni dei produttori. Ad esempio potrebbero essere bloccati gli accessi da parte di chi usa estensioni per il browser ritenute non accettabili oppure i tentativi di connessione effettuati da device non più supportati perché ormai giunti al loro “fine vita”.

Tanta attenzione su Google perché Chrome è il browser dominante

Perché in questi giorni si è parlato tanto delle Web Integrity API mentre Private Access Tokens, già in uso da parte di Apple nel suo ecosistema, sono passate sotto silenzio? Semplice. Chrome vanta oltre il 60% delle quote di mercato nel segmento dei browser e, complessivamente, tutti i prodotti basati su Chromium superano il 70%.

Una maggioranza bulgara che ha portato gli esperti a mettere ai raggi X la soluzione di Google prima ancora di quella della concorrenza. Apple Safari ha circa il 20% delle quote di mercato nei browser (25% su dispositivi mobili e 15% su desktop). L’utilizzo di Chrome è quindi nel complesso fonte di maggiore preoccupazione.

Tuttavia, con Web Integrity API e Private Access Tokens operativi, il 90% dei dispositivi client in uso a livello mondiale si potrebbe trovare a dover superare una procedura di attestazione. Subendo un “trattamento” differente in caso di mancato superamento della stessa.

Credit immagine in apertura: iStock.com/sesame