Che cos'è la riduzione dello user agent?

La riduzione dell'user agent (UA) riduce al minimo le informazioni di identificazione condivise nella stringa user agent, che potrebbero essere utilizzate per il fingerprinting passivo. Ora che queste modifiche sono state implementate per la disponibilità generale, tutte le richieste di risorse hanno un'intestazione User-Agent ridotta. Di conseguenza, i valori restituiti da determinate interfacce Navigator sono ridotti, tra cui navigator.userAgent, navigator.appVersion e navigator.platform.

Gli sviluppatori web devono esaminare il codice del proprio sito per verificare l'utilizzo della stringa User-Agent. Se il tuo sito si basa sull'analisi della stringa User-Agent per leggere il modello di dispositivo, la versione della piattaforma o la versione completa del browser, dovrai implementare l'API Client hint User-Agent.

Client hint dello user agent (UA-CH)

Gli indicatori client User-Agent consentono di accedere al set completo di dati User-Agent, ma solo quando i server dichiarano attivamente un bisogno esplicito di dati specifici.

Rimuovendo i dati utente esposti passivamente, misuriamo e riduciamo meglio la quantità di informazioni esposte intenzionalmente dagli intestazioni delle richieste, dalle API JavaScript e da altri meccanismi.

Perché abbiamo bisogno di UA e UA-CH ridotti?

In passato, la stringa User-Agent trasmetteva una grande stringa di dati sul browser, sul sistema operativo e sulla versione di un utente con ogni richiesta HTTP. Questo era problematico per due motivi:

  • La granularità e l'abbondanza di dettagli possono portare all'identificazione dell'utente.
  • La disponibilità predefinita di queste informazioni può portare a un monitoraggio occulto.

UA e UA-CH ridotti migliorano la privacy degli utenti condividendo per impostazione predefinita solo informazioni di base.

Lo User-Agent ridotto include il brand del browser e una versione significativa, la provenienza della richiesta (computer o dispositivo mobile) e la piattaforma. Per accedere a più dati, gli indicatori client User-Agent ti consentono di richiedere informazioni specifiche sul dispositivo o sulle condizioni dell'utente.

Inoltre, nel tempo la stringa User-Agent è diventata più lunga e complessa, il che ha portato a un'analisi della stringa soggetta a errori. UA-CH fornisce dati strutturati e affidabili che sono più facili da interpretare. Il codice esistente che analizza la stringa UA non dovrebbe interrompersi (anche se restituirà meno dati) e dovrai eseguire la migrazione a UA-CH se il tuo sito ha bisogno di informazioni specifiche sul cliente.

Come funzionano UA e UA-CH ridotti?

Ecco un breve esempio di come funzionano la stringa User-Agent ridotta e UA-CH. Per un esempio più approfondito, consulta Migliorare la privacy degli utenti e l'esperienza degli sviluppatori con gli indicatori client User-Agent.

Un utente apre il browser e inserisce example.com nella barra degli indirizzi:

  1. Il browser invia una richiesta per caricare la pagina web.

    1. Il browser include l'intestazione User-Agent con la stringa User-Agent ridotta. Ad esempio: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36

    2. Il browser include le stesse informazioni nelle intestazioni dell'agente utente Client Hint predefinite. Ad esempio:

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. Il server può chiedere al browser di inviare ulteriori suggerimenti per il client, ad esempio il modello del dispositivo, con l'Accept-CH intestazione di risposta. Ad esempio: Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model

  3. Il browser applica i criteri e la configurazione utente per determinare quali dati è consentito restituire al server nelle intestazioni delle richieste successive. Ad esempio:

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

Client hint critici

Se hai bisogno di un insieme specifico di indicatori client nella richiesta iniziale, puoi utilizzare l'intestazione di risposta Critical-CH. I valori di Critical-CH devono essere un sottoinsieme dei valori richiesti da Accept-CH.

Ad esempio, la richiesta iniziale potrebbe includere una richiesta di Device-Memory e Viewport-Width, dove Device-Memory è considerato critico.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

Se il browser richiede un suggerimento critico (Critical-CH) per eseguire il rendering corretto della pagina web, il server può richiedere queste informazioni aggiuntive con l'intestazione Accept-CH. Il browser può quindi inviare una nuova richiesta per la pagina, incluso l'indizio critico.

In sintesi, Accept-CH richiede tutti i valori che vuoi per la pagina, mentre Critical-CH richiede solo il sottoinsieme di valori che devi avere al caricamento per caricare correttamente la pagina. Per ulteriori informazioni, consulta la specifica relativa all'affidabilità degli indicatori client.

Rilevare i dispositivi tablet con l'API UA-CH

Poiché la linea di demarcazione tra dispositivi mobili, tablet e computer continua a diventare meno distinta e i fattori di forma dinamici sono più comuni (schermi pieghevoli, passaggio dalla modalità laptop a quella tablet), è consigliabile utilizzare il design responsive e il rilevamento delle funzionalità per presentare un'interfaccia utente appropriata.

Tuttavia, le informazioni fornite dal browser sia per la stringa User-Agent sia per gli indicatori client User-Agent provengono dalla stessa origine, pertanto dovrebbero funzionare le stesse forme di logica.

Ad esempio, se questo pattern è selezionato nella stringa UA:

  • Pattern del telefono: 'Android' + 'Chrome/[.0-9]* Mobile'
  • Pattern del tablet: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

L'interfaccia delle intestazioni UA-CH predefinite corrispondenti può essere controllata:

  • Pattern di telefono: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • Motivo del tablet: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

