Fingerprinting

Il fingerprinting prevede il tentativo di identificare un utente quando torna sul tuo sito web o l'identificazione dello stesso utente su diversi siti web. Molte caratteristiche possono variare tra la tua configurazione e quella di un altro utente. Ad esempio, potresti utilizzare un tipo di dispositivo e un browser diversi, avere schermi di dimensioni differenti e caratteri installati. Se ho installato il carattere "Dejavu Sans" e tu non lo usi, qualsiasi sito web può capire la differenza tra me e te controllando questo carattere. Questo è il funzionamento del fingerprinting: crei una raccolta di questi punti dati, ognuno dei quali offre più modi per distinguere gli utenti.

Una definizione più formale potrebbe essere la seguente: il fingerprinting è l'azione di utilizzare caratteristiche di lunga durata ovvie e non ovvie della configurazione di un utente per cercare di distinguerlo dal maggior numero possibile di altri utenti.

Perché il fingerprinting ostacola la privacy dell'utente

Ci sono alcuni casi limite in cui il fingerprinting di un utente è importante: ad esempio, il rilevamento di attività fraudolente. Tuttavia, il fingerprinting può anche essere utilizzato per monitorare gli utenti su più siti e questo monitoraggio viene spesso eseguito senza il consenso degli utenti o, in alcuni casi, sulla base di un consenso non valido che non informa in modo adeguato l'utente. Una volta fatto ciò, questi utenti lo troveranno un po' inquietante e si sentiranno piuttosto traditi.

Il fingerprinting significa trovare dei modi per distinguere occultamente un utente dall'altro. Il fingerprinting può essere utilizzato per riconoscere che si tratta dello stesso utente sullo stesso sito web o per riconoscere lo stesso utente in due profili del browser diversi contemporaneamente. Ciò significa che il fingerprinting può essere utilizzato per monitorare gli utenti su più siti. I metodi di monitoraggio deterministici e palesi, come l'archiviazione di un cookie con un ID specifico per un utente unico, possono essere in qualche modo osservati dagli utenti e controllati (e il modulo precedente ha spiegato alcuni di questi approcci). Ma il fingerprinting è più difficile da evitare esattamente perché è nascosto, si basa su caratteristiche immutate e molto probabilmente avviene in modo invisibile. Questo è il motivo per cui viene chiamato "fingerprinting". È difficile nel migliore dei casi cambiare l'impronta, sia quella digitale sia quella all'estremità delle dita.

I fornitori di browser sanno che agli utenti non piace essere monitorati e implementano continuamente funzionalità per limitare il fingerprinting (alcune delle quali abbiamo visto nel modulo precedente). Qui, vedremo in che modo queste funzionalità possono influire sui requisiti della tua attività e come continuare a fare ciò che vuoi fare nel rispetto della privacy. Si tratta più del modo in cui la protezione del browser contro il fingerprinting inciderà sulle tue attività e sulle modalità, piuttosto che su come ti impedisce di eseguire il fingerprinting.

In pratica, la maggior parte degli sviluppatori e delle aziende non hanno bisogno di fingerprint degli utenti. Se la tua app richiede agli utenti di eseguire l'accesso, questi si identificano con te, con il loro consenso e in un modo che possono disattivare unilateralmente in qualsiasi momento. Si tratta di un metodo di protezione della privacy che consente di capire quali utenti hanno eseguito l'accesso. La tua app potrebbe non richiedere agli utenti di eseguire l'accesso, il che protegge ancora meglio la loro privacy (in questo caso, raccoglierai solo i dati di cui hai bisogno).

Che cosa fare

Valuta le terze parti per il fingerprinting. Nell'ambito del modulo Terze parti, potresti già avere un elenco dei servizi di terze parti che hai incluso e le richieste web che effettuano. Potrebbe essere possibile controllare queste richieste per vedere quali dati vengono ritrasmessi all'autore dell'origine, se necessario. Tuttavia, questo è spesso difficile: il fingerprinting è per natura un processo nascosto che comporta la richiesta di dati non soggetti all'approvazione dell'utente.

È inoltre consigliabile leggere le norme sulla privacy dei servizi e delle dipendenze di terze parti per cercare indicazioni dell'utilizzo del fingerprinting. A volte è definita "corrispondenza probabilistica" o come parte di una suite di tecniche di corrispondenza probabilistica, invece di "corrispondenza deterministica".

Come funziona il fingerprinting

Spesso la tua combinazione personale di tutti questi attributi è unica per te o almeno per un piccolo gruppo di persone simili; questa combinazione può essere utilizzata per seguirti in modo nascosto.

