A Website Should Not Be Able to Watch Your SSD
FROST is a browser side channel that uses OPFS storage timing and SSD contention to infer what else is happening on your machine. It is not a catastrophe. It is a warning about how much power we keep handing to ordinary web pages.
There is a particular kind of privacy bug that sounds fake until you remember what the modern browser has become.
A website can run code. It can store files. It can measure timing. It can keep a worker busy in the background. It can act less like a document and more like a small operating system with a nice URL bar attached.
So when researchers show that a website can infer activity on your SSD, the surprising part is not that the browser leaks a signal. The surprising part is how unsurprising that has become.
The technique is called FROST, short for Fingerprinting Remotely using OPFS-based SSD Timing. Help Net Security covered it this week, and the research paper is blunt about the mechanism: JavaScript in a normal web page can use the browser's Origin Private File System, or OPFS, to create timing patterns. Those patterns shift when other programs compete for access to the same solid-state drive.
That is the leak. Not your files. Not your passwords. Not a browser sandbox escape. A timing signal.
But privacy has always died by timing signals.
What FROST actually does
FROST is a side-channel attack. Instead of breaking into a protected area directly, it watches an indirect signal and learns something from the noise.
In this case, the signal is SSD contention. If the browser is writing and measuring operations through OPFS while another website or local application is also using the same drive, the timing changes. Those changes can be used to infer activity elsewhere on the machine.
The researchers describe two important shifts.
First, older SSD side-channel work usually needed code running on the device. FROST moves the measurement into the browser. A user only has to visit a page that runs the attack code. No extension. No installer. No admin privileges. No dramatic malware scene with a skull icon.
Second, the attack uses a legitimate web platform feature. OPFS exists because web apps now need local storage that behaves more like a filesystem. That makes sense for browser-based editors, office suites, IDEs, design tools, and all the other applications we decided should run inside tabs.
The privacy cost is that every new capability gives the browser one more physical thing to touch.
This is not a panic story
It would be easy to oversell FROST. That would be a mistake.
The technique has limits. Long measurements need a large OPFS file, which can consume enough storage that a careful user might notice. The target activity generally has to compete on the same SSD. It does not read files directly. It does not bypass the browser sandbox. It does not magically tell a website everything you are doing.
Good. Those limits matter.
But the uncomfortable part remains: a website can learn from storage behavior that most people do not even know the browser can observe indirectly.
This is where the privacy conversation often goes wrong. We wait for the catastrophic version before caring. If an attack does not dump the disk, steal the session, or compromise the kernel, it gets filed away as "just fingerprinting" or "out of scope."
That attitude is how tracking infrastructure gets normalized.
Fingerprinting is rarely one perfect signal. It is usually a pile of mediocre signals: screen size, fonts, GPU quirks, timing jitter, media devices, language settings, battery behavior, canvas output, and now maybe storage contention. Each piece looks defensible in isolation. Together, they become a way to recognize people who tried not to be recognized.
The browser is now a privacy boundary, not just an app
The old mental model of the browser was simple: it fetched pages and showed them to you.
That model is dead.
The browser now runs work tools, password managers, video editors, local databases, AI chat surfaces, IDEs, crypto wallets, admin consoles, and half the software stack of a normal office. It talks to cameras, microphones, Bluetooth devices, USB devices, clipboards, notification systems, GPUs, and local storage.
That does not mean the web platform is bad. It means the browser has become one of the most important privacy boundaries on the device.
FROST matters because it shows how even a sandboxed feature can create a cross-context observation point. The page is not supposed to know what else is happening on your machine. But if it can create enough I/O pressure and measure the response carefully enough, it can learn something anyway.
That should bother browser vendors more than it apparently does.
According to Help Net Security, the researchers disclosed the findings to Google, Mozilla, and Apple. Chromium reportedly did not consider fingerprinting attacks to be security vulnerabilities. Apple considered the attack out of scope, while leaving the door open to future mitigations. Mozilla acknowledged the findings but had not implemented mitigations at publication time.
I understand the triage problem. Browser teams cannot treat every fingerprinting primitive like a remote code execution bug. But "not a security vulnerability" is not the same as "not a user harm."
For ordinary people, the difference is academic. If a website can use browser APIs to identify or monitor them after they tried to avoid tracking, that is a privacy failure.
What would help
The paper and Help Net Security coverage point to a few mitigations: limit OPFS storage, reduce timing precision, and warn users when sites store unusually large amounts of data.
Those are reasonable starts. I would add a more basic rule: powerful local browser features should be treated as privacy-sensitive even when they are sandboxed correctly.
A sandbox answers one question: can the page directly access what it should not access?
Privacy asks another: can the page infer something it should not know?
Those are different questions. Browser permission systems are still much better at the first than the second.
Users do not have many good knobs here. Clearing site data helps after the fact. Blocking untrusted scripts helps when it is practical, which is not often enough. Privacy-focused browsers and anti-fingerprinting modes can reduce some timing and storage surfaces, but they also break enough sites that many people eventually turn them off.
So the real burden sits with browser vendors and web standards groups. If a feature lets any random site create large local files and run tight timing measurements, the privacy review should not stop at "the files are origin-scoped." Origin scoping prevents one class of theft. It does not prevent every class of observation.
The web keeps getting more physical
The browser used to feel abstract. Pages, links, text, images.
Now the web reaches into the physical machine constantly. It asks the GPU to render, the disk to store, the microphone to listen, the camera to see, the clipboard to move secrets around, and the notification system to interrupt your day. AI tools are only accelerating this, because the browser is becoming the place where reading, deciding, and acting all collapse into one interface.
FROST is a small story in that bigger shift. A clever side channel. A research result. Not a reason to throw your laptop into the sea.
But it is a good reminder that "just visiting a website" is no longer a small act.
A website should not be able to watch your SSD well enough to learn what else your computer is doing. If the web platform keeps giving pages more local power, then privacy engineering has to move closer to the hardware too.
Otherwise every new browser capability becomes one more sensor we forgot to call a sensor.
Sources: Help Net Security — Websites can spy on user activity by analyzing SSD behavior, FROST research paper