11–20 of 55 posts
This is the type of program that should be written in C, not in Javascript with 9 different dependencies...
Though, on second thought, this cloud service idea has some nice potential for evil :)
If I've understood correctly when I read about this before, programs that overwrite before unlinking do not work for an SSD. The SSD probably will not write the data to the same location as the old file. Instead, use fstrim to have the disk reclaim all free space. After that it's supposed to be impossible to recover. https://en.m.wikipedia.org/wiki/Trim_(computing)
That's not quite true. TRIM simply tells the SSD that the corresponding block is not in use anymore, it doesn't tell the SSD what to do with it.
The controller will usually unmap the physical block and schedule it for erasure but usually not erase it immediately unless it doesn't have any free block to remap. And it will return zeroes if the block is read.
The data is recoverable at that point (until the block is actually erased) and can remain so for a fairly long time[0] if the attacker can either bypass the SSD controller or can physically access the raw flash memory.
[0] depending on storage pressure and the exact make and recycling strategy of the SSD
This is the type of program that should be written in C, not in Javascript with 9 different dependencies...
This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed. Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs, and it's also not guaranteed to work on filesystems with copy-on-write semantics. If you're really concerned with this, you should be doing…
> This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed. That's only true for GNU-based userlands, not BSD-based ones. > Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs And if the system properly TRIMs it might not be necessary at all, though…
Sure, but installing (a subset of) GNU coreutils is probably going to pull in a lot fewer dependencies than this JavaScript command line tool. Plus, you can use ports, no need to mess with a seperate package manager (npm) and the associated package verification foibles.
> And if the system properly TRIMs it might not be necessary at all, though that greatly depends on the SSD.
The "depends on the SSD" is a big one. Various recent forensic papers have shown that it can take a while until a TRIM'd sector is actually erased by the firmware.
I still think that if this kind of thing causes worries, full-disk encryption is really the only sensible solution.
>Files are overwritten three times, first with the byte pattern 0xff, then 0x00, and then 0xff again, before they are deleted.
Plus the -P flag is available on both GNU and BSD versions of rm. Somehow I fail to see the user-friendliness factor.
Edit: formatting
This is the type of program that should be written in C, not in Javascript with 9 different dependencies...
Yes they are. As a user, I see a file, type rm file, then it is gone. The file has been removed.
Yes those parts of that file are possibly recoverable back into the original file, even without much work, but the file has been removed.
Earlier quoted context omitted.
> This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed. That's only true for GNU-based userlands, not BSD-based ones. > Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs And if the system properly TRIMs it might not be necessary at all, though…
> That's only true for GNU-based userlands, not BSD-based ones. Sure, but installing (a subset of) GNU coreutils is probably going to pull in a lot fewer dependencies than this JavaScript command line tool. Plus, you can use ports, no need to mess with a seperate package manager (npm) and the associated package verification foibles. > And if the system properly TRIMs it might not be necessary at all, though that grea…
No objection here. Though the original note is right, you just pointed to the wrong tool:
> I still think that if this kind of thing causes worries, full-disk encryption is really the only sensible solution.
And full agreement there.
Should have used /dev/random, and done it 7 times, then you could sell this to enterprise customers!