FROST uses browser OPFS and SSD timing to fingerprint sites/apps

Researchers at Graz University of Technology presented FROST in a paper due at DIMVA 2026. The proof-of-concept runs in a web page’s JavaScript sandbox and infers which websites or native apps a user opens by observing SSD read timing, without requiring extensions, native code or permission prompts.

The attack uses the Origin Private File System (OPFS), a browser API added in 2023 that lets web pages store files on disk. FROST creates an OPFS file larger than the machine’s RAM so that repeated reads cannot be served entirely from memory. The page repeatedly reads random 4 KB chunks and measures each read with performance.now(). By enabling cross-origin isolation on the attacker-controlled page, the code restores high-resolution timing and records small delays when other software accesses the same SSD.

Timing traces are processed by a neural network trained to match patterns to specific websites or applications. On macOS, the paper reports an F1 score of 88.95% in a closed-world test of the top 50 sites and 86.95% in an open-world test that added 300 unseen sites. For ten preinstalled macOS apps the classifier reached 95.83% accuracy. The researchers also implemented a covert channel that transfers data from a cooperating native app to the malicious page via OPFS at about 661.63 bit/s on Linux and 719.27 bit/s on macOS.

FROST differs from earlier SSD timing work by running entirely in the browser. A prior project from the same group required native access to low-level interfaces such as io_uring. Another earlier technique from the group used only network latency to infer visited sites. FROST removes the need for native code by relying on the OPFS API.

The attack depends on storage quotas and hardware layout. Chrome and Safari permit OPFS storage to grow to around 60% of disk space, enabling multi-gigabyte files; Firefox applies a smaller per-origin cap, though attackers can spread data across origins. FROST detects activity only on the same physical drive as its OPFS file. Systems with multiple drives can isolate activity on a separate disk, but many applications access user directories and may still cause measurable contention.

On Linux, systems that keep the browser profile in RAM using tools such as profile-sync-daemon are not affected by the zero-click variant because OPFS writes do not reach the SSD. The paper notes that closing the attacker’s tab stops measurements. Detecting an unexplained multi-gigabyte OPFS file is another potential indicator, but browsers do not present OPFS usage in an obvious way to users.

The researchers notified browser vendors before publication. Chromium maintainers do not classify fingerprinting as a security vulnerability. Apple marked the issue out of scope while leaving open the possibility of mitigation. Mozilla acknowledged the finding and has not shipped a fix. The paper indicates there is no CVE and no public evidence of in-the-wild exploitation.

The paper lists possible mitigations including capping OPFS sizes so files fit in RAM, throttling high-resolution timers while OPFS is in use, or prompting users before allowing large OPFS allocation. Each approach would affect performance or user experience. The authors observe that APIs granting web apps broader disk access can create new timing and side-channel leakage and present FROST as an example tied to the OPFS feature introduced in 2023.