On 2014/10/14 13:48, Ross Altman wrote:
Hi Martin,

Thank you, I'll definitely look into that. It's unfortunate that there
isn't a simpler way to do this... oh well.

Let me bud in here since I encounter this question a lot in other matters. There typically are three reasons one would like to protect the data in a file from end-users' meddling:
  - You need to protect idiot users against themselves,
  - You need the data to remain clean and untarnished to make some other system 
depending on it function correctly, or
  - The data itself is important for legal reasons or you have some kind of 
liability towards data accuracy.

If it is the first case, then you are stuffed and Richard's byte-change is the 
closest to a solution you can come.

If the second case, then make the other system check the file, add table with encrypted values that has meaning only to the other system, or even use file encryption for the entire database - this is common and can be had commercially from http://www.hwaci.com/sw/sqlite/see.html

For the latter I suggest recording the file hash (sha512+) whenever you update it and store that in a data list marking release dates. That way if someone claims that they have data gotten from you that says x while you claim it says y... then simply whip out the hash list and compare to their file, any changes will be evident immediately.

You probably need to then also keep a register history of DBs that correspond to those hashes, else you cannot prove the data from that file to correspond to any specific hash. Also it is safer to upload such hashes to a blog or something that is not under your control, where any edits will be marked and timestamped, then it is impossible for yourself to meddle with the files after release and a public record exists of the file version hashes. Pretty solid in legal terms.

Whichever way, good luck!

sqlite-users mailing list

Reply via email to