Wasn’t me, lol.
1 Like
It’s been concerning how many people in this thread refuse to see this as problematic.
I will try and respond to the benefits you listed but, it seems like the point of these benefits, in this context, have been lost. I am questioning the benefits of why open source should be a criteria for password managers, not the benefits of open source in general.
Not sure this should even be considered a benefit. There are still so many challenges in the way for this type of “continuity” to be successful that it makes the benefit improbable, including loss of expertise, fragmentation, and lack of financial support.
This is why audits are already a criteria.
You say this like there isn’t a massive expertise gap for the majority of users preventing them from realizing this benefit. This benefit is also a double edged sword, the availability of source code can create a false sense of security, potentially leading to less rigorous internal verification processes.
1 Like
I don’t really think that’s fair to say. There’s not any reason software developers would suddenly stop caring about security just because something is open source. They don’t even need to take contributions if they don’t want to.
2 Likes
I did not say there was. The issue isn’t a lack of caring, the issue is a false sense that “if we do slip up, the community will catch us” which can lead to less rigorous verification. Which I think is fair to point out. I think this attitude is very prevalent in the open source community, that nothing bad can happen with the code because the community is always reviewing it.
2 Likes
Well that’s why we require audits from reputable third parties. Which are much more important than the product being open source.
1 Like
/me Points frantically in the direction of Heartbleed
Which I pointed out.
Which goes directly to my point that
But you were using that as a point against open source when it’s not.
Its all the same. In that, we already have criteria covering these “benefits” that people are using as reasons why open source should be a criteria for password managers.
Regarding audits being a replacement for FOSS, I will just quote a piece from GrapheneOS:
The benefits of a group unfamiliar with the code spending a short time doing a shallow review are greatly overstated in marketing.
4 Likes
Honestly this feels more like an argument for why the criteria should be changed to be regular audits and not “a published audit”…
Obviously GOS is very proud of being open source but, I am not sure their commitment to easily reviewable code and having “relationships with security researchers and organizations” is apples to apples with how other open source projects operate.
I think if we are going to use GOS as a model then those two aspects, easily reviewable code and strong relationships with security researchers and organizations, would need to be met before we could truly say a company or tool has met the standard of open source.
1 Like
Your arguments are off topic in this thread. Please take them to the open source definition thread. You seem to already have presupposed notions against open source, attributing stuff which was never implied.
Now that the definition is clarified by @jonah in the other thread, can we bring this discussion back to extending open source requirement to password managers?
Should PG differentiate between clients and servers when extending it? Imo yes. Since well implemented clients don’t trust servers in their threat model anyway. For anyone who is worried about the continuity, you can easily recreate the back end based on connections made by the client which are well documented, so I don’t think PG would need to disqualify Proton Pass. So the requirement for minimum would be open source clients, and best possible situation would be open source stack (client and back end both).
BW and Psono are already Open source compliant, so are Keepass clients. Strongbox apparently isn’t, so maybe someone will need to open a thread to remove it and add something like Keepassium.
2 Likes
If the criteria for PWMs are changed to include a requirement for open source, the above is inline with what I believe would make the most sense (open source clients are mandatory minimum criteria, and open source client + server is best-case criteria).
For reference, what you’ve described is precisely how the criteria are currently written for the ‘Real Time Communication’ section:
Minimum Requirements:
- Has open-source clients.
Best Case:
- Has open-source servers
The only thing I’d add is for best case, I think we could/should try to also acknowledge and recognize those services that go above and beyond simply open-sourcing server side stuff, by making an effort to really document, and support and empower users ability to self-host as an option/alternative (examples: Bitwarden, Addy, Adguard, Ente).
3 Likes
Now that Jonah has decided that PG sees open source as defined by OSI, could we proceed with this requirement?
1 Like
It would seem so, we now have a proper term to work with.
1 Like
What?
The FOSS community did wise up and numerous forks and alternative implementations emerged in the wake of Heartbleed (for example, AWS switched to its own formally-verified, nimble TLS implementation). Not to mention the then poorly-resourced and under-funded OpenSSL managed to raise a substantial amount & directly lead to the creation of a well-financed initiative within the Linux Foundation that now supports many such critical FOSS projects.
If you follow the security scene at all, you’d know that each of the major setbacks have strengthened FOSS. Au contraire, with closed source shops, you only get “no comment” wrt breaches, most of the time.
1 Like
Do not take that comment to seriously, I was obviously joking around there. 
2 Likes
Alright, coming back to this. I still don’t really understand the motivation behind removing well-regarded products solely because of their source code licensing (or lack thereof).
Historically we have only removed recommendations when something happens that directly impacts people’s privacy negatively.
It seems like some people in this community don’t think open source has any relation to privacy, so by that logic we shouldn’t feel the need to delist 1Password.
Some (many?) other people in this community think that open source is related to privacy, but in a more indirect/idealistic way ← I am in this camp
In either case it still doesn’t make sense for either of these camps to delist 1Password for source availability reasons alone, I don’t think.
As far as I see it, the only reason we would want to add this criteria is if we collectively believe that software being open source is a requirement for privacy/security. I believe this is a minority viewpoint, and it’s a point that we have explicitly tried to downplay in our content, as we prefer to evaluate products based on our current best judgement of how they are as-is.
Therefore… I still continue to believe that we should not add this minimum criteria 
7 Likes
My argument is defense in depth. Lets say open source does not explicitly make a project more private or secure. But doesn’t adding it make it easier to ensure that it does? Like I wish to hide a secret, I don’t rely on just a lock right, I also hide the chest and the key separately, build strong walls around it, etc. Open source does not exist in isolation.
There is also the important idea that privacy also includes data sovereignty. So if I wish to retain 1Password experience and data after the company shut downs, I would have no option to continue. It would just be to change my providers.
I again re-emphasize: Instead of asking why open source for any category, the question should always start from the solid base of “Why not”. The reasons can be practicality, too bare bones solutions, etc. but the justification should always be why not open source. Its layering end user protection, not end all be all.
2 Likes
Voting is not that useful in these issues. I can get any decision passed in forums like this with no identity verification by just burning accounts.
It should be a critically evaluated decision, and people need to understand why this is a significant decision to take.
2 Likes