Yeah I agree it’s a long time coming I think. There didn’t used to be as many good open source options as there are now and they’re only getting better over time.
1 Like
I believe there were good enough options at all times.
Keepass was always there, or even Password Safe back then.
The problem is the criterias like cross-platform, syncing, online-local, with iOS being the main problem with their restricted and expensive ecosystem.
These criterias, are important, but should never overcome the open source one, especially for password managers.
1 Like
I have mixed feelings,
IMO for a password manager–because this is often the very first step less technical people take towards improving security or privacy–very easy/intuitive UX, and very hard to screw up UX, and easy/reliable backups are paramount for at least one of the recommendations.
I have helped a handful of relatives transition from Lastpass to Bitwarden, and among my less technical relatives, the feedback I’ve received is mostly positive, but common complaints about autofill, about inconsistent auto-recognition of new logins, and just general minor confusion with UI/UX. From what I’ve heard, most people on this forum who have used both Proton Pass and Bitwarden Premium say that Pass is not yet on par with Bitwarden, so I assume Pass wouldn’t be an improvement for this demographic at this point in time.
So my concern is that a premature requirement for open-source only may be a case of “letting great be the enemy of good” because we would arguably be ruling out the option that is most appropriate for the broadest audience. (I say premature, because I expect both Bitwarden and Proton Pass to continue the steady course of improvement).
With that said, I could probably just as easily make the opposite argument (that open source or at least source available clients is mandatory) and for my own personal choices, I consider open source clients to be a hard requirement for a password manager. And just as a general value, I prefer to highlight and promote FOSS projects over proprietary ones.
2 Likes
The requirements are different for different types of software and services. It’s not really ideal to try and force a single set of requirements for everything. Some things are specific to the type of software, some software might be able to run fully offline while others can’t like search engines. Sometimes there aren’t very many options for software, sometimes there’s an abundance of great options so the requirements can be tightened. It’s an ever evolving thing. Generally we try to tighten the requirements over time because usually there are more options and the offerings improve over time as well.
2 Likes
Can you explicit ? What are those ? I only know of Proton, Bitwarden and KeePass
1 Like
Thanks for bringing this up, it was long overdue.
The reason was that stuff like keepass is to difficult for certain users, even Bitwarden wpuld be too difficult for some older folks. This criteria allowed for some password managers that were closed source, but had a good UX.
That said, currently I do think that Protonpass has grown into a fully fledged password maanger that has a good enough UX, so I too think we can go ahead and merge this new criteria.
2 Likes
Just for clarity, do we want to implement a full open-source requirements, or just FUTO-like “Source - first”?
I am asking this because if we say open-source, then we must be ready and willing to remove Bitwarden if they start again with SDK license shenanigans.
In my humble opinion, source first is better than open source.
1 Like
While I’m personally an advocate for FREE (better term than open source) software, I think “source available” is good enough because that’s what matters the most if you want to be (theoretically) able to check if the application is actually protecting your passwords.
For those who want to change the criteria, I think there are two primary questions to answer:
- should the minimum criteria require: source-availability, or free and open source?
- should the criteria apply only to client side software (the “apps” and browser extension) or should it apply to all the code necessary to use the service (both client and server side)?
If the criteria weren’t specifically limited to open source (or source available) clients Proton Pass would be eliminated long before Bitwarden. IF the criteria is to be changed, It’d be worthwhile to consider unintended consequences that could impact Proton Pass now (or a hypothetical future Bitwarden).
[example criteria from other sections]
The VPN criteria or the RTC criteria are two examples of sections where the Criteria is crafted in such a way that availability of FOSS clients is mandatory but the requirement is limited to to client-side-software only.
- RTC keeps it short and sweet:
-
Criteria: Has open-source clients.
-
- VPN gives a bit more explanation: *
-
Criteria: If VPN clients are provided, they should be open source, like the VPN software they generally have built into them. We believe that source code availability provides greater transparency about what your device is actually doing.*
-
1 Like
Another thing I will point out is that if we agree with the arguments being made in this thread, then logically we must also require open-source for security keys as well, which play the same role in many people’s workflows.
I don’t agree with the need for this criteria, personally.
5 Likes
Not necessarily. Physical keys are very unlikely to ever screw you over with TOS changes.
Plus, there aren’t many security keys while there is plenty of password managers.
2 Likes
This is out of subject, and lets not get drown away.
2 Likes
I think those could be a separate discussion. The only open source keys I’m aware of are nitro keys, so I think with the limited selection it makes sense not to do that for security keys.
3 Likes
Feels like this discussion should be tabled until people can agree on what they even mean by open source, which should probably be its own thread.
I know PG has its own definition but I have seen others throw out their preferred definiton as well.
This whole things feels a bit ambigious, with no clear benefit other then people like open source stuff more then closed source.
2 Likes
PG already has an agreed-upon definition of open-source. Given that many other categories already require open-source (not source available and the like), I think it makes the most sense to stick with that definition throughout the site.
4 Likes
I understand that but it I have seen people mention this should be source first or source available instead. The thread was created over a year ago, its unclear to me if the intent was to even use open source as defined by PG when it was created. Considering that the definiton PG decided upon looks to have been finalized around Aug 2023 (based on the dates in the thread) and this thread was made in April 2023
EDIT: apparently PG has no agreed upon definiton of open source, which makes this criteria even more ambigious.