Security researchers at Graz University of Technology have unveiled a new browser-based side-channel attack they call FROST. The technique abuses the Origin Private File System (OPFS) in Chromium-based browsers, combined with precise JavaScript timing, to infer what other websites or applications a user has open. The attack requires no special privileges, just a visit to a malicious webpage.

FROST stands for “File Resource Observing Side-channel via Timing,” and it represents a fresh spin on an old problem: how software one component believes is isolated can still leak information through shared hardware. In this case, the hardware is the user’s SSD, and the leaky resource is the browser’s own internal storage system.

The Nuts and Bolts of the Attack

The Origin Private File System is a relatively new browser feature that gives web apps a sandboxed, origin-scoped area on the user’s disk for reading and writing files. It’s like a virtual hard drive just for that website – no user interaction required, and the data is kept private from other origins. Developers like it because it simplifies building complex offline-enabled apps, but now it appears the implementation comes with unforeseen privacy risks.

Here’s how FROST works:

  • A victim opens a legitimate website (say, an online banking portal) that uses OPFS to cache data or store temporary files.
  • While that tab is open, the victim opens another tab with an attacker-controlled page.
  • The attacker’s site runs JavaScript that performs repeated, carefully timed writes or reads to its own OPFS storage.
  • Because all OPFS traffic flows through the same underlying disk (typically an SSD), the attacker’s operations will occasionally slow down or speed up based on the disk’s real-time activity. That activity is influenced by what the other tabs are doing.

By analyzing these timing fluctuations – sometimes over hundreds or thousands of iterations – the attacker can create a “fingerprint” of the disk activity pattern. Different websites generate unique patterns. A banking site might write to its OPFS every 30 seconds to update user settings, while a social media site might read avatar images on a different schedule. These patterns become identifiable signatures that the attacker can match to a pre-built library of known website behaviors.

The researchers demonstrated that they could detect with high accuracy whether a target site was open in another tab, simply by watching these timing side channels. The attack does not require reading data from the other origin; it only observes timing, making it a classic covert channel.

Why SSDs Matter

Modern solid-state drives are the key enabler for this attack. SSDs use sophisticated internal parallelism and queuing to service I/O requests from multiple processes. The FROST technique exploits the fact that the OS and the SSD controller must arbitrate access to the physical NAND flash. When multiple tabs compete for disk operations, some requests get queued, and others finish faster. JavaScript, through the OPFS API, can measure these delays with fine granularity using high-resolution timers available in the browser (like performance.now()).

This is not a flaw unique to Chromium; it’s a consequence of how shared hardware resources are managed. But the browser’s decision to provide a synchronous-looking file system API to untrusted scripts makes the timing signal unusually loud.

Which Browsers and Platforms Are Affected?

Any browser that implements the Origin Private File System is potentially vulnerable. As of now, that’s limited to Chromium-based browsers:

  • Google Chrome (version 86 and later introduced OPFS)
  • Microsoft Edge
  • Brave
  • Opera
  • Vivaldi
  • Other Chromium forks

Firefox and Safari do not currently support OPFS, so they are immune to this particular attack vector. The demo was conducted on Windows 11 with an NVMe SSD, but the underlying principle applies broadly to macOS and Linux systems with SSDs, provided the browser implements OPFS.

It is worth pointing out that the researchers responsibly disclosed their findings to browser vendors before going public. While no specific CVE has been assigned yet, the disclosure is expected to spark discussions about whether the OPFS specification needs tighter security controls.

Real-World Implications: Not Just a Lab Curiosity

At first glance, inferring that someone has a particular website open might seem like a minor privacy leak. But in practice, the data can be extremely sensitive:

  • Fingerprinting: Websites could use this technique to build a more robust browser fingerprint by checking which of a list of “interesting” sites are open.
  • Targeted attacks: If an attacker knows you’re logged into your cryptocurrency exchange, they might tailor a phishing page to look like that exchange’s UI.
  • Cross-site tracking: Advertising networks could embed such probes to see if you’re visiting competitor sites, even in private browsing mode (since OPFS is available in Incognito, albeit with a separate storage partition).
  • Even inferring non-browser apps: In some configurations, heavy disk I/O from non-browser applications could also influence OPFS timing, meaning the side channel might leak information about whether you’re running a video editor, a game, or a disk backup tool – all from a simple web page.

