Grazie per aver seguito Google I/O. Guarda i contenuti on demand.

Questa pagina è stata tradotta dall'API Cloud Translation.

Fingerprinting

Per fingerprinting si intende il tentativo di identificare un utente quando torna sul tuo sito web o di identificare lo stesso utente su siti web diversi. Molte caratteristiche possono variare tra la tua configurazione e quella di un altro utente. Ad esempio, potresti utilizzare un tipo di dispositivo diverso e un browser diverso, avere dimensioni dello schermo diverse e avere installato caratteri diversi. Se ho installato il carattere "Dejavu Sans" e tu no, qualsiasi sito web può distinguere tra me e te controllando la presenza di questo carattere. Ecco come il fingerprinting. crei una raccolta di questi punti dati, ciascuno dei quali offre ulteriori modi per distinguere gli utenti.

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

Perché il fingerprinting ostacola la privacy degli utenti

Esistono alcuni casi limite in cui il fingerprinting di un utente è importante, ad esempio il rilevamento delle 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 adeguatamente l'utente. Al termine, questi utenti spesso lo trovano un po' inquietante e si sentono piuttosto traditi.

Con fingerprinting si intende trovare modi per distinguere in modo occulto un utente da un altro. Le fingerprint possono essere usate per riconoscere che si tratta sempre dello stesso utente sullo stesso sito web o a riconoscere lo stesso utente in due diversi profili del browser contemporaneamente. Ciò significa che il fingerprinting può essere utilizzato per monitorare gli utenti su tutti i siti. I metodi di monitoraggio deterministici e palesi, come la memorizzazione di un cookie con un ID utente univoco, possono essere osservati e controllati in qualche misura dagli utenti (e il modulo precedente ha spiegato alcuni di questi approcci). Ma il fingerprinting è più difficile da evitare con precisione perché è nascosto. fa affidamento su caratteristiche immutabili e molto probabilmente avviene invisibilmente. Ecco perché viene chiamato "fingerprinting". Nella migliore delle ipotesi è difficile cambiare l'impronta digitale, sia quella digitale sia quella finale delle dita.

I fornitori di browser sanno che agli utenti non piace essere monitorati e stanno continuamente implementando funzionalità per limitare il fingerprinting (alcune delle quali abbiamo visto nel modulo precedente). In questo articolo esamineremo in che modo queste funzionalità possono influire sui requisiti della tua attività e come continuare a fare ciò che vuoi in modo da proteggere la privacy. Si tratta più di come la protezione del browser contro l'impronta influirà su cosa fai e come, piuttosto che su come ti impedirà di creare l'impronta.

In pratica, la maggior parte degli sviluppatori e delle aziende non ha bisogno di inserire le impronte digitali degli utenti. Se la tua app richiede agli utenti di accedere, gli utenti si identificano con te, con il loro consenso e in un modo che consente loro di disattivare unilateralmente la funzionalità in qualsiasi momento. Si tratta di un metodo che protegge la privacy per capire quali utenti hanno eseguito l'accesso. La tua app potrebbe non richiedere agli utenti di accedere, il che protegge ancora di più la loro privacy (e raccoglierai solo i dati di cui hai bisogno).

Cosa fare

Valuta le terze parti per il fingerprinting. Nell'ambito del modulo Terze parti, puoi potrebbe già disporre di un elenco degli eventuali servizi di terze parti che hai incluso e delle richieste web che effettua. Potrebbe essere possibile per esaminare queste richieste per vedere quali dati vengono restituiti all'autore dell'origine, se presenti. Tuttavia, spesso è difficile: il fingerprinting è per natura un processo nascosto che prevede la richiesta di dati non soggetti all'approvazione dell'utente.

Vale la pena leggere anche le norme sulla privacy dei servizi e delle dipendenze di terze parti per cercare indicazioni sull'eventuale utilizzo del fingerprinting. A volte viene definita "corrispondenza probabilistica" o fa parte di una suite di tecniche di corrispondenza probabilistica, al contrario della "corrispondenza deterministica".

Come funziona il fingerprinting

Spesso la combinazione personale di tutti questi attributi è unica per te oppure in a un gruppo ristretto di persone con caratteristiche simili. può essere usato per rintracciarti in modo nascosto.

