FROST trasforma l'accesso al disco del browser in uno strumento di sorveglianza

Ogni volta che un browser acquisisce nuove capacità, apre anche qualche finestra inattesa. L'ultima dimostrazione arriva da un gruppo di ricercatori della Graz University of Technology, che ha descritto un attacco battezzato FROST: sfruttando un'API ormai standard dei browser moderni, è possibile misurare i tempi di accesso all'SSD e ricavare informazioni su quali siti e applicazioni la vittima stia usando in quel momento. Il tutto eseguendo semplice JavaScript in una pagina web visitata dall'utente, senza installare nulla e senza chiedere alcun permesso.

Il filesystem invisibile al centro dell'attacco

Per capire come funziona FROST bisogna partire dall'OPFS, il meccanismo che i browser mettono a disposizione delle applicazioni web per gestire file in locale. L'OPFS è progettato come uno spazio privato per ogni sito, isolato e invisibile all'utente: non compare nel filesystem del computer, non richiede autorizzazioni esplicite e funziona dentro una sandbox. È nato per rendere possibili web app più vicine al software desktop — editor di testo, strumenti di produttività, applicazioni che funzionano anche offline, librerie che gestiscono database locali — consentendo operazioni su disco più dirette e performanti rispetto alle vecchie soluzioni.

FROST usa proprio questa caratteristica come leva. L'idea di fondo è costringere il browser a compiere operazioni di lettura e scrittura che arrivino davvero all'SSD fisico, aggirando la cache in memoria del sistema operativo. Per farlo, i ricercatori usano un file OPFS molto grande: un oggetto abbastanza voluminoso ha più probabilità di generare accessi reali al disco. A quel punto, mentre l'utente lavora su altre app o tiene aperte altre pagine, la contesa delle risorse di I/O — cioè chi sta usando l'SSD in quel momento — lascia una traccia temporale misurabile. Non serve un segnale preciso: basta un pattern ripetibile, che modelli di machine learning riescono a classificare anche in presenza di rumore.

Non è fingerprinting tradizionale

Molte tecniche di fingerprinting — cioè di identificazione degli utenti tramite le caratteristiche del loro dispositivo — si basano su elementi statici: il tipo di scheda grafica, i font installati, le impostazioni del browser. FROST punta invece all'attività in corso, promettendo un salto concettuale da «chi sei» a «cosa stai facendo adesso». In pratica, non si tratta di rubare password o file, ma di capire il contesto: se l'utente sta lavorando in una certa applicazione, se ha aperto un sito sensibile, se sta usando un servizio specifico.

La dinamica ricorda quella della stagione 2018, quando le vulnerabilità Spectre e Meltdown nei processori costrinsero i produttori di browser a intervenire riducendo la precisione dei timer interni. Quella risposta fu parziale: gli attaccanti impararono ad amplificare le differenze temporali o a costruire «cronometri» alternativi sfruttando altre risorse. Negli anni successivi la ricerca accademica ha dimostrato più volte che i side-channel — i canali laterali che permettono di inferire informazioni in modo indiretto — non dipendono necessariamente da un singolo meccanismo.

Il browser è diventato un sistema operativo e porta con sé gli stessi rischi fisici

I vendor minimizzano, ma il problema resta aperto

Secondo quanto riportato nella copertura delle ultime ore, aziende come Google, Apple e Mozilla hanno minimizzato il rischio, non considerando il fingerprinting una vulnerabilità di sicurezza in senso stretto. La distinzione è tutt'altro che tecnica: classificare un comportamento come «abuso della privacy» anziché come «bug di sicurezza» significa inserirlo in una zona grigia, fatta di mitigazioni incrementali, euristiche diverse tra browser e tempi di risposta molto più lenti.

Un aspetto che pesa sulla praticabilità dell'attacco fuori dal laboratorio riguarda le quote di storage, cioè i limiti massimi di spazio che ogni sito può occupare sul disco dell'utente. Questi limiti variano sensibilmente tra browser e piattaforme: la documentazione tecnica di MDN riporta che su macOS con un disco da 1 TiB, Safari può arrivare a consentire a ogni singolo sito fino a circa 600 GiB. Sul fronte Firefox, una discussione pubblica nel sistema di tracciamento dei bug indica una soglia predefinita di 10 GB per sito, che può crescere se l'utente ha concesso il cosiddetto persistent storage. Per un attacco che ha bisogno di file molto grandi per ridurre l'effetto della cache, la differenza tra 10 GB e centinaia di gigabyte cambia radicalmente la fattibilità pratica.

Ogni nuova capacità apre un canale laterale

Il punto che mette pressione sui produttori di browser è la direzione di marcia, non la singola tecnica. Per far girare applicazioni web ricche servono API che parlino con GPU, storage, thread e file: ogni volta che il web guadagna prestazioni, guadagna anche nuovi percorsi indiretti per ricavare informazioni che non dovrebbero essere accessibili. Lo storage locale del browser sta diventando abbastanza capiente e veloce da produrre segnali fisici misurabili — e quei segnali, a differenza delle caratteristiche statiche del dispositivo, descrivono comportamenti in tempo reale.

Le mitigazioni pulite sono rare. Limitare drasticamente le dimensioni dei file OPFS, o richiedere un permesso esplicito quando un sito vuole allocare molto spazio, avrebbe un impatto diretto sulle web app che cercano di sostituire il software tradizionale. La gestione delle quote di storage da parte dei vendor riflette questa tensione strutturale: le piattaforme promettono potenza senza attrito, ma ogni frizione introdotta per motivi di sicurezza — limiti, prompt, rumore artificiale nei timer — ha un costo immediato e visibile, mentre i benefici restano invisibili finché non emerge un caso pubblico.

Ogni freno alla sorveglianza rallenta anche le app che usiamo ogni giorno

Cosa cambia per chi naviga

Per l'utente comune la domanda è diretta: basta visitare un sito malevolo? Secondo il modello descritto dai ricercatori, sì — l'attacco parte dal JavaScript caricato nella pagina, senza estensioni né codice nativo. Questo però non si traduce automaticamente in un rischio elevato nella pratica: perché l'inferenza sia utile, chi attacca deve disporre di modelli addestrati e di una mappa precisa dei target. Lo scenario più plausibile non è l'inventario completo di tutto ciò che è aperto, ma la profilazione di contesto: capire se l'utente sta lavorando in una certa app o visitando un sito sensibile. Un'informazione che non ruba credenziali, ma rende più efficaci tracciamento e sorveglianza mirata.

La risposta più probabile da parte dei vendor, se arriverà, sarà stratificata: quote più conservative e uniformi, limiti dinamici quando vengono rilevati pattern anomali di accesso al disco, possibili cambiamenti nel modo in cui le operazioni OPFS vengono schedulate per rendere meno misurabile la contesa. La storia recente dei browser suggerisce però che «mitigazione» non equivale a «eliminazione del problema»: se il browser continua ad esporre sempre più risorse hardware a codice remoto, i canali laterali tenderanno a migrare verso nuove superfici, non a scomparire.

Sul piano pratico, due indicazioni rimangono solide indipendentemente dall'evoluzione della vicenda. La prima è comportamentale: pagine e script di terze parti, anche senza chiedere permessi, possono raccogliere segnali che diventano dati. La seconda è tecnica: aggiornare il browser appena arrivano modifiche alle policy di storage e usare consapevolmente la modalità di navigazione privata, che in molti browser applica regole più restrittive sulla persistenza dei dati. Non è una protezione assoluta, ma è coerente con il modo in cui l'ecosistema sta già cercando di bilanciare esperienza utente e riduzione della tracciabilità.