In case 2, you should assume that you have no legal right to get the data deleted (YMMV depending on country), it is unlikely to be deleted, and even if it is truly deleted, it may be on backups for X years or forever. So the best option by far is avoiding having the data collected in the first place.
In case 1, you can delete the data but watch out for backups.
In the extreme (depending on your personal threat model), physical destruction of the drive is the only option e.g. high temperature incineration - but that may not be a good option if you live in an apartment.
If you are erasing the drive then shred is your friend. You have the option of multiple randomize passes and an optional final zero pass. For SSDs you more or less have to do multiple passes because of wear leveling - and even then there is no absolute guarantee that all blocks have been overwritten.
In many situations it is a good idea to use full disk encryption / full partition encryption. In that case, it may be sufficient to erase the on-disk encryption info only e.g. much faster - but this remains problematic for SSDs.
An alternative (cheaper and faster) approach is to use a key file on a different medium (in addition to or instead of a passphrase) and then you can physically destroy or shred the key file. I believe that LUKS also gives you the option of storing the security header on another medium, which would lend itself to a similar approach.
If this feature doesn’t already exist in PureOS, Purism should add it. There should be a right-click on a file or directory and then select “Delete” (standard feature). But there should also be a “Secure Delete” selection available there also. The “Secure Delete” selection would cause multiple checkerboard erase/write patterns to write and over-write to the location where the file or directory was. This would make the deleted item ir-retrievable.
On spinning rust maybe. The most you can do is ask the drive firmware to “pretty please, really erase this”. Writing over doesn’t actually work (and the firmware likely has a wear-leveling table, so the logical sector doesn’t actually map to a fixed physical sector). Not even filling up the whole disk works for a multi-pass erase, as something blank (or mostly blank) might have gotten onto the sensitive-data-containing block. Nor is it a guarantee if you erase the whole content of the drive and fill it several times, as the physical storage of the drives is over-provisioned, and it’s possible the sensitive block has been cycled out either into “spare” or “end-of-life” status, and won’t get overwritten. If it got marked EOL, even repeatedly rewriting the disk until the disk fails won’t erase it.
Bottom line is, short of physical destruction of the disk (or, I suppose, hooking your own flasher directly to the flash chips), the only way to guarantee the data is not on a disk is to never write the data to the disk.
There is a “persistent RAM” device from the early 2000s which has possibilities… It uses the “standby” power from the PSU to not erase itself, and is populated by DDR2 ram sticks. To the computer it presents as a PCIe block device.
For some classes of data, it might be worthwhile, just hope your UPS doesn’t fail.
Depends what that means. In some contexts “ram disk” means creating a virtual disk device out of a portion of the RAM of the system. That is actually an improvement for temporary files that will fit on the RAM disk. You don’t have to erase from the disk that which was never written to the disk.
Otherwise, there’s no way I would trust my persistent data to RAM on an ongoing basis. Your UPS will fail. If nothing else, the battery condition will eventually be inadequate and I have my doubts that you can replace the battery while keeping the UPS on mains power. (Maybe a more expensive UPS would support this.) Something else will go wrong.
I’m sticking with: key file on low capacity, cheap USB flash drive - and when you want to erase the SSD, just physically destroy the USB flash drive.
Unfortunately that doesn’t deal with erasing individual files. For that, perhaps you would need to regularly change the key and re-encrypt all the blocks that are in use in the file system. That won’t do much for SSD lifetime - and you will be going through those cheap USB flash drives at a faster rate.
If you have CPU cycles to burn, enabling zram gets you about 3x space efficiency. You can even use a backing device with it, which still mostly retains the transience of the data (trying to reconstruct fragments of compressed files is non-trivial).
That said, a persistent ramdisk is actually not terrible. There’s a reason the DDR2 based device exists, speed wise, it outperformed spinning rust by 3 orders of magnitude. If you need data to persist across reboots, yet be erased by unplugging the machine, it’s still a good choice. The key is that the power draw in standby is quite minimal, so short duration UPS failures while in standby (like for changing UPS batteries) aren’t an issue (and decent quality dual-battery UPSs exist). Obviously, if the data is important, backups are necessary, but that’s the case regardless because “computers barely work”.
Yes. I was more (in my mind) contrasting, in respect of UPSs, what we have at work - and what it costs - versus what I have at home and what that costs.
An alternative approach is a computer that has dual power supplies and inputs.
That’s actually a good idea, dual PSU server chassis are pretty common, for exactly that sort of thing. They’re much cheaper than dual battery UPSs.
On a slightly more practical note, there is a mini computer available which, rather than keeping the whole “disk” in memory, keeps its encryption keys in memory (with an internal button battery providing stability across reboots). It’s a sealed box, complete with chassis intrusion and other “tamper” sensors, and will dump the keys if it thinks it’s compromised. Has some advantages as a “turnkey” solution when data security is more important than data integrity.
ORWL is the name of the computer. Doesn’t look like you can easily lay hands on them anymore, but you can still find parts. (FWIW, Linus Tech Tips did an exposé on them about 2 years ago).
As for the battery exhaustion, move your data off and replace the battery, then move it back. (Given that the battery is inside, there is no replacing the battery without tripping the intrusion detection.
