I don’t care how

grabs your phone, throws it on the ground and blasts it with a shotgun

There you go! =)

If every time an OS had to delete something it had to fill the space with zeros or garbage data multiple times just to make extra sure it’s gone, we’d all be trashing our flash chips very fast, and performance would be heavily degraded. There really isn’t a way around this.

The solution to keep private files private is to put them into an encrypted container of some sort where you control the keys.

But as a user, when I delete something, it should go away forever.

Years of working tech support in my past tells me that this is a lie. “OMG restore this!”

The OS should never let that happen. It always should abstract the partition into a filesystem.

That is what thermite is for.

I mean, to be completely fair, that’s how data storage works.

We cannot really just make data disappear, so we let it get overwritten instead

That’s how a lot of people handle deleted data in database, it’s literally just a flag. That’s why there’s a recommendation to edit Reddit posts before deleting them, to ensure they’re actually overwritten so they can’t just be restored.

You should check out the federated backup of Apple Cloud. You can reach it at lemmynsfw.com. I mean your friend.

I think that already happened and was called “The Fappening”. You can still find it with Google.

“I know it’s not your nude, but it’s a nude and that’s what you were looking for, right?”

There’s a post on reddit about some dude who gave his phone to a friend (wiped it, new iCloud, everything), and the undeleted photos are from when OP owned the phone.

This is dependent on the TRIM schedule. It could be size based (execute a TRIM when 50% of the blocks are used).

There’s most certainly residuals, I’ve accidentally deleted then installed Windows on top of a bunch of my game saves. I found some random file recovery application and let it run for awhile. Guess what? Nearly everything was readable despite the fact it got wiped and then had a whole windows install.

NAND also experiences minor permanent damage on writes. Actually clearing the NAND involves a write as the charge has to be forced out (a write of 0s)

Which means that data is gone, permanently) for that data, there’s no residuals to worry about like with spinny’s and is in fact necessary to ensure decent lifespans.

I doubt that the firmware is doing an overwrite of TRIMmed data. Rather, I expect it’s marking it as having been TRIMmed, and so can report that it’s zeroed to higher layers. If a higher layer queries the firmware for its content, sure, they might get zeroes returned. But if you can modify the firmware or otherwise bypass it, you may be able to get at the underlying media.

There is also the “bad block” issue, where storage media can take blocks – which may contain readable data – out of use, so that higher layers cannot access them. That applies to rotational drives and it looks like SSDs do the same thing. Again, might require bypassing or modifying the firmware to get direct access. But there can be data leaked there.

I also wouldn’t be terribly surprised if there is lingering information even after zeros are written to an SSD that might be recoverable if you could directly access the media, though I’m not familiar with the situation there. That is the case for rotational drives – the drive platter itself is “analog”, doesn’t just store a discrete string of ones and zeroes at the physical level. I once knew a cryptographer who was working on quantifying that leakage for rotational drives.

Now, attacking some of that is a pain and probably not a concern, but there are some cases where it might be a target. I once knew a professor who used to work at the Department of Defense, and he’d talk about their disposal process for rotational drives:

1. Drive has N random overwrites.

2. Drive gets passed through a rock-crusher device.

3. Remains get put in an acid bath.

I don’t know what they did if Step 1 couldn’t be completed due to drive failure. Maybe they were allowed to skip that step in that case.

That being said, probably most people don’t have to worry about the same level of resources being aimed at them.

EDIT: Step 1 might have been a degauss rather than an overwrite. Either way, it was definitely just aiming to twiddle bits, not physically destroy the drive. I’m trying to remember a conversation from a couple decades back…

deleted by creator

In your analogy, they never even put the photos in the trash can. They just put a postit on them saying “don’t show to user”. Then the updated software forgot about the postits (and started to post tits).

I’m a paper user and I burn all my letters using a large amount of heat.

I’m an android user and I shred my files using a app that uses an algorithm that overwritten that bytes of the file

I suspect that it doesn’t actually work. I mean, they can overwrite the logical positions in the file file if they want, but that doesn’t entail that it actually overwrites the underlying physical blocks, for a number of reasons, starting with some of the stuff at the drive level, but also because of higher-level issues. What filesystem does Android use?

googles

Looks like yaffs2, at least on this system.

https://stackoverflow.com/questions/2421826/what-is-androids-file-system

rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
none /dev/cpuctl cgroup rw,cpu 0 0
/dev/block/mtdblock0 /system yaffs2 ro 0 0
/dev/block/mtdblock1 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock2 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:0 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

https://en.wikipedia.org/wiki/YAFFS

YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives.[3] It is also designed to be portable and has been used on Linux, WinCE, pSOS, RTEMS, eCos, ThreadX, and various special-purpose OSes. A variant ‘YAFFS/Direct’ is used in situations where there is no OS, embedded OSes or bootloaders: it has the same core filesystem but simpler interfacing to both the higher and lower level code and the NAND flash hardware.

Yeah, note the “log-structured” bit there.

https://en.wikipedia.org/wiki/Log-structured_file_system

A log-structured filesystem is a file system in which data and metadata are written sequentially to a circular buffer, called a log.

So, what happens is that when you write, it’s going to the log, and then there’s a metadata update once the write is complete saying “I wrote to the log”. The app probably isn’t writing to the previous location of the data on the disk, because writing to byte offset 32,000 the second time in a file will go to a different logical location on the storage device than the first time you wrote it, causing the thing to not actually be overwritten.

googles

https://arxiv.org/pdf/1106.0917

Secure Deletion on Log-structured File Systems

We address the problem of secure data deletion on log-structured file systems. We focus on the YAFFS file system, widely used on Android smartphones. We show that these systems provide no temporal guarantees on data deletion and that deleted data still persists for nearly 44 hours with average phone use and indefinitely if the phone is not used after the deletion. Furthermore, we show that file overwriting and encryption, methods commonly used for secure deletion on block-structured file systems, do not ensure data deletion in log-structured file systems.

I’d also note that this is a lead-up to proposed solutions, but that’s only handling things down to the level that the OS sees, not what the flash device sees; they don’t mention things like wear leveling, so they probably aren’t taking that into consideration.

EDIT: Oh, they do mention it, but just to say that some of their approach might work (like, what they mean is that if it writes enough data in the background, it might eventually overwrite whatever, even if the OS has no control as to what’s being written):

Wei et al. [16] have considered secure deletion on flash storage in the context of solid state drives (SDDs). An SSD makes use of a Flash Translation Layer (FTL). This layer allows a regular block-based file system (such as FAT) to be used on flash memory by handling the nuances of erase blocks opaquely through the FTL’s layer of indirection. This layer has the same effect as a log-structured file system, where the FTL writes new entries at empty locations, so old entries remain until the entire erase block can be reclaimed. They executed traditional block-based approaches to secure deletion and determined that they do not properly sanitize data on flash storage. They also showed alarmingly that some built-in sanitization methods do not function correctly either. They propose to address this concern by having flash hardware manufacturers make use of zero overwriting, and add it into the FTL hardware. They state that circumventing the problem of a lack of secure deletion requires changes in the FTL, but depending on how the FTL is implemented, our userlevel approaches may also succeed similarly without requiring hardware changes.