[GLLUG] "Data-poisoning" & "Data Safety" -- Wisdom, please!

Alistair Mann al at pectw.net
Wed Jun 1 22:30:49 UTC 2016

If gllug knows these two concepts already, what name does gllug know 
them by?

Much exercised by repeated dataloss and ransomware callouts, I’m 
developing a linux-based FUSE filesystem from which filesystem objects 
(file, directory, metadata etc) behave as normal to remote users, but 
behind the scenes once written to disk cannot be changed without proof 
of physical presence. As data “which cannot be changed” fundamentally 
changes how filesystems should be viewed (never mind the data protection 
implications) I’m also writing a paper around the subject. I include in 
it two concepts whose names I thought were widely recognised, but 
apparently not – I’ve had blank looks from other digerati I’ve run them 
by. What I describe is recognised, just not the names.

Concept 1: “Data-poisoning”
This occurs when an object is modified other than a user would intend. 
Examples include accidentally or maliciously:
- saving an empty document over an original copy
- deleting a tree of folders
- drag and dropping to a nearby directory
- password protection on an archive from a user long since left.
- find . -exec touch {} \;
Is there an existing noun/verb for this kind of damage?

Concept 2: “Data safety”
For the purposes of the DPA, the “safety of data” can be said to be a 
duty of the data controller. If they discharge their responsibilities 
properly, they could be said to have practiced good “Data safety”. This 
isn’t to target ICO approval; not opening a dodgy link is good “Data 
safety”, as is spot checks of what users store in ~/Desktop instead of 
on the server, practicing a full restore from backups and so forth. 
“Safe hex” might be a parallel concept, but I want more a focus on “What 
practices and technology is needed to keep this data safe?” Backups seem 
clearly to be “of” Data safety, but nothing like the whole story.
Does this kind of approach to data have an existing name?

It may help to say the paper will posit that “the safety of data 
committed to a filesystem should now be viewed as a responsibility of 
that filesystem”. That is, with awareness of “Data Safety”, the 
filesystem could by design inhibit “Data-poisoning”.

Thanks for any insight, pointers!
Alistair Mann

More information about the GLLUG mailing list