> The “Erase all content and settings” option in Settings obliterates all the keys in Effaceable Storage, rendering all user data on the device cryptographically inaccessible.

Semantics debate around whether leaving data practically inaccessible is the same as removing it, but considering where we are, I'd say it isn't.

Granted, this is from 2018, but I doubt the defaults and concept have changed.

Personally, that's not a risk that I would care about (especially in the context of an Echo Dot or even an iPhone), but deleting the keys will not be better than inaccessible forever.

* if I recall correctly iOS devices don’t use a traditional flash controller and Apple does that mapping themselves (it’s also largely why Apple devices have better flash performance than competitors)

This is incorrect. Secure deletion should cover the entire disk no matter how much data was used before, in order to deny an attacker any information or to guide their recovery efforts. I would absolutely expect a secure deletion process to take the exact same amount of time regardless of how much data is used.

A better tell is the difference between the same model of phone with different storage sizes. A 512GB iPhone should take 2x as long to securely wipe compared to a 256GB one, assuming they’re actually overwriting the encrypted data with random noise.

> iPhones don’t have erase speeds of 12gigabit/s

It’s worth pointing out that a true secure delete is actually a write not a delete. But it’s true that your typical iPhone could not possibly overwrite its entire disk in 10s or so, although last time I did a reset it took much longer than that.

That's a fair point. Still, mobile devices typically employ FDE to avoid the need for scribbling over the entire flash (also improves the lifetime of the flash in that way).

> It’s worth pointing out that a true secure delete is actually a write not a delete

Flash storage doesn't work that way unless you're referring to something else. To write a block you have to erase it first (makes the block all 1s or all 0s depending on the chip). An update of a block is technically then a read/erase/modify/write (although flash translation layers will elide the first 3 steps by writing to a free block & marking the old one as GC'able). Writing random patterns into flash to my knowledge generally isn't needed anyway as it was with magnetic storage. The only purpose of writing in a secure erase scenario is to try to overwhelm the flash translation layer to force every block to be touched.

> although last time I did a reset it took much longer than that.

I haven't profiled it, but any slowness erasing an iOS device is probably because the flash storage backing the secure element is optimized for reads rather than writes. Additionally, it may be erasing various metadata/caches in the OS storage that aren't covered by the encryption key.