3 ms·
> If you don't trust the vendor, don't let them handle your passwords, obviously. The problem is you not only have to trust your vendor today, but you also hav
by lisper 5y ago
> If you don't trust the vendor, don't let them handle your passwords, obviously.
The problem is you not only have to trust your vendor today, but you also have to trust them tomorrow. Every vendor is one acquisition or compromised senior executive or engineer [1] away from becoming untrustworthy even if they started out being perfectly trustworthy. Assessing present trustworthiness is hard enough. Assessing future trustworthiness is obviously impossible.
[1] They don't even have to be compromised. All they have to do is make a bad decision. Apple, the company that built an entire marketing campaign on trust, is now installing spyware on its devices.
- pvg 5y agoRight, but this applies to big piles of security-critical software in general - a near tautology. It's really an argument in favour of my position that neither open-sourcedness nor hostedness are useful criteria in evaluating the security and fitness-for-purpose of a password manager.
- lisper 5y agoNo. If I trust the vendor today, and my code is open source, then I can control if, when, and how it changes. With closed source, the vendor can introduce a backdoor with every update. They can also force me to update by making the current code stop working by changing their servers. The potential for compromise due to an untrustworthy vendor is not zero, but it's vastly lower with open source.