"You no longer have to be on the machine to pull it off," the researchers wrote — a crisp way to describe a new remote fingerprinting technique that turns SSD timing into a disclosure channel from inside a web page.
How FROST turns browser storage into a timing spy
FROST is an attack, described in a paper from researchers at Graz University of Technology set to appear at DIMVA 2026, that uses only JavaScript in a webpage and the timing of reads from an SSD to infer what sites a user visits or which native apps they open. The entry point is the Origin Private File System (OPFS), a browser storage feature added in 2023 so web apps can keep files on disk without triggering a permission dialog. OPFS gives each origin a sandboxed slice of disk; because that slice is treated as local storage, a page can write large files without user consent.
The attack creates a file larger than the machine's RAM so the page cache cannot hold it and reads keep hitting the SSD. Malicious code reads random 4 kB chunks in a tight loop and times each read with performance.now(). Browsers blunt high-resolution timers by default, but FROST restores the needed resolution by switching on cross-origin isolation inside its own page. When the victim opens a site or starts an app on the same drive, that activity competes for SSD access and measurably shifts the read timings. A neural network trained on those timing traces matches the pattern back to a site or app.
Accuracy, covert channels, and measurable performance
The Graz team reports striking accuracy on macOS. In a closed-world test against the top 50 websites the classifier achieved an F1 score of 88.95%; in an open-world test that added 300 previously unseen sites it held at 86.95%. For ten native, pre‑installed macOS apps the F1 reached 95.83%.
Beyond fingerprinting, the researchers built a covert channel using the same signal that moved data from a cooperating native app into the malicious page through OPFS at 661.63 bit/s on Linux and 719.27 bit/s on macOS. The team notes a native attacker could often be faster, but those bitrates are high for code confined to a browser sandbox.
Platforms, scope and practical limits
The timing channel works on macOS and Linux; however, the fingerprinting numbers reported are macOS results — the paper ran its full classifier on macOS. FROST only reveals activity touching the same disk as its OPFS file. Single‑drive laptops therefore leak broadly; multi‑drive workstations hide activity on separate drives, although app startups that touch the home directory tend to leak anyway.
Browser differences matter: on Chrome and Safari an OPFS origin can grow to roughly 60% of disk space, easily exceeding RAM and forcing reads to the SSD. Firefox caps each origin at a lower size, but an attacker can spread storage across multiple origins to bypass that cap. The technique requires no native code, no browser extension, and no permission prompt; it runs inside the browser sandbox as a remote, zero‑click attack. A weaker variant — where a page convinces a user to select a large file through a file‑picker dialog — still works when writes do not happen silently.
Vendor responses and possible fixes
The Graz team notified Google, Mozilla, and Apple before publication. The Chromium team does not treat fingerprinting as a security vulnerability. Apple called the issue out of scope but left room for a mitigation later. Mozilla acknowledged the report and has shipped nothing. There is no CVE and no public evidence the technique has been used in the wild.
The practical fixes lie with browser vendors: cap OPFS size so files fit in memory and avoid contention, throttle high‑resolution timers during OPFS use, or require a permission prompt before allowing large OPFS allocations. Each mitigation carries costs in speed or usability, which the researchers say is part of why none has been adopted yet.
What this means for technologists, policymakers, and end users
- Technologists and security teams: Expect a need to reassess browser storage features in threat models. Mitigations such as limiting OPFS allocations or monitoring large, unexplained OPFS files are immediate defensive steps, though browsers do not make OPFS usage easy to observe.
- Policymakers and regulators: The incident frames a structural question about giving web apps near‑native access to hardware without additional controls; the researchers flag that pattern — not just this API — as the long‑term concern.
- End users and administrators: The measurement runs only while the attacker's page is open, so closing the tab ends the leak. Linux systems running profile‑sync‑daemon that keep the browser profile in RAM are incidentally protected against the zero‑click variant because OPFS writes never reach the SSD; the file‑picker variant still works.
The immediate takeaway is straightforward and unsettling: a webpage can now, in realistic conditions, watch for disk contention and report back what else the machine is doing without asking. The core debate is no longer about a single proof‑of‑concept but about whether sandboxed web APIs should be allowed gradual, near‑native reach into hardware — and what tradeoffs vendors are willing to accept between performance, usability, and privacy.
