This is a pretty good nit-pick, Toby. ;-) But I think I can nit-pick your nit-pick:
We distinguish between integrity -- accidents or unauthorized people can't change the contents of your files -- and reliability -- accidents or unauthorized people can't delete your files. We also distinguish both of those from availability -- accidents or unauthorized people can't make your files unreachable to you even for a limited time. Therefore it is fair to say that someone who owns all of the storage servers can't violate your file integrity even though he can erase your file (or make it unavailable to you). Also there is the vexing subtlely of roll-back attack. Unauthorized people, even if they control all of the storage servers *can't* forge new file contents and trick you into thinking that their choice of contents is the correct new contents of the file, so we can say that you don't rely on the storage servers at all for "integrity", but they *could* trick you into thinking that an older version of the file is the current version, just by rewinding their storage server state to an earlier state. For simplicity, I like to exclude roll-back from the definition of "integrity" -- you have integrity if unauthorized people can't trick you into accepting arbitrary new file contents. By the way, we already have fairly strong protection against roll-back attack in the form of a quorum system -- if some of the storage servers that you do talk to tell you about the newer version of the file then you can believe them because you can check the digital signature on the newer version number. That means that an attacker who wants to do a roll-back attack has to make sure you don't ask good servers in addition to making sure that you ask bad servers. There's another fairly cheap defense which it would be nice to add: you can remember the most recent version of that file that you've seen in the past, so that nobody can ever trick you into believing in a version of the file older than the most recent version you've seen. It would be great if someone would implement that (it's a curious question as to where you store that information -- one intriguing possibility is in the metadata of the parent directory!). Is there a ticket for this issue? Oh by the way, I recently made the text of about.html a little less precise, as you correctly pointed out, in the interests of brevity: http://allmydata.org/trac/tahoe/changeset?new=3888%40docs%2Fabout.html&old=3842%40docs%2Fabout.html Thanks for the feedback! I appreciate precision. Regards, Zooko _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
