FROST: A Browser‑Based SSD Timing Attack That Reveals Sites and Apps

FROST browser attack concept image

A malicious page can learn which websites you open and which desktop apps you launch by measuring your SSD’s timing—using only JavaScript. The technique, called FROST, runs inside the browser sandbox. No extensions. No native code. No permission prompt.

You load the page, leave the tab open, and its code quietly measures drive contention in the background.

The work comes from researchers at Graz University of Technology. Their paper, slated for DIMVA 2026, is available here. The underlying timing channel holds on macOS and Linux.

SSD timing attacks aren’t new. The same group’s earlier Secret Spilling Drive showed you could infer user behavior by watching read slowdowns—but it needed native access (e.g., Linux io_uring). FROST removes that requirement and turns a local attack into a remote one. The team also previously showed SnailLoad, which inferred pages and videos from network latency alone.

How FROST works

It starts with the Origin Private File System (OPFS), a storage feature browsers adopted in 2023 so web apps (like editors and IDEs) can keep files on disk. Each origin gets its own sandboxed area. Because it’s isolated, the browser skips the usual permission prompt. A page can simply write.

Normally, the OS page cache hides disk timing by serving repeated reads from memory. FROST sidesteps that by creating a file larger than RAM so reads keep touching the SSD. On Chrome and Safari, OPFS can grow to about 60% of disk space—plenty. Firefox sets a lower per-origin cap, but an attacker can split activity across multiple origins.

Diagram illustrating FROST’s OPFS read-timing loop

The page then repeatedly reads random 4 kB chunks of that file and times each read with performance.now(). Browsers reduce timer resolution by default, but the site can restore precision by enabling cross-origin isolation on its own page.

When you visit another site or start an app on the same drive, that activity competes with the attacker’s reads. The timing shifts in recognizable ways. A neural network trained on those traces classifies the target site or app.

What the researchers measured

  • Websites (macOS): Against the top 50 sites, FROST reached an F1 score of 88.95% (closed world). In an open-world test that added 300 unseen sites, it held at 86.95%.
  • Native apps (macOS): For ten pre-installed apps, accuracy reached 95.83%.
  • Covert channel: Using the same signal, a cooperating native app sent data to the malicious page through OPFS at 661.63 bit/s on Linux and 719.27 bit/s on macOS. A native-only channel was faster, but this is substantial for code confined to a browser sandbox.

The timing channel also works on Linux, but the full classifier was trained and evaluated only on macOS, so those accuracy numbers are macOS results. FROST observes activity only on the same physical disk as its OPFS file.

On a single-drive laptop, that generally means “almost everything.” On multi-drive workstations, activity on a separate drive is less visible, though app startups that touch the home directory can still leak.

What you can do today

For now, not much. The teams behind Chrome, Safari, and Firefox were notified before publication:

  • Google’s Chromium project does not classify fingerprinting as a security vulnerability.
  • Apple marked it out of scope, while leaving room for future mitigations.
  • Mozilla acknowledged the issue but has shipped no fix.

There is no CVE, and there’s no public evidence of in-the-wild use.

Practical steps, while we wait:

  • Close the tab. Measurement stops when the attacker’s page isn’t open.
  • Watch for unexplained multi‑gigabyte browser storage. OPFS usage isn’t easy to inspect, but a sudden growth can be a clue.
  • Linux note: systems using profile-sync-daemon, which keeps the browser profile in RAM, are incidentally protected from the zero‑click variant because OPFS writes avoid the SSD. A weaker variant, where a site gets you to pick a large file via a file dialog, still works.

What would actually fix it (browser-side)

  • Cap OPFS so the file fits in memory, removing SSD contention.
  • Throttle high‑resolution timers while OPFS is active.
  • Add a permission prompt for OPFS.

Each choice trades off speed or usability. That’s part of why none is deployed yet.

Why this matters

The disagreement is basic: is a website quietly learning what you do on your own machine a bug—or a feature working as designed? The researchers point to a structural issue: as browsers grant web apps near‑native access to hardware, near‑native data leakage follows. FROST is one API; the pattern is what to watch.

Reference: View article