Don't forget the SSL config analysis -- you're not bad, but not up to the DuckDuckGo standard yet! https://www.ssllabs.com/ssltest/analyze.html?d=onions.io htt

Don't forget the SSL config analysis -- you're not bad, but not up to the DuckDuckGo standard yet! https://www.ssllabs.com/ssltest/analyze.html?d=onions.io https://www.ssllabs.com/ssltest/analyze.html?d=onions.io Generally agreed with other comments -- it's impossible to prove that the server is trustworthy (just imagine how easy it would be to tweak the server code to simply log all the cleartext that comes in...), so a purist approach forces you to encrypt on the client-side. On the other hand, a good & open server architecture, hosted somewhere the gov't can't oblige you to cheat, with external security audits goes a long way as well. Good usability and reliability often involve some security trade-off (think about password resets -- these are next to impossible if the server is untrusted!); the important thing is to figure out the best balance based on your intended customers. Thinking more about the purist solution -- if the server is untrusted in your solution, you don't even need to provide the server anymore; let someone bigger handle that for you. I.e., you could generate a secure data file with your OSS client software (like KeePass or similar do), and let Dropbox or whoever else store it safely for you. If you could make this really useable (incidentally, KeePass is not a good model here), that'd be a valuable creation. Unfortunately, then you're stuck building native applications for multiple platforms, which is probably not what you were hoping to be working on.