A new privacy threat, named **FROST**, has emerged, demonstrating how malicious websites can infer a user's browsing habits and application usage. The attack, needing nothing more than JavaScript and the inherent timing characteristics of modern SSDs, represents a significant leap in browser-based fingerprinting capabilities.  This sophisticated technique, detailed in a paper destined for **DIMVA 2026**, exploits a common storage feature across major desktop browsers. It leverages an underlying timing channel that has been successfully demonstrated on both **macOS** and **Linux** systems. ### The Evolution of SSD Timing Attacks SSD timing attacks are not entirely new. The same **Graz University of Technology** research group previously published "**Secret Spilling Drive**" last year. That attack also observed user behavior by monitoring how drive reads were impacted by other system activity. However, "Secret Spilling Drive" necessitated native code execution via low-level interfaces like **Linux's io_uring**. **FROST** eliminates this requirement. By confining its operations within the browser's sandbox, it transforms a previously local attack into a remote one, meaning an attacker no longer needs physical access or prior code execution on the target machine. This isn't the first time the Graz lab has highlighted such vulnerabilities. Their earlier "**SnailLoad attack**" could infer visited websites and loaded videos purely from network latency, without any JavaScript at all. ### How FROST Operates At the heart of the **FROST** attack lies the **Origin Private File System** (**OPFS**), a storage feature introduced in browsers in 2023. **OPFS** allows web applications, such as in-browser editors, to store files on disk within their own sandboxed file system slice. Crucially, this sandboxing means it bypasses the typical permission prompts required for a web page to access user files. A site can initiate writing to **OPFS** without any user interaction. Normally, operating systems mask disk timing variations through the page cache, serving repeated reads from memory to avoid hitting the physical drive. **FROST** circumvents this by creating an **OPFS** file larger than the machine's available RAM. Since the entire file cannot be cached, subsequent reads consistently interact with the SSD. For instance, browsers like **Chrome** and **Safari** allow **OPFS** to consume up to 60% of disk space, more than enough for this purpose. While **Firefox** imposes lower caps per origin, an attacker can distribute the load across multiple origins to overcome this limitation.  The attacker's JavaScript continuously reads random 4KB chunks from this large file, timing each read using `performance.now()`. Although browsers typically reduce the precision of timers to thwart such measurements, the attacker can restore high resolution by enabling cross-origin isolation on their page. When a user opens a new website or launches an application on the same drive, this activity creates contention with the attacker's ongoing reads. This contention causes measurable shifts in the timing of the attacker's operations. A neural network, trained on these timing traces, can then accurately identify the specific website visited or application launched. ### Alarming Accuracy and Scope The accuracy achieved by **FROST** is particularly concerning. In tests on **macOS**, against the top 50 websites, **FROST** identified visited sites with an F1 score of 88.95% in a closed-world scenario. This score remained robust at 86.95% in an open-world test that included 300 previously unseen sites. For ten pre-installed **macOS** applications, the accuracy reached an impressive 95.83%. Beyond fingerprinting, the team also demonstrated a covert channel using the same signal, transferring data from a cooperating native app to the malicious web page at rates of 661.63 bit/s on **Linux** and 719.27 bit/s on **macOS** via **OPFS**. While native attacks can be faster, this represents a significant data leakage rate for code confined within a browser sandbox. It's important to note that while the timing channel works on **Linux**, the full classifier was only tested on **macOS**. Furthermore, **FROST** only detects activity on the same disk where its **OPFS** file resides. For single-drive laptops, this encompasses all activity. Multi-drive workstations might offer some protection for apps running on separate drives, though common application startups that touch the home directory often still leak data. ### Limited Defenses and Browser Indifference Currently, user-side defenses against **FROST** are limited. **Google**, **Mozilla**, and **Apple** were informed prior to publication. **Google's Chromium** team has stated they do not classify fingerprinting as a security vulnerability. **Apple** deemed it out of scope but indicated potential future mitigation. **Mozilla** acknowledged the issue but has not yet implemented any fixes. There is no **CVE** assigned, and no public evidence of **FROST** being exploited in the wild. For now, closing the malicious tab will terminate the attack. Users might also look for unusually large **OPFS** files in their browser's storage, though browsers do not make this information readily accessible. On **Linux**, systems using **profile-sync-daemon**, which keeps browser profiles in RAM, are incidentally protected against the zero-click variant, as **OPFS** writes never reach the SSD. However, a weaker variant requiring user interaction (e.g., selecting a large file via a file-picker dialog) would still be effective. Ultimately, effective mitigations lie with browser developers: capping **OPFS** size to ensure files fit in memory, throttling high-resolution timers when **OPFS** is active, or introducing a permission prompt for **OPFS** usage. Each of these solutions carries potential trade-offs in terms of performance or usability, which may explain the lack of immediate action. This research highlights a fundamental disagreement regarding whether a website's ability to covertly monitor user activity on their own machine constitutes a bug or a feature working as intended. The researchers' primary concern is the broader trend: as browsers grant web applications increasingly near-native access to hardware, the potential for near-native data leakage grows. **FROST** is just one example; the underlying pattern of expanding web API capabilities without commensurate privacy safeguards is the real issue at stake.