Nota a margine: fingerprinting passivo e attivo

Qui occorre fare una distinzione utile tra le tecniche di fingerprinting passiva e attiva. Il fingerprinting passivo è quella che utilizza informazioni fornite al sito web per impostazione predefinita; una tecnica di fingerprinting attiva è una che interroga esplicitamente il browser per cercare informazioni aggiuntive. Questa distinzione è importante perché i browser può tentare di rilevare e intercettare, o mitigare, le tecniche attive. Le API possono essere limitate o collegate tramite gateway dietro a una finestra di dialogo Richiesta dell'autorizzazione dell'utente (e quindi avvisa l'utente che è in uso o consente all'utente di negarlo) per impostazione predefinita). Una tecnica passiva è quella che utilizza i dati già forniti al sito web, spesso perché storicamente, nei primi giorni della superstrada dell'informazione, queste informazioni venivano fornite a tutti i siti. La stringa dello user agent è un un esempio di questo aspetto, che vedremo in dettaglio più avanti. È stato considerato utile per fornire molte informazioni sul browser, sulla versione e sul sistema operativo dell'utente in modo che un sito web possa scegliere di presentare in base a ciò. Tuttavia, ciò aumenta anche la quantità di informazioni distintive rese disponibili, che aiuta a distinguere un utente dall'altro; Pertanto, queste informazioni non sono più disponibili o sono comunque congelate in modo da non fare più distinzione. Se le tue azioni si basano su queste informazioni, ad esempio se utilizzi diversi rami di codice a seconda dell'user-agent, questo codice potrebbe non funzionare più man mano che i browser bloccano o interrompono sempre più queste informazioni. In questo caso, i test sono la difesa migliore ( vedi più avanti).

A parte: misurare la fingerprintabilità

