“undisclosed reasons”

There comes a point where I simply won’t believe in magic. Whether it’s 3 writes or 7 writes, at some point there is not enough contextual information left on rigid magnetic media to recover any amount of useable information.

They might be referring to SSDs which would also be bad to do overwrites on since you are essentially killing the life of the drive. Better off just outright filling up a whole drive.

yes I know, even the Gutmann wipe is no longer effective and SSDs are essentially unwipeable, but that's not what this is about. It's about the software not wiping (or not even deleting) data at all when you'd expect it to do so. Generally, you'd expect software to do what it tells you.

The best way to wipe an SSD is to have full disk encryption and then wipe the key off the ssd. Even if you do manage to recover the key which is a big if, you still need the key in your brain. Combined with writing random data over the ssd you will be lucky to pull anything out of it.

Or fill it with some AAA Steam games shouldnt take long to fill the whole thing.

I found random source to be slow, so, I made Perl script (in the 90s) - basically writing the same random blob over and over. Two passes with different blobs seemed to do the trick

http://edoceo.com/creo/drive-shred

This is also something I've done, just fill a text file, copy it over and over, eventually look for the old files, it's gone, good enough. It sucks laptops dont come with FDE by default.

I'm not sure why you'd want to do that, considering that it's inefficient (it requires internet access, and it's capped by its speed), and you're rolling the dice on whether it's wiped or not. eg. if you have 100GB of free space to wipe, and the closest you can get to 100GB with your steam games is 95GB, then there's a 5% chance that your data would still be on the disk. Doing something like

   cat /dev/urandom > /path/to/mount/point/temp.bin && fysnc && rm /path/to/mount/point/temp.bin

is much more reliable and isn't dependent on your internet.

Why would any of these suggestions be better than the following?

    dd if=/dev/urandom of=/dev/sdX bs=1M

Simply filling the disk by any means runs the risk of your incriminating (or whatever) information being retained in a sector that got remapped out from under you that you can no longer write to.

Wiping the encryption key takes care of that problem, as well as being much faster.

Thank you, this is what I was trying to avoid doing by simply filling an SSD with random data. As you mention, I suppose FDE is better, but now you have to ask yourself whether OS level or hardware level is best. In this case if you override an encrypted partition with a fresh OS installation it wont matter as much since most of what will be left will be gibberish.

Sometimes I do just that, I'll install Linux encrypted, and then reinstall later without migrating any bytes. My main concern is work related / personal finance documents being left over on a laptop. I've tested plenty of forensic utilities on my system after erasing files.

Asking because I don't know: does that also hold true for SSDs if the sectors are overwritten (either with new data, or due to wear levelling)?

Correct. None of the publicly/commercially available software can do that, so don't worry most people won't pay for it.

secure erase is the only way to clear all sectors on an SSD but at that point you're just relying on the manufacturer's implementation (and past experience from encryption has ruled that to be a derp).

an easy alternative is just to encrypt the drive using software-based encryption and just delete the key. Windows 10 has now stopped relying on hardware-based ssd encryption because it was found some of it was just garbage.

Edit: Additional caveats: some drives can move data in and out of the non-system viewable area and dead cells cannot be written if they're no longer viable so data can still remain there.

Thanks: helpful to know.