I read that more as “slightly resentfully” outlined (though I can partially empathize with that given the context). There are also some (possible) factually incorrect claims in that outline. For example:
Sep 2022: Strongbox is selected by PG on the basis of “more features” and “is enough”.
[Time unclear]: Apparently, KeePassium gets delisted as redundant.
Looking back at website snapshots, I can’t find any evidence that that second bullet point was ever true. Keepassium was not recommended in the months before or after Strongbox was added. So implying Keepassium was “delisted” as a result of Strongbox being added sounds inaccurate and misleading.
In fact I can’t find any indication that suggests Keepassium was ever recommended (did it change names at some point?) Zero commits mention the name “keepassium” and the commit that added strongbox doesn’t mention Keepassium.
With that said, I do very much agree that Strongbox egregiously misrepresenting their software as “open source” while seemingly being ignorant to what that actually means, and borderline hostile and disdainful towards core open source principles is to me a huge yellow if not red flag, and just an unethical and dishonest move. I understand companies trying to protect their commercial interests, but it is not okay to try to redefine or abuse the meaning of open source for your own self-interested commercial interests.
I rarely vote on these tool suggestions, but I voted to remove strongbox.
I would like to highlight this suggestion again because I believe there are many people in this community who would like to see this issue resolved. The lack of action suggests that this type of behavior demonstrated by the Strongbox developer is acceptable to Privacy Guides. By keeping Strongbox on the site, we are doing a disservice to our readers who rely on our recommendations.
I believe that issues with KeePassium that would have previously made it difficult to replace Strongbox have now been addressed. First, KeePassium now has an official macOS application and passkey support. Also, like @Astatine already mentioned, they were audited by Cure53 in November, which is something that Strongbox hasn’t done. So if there were any issues that prevented us from making this change before, I don’t think they exist anymore.
I also don’t think that the lack of open source requirement in our password manager category should prevent us from removing Strongbox. In the end, I believe this issue is fundamentally about trust, and if we cannot trust the developer because they spread disinformation about their product, I don’t see any reason why we cannot remove them. Therefore, I suggest that the team re-evaluate the situation so that we can finally resolve this issue.
I think PG, especially since the whole 1password / open source debate, has been relatively clear on what it takes to add or remove a recommendation.
The real question, in my mind, is based on your reasons do the actions of Strongbox rise to the level of “directly impacts people’s privacy negatively”?
I am not sure it does. Especially because the crux of your argument seems to be that they are no longer open source, which is still not a criteria.
While I can see your point about a loss of trust, since nothing about these actions change the actual product (ie the actual password manager is just as trustworthy), I am not sure it reaches that bar @jonah set.
The way I like to think about this is that if Strongbox wasn’t yet recommended by PG and we would evaluate it now with all the facts that we have, would we really choose to recommend a proprietary password manager developed by a single guy who we know is lying about his product being open source? I don’t think we would. So, if we wouldn’t recommend Strongbox now, we should remove it from our recommendations.
One of the reasons we don’t have the open source criteria for password managers is because we would have to drop 1Password, which has otherwise proven to be a very trustworthy provider. With proprietary software, it really comes down to trust, whereas with open source providers we can also inspect the code, so when we lose that trust, there is nothing left. Also, when the developer has been caught lying about their product, and they still haven’t stopped that, can you really say that the product is still just as trustworthy as it was before?
While I don’t necessarily want to make my core argument about open source, I think we are in a very different situation than when we first decided to recommend Strongbox, because at that time we believed that we were recommending an open source password manager, and because it was run by one guy, it was probably a necessity to be open source, so with these revelations the whole basis of that recommendation has crumbled, and PG should do something about it.
@jonah went over this scenario with 1Password (which I think is apples to apples).
The question is, is there a substantial reason to remove Strongbox from the list today given that it is already on there? I am not sure Strongbox being reliant on one dev (something other recommendations have had) or not being open source is “substantial” enough.
I could be convinced one way or the other. I just think its important to focus the conversation based on the precedent that has already been set for this category.
Personally, since the process to add a tool is so rigorous, it seems to me the bar for removal should be set very high. Since Strongbox still meets all the criteria and, since it seems like they removed saying they were open source (correct me if I am wrong). I don’t see enough here to remove it.
Privacy Guides should take trust and transparency extremely seriously when it comes to making recommendations. This sentiment holds even more weight in the context of password managers, which require the utmost trust.
Some people are falsely equivocating Strongbox with 1Password, when in fact, the circumstances surrounding the two could not be more different. There has been no incident to undermine the trust people place in 1Password. They have always been exceedingly forthright about the fact that their software is closed source — and whether they should be delisted for that reason alone is beyond the scope of this topic.
Strongbox, on the other hand, has leveraged the good name of open source for monetary benefit while violating many of the most fundamental technological and ethical principles of open source. I think it should be obvious how this is a massive breach of trust and that it is plainly irrelevant that open source is not a requirement for password managers. Privacy Guides cannot tolerate recommended products and services maliciously misrepresenting themselves at the cost of the community.
Therefore, Privacy Guides should promptly delist Strongbox without delay; the possibility of recommending KeePassium can be resolved at a later date and is hardly as pressing of an issue.
The situations are different but the precedent set for the category remains the same. The one major issue that everyone seems to be pointing to has already been fixed, they do not promote themselves as open source anymore.
For me, this whole trust issue would be more relevant if they refused to change how they promoted themselves.
While their apparent fundamental misunderstanding of what open source is, is “unfortunate” I am not sure it rises to this “massive breach of trust” that you are saying it is. To me the github thread shows a lack of understanding of these concepts from the dev more then a malicious intent to deceive its users.
They only changed when they were called out; that is not transparency. Everything indicates they would have been perfectly happy to continue with the status quo if they had had the opportunity to do so. They also tried to claim a flexible definition of open source rather than take responsibility when concerns were raised.
I think we probably just disagree with how we interpret the thread, and thats fine.
To me, this says they never fully understood what they were claiming and therefore did not understand the push back, more so then the intentional lack of transparency you see it as.
Maybe intent, in this case, does not matter. I don’t know.
I don’t know where they promoted this before, but at least on their about page, they still heavily imply that Strongbox would be open source:
As the world became more mobile and as desktop Windows lost its dominance the need for an Open Source password manager only grew and this is when my own need for a Password Safe client for other platforms grew. Strongbox emerged from this need and has grown and developed into what you see today.
Fair enough. I can be convinced that this is deceptive. I am not sure this blurb would be enough for me, personally, to delist it but I also wouldn’t oppose doing it, if PG decided to.
There hasn’t been any substantial arguments here in favor of retaining Strongbox over KeePassium. However, I won’t take a stance on an open-source requirement for password managers for now.
I’ll bring this suggestion up to the team and update the discussion accordingly.
I like this table. In security circles, I’ve seen some use “CCC” viz. comprehension (usable security), confidence (safety & trust), control (transparency & measurements).
I suspect unfortunately many people still won’t back me up that funding/business models do matter and are directly relevant to privacy, as we’ve seen with Skiff, as we’ve seen with Simple Mobile Tools, as we’ve seen with Wire, etc.
Hopefully someday we will be prepared to discuss and acknowledge that non-technical criteria are both needed, and probably more important in many cases than the technical criteria we impose.
Anyways, now that it has actually happened, it seems there’s no choice but to remove Strongbox, because the new company’s track record (with Voice Dream Reader for example) is abysmal. I’ll accept PRs approved
Especially because the crux of your argument seems to be that they are no longer open source, which is still not a criteria.
