The topic has already been briefly touched upon here, and I would like to put forth an actual proposal for it.
It has happened many times already that projects formerly recommended by Privacy Guides have had to be delisted from the website; the reasons for delisting a project have typically been one of the following, I think:
- the project had become unmaintained or was discontinued
- the project had shifted focus towards a different direction, deviating from its original privacy/security stance
- the project had been sold to a company that changed the core values of the project to no longer be aligned with the original privacy/security goals
In my view, some characteristics of a project that could lead it to such a fate are:
- the project is too young and not yet mature
- the project has only one or very few developers/maintainers
- the project is a hobby project, or is published without any guarantees of continued support
- the project doesn’t have a clear organisational structure and leadership behind it
- the project is not sustainable in the long term in the market it has entered
- the project is based on volunteer work, with little to no retribution or other incentive to maintainers/contributors
My proposal is that the inclusion criteria be expanded with some clauses aimed at future-proofing the recommendations. (Since such criteria would apply to all categories equally, perhaps it would make sense to not duplicate it in each page of the website, but instead publish it in a unique dedicated page?).
I have come up with the following suggestions for the criteria that a project would need to satisfy:
- the project shall be developed by a team of multiple official contributors, not by a single maintainer
- the project shall have a well defined organisational structure with clear separation of roles and responsibilities, and with a well defined direction and goals
- the project shall have demonstrated a history of continued stability and constant (non fluctuating) development effort
- the project shall have plans for its future (development roadmap, expansion plans, …) with a past history of respecting the published goals; and shall have made a commitment on continued development and support for the long term, possibly in a legally binding way
- the project shall have a solid business model and shall be in good financial standing (this clause should not a priori exclude purely donation-funded projects), and, possibly, should have a history of making sensible financial decisions
- the project shall have made commitments not to walk back on its privacy and security values, not to sell itself to companies with an incompatible vision for the project, and not to otherwise prioritise profit over people
- the project shall be in good legal standing (I mean that for example it should not be operating in a way that is against the law, or in a grey area, in its jurisdiction, because then it could be forced to cease operations by authorities, or it could be forced to compromise user privacy)
Best case criteria:
- the development team of the project shall include a dedicated group of security experts (it’s not strictly relevant but I think that if we request that the project have a team of developers, then it makes sense to request that at least one of the developers be responsible for the security)
- the organisation behind the project shall be registered as a non-profit (or is it out of scope for this discussion? My thinking is that a non-profit wouldn’t get easily distracted with the mentality of “profit over users”, and would be incentivised to do good for the people)
Some of the above conditions are arguably quite strict, and maybe should only be enforced for younger projects that aren’t yet well established and still need to prove themselves?
The reasons why I make this proposal are the following:
- The Privacy Guides recommendations should be applicable to a general audience: average people can’t be expected to be able and willing to keep up with frequent changes, and projects coming and going. Normal users seek a simple and stable recommendation that they can use without having to closely follow online communities for news. Projects that are developed by a single person are much more likely to eventually get abandoned and are more susceptible to unpredictable circumstances like the “bus factor”, so they aren’t a good option for the majority of people.
- A product/service backed by an organisation with a good team of people behind might offer better polish, UI, UX, and customer support compared to a hobby project, and it might be better optimised for ease of use by common people, etc.
- If there is a good team of developers behind a project, it suggests that, hopefully, there is better division of development roles, there are more eyes on the code, and it is easier to deal with security. In many cases I think that a single maintainer of a hobby project cannot be expected to keep up with the security aspect of serving a large user base (though there can definitely be exceptions, like when a project is only made up of small modifications to an already established larger project, or when the developer is a well respected security expert, or when the project is a simple app with small attack surface, …).
I will also quote the following passage from the common threats knowledge base page on Privacy Guides, giving advice on avoidance of supply chain attacks:[…] Noting the number of contributors or maintainers a program has. A lone developer may be more susceptible to being coerced into adding malicious code by an external party, or to negligently enabling undesirable behavior.
It is clear that if criteria similar to what I suggested get added to the inclusion criteria of Privacy Guides, it would render many recommendations no longer viable. Some of them being highly reputable projects (I’m thinking for example of uBlock Origin).
Having thought a bit about that, I came to the conclusion that maybe projects that do not meet these new criteria should still be mentioned in some way on the website. That’s because the average user isn’t the only kind of audience that visits Privacy Guides: many people here are enthusiasts that follow online communities and projects, and constitute a group of people that likely do not have a problem with the drawbacks of using software made by single developers on a no-guarantee basis. Also, it is likely the case that the recommendations that satisfy the future-proofing criteria aren’t as good in other criteria. So for people who know what they are doing it may make sense to keep separate recommendations.
My idea is that by default the recommendations on Privacy Guides would be those suitable for average people, and then in a separate page there could be listed additional recommendations with clarification of which criteria they do not fully meet. This approach, though, would mean overhauling the entire recommendation system, and probably needs its own separate discussion.
And then there’s the fact that in many categories there probably aren’t really any good viable options for recommendations at all, and I cannot think of a good solution… Maybe in these cases Privacy Guides could still include the current recommendations but with a warning that no truly good options exist and that the ones proposed are shown only due to lack of better alternatives.