Denote source availability for recommended tools

Site Development
1

Continuing the discussion from Require Open Source for Password Managers

I don’t think Privacy Guides should enforce a strict FOSS-only policy in this category—in fact, in any category. This approach could lead to excluding good projects just because their client-side or full code isn’t open source. It doesn’t mean they’re falsely claiming privacy or security. For example, 1Password has proven its reliability. While there are many great FOSS projects, they don’t always surpass proprietary options in terms of features or UI/UX.

I believe we should list both FOSS and proprietary tools in each category, with the condition that proprietary options undergo at least yearly audits. We could also provide badges and information highlighting each project’s strengths. A tool that works well for one person might not suit another. Just because a FOSS tool is favored by many in the community doesn’t mean it’s the best choice for everyone who visits the Privacy Guides website, especially for those new to privacy concerns.

We shouldn’t limit people’s choices based on the preferences of a few. While we should definitely establish criteria for evaluating proprietary projects, we shouldn’t prevent them from being recommended altogether.

Note: I would definitely appreciate it if we could discuss this further in a new thread.

6 Likes
2

I don’t disagree, but there is less of a guarantee that closed source applications aren’t spying on you. It can be investigated if they make network requests, but it’s harder to validate.

With this, why not provide the information quickly and let the user decide if it meets their requirements? Let’s add a small logo/icon/banner to each recommendation to indicate if it’s FOSS (FSF approved licenses only), Open Source (non-Free licenses), or Proprietary. Then each of those icons link to an article describing the difference between them, possibly linking to additional details on said licenses.

7 Likes
3

I am worried that something like that might be more information overload for users who might not need or care about that information. PrivacyGuides is already information dense, and for lack of a better term, I would rather not scare off the normies

2 Likes
4

I agree that this would be a positive step. It could provide users with clearer information and help them make more informed decisions.

I understand the concern about information overload. PrivacyGuides definitely needs to address its density issues, but I believe we shouldn’t limit users’ choices regarding FOSS, Open Source, or Proprietary software. Providing this information can still be valuable without overwhelming users if implemented thoughtfully.

5

The descriptions for most software already include the words free and open source software if something is FOSS

6

For better or worse, knowing the difference between the two is a deciding factor. Having it be an icon rather than fully explaining the license details should simplify its usage in our current recommendations. Some recs it may be complicated to add (services like ProtonMail have a closed source backend, but some open source client apps), but adding them where it makes sense can help out.

Further, having a dedicated FOSS vs Proprietary page should help readers understand how to make decisions with this information. I don’t think we should bias heavily towards FOSS and entirely exclude Proprietary, but rather lay out the facts as-is for the user and what they can expect.

The descriptions for most software already include the words free and open source software if something is FOSS

A simplified icon could standardize this, and enforce a consistent reader experience across all recommendations. However, we may also consider to leave in the text, or ensure that the icon is properly labelled with accessibility attributes.

7

Quick note here for everyone here not aware, our general policy around open source is that its not a requirement, but it is preferred when a user friendly and secure alternative is available.

3 Likes
8

This is exactly what I was thinking when I first wrote it.

In my opinion, these are the best ways to move forward. However, we should prioritize readability to ensure that both novices and experts can easily understand the differences between FOOS and Proprietary, as well as the distinctions between the project lists.

9

I think that makes sense, as long as the FOSS/Open Source icons are built with accessibility in mind for people who use screen readers or have colorblindness of some sort

2 Likes
11

I don’t think Privacy Guides should have a policy of always including at least one open source and one proprietary option in each category because that would also mean that we would have to recommend providers that are not very good.

VPNs are a good example, where I don’t know a single proprietary option that would be better than our existing recommendations.

Of course, open source doesn’t always mean that a product is secure. Still, I have noticed that the proprietary alternatives to many of the tools we recommend tend to have some privacy or security problems, which is why Privacy Guides wouldn’t recommend them in the first place. So, proprietary providers with great security and privacy, such as 1Password, are rare.

So, I see little reason to have a policy of always having at least one proprietary option for each category. Also, having audits is just one thing we evaluate, so that alone wouldn’t be enough to get listed, but maybe that’s not what you meant.

1 Like
12

I may have been a bit unclear, but I didn’t intend to insist on including both an FOSS and a proprietary option in every category. Instead, if there are qualifying FOSS or proprietary projects that meet the criteria, they should be listed, regardless of personal opinions about the project. We should provide specific details about each listing and let users decide based on their own threat models. Our role shouldn’t be to dictate what users can or cannot use based on our own threat models. The key point is to avoid criteria tied to specific threat models, such as requiring a project to be open-source.

Regarding audits, they are just one example of a “must-have” criterion for proprietary projects.

My main concern is that many discussions focus on removing projects that some individuals dislike or rejecting new submissions based on personal preferences, often driven by their own threat models.

We should establish clear criteria for each category, with specific guidelines for both FOSS and proprietary projects. Then, we should list any project that meets these criteria. It’s important to provide comprehensive information so that users can make decisions based on their own threat models, rather than limiting the list based on our own preferences. For example, it doesn’t make sense to exclude projects solely because they’re not open source, as has been debated.

13

FOSS isn’t just about privacy/security, but also about long-term maintenance of a project. If the provider of a proprietary software goes under, the project could easily become unmaintained and users must move away from it, whereas FOSS can always be picked up and maintained by someone else.

