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.
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.
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).
Now that Jonah has decided that PG sees open source as defined by OSI, could we proceed with this requirement?
It would seem so, we now have a proper term to work with.
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.
Do not take that comment to seriously, I was obviously joking around there.
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
Let’s do a Poll to help us decide. All votes are PUBLIC to prevent people from faking it with burner accounts.
- Keep the status-quo (proprietary allowed)
- Require source-first as a minimum
- Require open-source
- Other
We have already justified why not open source, when we added 1Password, as all such recommendations are discussed within the community.
Now we are attempting to undo this discussion from 2 years ago based simply on a feeling that open source is always better?
To which I would reiterate everything I said here: Require Open Source for Password Managers - #123 by jonah
I am against unnecessarily undoing existing work.
We can undo a decision that was made before, but only if new information or a new point of view came to light that we have not taken in before.
So far however, I do not really see any arguments mentioned here that were not mentioned before.
Edit to add on this: earlier in this thread I was on board with adding opensource as a requirement, my reason for changing my opinion where @ph00lt0 comments on the open source definition thread.
I agree that proprietary software is inherently less privacy-conscious than open-source alternatives. However, I do think we should prioritize open-source services over their proprietary counterparts.
In my opinion, Privacy Guides should maintain a consistent approach regarding their recommendation criteria. If we set open-source availability as a minimum requirement for tools like Notebooks or Office Suites, and require source availability for MFA, we should also reassess whether we shouldn’t apply similar standards to much more sensitive tools like password managers.
I am firmly against consistent site-wide criteria across different categories for reasons we are currently discussing in this thread: Should Privacy Guides require open-source, source-first or source-available as a criteria for all tools? - #4 by jonah
Quickly hopping in here, 1password could be removed even without requiring open source, the listing of 1password and the change of the criteria are two seperate discussions.
I don’t really think so, personally. Without an active/direct reason to change a current criteria I think the recommendations should be left as-is. In other words:
I don’t think we should start removing products with no clear deficiencies purely because other products improved themselves. This kind of churn is confusing to readers.
I see changes like this as promoting instability in the privacy space, which is a common complaint among people learning about the topic and seeking tool recommendations. This is why we add and remove tools cautiously.
Basically, the way I think about it is:
- When we add new tools, we need a strong justification on why they are substantially better than the alternatives.
- When we remove existing tools, we need a strong justification on why they are substantially worse than the alternatives.
I don’t think this second justification is met simply based on open source alone.
Yes, but as far as I know there are zero reasons to delist 1Password given in the Remove 1Password thread besides the desire to make the criteria change in this thread.
And on the other hand, making the proposed criteria change here would affect 1Password exclusively.
So these topics are related, this is just a more specific discussion.
A post was merged into an existing topic: Should Privacy Guides require open-source, source-first or source-available as a criteria for all tools?
There are alternatives to 1Password that are at least as good while being open-source. I can understand that in some cases there is no better choice, but here we have competitive alternatives that are open-source. Favouring open-source apps is already the existing policy.
Some people may point out that 1Password has a superior UI, but they are also seriously lacking in some important areas like Email Aliasing, so in my opinion, the alternatives are more competitive than some people think.
off topic voting
Requiring a trust level would prevent burner accounts from voting which was Encounter5729s concern.
Another way to put this is: Would I agree with adding 1Password to the list today if it wasn’t on there already? Probably not.
However, is there a substantial reason to remove 1Password from the list today given that it is already on there? No, I don’t think this is the case either.
Therefore, no changes needed.