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.
Step away from hardware constraints for a moment, and consider the OS:
If the OS says a file is deleted, under no circumstances should the OS be able to recover it. Sure, certain tools may exist to pull it back; but it should be unavailable to the OS after that. And yet, apparently a software update was enough to recover these files. Thus, the concerns about data safety in an environment where the OS cannot be trusted to remove data when it says it has been removed.
I think this is just semantics at this point, but to me there is a difference between “deleted” and “erased”. I see deleted as the typical “moved to trash” or rm action, with erased being overwritten bits, or like microwaving a drive.
Edit - If i remember correctly deleting something in most OS’s/File Systems just deletes the pointer to that file on disk. The data just hangs out until new data is written to that sector. The solution, other than the one you mentioned about encrypting stored data and destroying the key when you want the data “deleted”, would be to only ever store data in volatile memory. That would make for a horrendous user experience though.
Well, the storage device should handle that then. And modern NVMEs do. Self-encrypted drives are used to hide deleted information from an attacker that desolders the storage chips.
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.
Step away from hardware constraints for a moment, and consider the OS:
If the OS says a file is deleted, under no circumstances should the OS be able to recover it. Sure, certain tools may exist to pull it back; but it should be unavailable to the OS after that. And yet, apparently a software update was enough to recover these files. Thus, the concerns about data safety in an environment where the OS cannot be trusted to remove data when it says it has been removed.
So let’s stop calling it “deleted” then, and call it what it is. “Forgetting”.
I’m not sure what you actually want the OS to do about it other than as I said, fill it with random data.
I think this is just semantics at this point, but to me there is a difference between “deleted” and “erased”. I see deleted as the typical “moved to trash” or
rm
action, with erased being overwritten bits, or like microwaving a drive.Edit - If i remember correctly deleting something in most OS’s/File Systems just deletes the pointer to that file on disk. The data just hangs out until new data is written to that sector. The solution, other than the one you mentioned about encrypting stored data and destroying the key when you want the data “deleted”, would be to only ever store data in volatile memory. That would make for a horrendous user experience though.
You can delete files by overwriting the data. On Linux its shred -zu [file]. Its slow but good to do if you are deleting sensitive data.
Its good its not the standard delete function.
Well, the storage device should handle that then. And modern NVMEs do. Self-encrypted drives are used to hide deleted information from an attacker that desolders the storage chips.
That would apply in my “encrypted container of some sort” solution, yes.
Deletion commands are unfortunately not very reliable on many SSDs