The problem with lists like this is they really are just a "here's 100 open source products", without any criteria or individual evaluation. It is often just parrots repeating what other parrots say.
Something which is clearly alpha-state isn't usable to regular users shouldn't have a "recommendation". Then you get sub optimal recommendations, listing some projects which are unmaintained etc.
With the cleanup at https://privacyguides.org, (since we split from PTIO) we've removed a lot of things, and gone down the part of actually providing guidance rather than "use this software to make you magically more private".
I think it's important to think privately, modify behavior rather than rely on technology to do it all for you.
Looking at this particular list there are some bad choices:
- AndOTP: Uses PBKDF2 and a heap of rounds that is unbelievably slow when you have a number of OTPs. Aegis uses Argon, which doesn't have this problem, and we think it's code is developed by someone who is security conscientious.
- Mailfence: Last email I sent to them they don't use any kind of disk encryption
- CriptText, these things really don't help, they are walled, in that everyone has to be on a centralized service to get the benefit. E2EE that comes with web-apps can often be dangerous as it can change, have vulnerabilities introduced after an audit etc.
- Linux recommendations: Those are also awful and don't have any threat model in mind.
I'm going to stop now, it's basically every bad thing that was ever on PTIO, that we removed. Basically there are terrible recommendations with a few good ones sprinkled in.
"The problem" with lists like these is that they proliferate without reason. This fragmentation means that it's basically impossible for anybody who needs one to know which ones are good or up to date. It also guarantees that most of them will be unmaintained at any given time.
Somebody should make a list of lists. Or a list of lists of lists...
> - Off-The-Record: Doesn't cover group chats or other side channels, such as status updates, VOIP.
... and yet it's still the ONLY cross-messenger system, not everybody uses group chats, and not everybody cares about status updates or whatever.
> PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication.
That's not what it's for, and email is not "real time communication". I have an archive of email going back 30 years. Forward secrecy is not always a win.
> Tox + qTox: Developed wrong. They developed the software then decided to write the spec afterwards.
Many of the projects you recommend don't even have specs. Tox may be a hot mess, but it's not unusual in that regard.
> Browser Extensions: NO JUST NO.
That's an awfully strong statement to make without a threat model...
> Video Platforms: These are not private
... but you list "social networks", which are intrinsically "not private" in their very purpose, just like video sharing...
> ... and yet it's still the ONLY cross-messenger system, not everybody uses group chats, and not everybody cares about status updates or whatever.
There is Matrix. The issue is that people don't know what actions are E2EE and what is not.
> That's not what it's for, and email is not "real time communication". I have an archive of email going back 30 years. Forward secrecy is not always a win.
It was listed under the "encrypted messaging" section.
> That's an awfully strong statement to make without a threat model...
It's not, its that browsers have evolved to the point where a lot of those extensions are unessary and actually are counter to privacy, modifying your fingerprint to be unique.
> ... but you list "social networks", which are intrinsically "not private" in their very purpose, just like video sharing...
>PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication.
OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting.
Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.
> OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting.
There are actually some XMPP clients which offer it as an option, which you should never use when you've got OMEMO, or (OTRv4). The double ratchet protocols olm, etc are better for this usecase.
> Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.
I was specifically talking about instant messengers, not email usecases. It's also why things like Deltachat are basically taking the worst parts of email encryption and mashing it into an instant messenger client.
I actually do PGP over XMPP these days. It is so simple that it ends up being quite reliable. So I consider it the superior protocol.
>I was specifically talking about instant messengers, not email usecases.
Forward secret PGP would be simple for an online application like instant messaging. You could just throw up a new public encryption key on the server before you delete the private key.
Deltachat also embodies some of the best parts of email encryption. Open federation based on the popular and well known SMTP standard. Encryption based on the popular and well known OpenPGP standard. Contrast with what happened with the Signal encryption protocol. OMEMO, Signal Messenger, Matrix are all entirely incompatible. Things are worse off now than they were before.
OMEMO, signal protocol and Olm (as used by Matrix) are pretty much bitwise identical. OMEMO for instance has been implemented using both libsignalprotocol and libolm.
The “incompatibility” comes from the fact that the payloads within the encryption are utterly different. It’s nothing to do with the encryption; you’d see the same thing with PGP.
How? The payload is completely defined under the base standard (RFC-4880), both the binary and ASCII protected versions. Otherwise what would be the point of a universally interoperable end to end encryption standard like OpenPGP?
> Deltachat also embodies some of the best parts of email encryption
It also embodies all of the metadata associated with it, which is still not encrypted.
> Open federation based on the popular and well known SMTP standard
and inefficient for messaging protocols, attachments are literally base64 encoded, every message includes a heap of metadata.
For transient communication you're better off installing a purpose built client with a purpose built protocol rather than trying to butcher email to do it.
This replaces the subject with "...", however if I send that email to someone who doesn't support that every email I send is going to have the same subject, making it difficult for them to easily find the "correct" email from a group. Protonmail for example doesn't support encrypted subjects.
With Matrix for example the only real metadata is room id, and flow of events (what Matrix ID is in what room). You can have rooms which are centralized to a specific server and then that's not an issue.
It will be interesting to see where P2P functionality leads in the future. https://matrix.org/blog/2021/05/06/introducing-the-pinecone-... I think with any long-term identity, it's going to be trackable to some extent, so that is up to specific threat model, whether you get worried about that.
With Signal and Sealed Sender https://signal.org/blog/sealed-sender/ even less metadata is available, although this centralized model is not without downsides such as being operated by a single entity.
> Yeah, the world definitely needs more "purpose built" protocols...
With protocols like olm, you also have concept of different devices, device keys, which can be revoked, and shifted without having to ditch all your keys at once. Cross signing means new devices can be "trusted".
Could you elaborate? My friends and I self-host mumble. I never really thought about it, but I kind of just assumed that this is as private as it gets. I didn't read through the mumble source code, but I just assumed it wouldn't be sending data anywhere else.
Edit: Their privacy page describes what data is sent where/when and it reads very privacy friendly to me: https://www.mumble.info/privacy/
Hmm, I guess that matters if you are using public servers. If you are running your own server, then it is a non-issue. I still think self hosted mumble is a great solution to the problem.
Looking through the privacyguides recommendations[0], I don't see a good alternative.
As long as everyone involved trusts the server operator, and the risk of the server being compromised is negligible, you would be right. I do think that removing it from the list here was the right call, as most people probably aren't going to self-host.
Unless your self hosting, it's not really private, as it doesn't use E2EE. If you're self hosting and restricting access, then any software could fit into the "private" category. Does that mean every self-hostable piece of software should be classified as "private"?
> As long as everyone involved trusts the server operator
This is the key point that is never mentioned. The software is mentioned but nothing about who is running it.
On a side note something we're looking very forward to is:
> Does that mean every self-hostable piece of software should be classified as "private"?
In my mind, as long as the self-hostable software isn't sending data back to some central server, yes? I guess we have different definitions, which is fine, this wasn't criticism of your list. I was just curious if you knew something I didn't.
> This is the key point that is never mentioned. The software is mentioned but nothing about who is running it.
It's interesting to have list of tools that can be self-hosted. My friends and I host mumble/irc/pastebin/img upload for our use. We've got it in a wireguard vpn, it works well. Finding out about other services that we can self-host and use is a always interesting. Although I can't really think of something we need at the moment.
There's nothing inherently wrong with a having lists like that to serve as a starting point to see what exists for your own research, the bigger issue is that it claims to be curated when it's more like a wiki.
It feels as if their project was ill-defined and grew too quickly, and they're not really sure exactly what it's supposed to be yet.
> starting point to see what exists for your own research, the bigger issue is that it claims to be curated when it's more like a wiki.
Problem is they also serve to repeat bad/out of date practices.
I always feel people who put together these lists are in a competition to list as many products and cover as many areas as possible, without evaluation.
I want to revise my claim of "nothing inherently wrong with a having lists like that".
This is not just a simple list of software with summaries, and after looking at it more it's worse than I thought. And you're right about propagating bad/out of date advice being a problem.
> I always feel people who put together these lists are in a competition to list as many products and cover as many areas as possible, without evaluation.
Unfortunately this seems to be the quickest and easiest way to get the most attention. Proper curation takes lots of effort, and is hard to get noticed by people who don't know any better.
> This is not just a simple list of software with summaries, and after looking at it more it's worse than I thought. And you're right about propagating bad/out of date advice being a problem.
Where we notice this effect is in our subreddit /r/privacyguides and /r/privacy, particularly in regard to browser extensions.
Fortunately through re-nforcement from the Arkenfox, Librewolf and our project we're starting to turn the tide away from "install 100 privacy browser extensions", so I think that's a positive benefit.
> Unfortunately this seems to be the quickest and easiest way to get the most attention. Proper curation takes lots of effort, and is hard to get noticed by people who don't know any better.
Pretty much why we're about quality over quantity with privacyguides.org. People have often asked "why don't we have a section for "this" or "that".
Each section requires research, and not just parroting what someone else says.
Why don't you submit a PR with a more up to date list? Or fork it? Lists don't get solved magically and a single person cannot keep up with all projects although your Privacy Guide seems to do a good job.
I've followes the specs a little and it seems to be implemented in a cautious manner. But haven't seen it being mentioned anywhere on privacy focussing lists, and I haven't heard of any audit of their codebase/protocol specs.
Do you know by chance anyone currently auditing and/or describing threat models etc for it?
Something which is clearly alpha-state isn't usable to regular users shouldn't have a "recommendation". Then you get sub optimal recommendations, listing some projects which are unmaintained etc.
With the cleanup at https://privacyguides.org, (since we split from PTIO) we've removed a lot of things, and gone down the part of actually providing guidance rather than "use this software to make you magically more private".
I think it's important to think privately, modify behavior rather than rely on technology to do it all for you.
Looking at this particular list there are some bad choices:
- LessPass: We explicitly removed deterministic password managers https://github.com/privacyguides/privacyguides.org/pull/323, https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...
- AndOTP: Uses PBKDF2 and a heap of rounds that is unbelievably slow when you have a number of OTPs. Aegis uses Argon, which doesn't have this problem, and we think it's code is developed by someone who is security conscientious.
- Qwant: https://github.com/privacyguides/privacyguides.org/pull/342#..., we removed due to "due to bad privacy policies data is collected and shared with third parties"
- Silence: Unmaintained, uses SS7 network, should never be recommended.
- Off-The-Record: Doesn't cover group chats or other side channels, such as status updates, VOIP. In general XMPP isn't particularly "privacy friendly" https://web.archive.org/web/20211215132539/https://infosec-h...
- PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication.
- Matrix + Riot client: Seriously, it's been "Element" for ages now, makes me think the author really isn't up to date with current events.
- Ricochet: Unmaintained, (2016) domain dead, Only supported .onion HSv2
- Tox + qTox: Developed wrong. They developed the software then decided to write the spec afterwards. There's also https://github.com/TokTok/c-toxcore/issues/426
- Mailfence: Last email I sent to them they don't use any kind of disk encryption
- CriptText, these things really don't help, they are walled, in that everyone has to be on a centralized service to get the benefit. E2EE that comes with web-apps can often be dangerous as it can change, have vulnerabilities introduced after an audit etc.
- TorBirdy: Unmaintained
- Mumble: Not really private
- Linphone: Not really private
- Rocket Chat: Experimental E2EE
- Browser Extensions: NO JUST NO. https://blog.privacyguides.org/2021/12/01/firefox-privacy-20... https://github.com/arkenfox/user.js/wiki/4.1-Extensions
- Video Platforms: These are not private
- RSS Clients: There are better options
- Mobile Operating Systems: Options without Verified Boot. NO. https://source.android.com/security/verifiedboot
- Linux recommendations: Those are also awful and don't have any threat model in mind.
I'm going to stop now, it's basically every bad thing that was ever on PTIO, that we removed. Basically there are terrible recommendations with a few good ones sprinkled in.
This list is *not* maintained!