In fact ... we like this particular writeup so much that we are going to start pointing customers to it since it is a bit simpler than the EncFS/Truecrypt recipes we were handing out, and just works perfectly with the platform.
You keep the data fully under your control. Who knows whatever ram-scanning-key-searching tricks Dropbox or any other Closd Source piece of software utilize...
Why would dropbox even need that level of obfuscation for a backdoor? The binary just do evil directly (although having something that seems plausibly like a bug would be ideal.)
The XML file contains encoded key and salt data. It also includes other metadata like KDF iterations, etc. Narrowing down the problem domain for the attacker leads to faster password cracking. While that is true using a strong password should render this attack useless.
Well how are you going to decrypt the files if you suffer data loss without that file? Plus, the key should be strong enough that this doesn't matter, yeah.
Git gets very slow with large files and isn't optimized for binaries. bup (https://github.com/bup/bup) is based on git but designed to solve this problem (has its own high-speed packwriter/readers).
Although still can't delete old data at the moment (though its being worked on).
In another thread, you mentioned bup. Quickly skimming bup's readme on github, I seem to only find references to the backup use case - not sync. Am I mistaken and bup also supports syncing, or did you bring up bup for another reason?
Someone mentioned using git - which has noted problems as a general purpose backup tool with large files. bup is the tool developed to solve those (git big-file is another, and technically git-annex could work that way but its not really a backup tool).
1. You have been able to use rsync.net as a target for this scheme for ... 4-5 years now. [1]
2. https://news.ycombinator.com/item?id=5640700