El ataque FROST permite a una página web identificar qué sitios y aplicaciones tienes abiertos midiendo la actividad del SSD desde el navegador, sin pedir permisos ni interacción del usuario. Es una técnica de side‑channel construida sobre el API Origin Private File System (OPFS) que, en pruebas, alcanzó altos porcentajes de identificación en un Mac de pruebas.
Cómo funciona el ataque FROST
Los autores, del grupo de seguridad de la Universidad de Graz, construyen en la máquina de la víctima un archivo OPFS muy grande y leen bloques aleatorios de 4 KB desde JavaScript. Si el archivo supera la memoria RAM disponible, esas lecturas caen directamente al SSD y su latencia refleja la contención que generan otras operaciones de disco.
Cuando el sistema realiza I/O por otras aplicaciones o por la navegación en segundo plano, esas operaciones generan picos medibles en la latencia de lectura del atacante. Esos patrones temporales son la firma que utilizan para reconocer sitios y programas.
En el trabajo describen un pipeline de análisis que convierte las mediciones de latencia en imágenes temporales y las clasifica con una red neuronal convolucional. En su experimento con un M2 Mac mini (8 GB RAM, SSD 256 GB) la técnica identificó sitios visitados con aproximadamente 89% de precisión y aplicaciones en ejecución con cerca de 96% de precisión.
Un aspecto relevante es que la contención ocurre a nivel del almacenamiento físico, por eso el ataque funciona entre navegadores: ejecutar la página maliciosa en Chrome mientras la víctima navegaba en Safari dio una diferencia de rendimiento de solo 3,38% frente a un ataque dentro del mismo navegador.
Limitaciones, alcance y mitigaciones
El método no es universal. Requiere que el archivo OPFS del atacante resida en el mismo SSD físico donde ocurren las operaciones que se quieren espiar; en equipos con varias unidades o almacenamiento en red esto puede fallar. Además, el fichero debe ser mayor que la memoria RAM del sistema, lo que implica ocupar decenas o cientos de gigabytes: en una unidad de 256 GB los navegadores que probaron permiten reclamar hasta el 60% del disco vía OPFS, es decir, más de 150 GB.
Ese requisito práctico es a la vez la mayor barrera de la técnica y la más obvia para detectar el ataque: la desaparición repentina de decenas de gigas en disco suele notarse. Aun así, los investigadores demostraron la viabilidad del concepto y propusieron medidas razonables.
Entre las soluciones que plantean están limitar el tamaño máximo de los archivos OPFS para que no excedan la memoria del sistema (evitando que las lecturas caigan al SSD) y pedir permiso explícito al usuario antes de permitir a un sitio crear archivos OPFS tan grandes. Otra alternativa es introducir ruido o latencias aleatorias en las respuestas del API para romper las firmas temporales.
Los autores divulgaron sus hallazgos a Google, Apple y Mozilla. La respuesta fue desigual: Google ha dicho que el fingerprinting no lo considera un fallo de seguridad por sí mismo; Apple lo ha clasificado como «fuera de alcance actualmente»; y Mozilla ha reconocido el informe sin aplicar correcciones inmediatas.
En pruebas adicionales los investigadores confirmaron que desde un navegador en Linux pueden medir latencias del SSD, aunque no completaron la fase de clasificación de huellas en ese sistema. Windows no fue probado en el estudio publicado.
En la práctica, esto significa que el riesgo real depende del navegador, de la configuración de almacenamiento del equipo y del comportamiento del usuario. Un equipo con mucho disco libre y varias unidades físicas reduce la probabilidad de éxito del atacante; por el contrario, laptops con una única SSD y poca RAM son el escenario ideal para FROST.
No es un detalle menor: las APIs diseñadas para facilitar experiencias web offline y almacenamiento local, como OPFS, abren vectores nuevos cuando se combinan con las características físicas del hardware.
Para usuarios que quieran minimizar la exposición, las medidas inmediatas son prácticas: controlar el uso de espacio en disco, limitar los permisos de sitios desconocidos y mantener navegadores actualizados. A nivel técnico, los fabricantes de navegadores tendrían opciones razonables —cotar el uso de OPFS, pedir consentimiento para grandes reservas de espacio o introducir mitigaciones a nivel de scheduler de I/O—, pero la implementación dependerá de si consideran el fingerprinting como un riesgo que justifique cambios con coste de usabilidad.
Lo que los fabricantes no aclaran todavía es si acaban introduciendo límites automáticos al tamaño de OPFS o un sistema de consentimiento explícito. Dado que Google no contempla el fingerprinting como vulnerabilidad, es poco probable que veamos soluciones rápidas que alteren el comportamiento por defecto de los navegadores más populares.
El trabajo de Graz demuestra que las fronteras entre software de navegador y recursos hardware siguen siendo una fuente rica de fugas de privacidad. Aunque FROST tiene condiciones que limitan su despliegue masivo, sirve como recordatorio: las optimizaciones y APIs orientadas a rendimiento o conveniencia pueden generar vectores de fuga inesperados.