La misura tecnica della quantità di informazioni fornite da ciascuno di questi punti dati si chiama entropia e viene misurata in bit. Una funzionalità per cui sono possibili molti valori diversi (come l'elenco dei caratteri installati) può contribuire con molti bit al totale, per cui un elemento con un potere di distinzione elevato (ad esempio il sistema operativo in uso) potrebbe aggiungere alcuni. L'HTTP Almanac descrive in che modo le librerie di fingerprinting esistenti automatizzano questo processo di combinazione delle risposte di molte API diverse in un "hash", che può identificare solo un piccolo gruppo di utenti, forse anche solo uno. Maud Nalpas tratta questo argomento in dettaglio questo video di YouTube, ma, in breve, immagina che dovessi vedere un elenco dei tuoi amici con la loro musica e il loro cibo preferito e le lingue che parlano... ma con i loro nomi. rimosso. È molto probabile che l'elenco di una persona la identifichi in modo univoco tra i tuoi amici o almeno lo limi a poche persone. Questo è il funzionamento del fingerprinting: l'elenco di ciò che ti piace diventa l'"hash". Con questo hash, identificare un utente come la stessa persona su due diversi siti non collegati diventa più facile, che è l'obiettivo di monitoraggio: per eludere il desiderio di privacy dell'utente.

Cosa fanno i browser contro il fingerprinting?

È importante sottolineare che i fornitori di browser sono molto consapevoli di 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 in cui diversi bit di informazioni possono contribuire all'unicità di quell'impronta. Alcuni di questi metodi sono espliciti e voluti, ad esempio la stringa user agent del browser, che spesso Identifica il browser, il sistema operativo e la versione in uso (e ciò contribuisce a distinguerti da me, se tu e utilizzo diversi browser). Alcuni metodi non sono stati intenzionalmente creati per essere impronte, ma finiscono per esserlo in ogni caso, ad esempio l'elenco dei caratteri o i dispositivi video e audio disponibili per il browser. (il browser non deve utilizzare questi dispositivi, ottieni un elenco per nome.) Inoltre, è stato stabilito che alcuni contribuiscono a creare una impronta anche molto tempo dopo il rilascio, ad esempio il rendering esatto dei pixel dell'antialiasing dei caratteri in un elemento canvas. Ce ne sono molti altri e ogni modo in cui il browser differisce dal mio aggiunge entropia e quindi contribuisce potenzialmente a una un modo per capire la differenza tra te e me e identificare una singola persona nel modo più univoco possibile su tutti i siti web. https://amiunique.org offre un lungo elenco (ma sicuramente non esaustivo) di potenziali contributi tramite fingerprint e l'elenco continua a crescere (perché esiste un forte interesse monetario nel riuscire a utilizzare le impronte digitali degli utenti, anche se non lo vuoi o magari non te lo aspetti).

Mancato supporto di alcune API potenti

La risposta dei fornitori di browser a tutti questi approcci al calcolo del fingerprint di un utente è trovare modi per ridurre la quantità di entropia disponibile da queste API. L'opzione più restrittiva è non implementarli. Questa operazione è stata eseguita da alcuni dei principali browser per diverse API hardware e dei dispositivi (ad esempio, NFC e accesso Bluetooth da app web lato client), con problemi di fingerprinting e privacy citati come motivi per cui non sono stati implementati. Questo, ovviamente può incidere sulle tue app e sui tuoi servizi: non puoi utilizzare un'API in un browser che non la implementa e questo può escludere completamente alcuni approcci hardware.

Il gateway delle autorizzazioni utente

Un secondo approccio adottato dai fornitori di browser consiste nel impedire l'accesso ad API o dati senza una qualche forma esplicita di autorizzazione dell'utente. Questo approccio viene spesso adottato anche per motivi di sicurezza: un sito web non deve essere in grado di scattare foto con la tua webcam senza la tua autorizzazione. In questo caso, però, privacy e sicurezza possono avere interessi simili. L'identificazione della posizione di una persona è violazione della privacy di per sé, ovviamente, ma contribuisce anche all'unicità di un'impronta. Richiesta dell'autorizzazione la geolocalizzazione non riduce l'entropia extra che una località aggiunge all'unicità dell'impronta, ma in sostanza elimina l'utilizzo della geolocalizzazione per il fingerprinting, perché questa operazione non viene più eseguita in modo invisibile. L'intero punto il fingerprinting consiste nel distinguere surreptisamente gli utenti l'uno dall'altro. Se sei pronto a che 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 questo account.

Aggiunta di imprevedibilità

Un terzo approccio adottato in alcuni casi prevede che i fornitori di browser "offuschino" le risposte delle API per renderle meno granulari e quindi meno identificabili. Questo è stato descritto come parte del meccanismo di risposta casuale nel modulo relativo ai dati come qualcosa che puoi fare quando raccogli dati dagli utenti per evitare di raccogliere inavvertitamente dati che consentono l'identificazione. Fornitori di browser possono adottare questo approccio per i dati delle API resi disponibili anche alle app web e a terze parti. Un esempio è la API con tempi molto precisi utilizzati per misurare il rendimento delle pagine da window.performance.now(). Il browser conosce questi valori con un'accuratezza in microsecondi, ma i valori restituiti vengono deliberatamente ridotti di precisione arrotondandoli ai 20 microsecondi più vicini confine per evitare il loro utilizzo nel fingerprinting (e anche per la sicurezza per evitare attacchi temporali, bisogna ammettere). L'obiettivo è garantire che le API rimangano utili, ma rendere le risposte meno identificabili: in sostanza, fornire "immunità di gregge" facendo sembrare il tuo dispositivo più simile a quello di tutti gli altri anziché essere peculiare per te. Safari presenta una versione semplificata della configurazione di sistema proprio per questo.

Applicare un budget per la privacy

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

Utilizza un ambiente di test ampio

Tutti questi aspetti influiranno sul modo in cui crei app e servizi. In particolare, le risposte e gli approcci sono molto diversi tra browser e piattaforme in quest'area. Ciò significa che testare il tuo lavoro in più ambienti diversi è fondamentale. Questo è ovviamente sempre importante, ma può essere ragionevole presumere che il rendering HTML o CSS sia costante per un determinato motore di rendering, indipendentemente dal browser o dalla piattaforma in cui si trova (e quindi può essere allettante testare solo su un browser basato su Blink, ad esempio). Questo non è assolutamente il caso dell'uso delle API, proprio perché i browser che condividono può differire notevolmente in termini di protezione della superficie API contro il fingerprinting.

Cosa fare

Controlla le tue analisi e il tuo pubblico per determinare l'insieme di browser a cui dovresti dare la priorità durante il test.
Un buon insieme di browser da testare è composto da Firefox, Chrome, Edge, Safari su computer, Chrome e Samsung Internet su Android e Safari su iOS. In questo modo potrai testare i tre principali motori di rendering (Gecko in Firefox, vari fork di Blink) in Chrome, Edge e Samsung Internet, nonché Webkit in Safari), nonché su piattaforme mobile e desktop.
Se il tuo sito potrebbe essere utilizzato anche su dispositivi meno comuni, come tablet, smartwatch o console per videogiochi, esegui il test anche su questi dispositivi. Alcune piattaforme hardware possono essere in ritardo rispetto a quelle mobile e desktop per gli aggiornamenti del browser, il che significa che alcune API potrebbero non essere implementate o essere disponibili nei browser su queste piattaforme.
Esegui il test con uno o più browser che spingano la privacy degli utenti. Includi le versioni di prova e pre-release imminenti dei browser più comuni, se disponibili: Technology Preview di Safari, Canary di Chrome, canale beta di Firefox. Queste ti offrono le migliori possibilità di identificare i malfunzionamenti delle API e le modifiche che interessano i tuoi siti prima che queste modifiche si ripercuotano i tuoi utenti. Allo stesso modo, fai in modo che i tuoi utenti ambienti in mente con riferimento alle analisi che avete presentato. Se le tue La base utenti ha un numero elevato di smartphone Android meno recenti, assicurati di includerli nei tuoi test. La maggior parte delle persone non ha l'hardware veloce e le ultime release usate da un team di sviluppo.
Eseguire test sia con un profilo pulito che 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 nella protezione anti-impronta di Firefox . In questo modo verranno mostrate le finestre di dialogo delle autorizzazioni se la pagina sta tentando di eseguire il fingerprinting oppure verranno restituiti dati fuzzed per alcune API. In questo modo puoi verificare se terze parti incluse nel tuo servizio utilizzano dati che possono essere sottoposti a fingerprinting o se il tuo servizio dipende da questi dati. Puoi quindi valutare se la fuzzing intenzionale rende più difficile fare ciò che ti serve. Valuta la possibilità di apportare correzioni in modo da ottenere i dati da un'altra fonte, farne a meno o utilizzare dati meno granulari.
Come discusso in precedenza nel modulo sulle terze parti, è importante anche eseguire la revisione delle dipendenze di terze parti per verificare se utilizzano tecniche di fingerprinting. Il fingerprinting passivo è difficile da rilevare (e impossibile se una terza parte lo fa sul proprio server), ma la modalità di fingerprinting potrebbe segnalare alcune tecniche di fingerprinting, Anche la ricerca di utilizzi di navigator.userAgent o della creazione imprevista di oggetti <canvas> può rivelare alcuni approcci che meritano un'analisi più approfondita. È inoltre opportuno cercare gli usi del termine "corrispondenza probabilistica" nel marketing o materiale tecnico che descrive una terza parte; Ciò a volte può indicare l'utilizzo di tecniche di fingerprinting.

