FROST Attack Shows Browser‑Based SSD Timing Can Reveal Your Open Apps and Sites

Featured image

Announcement

Security researchers at Graz University of Technology have published a paper describing FROST (Fingerprinting Remotely using OPFS‑based SSD Timing), a side‑channel attack that works entirely inside a standard browser sandbox. By creating a large file in the Origin Private File System (OPFS) and timing reads from JavaScript, the attack can identify other open websites with roughly 89 % accuracy and running desktop applications with about 96 % accuracy on a test Mac. No permissions, no downloads, and no user interaction are required.

Technical specs

How OPFS enables the attack

• OPFS is a relatively new browser API that lets a site store files on the local disk without prompting the user. Both Chrome and Safari allow a site to allocate up to 60 % of the total storage capacity.
• On a 256 GB SSD this translates to more than 150 GB of file space. The researchers fill this space with a single file larger than the system’s RAM (8 GB in their test configuration) so that every 4 KB read forces the SSD to service the request rather than hitting the OS page cache.

Measuring latency

• The malicious script performs a tight loop of random 4 KB reads and records the time taken for each operation using performance.now().
• When the victim’s OS or another application accesses the same SSD, the SSD’s internal queue experiences contention, producing measurable latency spikes.
• These spikes form a timing trace that is fed into a convolutional neural network (CNN) trained on labeled traces for a set of popular websites and common desktop apps.

Cross‑browser behavior

• Because the contention occurs at the storage controller level, the attack works regardless of which browser the victim uses for the background activity. In the authors’ experiments, running the attacker page in Chrome while the victim browsed in Safari produced only a 3.38 % difference in classification throughput compared to a same‑browser scenario.

Platform coverage

Platform	SSD timing observable	Full classification tested
macOS (M2 Mac Mini, 8 GB RAM, 256 GB SSD)	✅	✅
Linux (various distros)	✅	❌
Windows	–	–

The attack relies on the OPFS file residing on the same physical SSD as the victim’s activity. Multi‑drive workstations that separate system and data disks would reduce the observable signal.

Performance numbers

Metric	Value
Website identification accuracy	≈ 89 %
Application identification accuracy	≈ 96 %
Required file size	> RAM (≥ 8 GB in test)
Bandwidth overhead for the attacker	~ 150 GB of writes/read cycles during profiling

Market and supply‑chain implications

1. Browser vendors face a trade‑off between storage convenience and privacy. OPFS was introduced to give web apps offline capabilities without prompting for permissions, a feature that many progressive‑web‑app developers rely on. Capping OPFS allocations to a fraction of system memory (e.g., 1 GB) would blunt the attack but could break legitimate use cases such as large‑scale video editing or scientific data caching in the browser.
2. SSD manufacturers may see increased scrutiny of internal queue management. The attack exploits the fact that SSD controllers expose variable latency under contention. Vendors could mitigate by smoothing latency spikes (e.g., through larger internal buffers or more aggressive wear‑leveling), but such changes could affect performance benchmarks that drive marketing claims.
3. Enterprise security policies may need to adjust. Organizations that lock down browsers with extensions or CSP headers will now have to consider OPFS as a potential exfiltration vector. Policies that previously focused on native code execution (e.g., sandbox escapes) must be broadened to include high‑volume storage APIs.
4. Supply‑chain risk assessments gain a new dimension. If a malicious actor can embed the FROST script in a popular advertising network, the attack could be launched at scale without any software install. This pushes the threat model from “malware on the endpoint” to “malicious web content served from trusted domains.”

Mitigations and outlook

• Permission gating – Requiring explicit user consent before allocating more than a few megabytes in OPFS would raise the barrier dramatically. The consent dialog could be similar to the one used for camera or microphone access.
• File‑size caps – Browsers could enforce a hard limit tied to available RAM (e.g., min(availableRAM, 1 GB)). This would keep the attack’s file below the threshold needed to force SSD reads.
• Noise injection – Introducing random delays into performance.now() or adding dummy reads could obscure the timing signal, though this would also degrade legitimate performance‑critical web apps.
• Hardware‑level defenses – Future SSDs might expose a constant‑latency interface for read‑only operations, but such changes would require coordination across the storage industry and could impact drive pricing.

Google has stated that fingerprinting is not a security vulnerability, Apple labeled the issue “currently out of scope,” and Mozilla has acknowledged the findings without committing to immediate changes. Given these positions, short‑term browser updates are unlikely, placing the onus on developers and security teams to adopt defensive coding practices and monitor OPFS usage.

---

The original research paper can be accessed through the authors’ university repository, and the full dataset of timing traces is available on GitHub.