Too Busy For Words - the PaulWay Blog

In the lab that I work in, I'm supposed to write down everything I do, and everything I think of, and date it, in a big red book. Should there ever be a time where someone else informs me that my idea is not original and they were first to think of that, this book is theoretically going to settle the matter. Of course, I might still be wrong, but I wouldn't be just me saying so. And, of course, it looks better if I've got it in a book and they haven't.

Of course, I'm lazy, I type much faster than I write, and I don't have ideas that can be neatly mapped out on a page. But files - ah, files are untrustworthy. Discs are untrustworthy. You can fiddle with their contents whenever you like. It doesn't take much work to make a file look it was created on the day I was born in 1971 - although going past the Unix epoch (or your local filesystem's equivalent) is a bit more difficult. And since any challenge like this happens over the course of weeks, not in midnight raids, the temptation to fudge things a little to make it look like you came up with that idea for a method of delivering formatted content through the internet two years before Tim Berners-Lee ever thought of HTML.

So what one needs in this situation is a trustworthy repository with an audit trail. It must be a trusted third party, so you can deny any direct involvement. The audit trail must itself be untamperable. The third party has to also prove to you that your files, and their record thereof, hasn't been tampered with - that no-one else has submitted work claiming to be you. And, most importantly, it must use fairly simple mechanisms that can act on a day-to-day (or even more frequent?) basis, so that I don't have to wait until a CD is filled before mailing it off to the escrow agency.

Now, all this isn't too hard. Public Key encryption allows you to sign your work in ways that are provably hard to forge or tamper; it also allows them to sign their logs in such a way that you can verify with their public key that the log is a true and correct account, even if you can't play with it directly. Rsync and other methods provide a simple way to make a copy of your work here to a remote location with a minimal transfer, also using a secure transport (ssh). There are other methods - scp, webdav, version contron systems; I don't think it should need to be one protocol for moving the files to the remote location, just so that you can be confident that it's been received and that no-one else can tamper with your work.

At the remote site, I would imagine a system where every change - and using rsync or diff here would make a lot of sense - would be written to a log. Each entry in that log would be digitally signed by the secret key of the logging system. This then gets written to a CD-R, or some other permanent "can't be changed again" system - stone tablets, for example - stored in enough locations that it's too difficult for an attacker to change or destroy them all. And because your changes were signed with your public key, you can now prove that the online log of your changes agrees with what you say happened.

In fact, if you use the model of open source backups (i.e. "Real men don't make backups, they just upload their work to a public FTP server and call it the Linux Kernel."), you could create a system similar to FreeNet where people hosted small chunks of this growing data corpus, hashed and encrypted and distributed to such an extent that no-one knew what was in the blocks that they held. If you had to do that to access the system, then while you might be saving your own competitors' information, at least you're improving your own security in doing so. And obviating the need for stone tablets is a Good Thing.

Now I just need to invent the system to protect this document, so that in a years' time when someone wants to do this I can say "Ah, but I invented it first! Your solution must be open source and free for everyone!"