A parte: fingerprinting passivo e attivo

C'è un'utile distinzione tra tecniche di fingerprinting passiva e attive. Una tecnica di fingerprinting passiva utilizza le informazioni fornite al sito web per impostazione predefinita; una tecnica di fingerprinting attiva è una tecnica che interroga esplicitamente il browser per ulteriori informazioni. Il motivo per cui questa distinzione è importante è che i browser possono tentare di rilevare e intercettare o mitigare le tecniche attive. Le API possono essere limitate o possono essere collegate tramite gateway dietro una finestra di dialogo in cui viene chiesto l'autorizzazione dell'utente (in questo modo gli utenti vengono avvisati che vengono utilizzate o possono essere negati per impostazione predefinita). Una tecnica passiva è quella che utilizza dati già forniti al sito web, spesso perché storicamente, ai tempi iniziali della superstrada dell'informazione, queste informazioni venivano fornite a tutti i siti. La stringa dello user agent è un esempio di questo aspetto, che esamineremo più in dettaglio più avanti. Era considerato utile nel fornire molte informazioni sul browser, sulla versione e sul sistema operativo dell'utente, in modo che un sito web potesse scegliere di presentare cose diverse in base a questi dati. Tuttavia, ciò aumenta anche la quantità di informazioni distintive rese disponibili, informazioni che aiutano a identificare un utente dall'altro; pertanto, queste informazioni non sono più disponibili o sono almeno bloccate in modo da non fare più distinzione. Se ciò che fai si basa su queste informazioni, ad esempio se utilizzi rami di codice diversi a seconda dello user agent, questo codice potrebbe non funzionare perché i browser bloccano o interrompono sempre di più le informazioni. In questo caso i test rappresentano la migliore difesa ( vedi più avanti).

A lato: misurare l'improntabilità

