replicator.org ... continuous garbage collection

Finally, we are moved the code base into private beta. We changed the license to a new one we got from our lawyer and fixed some serious security problems:

1. If you had exported a Safe to your friends and they imported it, it was always possible for them to create arbitrary “new” Safes on your Account. From now on, exported Safes can not be used to create new Safes anymore. This is indicated in the Configuration tool:
   Ownership “Imported” means that the Account is imported and can not be changed or used to create further Safes. Ownership “Owned” (rendered in green) means that the Account was created by you and can be modified at will.
2. We found that the debug version was printing out the password for your Account in the log files. This has been suppressed.
3. We uploaded an SID based, but hash-derived User Id in the “encrypted” contents of each uploaded change set. So if someone was able to get the Safe’s encryption keys and your Windows SID (Security Identifier), it could be proven that you were the uploader. We did this for a technical reason, but found another way to implement the algorithm. From now on, meta data does not identify the uploader.
4. We added a new licensed feature that needs to be enabled. This is called the “Synchronize” feature and is enabled by default in the private beta. It runs out after 45 days, and when it does, basic synchronization is deactivated. Of course you get a notification some days before, and of course, no data in your Linked Folders is deleted.
   For our legal protection, we needed to be sure that we can disable all beta versions in a defined amount of time.

I am distributing the new version to the download server as I upload this blog post.

To bridge the time until the actual private beta release, the next step for me is to create one final big testcase. One that simulates a user on Speed. A test that randomly changes files and compares them from time to time with the synchronized contents of a folder that is linked to the same Safe. The implementation will take different file types and sizes into account (logarithmically random) and will also simulate moves, copies, creates and deletes in a hierarchical filesystem tree.

The goal here is to make SharedSafe more robust and for us to gain enough trust to finally use it for our very own synchronization needs (that’s why we originally started this project).