Why would you make this assumption? It seems perfectly reasonable to me to assume, in the absence of evidence to the contrary, that a program actually does what it claims to do.

that seems a little naive. what about actual evidence of performing said wipe? a little progress bar showing the 35× overwrite technique maybe, verified by a failed recovery. do any browsers have these small, open source capabilities baked in? seems like nowadays the only way to ensure and audit personal privacy is by having network inspection and disk utilities constantly monitoring these "pro-privacy" apps

>that seems a little naive. what about actual evidence of performing said wipe? a little progress bar showing the 35× overwrite technique maybe, verified by a failed recovery

Implementing this is problematic because depending on the filesystem, it might not be possible to "wipe" a file by repeatedly writing over it. For instance, if it's a log structured filesystem. On the other hand, you might not even need to overwrite in some cases, eg. filesystems on SSDs with trim support. Also you don't need 35x overwrites. There's no evidence that even 1x overwrite can be recovered on contemporary hard drives.

Store browsing data in memory. That said, data being available to forensic level HD recovery is very different from data still being used to populate the most visited sites.

storing in memory would only provide browsing data for the current session, permanent storage of history is not possible without writing to disk

That would provide fairly strong evidence that it was actually being deleted.

if what you are referring to were possible

It's not really hard, you just want a system that let's you save your history through a reboot.

even if the browser's storage engine was part of a RAMdisk for each session, such an area would still have to reside in hard disk storage to survive a reboot

Needing to survive a reboot isn't necessary. This system would let you know that nothing is being saved. It's not perfect, but it does that thing very well.

it is necessary in relation to the original topic of browser history

>seems like nowadays the only way to ensure and audit personal privacy is by...

Storing the history in memory also solves this half of this problem, and surviving a reboot is not necessary to ensure and audit privacy.

edit I'll stop. I can understand the flaws in this setup, I don't understand why you think it isn't possible/wouldn't solve the problem.

you cannot store the history in memory and survive a reboot, unless you write the memory to disk, then read into memory from disk on boot, but even then the history is being stored on disk and so is recoverable. surviving a reboot is necessary since the point of storing history is to make it accessible later, otherwise you would use incog/private mode, or stronger. I don't know what it is you think I don't think is possible

>surviving a reboot is necessary since the point of storing history is to make it accessible later, otherwise you would use incog/private mode, or stronger.

What actual evidence do you have that incognito mode is wiping the history at session end?

I did not say that, I said it doesn't store history

It stores history though, go log into any site in incognito mode. It has the same problem your original post highlights, and is an example of a situation where your history not surviving a reboot would not be an issue.

of course it doesn't actively store history. it doesn't wipe the storage medium so may leave a trace, but that's different. if a browser says it is wiping then there should be proof of this, instead of the "just trust us" stance which the article rightly highlights as dangerous

Because it is a well known fact that it is trivially easy for a resourced attacker to retrieve data from a storage medium well after your computer claims it is deleted.

Not if it is securely wiped multiple times. At that point they'll go looking at your DNS provider and ISP, or local fusion center.

Right, but my browser isn't doing that. Therefore the original point still stands.

> Because it is a well known fact that it is trivially easy for a resourced attacker to retrieve data from a storage medium well after your computer claims it is deleted.

No it isn't. You said nothing about a browser. You said storage medium.

I sometimes do computer forensics for clients and you can be sure that you leave traces. You'd need to wipe out the area of the disk over and over again to fully remove it (sometimes it'll still remain despite that, for undisclosed reasons).

“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.