Your SSD is leaking what you're doing

A new side channel, explained without drama

Researchers have demonstrated that a website can infer what else you are doing on your computer by watching how your solid-state drive responds to small, timed requests. The browser does not need permission to read your files. It only needs to ask the disk to do tiny amounts of work and measure how long the disk takes to answer. The variation in those response times leaks information about whatever else the SSD is busy with - including activity from other tabs, other applications, and in some cases, the operating system itself.

This is a side-channel attack. It does not break encryption, it does not exploit a memory bug, and it does not require malware. It exploits the fact that an SSD is a shared resource with measurable behavior, and that JavaScript in a browser tab can poke that resource and time the responses.

How the trick actually works

SSDs are not simple. Underneath the file system you see, the drive runs its own firmware that manages wear leveling, garbage collection, write caching, and a translation layer that maps logical addresses to physical flash cells. When the drive is idle, small reads come back fast. When the drive is busy - flushing a cache, garbage-collecting freed pages, writing a large file in the background - those same small reads come back slower. The difference is measurable in microseconds, sometimes milliseconds.

A tab running JavaScript can trigger disk activity in several ways without ever asking the user. It can write to IndexedDB. It can fill the Cache API with throwaway entries. It can request large blobs from a service worker. After each write, it measures how long the next operation takes. Those timing patterns form a fingerprint of what the disk was doing at that moment.

From that fingerprint a determined site can infer:

• Whether the user is downloading or uploading a large file in another tab.
• Whether a background process - a backup, a sync client, a virus scan - is running.
• Roughly when the user opened or closed a memory-heavy application that triggered a swap.
• In some published variants, which of a small set of known applications the user is launching, because each application has a recognizable disk-access signature on startup.

None of this requires elevated privileges. The browser is doing exactly what the web platform allows.

Why this is different from cookies and fingerprinting

Most privacy threats people understand involve identifiers the browser hands out: cookies, local storage, canvas fingerprints, the user-agent string. Those can be cleared, blocked, or randomized. Browser vendors have spent a decade hardening them.

SSD-timing inference is a different category. It does not identify you. It identifies what your machine is doing right now. That is a behavioral signal, not an identity signal, and it is harder to mitigate because the underlying capability - letting a webpage write data and measure how long the write took - is fundamental to how modern web applications work. A photo editor in the browser needs to write fast. A document editor needs reliable storage timing. You cannot simply remove the API.

The closest historical comparison is the cache-timing work that led browsers to reduce the resolution of performance.now() from nanoseconds to microseconds after Spectre. That mitigation traded a small amount of developer convenience for a large reduction in attack surface. SSD-timing inference will likely require something similar: deliberately fuzzing the timing of storage operations so the signal-to-noise ratio collapses.

What an attacker can realistically learn

The published proof-of-concept work is not yet at the level of “a website reads your other tabs.” It is closer to “a website can tell whether your machine is under load, and can sometimes distinguish between a small set of activities the attacker has trained against.”

That sounds limited. It is not.

Consider an advertiser that wants to know whether you are actively downloading a large file from a competitor’s service. Or a hostile site that wants to know whether your antivirus is currently scanning - a useful signal if it is preparing a follow-on attack. Or a nation-state operator who wants to confirm that a target is running a specific application before delivering a payload. Each of these is a low-resolution signal that becomes useful when combined with everything else the site already knows: your IP, your screen size, your timezone, the fonts on your system, the order in which you hit the page.

Side channels are not usually the whole attack. They are one more input to a correlation engine.

The hardware variation problem

One thing that limits the practical reach of this attack is that SSDs vary. A consumer Samsung NVMe drive behaves differently from an enterprise Intel drive, which behaves differently from the soldered storage in a MacBook. Garbage collection timing, write amplification, and cache flush behavior are firmware-specific. An attacker training a classifier against one drive model will not get the same accuracy against another.

That helps users with unusual hardware. It does not help the eighty percent of laptops sold in the last five years that use one of maybe a dozen common controllers. If you can build a model that recognizes the timing fingerprint of a Samsung 980 Pro, you have covered a meaningful slice of the consumer market without per-user training.

The attack also degrades on machines under heavy load - when many processes are hitting the disk, the signal from any one of them is buried. Ironically, a busy machine is a better-protected machine here, at least until the attacker invests in more sophisticated signal separation.

What browser vendors will probably do

The pattern from prior side-channel disclosures suggests a sequence:

1. Reduce timer precision for storage APIs. Round IndexedDB and Cache API timings to a coarser granularity so microsecond differences disappear into noise.
2. Add jitter. Deliberately delay the completion callback of storage writes by a random small interval. Developers will complain. The complaints will be ignored.
3. Throttle background tabs harder. A tab that is not in the foreground should not be allowed to run tight loops of disk writes.
4. Eventually, a permission prompt. For sites that perform sustained storage activity beyond a threshold, the browser will ask the user. Most users will click allow without reading. A few will not, and that few matters.

None of these are available today as a configurable user setting. They will arrive in browser updates over the next six to eighteen months, in the same quiet way that Spectre mitigations arrived.

What you can actually do now

The honest answer is: not much that is proportionate to the threat. This is a low-bandwidth side channel, and changing your daily behavior to defeat it would cost more than the leak is worth for most people. But if you are in a category where it matters - a journalist, a researcher handling sensitive material, anyone whose threat model includes targeted profiling - there are concrete steps.

• Run sensitive work in a separate browser profile or a separate browser entirely. Storage APIs are partitioned per origin, but the underlying disk is not. Using Firefox for one set of activities and Chrome for another does not help. Using a virtual machine for sensitive work does, because the VM mediates disk access.
• Use the Tor Browser for activities where behavioral inference is a real concern. Tor Browser already reduces timer precision and disables several storage features specifically to defeat side channels.
• Close tabs you are not using. Every open tab is a potential observer. This is a cheap habit with broad benefits beyond this specific attack.
• Keep your browser current. When the mitigations land, they will land in updates. A browser that is six months out of date will be six months behind on this and several other side channels.
• Do not rely on incognito mode for this. Private browsing prevents history and cookies from persisting. It does not prevent a page from measuring disk behavior while you are using it.

The pattern this fits into

Every few years a new class of side channel emerges from a part of the system that nobody thought of as a sensor. CPU caches became sensors with Spectre. GPUs became sensors with the work on pixel-stealing through compositor timing. Power consumption became a sensor on phones. Now storage becomes one.

The pattern is consistent. A shared resource with measurable behavior, accessible to untrusted code, eventually becomes a covert channel. The mitigation is always the same shape: reduce precision, add noise, restrict access. The cost is always paid by legitimate developers who lose a small amount of performance or convenience. The benefit accrues to everyone who never knew they were being observed.

If you take one operational thing from this: the surface area of what a webpage can learn about your machine is larger than the surface area of what it can read. Treat the browser as a process that sits next to everything else you do on your computer, not a sealed box. It has never been a sealed box. The walls just keep getting thinner in places people did not expect.