A gigabyte-plus browser storage file may be enough for a website to infer what else is happening on your machine — not by reading your files, but by timing how your SSD responds.
That is the privacy risk behind FROST, short for “fingerprinting remotely using OPFS-based SSD timing,” a research technique covered by Ars Technica. The attack runs in the browser with JavaScript and uses timing differences in storage operations to infer activity in other tabs, other browsers, and open apps.
Why should web users care that JavaScript can read clues from SSD activity?
The unsettling part is not that a site can open your documents. FROST does not mean a webpage can directly read local files, steal passwords from disk, or list filenames.
The concern is subtler: a site may be able to watch the “shadow” cast by other activity on the same storage device. If another app or tab is using the SSD, storage operations triggered by the attacker’s page can slow down in measurable ways. Those tiny delays become signals.
That puts FROST in the category of a side-channel attack. Side channels do not break into the protected data directly. They exploit indirect effects: timing, contention, cache behavior, electromagnetic leakage, or other physical traces of computation.
Ars reports that FROST can monitor other sites a visitor is viewing and what apps are open on the device, based on the researchers’ paper. The visitor does not need to click anything beyond opening the malicious site.
“Web browsers have evolved from simple document viewers into complex platforms capable of running sophisticated applications,” the paper authors wrote.
That shift matters. Browsers now support office suites, editors, development tools, offline storage, and other app-like workloads. Each new capability can create a new privacy boundary to test.
What is an SSD activity side channel in a web browser?
An SSD activity side channel is an indirect leak caused by multiple processes competing for the same storage hardware.
The browser sandbox is supposed to stop websites from accessing local files or peeking into other sites’ private storage. FROST does not bypass that rule in the obvious way. Instead, it measures performance changes in storage operations that the attacking site is allowed to perform.
Here is the difference:
| Tracking method | What it observes | How FROST differs |
|---|---|---|
| Cookies / local state | Prior visits, sessions, identifiers | FROST watches timing effects from shared storage use |
| Browser fingerprinting | Device and browser attributes | FROST looks at live hardware contention |
| History sniffing | Signals tied to visited pages | FROST can infer activity from SSD timing patterns |
| FROST | Latency changes in browser storage reads | It can reflect activity outside the attacking page |
The key resource is OPFS, or Origin Private File System. OPFS is browser-managed storage reserved for a specific site. It is sandboxed, meaning one website’s OPFS area is isolated from other websites and from the device’s broader file system.
FROST shows that isolation is not the whole story. Even if data is separated logically, the underlying SSD is still a shared physical resource.
How can simple JavaScript measure SSD behavior without file permissions?
FROST uses JavaScript to interact with OPFS and repeatedly measure storage read timing.
According to the researchers, the attacker creates a large OPFS file and performs random reads from it. When the SSD is also serving other activity — for example, another browser tab or an app — the attacking page can see latency changes in its own reads.
The researchers describe the mechanism this way:
“The attacker continuously measures SSD contention by performing random reads from a large OPFS file. SSD contention caused by user activity causes measurable latency differences for these read operations. By training a convolutional neural network (CNN) on these traces, the attacker can fingerprint user activity on the host system by classifying new traces using the trained model.”
That last step matters. The timing trace is not a clean dashboard saying “Photoshop is open” or “this exact website is in another tab.” It is noisy data. The researchers use a convolutional neural network, a deep-learning model commonly used to classify patterns in structured signals such as images, audio, and text, to classify those traces.
FROST is also narrower than a general browser storage warning. Modern browsers expose several storage and timing surfaces, but Ars reports this attack specifically uses OPFS. The significance is that OPFS gives web apps powerful local storage without asking the user for a file-system permission prompt.
There are constraints. The OPFS file must be extremely large — Ars says likely a gigabyte or more. The OPFS file also needs to be stored on the same SSD as the activity being measured. That is usually true for tracking open websites because browser storage sits in the browser’s default location, but it may fail if apps are installed or operating from a different SSD.
What could a malicious website infer from SSD timing patterns?
The reported FROST results are more serious than “your computer is busy.”
The researchers were able to determine websites open in other tabs — even in other browsers — and apps open on the device. That pushes the risk beyond ordinary fingerprinting, because the signal can reflect device-wide behavior rather than only the browser tab running the script.
Analysis: the privacy issue is strongest when FROST-style timing data is combined with signals websites already collect, such as IP address, account login state, browser fingerprints, cookies, or ad-tech identifiers. The SSD signal alone may be noisy. Paired with other identifiers, it can become another feature in a profiling system.
Still, the attack does not appear unlimited. Based on Ars’ report:
- No file contents: FROST does not directly read documents.
- No exact filenames: The technique infers activity patterns, not directory listings.
- Same-drive dependency: Apps on another SSD may not be visible.
- Large storage footprint: A gigabyte-scale OPFS file is easier to notice than a tiny tracker.
- No known wild use: Ars says there are no indications FROST attacks have been performed in the wild.
The research team performed the full FROST attack on an M2 Mac. On Linux, they showed the underlying primitive — measuring SSD access latency traces from JavaScript — works, but did not run the full attack. They did not test Windows.
How would an SSD spying attack look in a real browsing session?
A realistic FROST session starts with one mundane action: the user opens a site hosting the attack.
From there, the page creates a large OPFS file and begins measuring read latency. If the visitor has other websites open, or opens apps while the page remains active, the SSD contention can create timing patterns. The attacker then classifies those traces using a trained model.
A cautious mini case study, grounded in the reported research, looks like this:
- Entry: A visitor opens a site running the FROST JavaScript.
- Setup: The page creates a large OPFS file, likely 1GB or more.
- Measurement: The script performs repeated random reads and records latency traces.
- Contention: Other tabs, browsers, or apps create SSD activity.
- Classification: A trained CNN compares the trace against known patterns.
The important limit: Ars does not report that FROST has been deployed through ad slots, third-party widgets, or mass tracking infrastructure. The research describes what a site hosting the attack can do, not a confirmed real-world campaign.
That distinction matters. FROST is a demonstrated browser side channel, not evidence of a current surveillance network.
How can browsers, websites, and users reduce SSD timing leaks?
For users, the simplest defense named in the Ars report is blunt: close tabs when they are no longer needed. A FROST page needs to remain open to keep measuring.
More technical users can watch for unusual OPFS behavior, especially large storage allocations by unfamiliar sites. A random site creating a gigabyte-scale browser storage file should raise eyebrows.
Browser makers have harder choices. The researchers proposed limiting the maximum size of OPFS files. That could reduce FROST’s signal, but it may also affect legitimate web apps that depend on large local storage for offline work, media editing, development environments, or other browser-based tools.
Other mitigations mentioned in the broader browser security debate often involve reducing timing precision or throttling suspicious repeated operations, but the source material specifically highlights OPFS size limits as one proposed path.
The forward-looking issue is clear: as browsers keep absorbing workloads once reserved for native apps, they inherit more hardware-level leakage risks. FROST is scheduled to be presented at the DIMVA conference in July. Until browser vendors respond, the practical watch item is whether OPFS limits or related storage-timing defenses start appearing in mainstream browsers — and whether they can block the leak without breaking the web apps that made OPFS useful in the first place.
Impact Analysis
- FROST shows that browser features like OPFS can create new privacy risks through indirect hardware timing signals.
- A malicious site may infer activity in other tabs, browsers, or apps without directly accessing local files.
- The research highlights how increasingly app-like browsers expand the attack surface for side-channel surveillance.