The researchers emphasize that the attack requires a stable timing baseline, which means the victim needs to have the target tab open for a while. But in the age of always-open web apps like Gmail, Slack, and Office Online, that’s the norm rather than the exception.

The Technical Details

Under the hood, FROST leverages FileSystemFileHandle.createWritable() and FileSystemWriteableFileHandle.write() to perform burst writes or reads of controlled sizes. The attacker’s script times these operations with nanosecond precision using performance.now() or even the SharedArrayBuffer-based timer (where available).

A typical probing sequence might look like this:

const fileHandle = await opfsRoot.getFileHandle('probe.bin', { create: true });
const writable = await fileHandle.createWritable();
let times = [];
for (let i = 0; i < 1000; i++) {
  const start = performance.now();
  await writable.write(new Uint8Array(4096));
  const end = performance.now();
  times.push(end - start);
  await new Promise(r => setTimeout(r, 0)); // yield to other tabs
}
await writable.close();

The collected times array is then analyzed on the fly or sent to a remote server for pattern matching. The researchers used machine learning classifiers to distinguish between different target sites, achieving over 90% accuracy in some scenarios.

Mitigations: What Can Be Done?

Eliminating the timing side channel entirely is difficult because it stems from fundamental properties of shared hardware. However, the researchers propose several mitigations at both the browser and OS level:

  • Rate limiting or batching OPFS operations to reduce the granularity of timing information available to JavaScript.
  • Introducing artificial jitter into OPFS completion times so that the signal becomes too noisy to exploit.
  • Partitioning OPFS I/O per origin at the OS level, so that one origin’s disk operations don’t affect another’s timing as severely. This would require tighter integration with the OS I/O scheduler.
  • Disabling high-resolution timers when OPFS is in use, though this could break legitimate applications.
  • Warn users when a site is using OPFS extensively, similar to how some browsers now warn about excessive CPU or memory usage.

For now, browser vendors have not announced any immediate patches. Given the complexity, a coordinated update across Chromium, Windows, and even SSD firmware might be needed. In the past, side-channel attacks like Spectre led to sweeping changes; FROST may similarly force a rethink of how file system APIs are exposed to the web.

What Users Can Do Today

While a complete fix is pending, concerned users can take some practical steps:

  • Use Firefox or Safari if your threat model includes sophisticated tracking – neither browser supports OPFS, so the attack is impossible there.
  • Limit the number of open tabs from different contexts when visiting untrusted sites.
  • Employ browser profiles to isolate sensitive sessions (e.g., a separate Chrome profile for banking) – while OPFS is still used, cross-profile storage is isolated, so the timing leak won’t cross profile boundaries.
  • Keep your browser updated – once mitigations are rolled out, they will arrive via regular updates.

The vast majority of users will never be targeted by FROST in the wild, as it requires a motivated adversary who has developed the signatures for specific sites they want to detect. However, the research is a stark reminder that privacy boundaries in browsers are only as strong as the weakest hardware abstraction.

Looking Ahead

The FROST disclosure is likely to accelerate conversations about the wisdom of giving web apps direct access to high-performance storage APIs without corresponding privacy guardrails. The Web Hypertext Application Technology Working Group (WHATWG) and the W3C may need to revisit the File System Access specification with renewed attention to side-channel resistance.

Moreover, as browsers continue to evolve into full-fledged operating environments, the number of shared resources – GPU, network, disk – will only grow, along with the potential for novel side channels. FROST is a timely warning that the web platform’s security model must keep pace with the hardware it runs on.

For now, the researchers have provided both a proof of concept and a detailed technical paper, urging the community to treat this not as a bug to be squashed quickly, but as a design challenge that requires cross-industry collaboration.