The thing is that it isn’t just about logins. It’s also about credit cards and identities stored in these password managers.
Cache poisoning is still a thing, the overlay exploit (mentioned by the researcher who found the vulnerabilities) could fool anyone, hijacked domains do happen, etc.
Yes, it’s not exclusive to password managers. Any web browser extension capable of auto filling personal data is at risk. Yes, password managers aren’t able to “fix” this completely. The Chromium and Mozilla team should be involved as well. And there will always be the real risk of facing a comprised website. Something that only the website owner will be capable to fix
Should they just pretend that it’s fine and wait for an online outcry to introduce a simple on/off button that allows their users to adapt the protection level to their threat model? No.
If there’s something that can be fixed, in a piece of software like a password manager, it should be fixed. No question asked. If there’s a security issue, a leak, anything impacting the safety of a safety-focused software, it should be the top priority for these developers to at least mitigate the risks.
Open-source is not a magic thing that makes programs secure. As do audits.
However, there are reasons to think that the open-source PM we recommend are well tested and reviewed, in addition to their audits.
I think that the apps we recommend that do client-side encryption should be open-source, especially when managing very sensitive files (logins). So we can look at the encryption they use, etc. This can be a great sign of trust (as with KeePass, Bitwarden, Proton Pass, …).
If 1Password has unique features useful to 1% of PM users that no password manager with open-source clients have, I think that this shouldn’t be a reason to recommend it. Because it is not FeaturesGuide. Our policy is to prefer open-source in general when available. I find that the features that are unique to 1P are pretty niche. We CAN recommend alternatives to close-source products even if they are not equal in term of features (Apple Photos, Google Maps) ! Lacking some features is balanced by the trust that open-source can provide.
Why would this require open-source? You can do this with source-available as well, like how Bitwarden was for multiple months. I’m sorry but I haven’t seen a single convincing argument so far why open-source is better for privacy, and your post contains none either.
Yes, something as simple as Keepass but for iOS where I would then manage my own thing locally while being open source. I feel like there is no good option, only a local network hosted Vaultwarden looks fitting.
How is this even a question? FOSS should be required in all categories of software. Proprietary software can’t be trusted; it’s either malware or it’s potentially malware.
Source available also isn’t enough. You must be able to trust the build process. With FOSS, you can reasonably trust Linux package maintainers or build yourself from source.
Regarding password managers, nothing that has a third party cloud component can be trusted. The only cloud that is acceptable is my own. As I like minimal setups, I simply host my Keepass DB on my Samba server, and access it remotely via a Wireguard tunnel.
I just want to point out that Bitwarden is technically not open-source but source-available. They have an unusually long-winded FAQ just for this. Everything in the bitwarden_license folder on the client side is only source-available.
I know I’m nitpicking, but I can see someone in the future request removing Bitwarden because of this. I’m also expecting this thread will be dragged out long into the future because for some people, open-source is an ideology.
Agreed on the self-hosted VPN-accessible part.
Less sure about the open source/source available one.
If the code running is visible publicly, I’m not sure you need to specifically have the open-source part to it. If the maintainers are aware and fix the issue by themselves, you probably don’t need to directly contribute.
SQLite is doing exactly that and it works just fine.
With FOSS, you can reasonably trust Linux package maintainers or build yourself from source.
Trusts is another topic entirely and nothing protects you from having a webdev going rogue and messing up the FOSS code as it quite happened a few times in the past recently. It can even happen during the build process/etc.
Open source isn’t just an ideology—it’s a necessity if you want to be reasonably sure that software behaves as promised. Without access to the source code, you’re relying on blind trust.
SQLite is “public domain,” which is even less restrictive than the typical FOSS licenses (GPL, MIT). And rogue developers are clearly more of a problem in the proprietary world where their actions are much more likely to go unnoticed. In fact, it is fair to say that Microsoft, Apple, and Google are rogue developers, since they mistreat their users.
the code you’re running on your device/app is publicly available
all of it is buildable from the source
has been reviewed by some trustworthy 3rd party
company has a sustainable business
Then I don’t think that there is any red flag to be considered and could then be safe enough to use.
You don’t need the project to be MIT (or wider licence) + accepting Pull Requests etc to be acceptable from a trust perspective. That’s just cherry on the cake.
But open sourceness is not required for access to source code. That’s the whole point of the post you replied to. Source-available is exactly what it says, access to source code. Please provide a reason why open source is better for privacy than source available.
Reason: in SOME situations (like if you are journalist) you can be in risk, so even proprietary server will be bad (unlikely)
But for general usage, proprietary products that cannot be built by user is just “trust me bro” thing. Even if there are audits (once again it is “trust me bro” but this time to auditor because no code - no proof).
And we have no proof that there is no something backdoored by govs and forbidden to disclose (for example story with Anom messager)
Since I am seeing it more in these recent comments, I would be interested in having some clarification by @jonah on how this criteria would be interpreted if approved.
I had always assumed this would, functionally, only affect the 1Password recommendation but since others have mentioned other PMs not being “fully” open source, I am a bit unsure about what the affect on other recommendations would be.
On the surface, source-available software may seem sufficient. However, depending on how the license is worded, you might still be unable to freely build and redistribute the software. This means that neither you nor any third parties you trust may be able to compile it for themselves. (An example of this is Unreal Engine: it’s source-available, but it’s clearly non-free.) Additionally, without a true FOSS license, the product can effectively be reverted to a proprietary model at any time, leaving users effectively trapped.