Against legal. The best approach is to calculate the MD5 of the file If the file chance, the MD5 change Aldo. Il 14/ott/2014 15:37 "RSmith" <rsm...@rsweb.co.za> ha scritto:
> > 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! > Ryan > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