Strumenti di test multipiattaforma

Il test del codice per motivi di privacy è difficile da automatizzare e gli elementi da cercare durante il test manuale sono descritti in precedenza. Ad esempio, cosa succede quando neghi l'autorizzazione al sito per qualsiasi API a cui tenta di accedere e come viene presentata all'utente? Un test automatico non può valutare se il sito agisce in modo da rafforzare la fiducia dell'utente o, al contrario, incitare l'utente a diffidare. o pensare che qualcosa sia nascosto.

Tuttavia, una volta che il sito è stato controllato, il test delle API per confermare che non abbia funzionato nelle versioni più recenti del browser (o in "beta" in arrivo e "anteprima" ) possono essere automatizzate e in gran parte dovrebbero far parte della suite di test esistente. Qualcosa da considerare con gli strumenti per i test automatici, quando si lavora con la copertura della superficie delle API, è che la maggior parte dei browser consente un certo controllo sulle API e sulle funzionalità disponibili. Chrome lo fa tramite gli switch a riga di comando, come Firefox, e avere accesso a questi nella configurazione dello strumento di test ti consentirà di eseguire determinati test con le API disattivate o attivate. (Vedi, ad esempio, l'elenco delle plug-in per l'avvio del browser e il parametro "launch.args" di puppeteer per aggiungere flag del browser all'avvio).

Fare affidamento solo sulla stringa user-agent per informazioni approssimative

Per fare un altro esempio, i browser, fin dall'inizio del web, inviano una descrizione di se stessi con ogni richiesta nell'intestazione HTTP User-Agent. Da quasi altrettanto tempo, gli sviluppatori web vengono esortati a non utilizzare i contenuti dell'intestazione user-agent per pubblicare contenuti diversi in base al browser, ma per tutto questo tempo lo hanno fatto comunque, con una certa giustificazione in alcuni (ma non in tutti) i casi. Poiché i browser non vogliono essere selezionati per offrire un'esperienza non ottimale per i siti web, In questo modo, ogni browser si spaccia per un altro browser e la stringa dello user agent ha il seguente aspetto:

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.

Afferma, tra le altre cose, di essere Mozilla/5.0, un browser rilasciato nello stesso momento in cui i primi astronauti sono saliti sulla Stazione Spaziale Internazionale più di due decenni fa. La stringa user agent è una ricca fonte di entropia per il fingerprinting, ovviamente e per mitigare tale improntabilità, i produttori dei browser hanno già bloccato l'intestazione dello user agent o stanno lavorando a questo scopo. Questo è un altro esempio di modifica dei dati forniti da un'API senza necessariamente rimuoverla completamente. L'invio di un'intestazione user-agent vuota potrebbe causare il malfunzionamento di innumerevoli siti web che presuppongono che sia presente. Quindi, in generale, cosa fanno i browser è la rimozione di alcuni dettagli e di mantenerli praticamente invariati da quel momento in poi. (Puoi vedere che questo accade in Safari, Chrome e Firefox. Questa protezione il fingerprinting dettagliato significa essenzialmente che non puoi più fare affidamento sull'accuratezza dell'intestazione dello user agent. Se stai A tal fine, è importante trovare origini dati alternative.

Per essere chiari, i dati nell'user-agent non scompariranno del tutto, ma saranno disponibili a una granularità inferiore o a volte non saranno accurati perché potrebbe essere riportato un numero precedente, ma invariato. Ad esempio, Firefox, Safari e Chrome (tutto in maiuscolo) il numero di versione di macOS segnalato a dieci (vedi Aggiornamento sulla riduzione delle stringhe dello user agent). per ulteriori discussioni). I dettagli esatti su come Chrome prevede di ridurre i dati nella stringa user agent sono disponibili nella pagina Riduzione User-Agent, ma, in breve, puoi aspettarti che il numero di versione del browser registrato contenga solo una versione principale (quindi il numero di versione sarà simile a 123.0.0.0, anche se il browser è nella versione 123.10.45.108) e la versione del sistema operativo non sarà dettagliata e verrà bloccata su una di un numero limitato di scelte invariabili. Quindi una versione immaginaria di Chrome 123.45.67.89 in esecuzione su un "Windows 20" indica il numero di versione:

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 di cui hai bisogno (la versione del browser) sono ancora disponibili: si tratta di Chrome 123 su Windows. Ma la società controllata informazioni (l'architettura dei chip, la versione di Windows, la versione di Safari che sta imitando, la versione secondaria del browser) non saranno più disponibili dopo il blocco.

Confrontalo con un user-agent di Chrome "attuale" su una piattaforma diversa:

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 differenza è il numero di versione di Chrome (104) e l'identificatore della piattaforma.

Analogamente, la stringa user-agent di Safari mostra una piattaforma e un numero di versione di Safari, nonché una versione del sistema operativo su iOS, ma tutto il resto è bloccato. Quindi una versione di Safari immaginaria 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,

e 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**.

Ancora una volta, le informazioni di base (questo è Safari, è su iOS o macOS) sono disponibili e Safari per iOS fornisce ancora un numero di versione di iOS. Tuttavia, molte delle informazioni accessorie disponibili in passato sono state bloccate. È importante sottolineare che questo include il numero di versione di Safari, che non è necessariamente disponibile.

Le modifiche allo user agent segnalato sono state ampiamente dibattute. Riepiloghi https://github.com/WICG/ua-client-hints#use-cases Summarises degli argomenti e delle ragioni del cambiamento e Rowan Merewood ha una presentazione con alcune strategie per abbandonare l'utilizzo dello user agent per la differenziazione, nel contesto della proposta UA Client Hints spiegata più avanti.

Fuzzing

Il fuzzing è un termine della pratica di sicurezza, in cui le API vengono chiamate con valori imprevisti nella speranza che gestiscano male questi valori e mettano in evidenza un problema di sicurezza. Gli sviluppatori web devono avere familiarità con il cross-site scripting (XSS), che comporta l'aggiunta di script dannosi a una pagina, spesso perché quest'ultima non esegue correttamente l'interpretazione letterale all'HTML inserito (quindi esegui una query di ricerca con il testo <script>). Gli sviluppatori di backend saranno a conoscenza dell'iniezione SQL, in cui le query del database che non convalidano correttamente l'input dell'utente espongono problemi di sicurezza (come illustrato in particolare da xkcd con Little Bobby Tables). Il fuzzing, o test di fuzz, viene utilizzato più propriamente per tentativi automatici di fornire molti input diversi non validi o imprevisti a un'API e per verificare se i risultati presentano fughe di dati, arresti anomali o altri errori di gestione. Questi sono tutti esempi di fornire deliberatamente informazioni imprecise. In questo caso, però, viene fatto preventivamente dai browser (rendendo lo user agent deliberatamente errato), per incoraggiare gli sviluppatori a smettere di fare affidamento su quei dati.

Cosa fare

Controlla se nel codebase dipende la stringa dello user agent (è probabile che la ricerca di navigator.userAgent registri la maggior parte delle occorrenze) nel codice lato client ed è probabile che il codice di backend cerchi User-Agent come intestazione), incluso il codice delle dipendenze.
Se individui gli utilizzi nel tuo codice, scopri cosa viene controllato dal codice e trova un altro modo per differenziarlo (o trovare una dipendenza sostitutiva o lavorare con la dipendenza a monte, segnalando i problemi o verificando la disponibilità di aggiornamenti). A volte la differenziazione del browser è necessaria per aggirare i bug, ma lo user agent diventerà sempre più difficile da usare una volta bloccato.
Potresti essere al sicuro. Se utilizzi solo i valori principali di marca, versione principale e piattaforma, è quasi certo che questi valori saranno ancora disponibili e corretti nella stringa dell'agente utente.
MDN descrive buoni modi per evitare di fare affidamento sulla stringa user-agent ("browser sniffing"), tra cui il rilevamento delle funzionalità.
Se in qualche modo fai affidamento sulla stringa user agent (anche quando utilizzi i pochi valori principali che rimangono utili), da testare con gli user agent imminenti che saranno inclusi nelle nuove release del browser. È possibile eseguire il test con le versioni imminenti del browser tramite build beta o di anteprima della tecnologia, ma è anche possibile impostare una stringa user-agent personalizzata per i test. Puoi sostituire la stringa dello user agent in Chrome, Edge, Firefox e Safari durante lo sviluppo locale, per verificare in che modo il codice gestisce i diversi valori dello user agent che potresti ricevere dagli utenti.

Client hint

Una proposta importante per fornire queste informazioni è rappresentata dai client hint User-Agent, anche se non sono supportati in tutti i browser. I browser di supporto passeranno tre intestazioni: Sec-CH-UA, che fornisce una marca e un 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 dà un nome al sistema operativo. L'analisi di queste intestazioni è meno facile di quanto sembra perché si tratta di intestazioni strutturate anziché di semplici stringhe e questo viene applicato dai browser che inviano valori "difficili", che verranno gestiti in modo errato se non vengono analizzati correttamente. Come accennato in precedenza, questo è un esempio di "fuzz test" eseguito in modo preventivo dal browser. Uno sviluppatore che utilizza questi dati deve gestire correttamente perché i dati sono progettati in modo che un'analisi non corretta o lazy darà probabilmente risultati negativi, come mostrare brand che non o stringhe che non si chiudono correttamente). Fortunatamente, questi dati vengono resi disponibili anche dal browser in JavaScript direttamente navigator.userAgentData, che in un browser di supporto potrebbe essere simile al seguente oggetto:

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