Oppure l'interfaccia JavaScript equivalente:

  • Pattern del telefono: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • Pattern del tablet: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

Per i casi d'uso specifici dell'hardware, il nome del modello del dispositivo può essere richiesto tramite il suggerimento Sec-CH-UA-Model ad alta entropia.

Come faccio a utilizzare e testare UA ridotta?

Per iniziare, esamina il codice del tuo sito per individuare le istanze e gli utilizzi della stringa User-Agent. Se il tuo sito si basa sull'analisi della stringa User-Agent per leggere il modello del dispositivo, la versione della piattaforma o la versione completa del browser, dovrai implementare l'API UA-CH.

Dopo aver eseguito l'aggiornamento all'API UA-CH, devi verificare di ricevere i dati previsti dall'agente utente. Esistono tre modi per eseguire il test, ognuno con un livello di complessità crescente.

La disponibilità scalata per la riduzione dello user agent indica la stringa UA completamente ridotta distribuita su tutti i dispositivi Chrome. La riduzione è iniziata con una release minore di Chrome nel secondo trimestre del 2022.

Testare le stringhe personalizzate localmente

Se vuoi testare il tuo sito utilizzando stringhe User-Agent personalizzate per simulare diversi dispositivi, avvia Chrome con il flag della riga di comando --user-agent="Custom string here". Scopri di più sui flag della riga di comando qui.

In alternativa, utilizza l'emulatore di dispositivi in Chrome DevTools.

Trasforma la stringa nel codice del tuo sito

Se elabori la stringa user-agent di Chrome esistente nel codice lato client o lato server, puoi trasformarla nel nuovo formato per testare la compatibilità. Puoi eseguire il test sostituendo la stringa o generando la nuova versione e testando le due versioni affiancate.

Supporto per gli indicatori client e gli indicatori critici

Esistono tre suggerimenti client predefiniti restituito al server, tra cui il nome del browser e la versione principale, un valore booleano che indica se il browser è su un dispositivo mobile e il nome del sistema operativo. Vengono inviati dopo l'handshake del protocollo Transport Layer Security (TLS). Queste funzionalità sono già disponibili e supportate nel tuo browser.

Tuttavia, a volte potresti dover recuperare informazioni importanti per il rendering del tuo sito.

Ottimizzare i suggerimenti critici

Un handshake TLS è il primo passaggio per creare una connessione sicura tra il browser e il server web. Senza un intervento, l'intestazione di risposta Critical-CH è stata progettata per indicare al browser di riprovare immediatamente la richiesta se la prima è stata inviata senza un suggerimento critico.

Diagramma di sequenza per Client Hints con suggerimenti critici.
Quando il server richiede un suggerimento critico, il client riprova a inviare la prima richiesta per la pagina web con il suggerimento critico. In questo esempio, l'indizio per Sec-CH-UA-Model viene richiesto due volte: una come Suggerimento client con Accept-CH e di nuovo come suggerimento critico con Critical-CH.

Per ottimizzare gli indicatori critici (intestazione Critical-CH), devi intercettare questo handshake e fornire un modello per gli indicatori client. Questi passaggi possono essere complessi e richiedere conoscenze avanzate.

I ACCEPT_CH frame HTTP/2 e HTTP/3, combinati con l'estensione TLS ALPS, sono un'ottimizzazione a livello di connessione per fornire le preferenze del client hint del server in tempo per la prima richiesta HTTP. Queste richiedono una configurazione complessa e ti consigliamo di utilizzarle solo per informazioni veramente critiche.

BoringSSL (un fork di OpenSSL) ti consente di utilizzare le funzionalità sperimentali di Google in Chromium. Al momento, ALPS è implementato solo in BoringSSL.

Se devi utilizzare gli indicatori critici, consulta la nostra guida sull'affidabilità e l'ottimizzazione degli indicatori critici.

Domande frequenti

Per quanto tempo verranno inviati i suggerimenti specificati tramite l'intestazione Accept-CH?

I suggerimenti specificati tramite l'intestazione Accept-CH verranno inviati per tutta la durata della sessione del browser o fino a quando non viene specificato un insieme diverso di suggerimenti.

UA-CH funziona con HTTP/2 e HTTP/3?

UA-CH funziona sia con le connessioni HTTP/2 sia con quelle HTTP/3.

I sottodomini (e i CNAME) richiedono una pagina di primo livello Permissions-Policy per accedere a UA-CH ad alta entropia?

Gli UA-CH ad alta entropia nelle intestazioni delle richieste sono limitati nelle richieste cross-origin, indipendentemente da come l'origine è definita lato DNS. La delega deve essere gestita tramite Permissions-Policy per qualsiasi risorsa secondaria cross-origin o ottenuta tramite JavaScript che viene eseguito nel contesto cross-origin.

In che modo la riduzione dello user agent influisce sul rilevamento dei bot?

La modifica della stringa user agent di Chrome non influisce direttamente sulla stringa user agent che un bot sceglie di inviare.

I bot possono scegliere di aggiornare le proprie stringhe in base alle informazioni ridotte inviate da Chrome, ma questa è interamente una scelta di implementazione. Chrome continua a inviare lo stesso formato User-Agent e i bot che aggiungono il proprio identificatore alla fine di una stringa User-Agent di Chrome possono continuare a farlo.

Per eventuali dubbi su bot specifici, potrebbe essere opportuno contattare direttamente i proprietari per chiedere se hanno intenzione di modificare la stringa User-Agent.

Coinvolgere e condividere feedback

Scopri di più