FROST: Your Browser Betrays You — A JavaScript SSD Timing Side-Channel Attack

Last week, a paper named FROST (Fingerprinting Remotely using OPFS-based SSD Timing) was published, and the implications are unsettling: a web page can figure out which other websites you visit — and even which applications you have open — by running JavaScript in your browser. No extension to install, no click required, just visit a tab. It works on Linux and macOS.

The team behind it — researchers from Graz University of Technology (TU Graz) and Liebherr Transportation Systems GmbH — presented the work at DIMVA 2026. Hannes Weissteiner is the lead author, and the senior author is Daniel Gruss, who is also on the teams that discovered Meltdown and various Rowhammer attacks. That pedigree alone should make you pay attention.

This post walks through how the attack works, why classic tracker-blockers don't catch it, and what a Linux user can actually do about it.

What Does the Attack Do?

FROST takes a previously known phenomenon — that microsecond-level variations in SSD access latency can leak information about a system — and ports it into the browser sandbox. Earlier work in this area required native code execution on the victim's machine. FROST runs entirely in JavaScript, inside the browser.

The mechanism in four steps:

1. OPFS (Origin Private File System): Modern browsers (Chrome, Firefox, Edge) let JavaScript create and read files scoped to a specific origin. FROST uses this API to issue disk reads and writes — fully from the browser sandbox, with zero user interaction.
2. Bypassing the page cache: The biggest hurdle in prior work was that the operating system keeps file pages in RAM, masking SSD-level latency. The FROST team devised a way to evict and bypass the page cache, so measurements reflect real SSD contention.
3. SSD contention: When other applications or sites hit the disk at the same time, the SSD's response time shifts at the microsecond scale. FROST measures those shifts.
4. Pattern matching: A trained model maps the timing signal to visited websites (88.95% F1) or opened applications (95.83% F1).

A second result is even more striking: as a covert channel (a side channel for exfiltrating data from a native app to a malicious site), FROST achieves 661.63 bit/s on Linux and 891.77 bit/s on macOS. So a website can quietly pump data out of an app you have running.

Why Doesn't "Tracker Blocker" Catch This?

Most users assume they're fine: I use a tracker blocker, I clear cookies, I sometimes even use private windows. FROST breaks all three assumptions:

• It doesn't touch cookies. No third-party requests, no localStorage reads.
• It doesn't need fingerprinting APIs. No navigator.userAgent, no canvas fingerprinting, no font enumeration.
• It abuses one of the most basic JavaScript capabilities: disk I/O via the OPFS API. Disabling that breaks significant chunks of modern web applications.
• It doesn't require user interaction. Visit a tab and the attack is in flight — no permission dialog, no click.

Net effect: Tor, VPN, tracker blockers, and even private windows do not protect against FROST. The signal lives below the layer those tools operate on.

A Step Back: What Even Is a Side Channel?

A side-channel attack extracts secrets from a system by observing something the system was not designed to expose — power draw, sound, timing, electromagnetic emissions, cache misses, and so on. Famous examples:

• Timing — A crypto routine that runs 1 ns slower on a correct password guess.
• Power — TEMPEST attacks that read a CRT monitor from across the room.
• Acoustic — Listening to a printer to reconstruct the page.
• DRAM — Rowhammer flipping bits in adjacent rows.

FROST adds SSD timing to the list. SSDs have multiple parallel NAND channels; concurrent reads/writes create contention that produces measurable latency variation. That variation tells you what else is currently using the disk.

Why Does This Hit Linux Users Too?

The paper says the attack works better on macOS — Apple's I/O scheduler and page cache behavior is more amenable to the technique. But Linux is in scope too, particularly if you:

• Run an NVMe SSD (the modern default for most machines)
• Keep many tabs open while working (more I/O contention in the background)
• Use a recent browser version with OPFS support (Firefox 111+, all current Chrome/Edge)

The Linux kernel does include mitigations (IO schedulers, blk-mq, multi-queue dispatch) but none of them neutralise FROST outright. The attack's core assumption — JavaScript can issue timed I/O — is still true.

What Can You Actually Do?

Honest answer: the options for an individual user are limited, because the attack abuses a foundational web API. But layered defense is still possible.

1. Disable JavaScript Entirely (Radical)

NoScript on Firefox, or a global JS-block in the browser, is the strongest defense. The cost: most of the modern web stops working. Banking portals, web-based office apps, e-commerce — all broken.

2. Disable OPFS Specifically (Sweet Spot)

Firefox lets you turn OPFS off through about:config:

about:config → dom.fs.enabled → false
about:config → dom.fs.workers.enabled → false

This kills the exact API FROST depends on. The web still works — most sites don't use OPFS yet.

Chrome has no equivalent UI toggle, but enterprise policies like OPFSBlockedForOrigins can lock it down. As an individual, you'd need to use a policy-flagged Chrome build.

3. Tighten Site Isolation

Firefox's privacy.resistFingerprinting = true rounds some timing values, which degrades the FROST signal without disabling it. It's a partial mitigation, not a fix.

4. Keep Your Browser Updated

FROST went public at the end of May 2026. Expect browser vendors to add OPFS timing noise or per-origin rate limits in their 2026 summer releases. Firefox nightly already has active discussion. Track the ESR and stable channels.

5. Disk Encryption Doesn't Help

LUKS or FileVault protect the content of your disk. They don't change timing. So "I have full-disk encryption" is not a defense here.

The Open-Source and Linux Position

FROST is also a reminder that the attack surface is the stack, not just the code. The Linux kernel can be flawless, but if the browser leaks timing across an API, the kernel's security guarantees don't extend to your web activity.

The good news: this was disclosed through a peer-reviewed venue, not weaponized in the wild first. Browser vendors, W3C, and IETF are now discussing what OPFS should look like in 2027.

The bad news: there's credible suspicion that state-sponsored and ad-tech actors already use similar side channels. FROST is the part we can see. The part we cannot see is likely more advanced.

Conclusion

FROST is a wake-up call for anyone who thought "the web can't track me" was still a defensible position. Every capability we got — local file APIs, async I/O, parallel workers — is also a new side channel.

What you should do today:

1. Disable OPFS in your browser. Two about:config entries, five minutes.
2. Keep a JS-blocker handy. NoScript or uBlock Origin with a small whitelist.
3. Stay on the latest browser version. The 2026 summer updates will be the first line of defense.

Side channels are the invisible front of security. You won't catch them by reading source — you catch them by measuring time. Once you do, there's no un-knowing.

Tags: security, privacy, cybersecurity, side-channel, fingerprinting, ssd, opfs, browser-security, linux, firefox Date: 2026-06-06 Sources: FROST paper (Weissteiner et al., DIMVA 2026), The Hacker News Weekly Recap