La misura tecnica relativa alla quantità di informazioni fornite da ciascuno di questi punti dati è chiamata entropia e viene misurata in bit. Una funzionalità in cui sono possibili diversi valori (come l'elenco dei caratteri installati) può contribuire molti bit al totale, mentre qualcosa che non ha molta potenza distintiva (come il sistema operativo in uso) potrebbe aggiungerne solo alcuni. L'almanacco HTTP descrive in che modo le librerie di fingerprinting esistenti automatizzano questo processo di combinazione delle risposte di molte API diverse in un "hash", che potrebbe identificare solo un piccolo gruppo di utenti, forse anche uno solo. Maud Nalpas affronta questo argomento in modo dettagliato in questo video di YouTube, ma, in breve, immagina di vedere un elenco dei tuoi amici con la loro musica preferita, il loro cibo preferito e le lingue che parlano, ma senza il loro nome. È molto probabile che l'elenco di un determinato utente lo identifichi in modo univoco tra i tuoi amici o che almeno lo restringa a poche persone. È così che funziona il fingerprinting: l'elenco di cose che ti piacciono diventa l'"hash". Con questo hash, identificare un utente come la stessa persona su due diversi siti non collegati diventa più facile, il che è l'obiettivo del monitoraggio: eludere il desiderio di privacy dell'utente.

Cosa fanno i browser contro il fingerprinting?

È importante sottolineare che i fornitori di browser sono consapevoli dei molti modi diversi in cui un sito web (o una terza parte inclusa in un sito web) può calcolare un'impronta distintiva per un utente o perché bit di informazioni differenti contribuiscono all'unicità di tale impronta. Alcuni di questi metodi sono espliciti e deliberati, ad esempio la stringa user agent del browser, che spesso identifica il browser, il sistema operativo e la versione in uso (contribuisce a distinguerti da me, se io e te usiamo browser diversi). Alcuni modi non sono stati appositamente creati per essere fingerprint, ma finiscono comunque per esserlo, ad esempio l'elenco dei caratteri o i dispositivi video e audio disponibili nel browser. Il browser non deve necessariamente utilizzare questi dispositivi, è sufficiente ottenerne un elenco per nome. E alcuni sono stati comprovati per contribuire all'acquisizione di una fingerprint anche dopo il rilascio, come ad esempio l'esatto rendering in pixel dell'antialiasing dei caratteri su un elemento canvas. Ce ne sono molti altri e ogni modo in cui il tuo browser si differenzia dal mio aumenta l'entropia, quindi potenzialmente contribuisce a distinguere tra te e me e identificare una singola persona nel modo più univoco possibile sui siti web. https://amiunique.org ha un lungo elenco di potenziali funzionalità che contribuiscono all'impronta digitale e l'elenco cresce continuamente (poiché gli utenti non vogliono

Mancato supporto di alcune potenti API

La risposta dei fornitori di browser a tutti questi approcci per il calcolo dell'impronta di un utente è trovare modi per ridurre la quantità di entropia disponibile da queste API. L'opzione più restrittiva consiste nel non implementarli inizialmente. Ciò è stato possibile da alcuni dei principali browser per una varietà di API hardware e per dispositivi (ad esempio l'accesso NFC e Bluetooth dalle app web lato client), con problemi di fingerprinting e di privacy menzionati come motivi per cui non sono state implementate. Questo, ovviamente, può influire sulle tue app e sui tuoi servizi: non puoi utilizzare un'API in un browser che non la implementa e questo può limitare o escludere del tutto alcuni approcci hardware dalla considerazione.

Il gateway delle autorizzazioni utente

Un secondo approccio adottato dai fornitori dei browser consiste nell'impedire l'accesso all'API o ai dati senza un qualche tipo di autorizzazione esplicita dell'utente. Questo approccio viene spesso adottato anche per motivi di sicurezza: un sito web non dovrebbe essere in grado di scattare foto con la webcam senza la tua autorizzazione. Ma qui, privacy e sicurezza possono avere interessi simili. Identificare la posizione di una persona rappresenta una violazione della privacy, ma ciò contribuisce anche all'unicità delle impronte digitali. Richiedere l'autorizzazione per visualizzare la geolocalizzazione non diminuisce l'entropia aggiuntiva aggiunta da una località all'unicità dell'impronta, ma elimina fondamentalmente l'utilizzo della geolocalizzazione per il fingerprinting, perché non viene più eseguita in modo invisibile. Lo scopo del fingerprinting è quello di distinguere gli utenti l'uno dall'altro incredibilmente. Se sei preparato affinché l'utente sappia che stai tentando di identificarlo, non hai bisogno di tecniche di fingerprinting: chiedi all'utente di creare un account e di accedere con quest'ultimo.

Aggiungere imprevedibilità

Un terzo approccio adottato in alcuni casi prevede che i fornitori di browser "fuzz" le risposte dalle API per renderle meno granulari e quindi meno identificabili. Ciò è stato descritto come parte del meccanismo di risposta randomizzata nel modulo dati come qualcosa che puoi fare quando raccogli i dati degli utenti, per evitare di raccogliere inavvertitamente dati che consentono l'identificazione. I fornitori di browser possono adottare questo approccio per i dati delle API resi disponibili anche per app web e terze parti. Un esempio sono le API per i tempi molto precise utilizzate per misurare le prestazioni delle pagine da window.performance.now(). Il browser conosce questi valori con un'accuratezza in microsecondi, ma i valori restituiti vengono deliberatamente ridotti in precisione arrotondando al limite di 20 microsecondi più vicino per evitarne l'uso nel fingerprinting (e anche per la sicurezza, per evitare di sincronizzare gli attacchi, certamente). L'obiettivo qui è garantire che le API rimangano utili, ma rendere le risposte meno identificabili: in sostanza, fornire"immunità di gregge" rendendo il tuo dispositivo più simile a quello di tutti gli altri, anziché essere unico per te. Safari presenta una versione semplificata della configurazione di sistema proprio proprio per questo motivo.

Applicazione di un budget per la privacy

Il budget per la privacy è una proposta che suggerisce ai browser di stimare le informazioni rivelate da ciascuna piattaforma di fingerprinting. Non è stato ancora implementato nei browser. L'obiettivo è consentire API potenti tutelando al contempo la privacy degli utenti. Scopri di più sulla proposta di budget per la privacy.

Utilizzare un ambiente di test ampio

Tutti questi elementi influenzeranno il modo in cui crei app e servizi. In quest'area c'è un'ampia varietà di risposte e approcci per browser e piattaforme. Ciò significa che testare il tuo lavoro in più ambienti diversi è critico. Questo è, ovviamente, sempre importante, ma si può ragionevolmente presumere che il rendering HTML o il CSS saranno costanti per un determinato motore di rendering, indipendentemente dal browser o dalla piattaforma in cui si trova il motore (e di conseguenza potrebbe essere tentata la tentazione di eseguire test in un solo browser basato su Blink). Questo non è assolutamente il caso dell'uso delle API, proprio perché i browser che condividono un motore di rendering possono differire drasticamente in termini di protezione della superficie dell'API contro il fingerprinting.

Che cosa fare

• Controlla le tue analisi e il tuo pubblico per orientare l'insieme di browser a cui dovresti dare la priorità durante i test.
• Un buon insieme di browser su cui eseguire il test sono Firefox, Chrome, Edge, Safari su computer, Chrome e Samsung Internet su Android e Safari su iOS. In questo modo puoi eseguire test sui tre principali motori di rendering (Gecko in Firefox, vari fork di Blink in Chrome, Edge e Samsung Internet e Webkit in Safari), sia su piattaforme mobile che desktop.
• Se il tuo sito potrebbe essere utilizzato anche su dispositivi meno comuni, come tablet, smartwatch o console per videogiochi, esegui un test anche su questi dispositivi. Alcune piattaforme hardware possono restare indietro rispetto ai dispositivi mobili e ai desktop per gli aggiornamenti del browser, il che significa che alcune API potrebbero non essere implementate o non disponibili nei browser su queste piattaforme.
• Esegui il test con uno o più browser che dichiarano la privacy dell'utente come motivazione. Includi versioni pre-release e di test future dei tuoi browser più comuni dove puoi e se sono disponibili: l'anteprima tecnologica di Safari, Canary di Chrome, il canale beta di Firefox. In questo modo hai la migliore possibilità di identificare interruzioni dell'API e modifiche che interessano i tuoi siti prima che le modifiche vengano applicate ai tuoi utenti. Allo stesso modo, tieni a mente gli ambienti dei tuoi utenti con riferimento a qualsiasi analisi disponibile. Se la tua base utenti ha un numero elevato di telefoni Android meno recenti, assicurati di includerli nei tuoi test. La maggior parte delle persone non dispone dell'hardware veloce e delle release più recenti di un team di sviluppo.
• Esegui dei test utilizzando sia un profilo pulito sia in modalità di navigazione in incognito/privata. È probabile che tu abbia già concesso le autorizzazioni richieste nel tuo profilo personale. Verifica cosa succede se neghi l'autorizzazione al sito per qualsiasi domanda.
• Testa in modo esplicito le tue pagine con la modalità di protezione delle impronte di Firefox. In questo modo verranno visualizzate finestre di dialogo di autorizzazione se la pagina sta tentando di eseguire il fingerprinting oppure restituirà dati con problemi per alcune API. In questo modo puoi verificare se terze parti incluse nel tuo servizio usano dati delle impronte digitali o se il tuo servizio dipende da questi dati. Puoi quindi valutare se il fuzzing intenzionale rende più difficile fare ciò che ti serve. Valuta la possibilità di apportare correzioni di conseguenza per ottenere i dati da un'altra fonte, evitarli o utilizzare dati meno granulari.
• Come già discusso nel modulo Terze parti, è importante anche controllare le dipendenze di terze parti per verificare se stanno utilizzando tecniche di fingerprinting. Il fingerprinting passivo è difficile da rilevare (e impossibile se una terza parte lo fa sul proprio server), ma la modalità fingerprint potrebbe segnalare alcune tecniche di fingerprinting. Inoltre, la ricerca di usi di navigator.userAgent o la creazione imprevista di oggetti <canvas> potrebbe anche rivelare alcuni approcci che meritano un ulteriore esame. Inoltre, vale la pena cercare l'uso del termine "corrispondenza probabilistica" in materiali di marketing o tecnici che descrivono una terza parte; questo a volte può indicare l'uso di tecniche di fingerprinting.

Strumenti di test cross-browser

Testare il codice per motivi di privacy è difficile da automatizzare e le cose da cercare durante i test manuali sono descritte in precedenza. Cosa succede, ad esempio, se neghi l'autorizzazione per le API a cui tenta di accedere al sito e come viene presentata all'utente? Un test automatico non è in grado di valutare se il sito agisce in modo da indurre l'utente a fidarsi o, al contrario, incoraggiare l'utente a diffidarsi o pensare che qualcosa sia nascosto.

Tuttavia, in seguito a un controllo del sito, è possibile automatizzare i test delle API per confermare che nulla ha subito malfunzionamenti nelle versioni più recenti del browser (o nelle prossime versioni "beta" e "anteprima") e in gran parte dovrebbero far parte della suite di test esistente. Un aspetto da considerare con gli strumenti di test automatizzati quando si lavora con la copertura della superficie API è che la maggior parte dei browser consente un determinato livello di controllo sulle API e le funzionalità disponibili. Chrome esegue questa operazione mediante opzioni della riga di comando, come Firefox, e avere accesso a queste opzioni nella configurazione dello strumento di test ti permette di eseguire determinati test con le API disattivate o attivate. Vedi, ad esempio, il plug-in del browser-launch di Cypress e il parametrolaunch.args di puppeteer per scoprire come aggiungere flag del browser all'avvio.

Utilizza solo la stringa dello user agent per ottenere informazioni approssimative

Facendo un altro esempio, sin dall'inizio del web i browser hanno inviato una descrizione di se stessi con ogni richiesta nell'intestazione User-Agent HTTP. Da quasi tutto il tempo le persone esortano gli sviluppatori web a non usare i contenuti dell'intestazione user-agent per pubblicare contenuti diversi per browser diversi e, per tutto il tempo, gli sviluppatori web l'hanno fatto comunque, con una certa quantità di giustificazioni in alcuni casi (ma non in tutti). Poiché i browser non vogliono essere individuati per offrire un'esperienza non ottimale dai siti web, ciò fa sì che tutti i browser si fingano di tutti gli altri browser e la stringa dello user agent abbia un aspetto simile al seguente:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

Si tratta, tra le altre cose, di Mozilla/5.0, un browser rilasciato in contemporanea con l'imbarco dei primi astronauti sulla Stazione Spaziale Internazionale oltre due decenni fa. La stringa dello user agent è una ricca fonte di entropia per il fingerprinting, ovviamente, e per mitigare l'improntabilità, i produttori dei browser hanno già bloccato l'intestazione dello user-agent o stanno lavorando per farlo. Questo è un altro esempio di modifica dei dati forniti da un'API senza necessariamente rimuovere completamente l'API. L'invio di un'intestazione user-agent vuota comporterebbe il malfunzionamento di innumerevoli siti web che presuppongono che sia presente. In generale, ciò che fanno i browser è rimuovere alcuni dettagli da questo browser per poi rimanere per lo più invariati da quel momento in poi. Puoi verificarlo in Safari, Chrome e Firefox. Questa protezione contro il fingerprinting dettagliato significa essenzialmente che non è più possibile fare affidamento sull'accuratezza dell'intestazione dello user-agent; se lo fai, è importante trovare origini dati alternative.

Precisiamo che i dati nello user-agent non stanno per scomparire del tutto, ma sono disponibili con una granularità inferiore o, a volte, sono imprecisi perché potrebbero essere riportati un numero più vecchio ma invariato. Ad esempio, Firefox, Safari e Chrome limitano il numero di versione di macOS riportato a dieci (consulta Aggiornamento sulla riduzione delle stringhe dello user agent per saperne di più qui). I dettagli esatti su come Chrome prevede di ridurre i dati nella stringa dello user agent sono disponibili nella pagina User-Agent Reduction, ma, in breve, il numero di versione del browser segnalato conterrà solo una versione principale (quindi il numero di versione sarà 123.0.0.0, anche se il browser è la versione 123.10.45.108) e la versione del sistema operativo verrà bloccata senza dettagli e senza alcuna scelta. Quindi una versione immaginaria di Chrome 123.45.67.89 in esecuzione su un "Windows 20" immaginario segnalerebbe il numero di versione come:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Le informazioni di base necessarie (la versione del browser) sono ancora disponibili: si tratta di Chrome 123, su Windows. Tuttavia, le informazioni sulla società controllata (l'architettura del chip, la versione di Windows, la versione di Safari che imita, la versione secondaria del browser) non saranno più disponibili dopo il blocco.

Confronta questo codice con uno user agent Chrome "attuale" su un'altra piattaforma:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

e si può notare che l'unica cosa che differisce è il numero di versione di Chrome (104) e l'identificatore della piattaforma.

Allo stesso modo, la stringa dello user agent di Safari mostra una piattaforma e un numero di versione di Safari e indica anche una versione del sistema operativo su iOS, ma tutto il resto è bloccato. Quindi una versione immaginaria di Safari 1234.5.67 in esecuzione su un macOS 20 immaginario potrebbe dare al suo user agent come:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

mentre su un iOS 20 immaginario potrebbe essere:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

Anche in questo caso, le informazioni principali (Safari, su iOS o macOS) sono disponibili e iOS Safari fornisce ancora un numero di versione iOS; ma molte delle informazioni accessorie disponibili in passato sono state bloccate. È importante sottolineare che è incluso il numero di versione di Safari, che non è necessariamente disponibile.

Le modifiche allo user agent segnalato sono state molto dibattute. https://github.com/WICG/ua-client-hints#use-cases sintesi riassume alcune delle argomentazioni e dei motivi del cambiamento, mentre Rowan Merewood ha pubblicato una presentazione con alcune strategie per abbandonare lo user agent per la differenziazione, nel contesto di ulteriori suggerimenti per il client UA.

Fuzzing

Fuzzing è un termine della pratica di sicurezza in cui le API vengono chiamate con valori imprevisti nella speranza di gestire male i valori inaspettati e di esporre un problema di sicurezza. Gli sviluppatori web dovrebbero avere familiarità con il cross-site scripting (XSS), che comporta l'aggiunta di script dannosi a una pagina, spesso perché la pagina non esegue correttamente l'escape del codice HTML inserito (quindi devi eseguire una query di ricerca contenente il testo <script>). Gli sviluppatori di backend conoscono l'iniezione SQL, in cui le query di database che non convalidano correttamente l'input utente espongono problemi di sicurezza (come illustrato da xkcd con Little Bobby Tables). Il fuzzing, o test fuzz, è utilizzato più correttamente per i tentativi automatici di fornire molti input non validi o imprevisti a un'API e per verificare i risultati per rilevare fughe di sicurezza, arresti anomali o altri tipi di gestione scorretti. Questi sono tutti esempi di fornitura deliberata di informazioni imprecise. In questo caso, però, viene eseguito preventivamente dai browser (rendendo lo user agent deliberatamente errato) per incoraggiare gli sviluppatori a smettere di fare affidamento su questi dati.

Che cosa fare

• Verifica che nel tuo codebase si faccia affidamento sulla stringa dello user agent (è probabile che una ricerca di navigator.userAgent trovi la maggior parte delle occorrenze nel codice lato client e il codice di backend cercherà User-Agent come intestazione), incluse le dipendenze.
• Se trovi utilizzi nel tuo codice, scopri cosa cerca il codice e trova un altro modo per fare questa differenziazione (o trova una dipendenza sostitutiva o lavora con la dipendenza upstream segnalando i problemi o verificando la disponibilità di aggiornamenti). A volte per aggirare i bug è necessaria la differenziazione del browser, ma, una volta bloccato, lo user agent non sarà più il modo per farlo.
• Potresti stare al sicuro. Se utilizzi solo i valori fondamentali del brand, della versione principale e della piattaforma, questi saranno quasi certamente ancora disponibili e saranno corretti nella stringa dello user agent.
• MDN descrive buoni modi per evitare di fare affidamento sulla stringa user-agent ("browser sniffing"), la cui principale è il rilevamento delle funzionalità.
• Se fai affidamento sulla stringa dello user-agent in qualche modo (anche quando utilizzi pochi valori principali che rimangono utili), è una buona idea eseguire test con gli user agent in arrivo che saranno disponibili nelle nuove release del browser. È possibile eseguire il test con le versioni future del browser tramite build di anteprima beta o tecnologica, ma è anche possibile impostare una stringa user-agent personalizzata per i test. Puoi eseguire l'override della stringa dello user agent in Chrome, Edge, Firefox e Safari, durante lo sviluppo locale, per verificare in che modo il codice viene gestito con i diversi valori dello user agent che potresti ricevere dagli utenti.

Client hint

Una delle principali proposte per fornire queste informazioni è la funzionalità User-Agent Client Hints, anche se non è supportata su tutti i browser. I browser di supporto trasmetteranno tre intestazioni: Sec-CH-UA, che indica il brand e il numero di versione del browser; Sec-CH-UA-Mobile, che indica se la richiesta proviene da un dispositivo mobile, e Sec-CH-UA-Platform, che indica il nome del sistema operativo. L'analisi di queste intestazioni è meno facile di quanto sembri perché sono intestazioni strutturate piuttosto che semplici stringhe e ciò viene applicato dai browser che inviano valori "difficili", che verranno gestiti in modo errato se non analizzati correttamente. Questo è, come in precedenza, un esempio di "test fuzz" eseguito preventivamente dal browser. Uno sviluppatore che utilizza questi dati è tenuto a gestirli correttamente perché i dati sono progettati in modo che un'analisi errata o lazy generi probabilmente risultati errati, come la visualizzazione di brand che non esistono o stringhe che non si chiudono correttamente. Fortunatamente, questi dati vengono resi disponibili anche dal browser a JavaScript direttamente come navigator.userAgentData, che in un browser di supporto potrebbe avere un aspetto simile a questo oggetto:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}