h a l f b a k e r yGetting blown into traffic is never fun.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
There are practical and legal reasons why you might not wish to have a certain piece of data in your possession. For example, someone might accidentally email you their entire address book, or they might accidentally put their nudie pics in your shared dropbox, or you might accidentally download classified
military documents because a government civil servant mistitled them on a government server and all you wanted was the bin collection schedule not the minutes of the CIA meetings where the Putin assasination plan was laid out in detail.
Now you can just press delete but the trouble is that most systems don't actually delete everything. They move them to the rubbish bin or whatever its called. Meanwhile the automatic overnight backups on both your own machine and also on the remote server creates spiralling uncontrollable and unknowable copies of the documents.
This auto duplication is perfect when you are finishing writing up your PhD thesis and then burglars come and steal all your gear and trash your house the day before you are due to make the final edits and submit. But its less good when you want to delete this unwanted and probably illegal information.
I know the preferred way to delete unwanted data is with a hammer, but that is a disk-level protocol rather than the file-level that I am thinking of here.
Proposed is a special function or button that recursively tracks through every instance of the data and over-writes it on the disk with random noise multiple times. This protocol would be generic and universal, so it would also run on your email server, on Dropbox and other remote data storage servers, on your backup disks, etc.
In time the protocol could be expended to keep track of screenshots, printout, optical media etc.
[link]
|
|
Programs which securely delete files exist - my antivirus software has that as a function.
What it doesn't do is trawl the entire filesystem for copies. |
|
|
To be honest, I'd be a bit nervous about that, because it might delete other things by mistake. To a first approximation you could go by
filename and/or exact size matches, which would allow a quick screen and pick up deliberate full copies. But also potentially similar things
you don't want to delete. More likely than you might think, if files are small and innocuously named.
So before you deleted the original file, you'd need to generate a hash to compare other copies to. Which would essentially eliminate
accidental false-positives. |
|
|
But if you're worried about copies of the data in your data storage, you possibly also want to worry about partial and slightly changed
copies. To check for those, you might want to do a BLAST-style search[1] of the full storage. If a partial match were found in an 'empty' part
of the filesystem, it would presumably be reasonable to just securely overwrite it. However, I think it's obvious that the only straightforward
way to deal with a partially matching file would need a human in the loop to make the decision about whether to securely delete it. |
|
|
[1] BLAST is an algorithm which quickly identifies sequences of information similar to a reference. It originated in bioinformatics, but has
also been adapted for use in other contexts. |
|
|
What if you don't over-write the file at a "1s & 0s on disk"
level, but change the contents of the file itself? So the OS
keeps the same file location etc, but the data contained in
that file is modified.
Eg: if the file you want to delete is a jpg, the image itself is
changed to another image (noise, kitten, whatever). Then
"delete/move to trash". |
|
|
//What if you don't over-write the file at a "1s & 0s on disk"
level, but change the contents of the file itself? So the OS
keeps the same file location etc, but the data contained in
that file is modified.// |
|
|
Then what you've got is my 419 delete idea, which I think
might be useful for some purposes. |
|
|
I thought that antivirus software offered to encrypt some files. The only way you'll be beaten is if someone else then encrypts your encrypted file and demands a ransom. |
|
|
Good idea, but two things:
1. The delete function would be legal within each account
or
piece of hardware you actually have rights over... if, after
hot data enters your sphere, you send it to a friend and
Deadly Delete reaches into their system to clean up, that's
an
issue.
2. Unless Deadly Delete constantly and proactively checks
the
validity of the target data's address, it will have to track all
changes to the system's directory structure, or rely on
another
resource that does so. Addendum, Third thing: If a copy
exists as part of the state of a system (e.g. virtual machine
file) you have to load the entire state just to access it for
deletion. That could be a pain |
|
|
In the past, I've deleted things in a self-harm type way. I
realise I'm in a minority, but I can imagine people who know
this exists royally screwing up their lives in an episode of
self-hatred. Not that it isn't a good function, I just don't
know if people can be adequately protected from
themselves. I also wonder what might happen with
divorces and separations when partners know or can guess
each others' passwords. |
|
| |