Never accepted the agreement, it constantly asks me to but works without it

Having said that, I am sure it still steals my photos because it’s close sourced

You don’t? Really?

“I don’t understand why people have sex and then complain when they can’t get an abortion because of Roe v Wade being appealed.”

This is what you sound like. Blame the system, not the individual for having a better sex life than you.

That is what thermite is for.

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.

I don’t care how

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

There you go! =)

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

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!”

Did you think some else’s nudes might have resurfaced there…?

I think mixing tech and nudity is awesome! I love getting dickpics!

I love mixing technology with nudity. But I have also avoided this problem because I don’t mix technology and Apple.

You don’t mix technology and YOUR nudity 😉

There are tons of reasons to take nude photos… you often have to send in nude photos for the beginning stages of surgery consultations.

And sexting is fun.

This comment comes across insanely judgemental of the individual, when the issue is that Apple deleting data and thus violating privacy.

That’s a feature, not a bug

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

The former would be hilarious, it would mean that iOS explicitly classified those images as nudes.

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.

Not true, it specifically states in the article that, for example, one user had over 300 photos reappear, “some of which were revealing”. This is obviously not great but it isn’t likely as scandalous as it’s being made out to be.

Oh, it’s up!