3 Likes
14

No one has said otherwise. The key here is to let people decide what’s best for them based on their own threat model.

I agree with this point, but we can’t list projects based solely on our own threat model. We need to establish certain criteria that do not exclude solutions simply because they are not FOSS/Open Source. For proprietary software, one of those criteria could be a requirement to support data export in an open and widely-used format.

The main goal is to empower people to choose what’s best for them. To achieve that, we should have criteria that don’t exclude projects based on someone’s individual threat model.

15

The below rant may be unwarranted, but it summarizes my beliefs why we should talk about it and include it as part of the guide.

FOSS means that someone can evaluate the source code. I can detect if a local application is sending network requests, proprietary or otherwise, but even if it did it would likely be encrypted and I couldn’t say what it was sending. The situation is more grim for software as a service, and very few of these services are under AGPL. The rabbit hole goes down that most servers live in Microsoft or Azure web servers, but that’s outside the immediate application problem discussed.

Just now in the news GM is getting sued as their proprietary software sending user data to insurance companies on driver behavior. If all users could request the source code, I’m confident some hacker or evaluator would have seen what was happening way sooner, and even more confident that GM would have never allowed this scummy tactic to be open sources for auditing and never done if that was a requirement.

So when software is FOSS, it’s no guarantee of privacy, but it’s a way we the consumers get to understand what the services and applications we interact use our information. It’s absolutely a contributing factor in privacy choices. Not the only one, but definitely one. And while it’s not even a factor in all recommendations (first party email provider is likely one where no FOSS exists - I don’t want a ping from forward mail on this as they are a forwarder), for others it may be a larger factor (I chose Bitwarden with higher confidence due to its licensing).

I find these licenses are end user agreements for the software provided to us. For services we use, we agree to terms of service and privacy policy. If we recommend that we read the ToS and privacy policy before using a service, then it’s also in our best interest to know the software end user agreement - especially since FOSS empowers us the consumer.

16

FLOSS should always be preferred over proprietary software, and there are plenty of reasons why. FLOSS matters.

The only exception is when it’s stupid to recommend FLOSS, for example, using a Linux-libre kernel or insecure laptops with FLOSS firmware, etc.

1 Like
17

I share a strong preference for FOSS, choosing it or my own projects over proprietary software 99% of the time, even when the features aren’t on par. However, that’s just my personal style and threat model.

For instance, my sister, who is just beginning to care about privacy, doesn’t like the UI/UX of Bitwarden and prefers 1Password instead. She tried Proton Pass but didn’t like that either. I had to explain the differences between open-source, code availability, proprietary software, etc. Her response was, “It would be great if blogs and forums discussed these differences and listed all the solutions so I can choose what’s best for me at the moment.” She also loves Gmail but wanted to switch, so she tried ProtonMail, Tutanota, etc., and ultimately settled on Fastmail. She told me, “Right now, this works for me. I know I’ll switch to something else in the future as I learn more, but for now, this is good enough. Understanding things like GPG keys is too much for me right now.”

This happens with almost all my friends…

I’ve realized that people are at different stages of understanding, and not everyone is ready or willing to fully embrace FOSS. Some might not like the idea, or their threat model doesn’t prioritize it, and that’s okay.

Therefore, we should refine our criteria universally for FOSS vs. proprietary software, create a resource to inform people of the differences, and be transparent in all listings about whether something is FOSS or not. Then, let people choose what’s best for them at that moment.

But again, that’s your worldview and your threat model. No one is saying FOSS is inherently better or worse than proprietary software. We’re discussing the importance of not imposing personal threat models on others. Instead, we need to teach people how to develop their own, understand the differences, and then let them choose what’s best for them.

3 Likes
18

Amazing write up, thank you. The UI/UX is something hardcore privacy users can look past, but it actually is likely the #1 factor for those who aren’t deeper in the rabbit hole. With this, I think it validates that FOSS is no means a hard requirement at all when making decisions to improve privacy. My current favorite saying is don’t let perfect be the enemy of good/getting better.

1 Like
19

Appreciate it, buddy!

I really liked that one!

I think the next step is to wait for a moderator to weigh in and clarify whether it makes sense to continue the discussion or if it should be paused because they don’t plan to proceed with it.

1 Like
20

Salute your independent thought process …
Last time, I looked, Mother Earth had more than just the under 30 developers/ programmers inhabiting …
If the mission statement of PG and Techlore is to only gather a nerd base then all speed ahead …
Otherwise, if it is to be inclusive and an " actual space to learn " then what is proposed makes sense …
Have asked why a specific product was never mentioned and yet has stood the test of time with regards to remaining in business and remaining at the forefront of cybersecurity, with attestation from multiple awards and competitions …
but nary a whisper …
and to be only responded with ghosts and crickets …

The road to ignonimity is continous ambivalence and disregard …

21

FOSS really has nothing to do with threat models, I don’t understand why you keep bringing threat models up.

FOSS is inherently better than proprietary software, which is why we always prefer it, it just isn’t inherently better at privacy/security, which is why we still recommend proprietary software sometimes anyways.

Since I think we are all in agreement that open source software isn’t more or less secure than proprietary software, it logically follows that using FOSS has nothing to do with threat modeling. It’s an independent factor.

Anyways, while I’m not opposed to noting this on each recommendation, I also think I agree that @gregandcin that it may not be necessary:

3 Likes