| [Disclosure: I work for AgileBits, the makers of 1Password] I'd like to elaborate on the two points made by @epistasis 1. Ability to deliver of a malicious client does not depend on where your encrypted data lives. If you sync over your own private network or if your encrypted data is held by us, it is just as difficult (or hard) to get away with delivering a malicious client. 2. There is a lot of security value to openness and having the source available, but it is only a defense against deliberately malicious software if you compile the software yourself. Otherwise, there is a very weak trust chain between the code that has been reviewed and the binary you are running. For the first point, a malicious client wouldn't need to exfiltrate all of your encrypted data. It would only need to exfiltrate the credentials needed to obtain your encrypted data. (As well as exfiltrating keys, etc). So for the overwhelming portion of people there is no significant difference with respect to us having your encrypted data or it living some place else. As for the second point, tools for deterministic builds are improving, but there are still practical impediments. In theory there are ways to ensure a good trust chain between the reviewed source and the binaries that people run. But these are far from ready for our target users: everybody. So if you, say, recommend KeePass for this sort of reason, are you also recommending it to people who will check the signatures on the source and then build from that? (I have enormous respect for both KeePass and for those who use it that way. But I have less respect for those who would recommend that to everyone. I hope that we are past the bad old days of "some people don't deserve security.") While we can't completely rule out the possibility of delivering a malicious client (through us turning evil, external compulsion, or an insider attack), there are things that we can do to make it harder for that to go undetected. You will find that where we can we have made it easy to run 1Password attached to a debugger. People with sufficient skills can see that it behaves as we say it does. This makes it far more likely that a widely distributed malicious client wouldn't go undetected. Also to support this (and try to gain some of the security benefits of openness), we've gone into gory detail about how 1Password works. Sure there are holes in some of the documentation, but we are slowly filling in those. I'll also mention the third claim that a "single employee" could cause the distribution of a malicious client. Again, there is no way to completely rule that out, but it would be hard for any single or small group of people do that without running a significant risk of this being detected internally. So it would have to be a fairly large conspiracy. And as we know, the plausibility of any conspiracy diminishes rapidly with the number of people who have to keep the secret. There are many eyes on the source, many eyes on the build and distribution process, and very few hands on the code signing keys. Several times I've mentioned "significant chance of getting caught". Consider the risks to anyone trying to do evil this way. What are the consequences to them if they are caught, and so how big of a risk will they accept? So even though we can't make it impossible for someone to get away with it, we do what we can to make it hard to get away undetected. None of this is perfect. And you have to weigh your own choices. But when you do so, make a fair comparison with the realistic alternatives instead of against an ideal. |