La migrazione agli User-Agent Client Hints: misurare i dispositivi senza la stringa UA completa

La lenta morte della stringa User-Agent

Per decenni l'header di richiesta User-Agent è stato il cavallo di battaglia dell'analytics per rispondere a domande basilari: quale browser, quale sistema operativo, mobile o desktop? Era anche una passività in termini di fingerprinting. Una stringa UA completa come Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xxx.0.0.0 Safari/537.36 rivela numeri di versione precisi e dettagli di piattaforma che, combinati con altri segnali, aiutano a identificare singoli visitatori.

L'iniziativa di User-Agent Reduction di Google sfoltisce questa stringa da anni. Chrome invia ora una UA ridotta, in cui la versione della piattaforma è congelata e i segmenti di versione minore sono azzerati. L'intento, secondo la documentazione di Chrome, è rimuovere l'entropia disponibile passivamente preservando al contempo un sostituto strutturato e a richiesta esplicita: gli User-Agent Client Hints (UA-CH).

Per chi costruisce analytics nel 2026 la conseguenza pratica è chiara. Fare parsing della vecchia stringa UA per ottenere qualcosa di più della famiglia approssimativa del browser è sempre meno affidabile — e sempre più l'approccio sbagliato.

Come funzionano davvero i Client Hints

UA-CH suddivide le informazioni sul dispositivo in hint distinti e richiedibili, anziché in un'unica stringa densa. Gli hint a bassa entropia vengono inviati per impostazione predefinita a ogni richiesta:

• Sec-CH-UA — elenco di brand e versione significativa
• Sec-CH-UA-Mobile — un booleano ?0 / ?1
• Sec-CH-UA-Platform — per esempio "macOS"

Gli hint ad alta entropia — versione completa della piattaforma, architettura, modello, bitness — non vengono inviati a meno che il server non li richieda esplicitamente. Il server li richiede con un header di risposta Accept-CH, e il browser può poi includerli nelle richieste successive. Il prefisso Sec- significa che questi header sono controllati dal browser e non possono essere impostati dagli script: una proprietà di integrità tutt'altro che trascurabile.

Questa inversione conta per la privacy. La postura predefinita è la divulgazione minima. L'entropia aggiuntiva diventa un atto deliberato, registrato nei vostri stessi header di risposta, invece di qualcosa raccolto in silenzio da ogni visitatore.

La lettura privacy-first di questo cambiamento

Monoid resta deliberatamente sul lato a bassa entropia di questo confine. Non inviamo mai Accept-CH per ottenere architettura, modello o versione completa della piattaforma, e non combiniamo mai gli hint che vediamo in una firma stabile del dispositivo. Sarebbe fingerprinting — ricostruire un identificatore a partire dalle caratteristiche del dispositivo — cioè esattamente ciò che la riduzione della UA è stata pensata per impedire, e ciò che l'articolo 5(3) della Direttiva ePrivacy e le policy anti-fingerprinting dei browser trattano come accesso alle informazioni dell'apparecchiatura terminale.

Gli hint predefiniti a bassa entropia bastano per le domande che l'analytics dovrebbe porsi:

• Famiglia e versione maggiore del browser da Sec-CH-UA, per pianificare compatibilità e supporto.
• Mobile o non mobile da Sec-CH-UA-Mobile, per segmentare layout e Core Web Vitals.
• Piattaforma da Sec-CH-UA-Platform, per suddivisioni a livello di sistema operativo.

Il punto cruciale: si tratta di dimensioni aggregate, non di chiavi per singolo visitatore. Un booleano e il nome di una piattaforma condivisi da milioni di visitatori non hanno di per sé alcun potere identificativo significativo.

Leggere gli hint sull'edge

Poiché i Client Hints sono normali header di richiesta, un worker sull'edge può leggerli senza alcuno script lato client. Su Cloudflare gli hint a bassa entropia arrivano sull'oggetto Request in ingresso:

export default {
  async fetch(request) {
    const brands = request.headers.get('Sec-CH-UA') || '';
    const isMobile = request.headers.get('Sec-CH-UA-Mobile') === '?1';
    const platform = request.headers.get('Sec-CH-UA-Platform') || '';
    // Deriva solo dimensioni grossolane; non persistere mai una chiave composita.
    return new Response('ok');
  }
};

Notate ciò che manca: nessun eco di Accept-CH, nessuna richiesta di hint ad alta entropia, nessun hash dei valori combinati. Il valore di Sec-CH-UA è un elenco strutturato, quindi analizzatelo con attenzione — contiene voci di brand "GREASE" intenzionali, pensate per scoraggiare un parsing fragile basato su corrispondenza esatta, una tecnica che la specifica prende in prestito dal TLS.

Cosa cambiare nella vostra pipeline

Se la vostra analytics applica ancora espressioni regolari alla stringa UA completa, col tempo si romperanno tre cose. I numeri di versione scivolano verso .0.0.0, le versioni di piattaforma si congelano e il rilevamento del mobile basato sulla ricerca di sottostringhe diventa inaffidabile. Il percorso di migrazione è lineare:

1. Preferite gli hint strutturati a bassa entropia al parsing della stringa UA.
2. Trattate la stringa UA ridotta come fallback solo per i client più datati.
3. Resistete alla tentazione di richiedere hint ad alta entropia "per sicurezza": ogni hint in più allarga la vostra superficie di fingerprinting e la vostra esposizione in termini di conformità.

La lezione più ampia è coerente con tutto ciò che costruiamo. I produttori di browser stanno rimuovendo con costanza l'entropia passiva dalla piattaforma web. La risposta giusta non è inseguirla attraverso nuove API, ma progettare una misurazione che non ne ha mai avuto bisogno.

Sources

• Chrome for Developers — User-Agent Reduction
• MDN — User-Agent Client Hints headers (Sec-CH-UA)
• W3C — User-Agent Client Hints specification
• MDN — Accept-CH header