Difference between revisions of "GNU/consensus/Secure Messaging Scoreboard"
(Get more consistent before going to sleep.) |
(Ricochet & Telegram) |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | == How Secure Can Messaging Be? == | ||
+ | |||
+ | Currently "secure messaging" is a loose term that [https://en.wikipedia.org/wiki/Secure_Messaging according to Wikipedia] is already achieved if your connection to your server or cloud is encrypted, regardless of the many intermediate nodes that could devise a way to intercept that communication and the server itself which most likely is obligated to provide surveillance interfaces by law or otherwise uses virtual machine technology or provides backdoor functionality in the hardware. That of course cannot be what ''we'' regard as Secure Messaging – software that protects the [https://en.wikipedia.org/wiki/Secrecy_of_correspondence Secrecy of Correspondence] as enshrined in most constitutions and human rights charters. With regard to the consensus developed in [[GNU/consensus/berlin-2013|Berlin 2013]] the criteria should be: | ||
+ | |||
+ | # End-to-end encryption | ||
+ | # Perfect Forward Secrecy | ||
+ | # Social graph and transmission pattern obfuscation (= Protection of Metadata or simply "Anonymity") | ||
+ | # Self determined data storage (= No cleartext data on servers) | ||
+ | # No software backdoors (= Free software or at least open source) | ||
+ | |||
+ | Unfortunately there are very few technologies capable of providing this mix of requirements. | ||
+ | |||
== Motivation == | == Motivation == | ||
− | The Electronic Frontier Foundation published a [https://www.eff.org/secure-messaging-scorecard Secure Messaging | + | The Electronic Frontier Foundation published a ''[https://www.eff.org/secure-messaging-scorecard Secure Messaging Scorecard]'' as the first phase of a promising campaign about Secure and Usable Cryptography. That is a good first step, but ''in the wrong direction'': it fails to take into account NSA blanket surveillance programs such as PRISM, as if the plethora of new spying information could cover the scandal of NSA corporate partners. '''The bulk collection of communication metadata is a threat to democracy,''' as it undermines several basic civil liberties such as the [https://en.wikipedia.org/wiki/Freedom_of_assembly Freedom of Assembly]. While encryption is about the thoughts being shared, metadata is about the actual people. The EFF scorecard does not even mention metadata protection and none of the listed solutions are truly capable of that. |
+ | |||
+ | Moreover, it provides a false sense of legitimacy to proprietary software that is audited independently by, wait for it: "an internal security team", while unticking most of the free software for not having received any formal security audit. This incentivizes companies into auditing proprietary software that users should not use in the first place (since most companies are by US law required to introduce surveillance backdoors while publicly claiming the contrary) rather than promoting the auditing of free software, the only that can by its transparency provide credible privacy. | ||
+ | |||
+ | When confronted with this, the EFF tries to minimize the situation--they have their reasons, explained at [https://www.eff.org/deeplinks/2014/11/what-makes-good-security-audit What Makes a Good Security Audit], and yes counting on ''extraordinaire'' individuals to do the right thing ''should'' be enough (unless they move on, etc.). | ||
+ | |||
+ | The scorecard can be useful for professionals who understand the implications, but to the casual user it is not at all clear how '''the availability of audits is completely pointless if the availability of source code and independently built executables is not given.''' In that sense the scorecard puts ''everyone and everything in the same bag, flattening the landscape of messaging solutions'' and ultimately achieves the unpleasant goal of whitewashing proprietary softwares which by design should not even exist as they try to provide constitutionally relevant functionality they cannot possibly fulfil such as secure private messaging. The supreme courts of the world should declare such software illegal. | ||
− | + | Our approach will therefore focus on building upon existing community work, and focusing on threat models and core features to discriminate among messaging solutions. We understand the objective of the EFF's Secure Messaging Scorecard, and respect their choice of starting from where the users are. But we disagree on how to present such solutions. Hopefully our work will prove useful to the EFF at some point. | |
− | We'll be using | + | We'll be using the following sources for our scoreboard: |
# the in-depth analysis of [http://secushare.org/comparison Secushare Capability Comparison]. | # the in-depth analysis of [http://secushare.org/comparison Secushare Capability Comparison]. | ||
# the rich and community-maintained catalogue of alternative solutions at [https://prism-break.org/ PRISM ⚡ Break]. | # the rich and community-maintained catalogue of alternative solutions at [https://prism-break.org/ PRISM ⚡ Break]. | ||
+ | |||
+ | See also the related [http://youbroketheinternet.org/secure-email Comparison of Secure Mail] technologies. | ||
== Which apps and tools actually keep your messages safe? == | == Which apps and tools actually keep your messages safe? == | ||
Line 22: | Line 42: | ||
=== Criteria === | === Criteria === | ||
− | One important thing you need to remember at all times: this is not a | + | One important thing you need to remember at all times: this is not a restaurant order, where you pick numbers and receive food. Those criteria are there to help you discriminate tools according to your needs, but your wants will get the last supper if you let them. Choose convenience or the cake with the cherry on top at your own risk. |
+ | |||
+ | === Threat model === | ||
+ | |||
+ | Our goal is whatever it needs to impede bulk surveillance. Our solutions probably cannot protect you if you are specifically targeted by authorities, but we want to keep you out of the unreasonable dragnet which is currently threatening the ability of entire populations to enact their basic rights. Most technologies being advertised by best-intended experts and media, let alone companies, do not actually fulfil the necessary requirements. | ||
+ | |||
+ | <!-- Hmmm.. is this actually helpful? | ||
; Risk | ; Risk | ||
Line 37: | Line 63: | ||
Technology is a great debate. There's obviously broken tech, there's somewhat naïve tech that wants to be strong, and then, there's great tech. The latter often comes with a terrible bug: it does only a number of things very well, and probably not much else. That's because to make great technology, a lot of work is required. It's not just putting a nice button here, and a responsive design there. There are shitloads of complex issues that may be solved, and some that won't. As for security, technology is mostly a matter of trade-offs. | Technology is a great debate. There's obviously broken tech, there's somewhat naïve tech that wants to be strong, and then, there's great tech. The latter often comes with a terrible bug: it does only a number of things very well, and probably not much else. That's because to make great technology, a lot of work is required. It's not just putting a nice button here, and a responsive design there. There are shitloads of complex issues that may be solved, and some that won't. As for security, technology is mostly a matter of trade-offs. | ||
+ | --> | ||
=== Legend === | === Legend === | ||
Line 46: | Line 73: | ||
! colspan="2" | Acronym | ! colspan="2" | Acronym | ||
! Description | ! Description | ||
− | ! Correspondence with EFF's SM | + | ! Correspondence with EFF's SM Scorecard |
|- | |- | ||
! SN | ! SN | ||
Line 59: | Line 86: | ||
|- | |- | ||
! UX | ! UX | ||
− | | Whether it's easy to use or requires skillz (easy, medium, hard) | + | ! Usability |
+ | | Whether it's easy to use or requires skillz (easy, medium, hard). | ||
+ | | ? | ||
+ | |- | ||
+ | ! MD | ||
+ | ! Metadata protection (Anonymity) | ||
+ | | Whether the fact that you are having secret conversations is openly visible or properly protected. Whether your social graph can be harvested or not. | ||
+ | | NA | ||
|- | |- | ||
! CV | ! CV | ||
Line 82: | Line 116: | ||
|} | |} | ||
− | We left | + | We left EFF's "''Encrypt in transit?''" column out because '''''any application that does not use any encryption at all is compromised''''', and not part of the table. |
− | We left | + | We left out EFF's "''Encrypted so the provider can't read it?''" column as well, because '''''any application that does not use end-to-end encryption is a serious threat''''', and considered [[#Compromised]]. |
Here we go... | Here we go... | ||
Line 124: | Line 158: | ||
! ST | ! ST | ||
! UX | ! UX | ||
+ | ! MD | ||
! CV | ! CV | ||
! FS | ! FS | ||
Line 131: | Line 166: | ||
| BlackBerry Protected | | BlackBerry Protected | ||
| Proprietary platform (SW and HW) | | Proprietary platform (SW and HW) | ||
− | | easy || Yes || No || No || Yes || No | + | | easy || No || Yes || No || No || Yes || No |
|- | |- | ||
| ChatSecure+Orbot | | ChatSecure+Orbot | ||
| GPLv3+ XMPP+OTR for Android | | GPLv3+ XMPP+OTR for Android | ||
− | | easy || Yes || Yes || Yes || Yes || Yes | + | | easy || Partial<ref>In [https://moderncrypto.org/mail-archive/messaging/2014/001083.html 001083] a developer of ChatSecure explains how Orbot (the [[Tor]] implementation for Android) can be employed to reduce metadata correlation, yet the problem of registering accounts on servers [https://moderncrypto.org/mail-archive/messaging/2014/001086.html persists].</ref> || Yes || Yes || Yes || Yes || Yes |
|- | |- | ||
| Cryptocat | | Cryptocat | ||
| AGPLv3+ Web browser extension | | AGPLv3+ Web browser extension | ||
− | | easy || Yes || Yes || Yes || Yes || Yes | + | | easy || No || Yes || Yes || Yes || Yes || Yes |
|- | |- | ||
| Jitsi + OStel | | Jitsi + OStel | ||
| LGPL application | | LGPL application | ||
− | | medium || Yes || Yes || No || Yes || No | + | | medium || No || Yes || Yes || No || Yes || No |
|- | |- | ||
| Mailvelope | | Mailvelope | ||
| GPLv3+ Web browser extension | | GPLv3+ Web browser extension | ||
− | | easy || Yes || Yes || No || Yes || Yes | + | | easy || No || Yes || Yes || No || Yes || Yes |
|- | |- | ||
| [https://otr.im/ Off The Record] (OTR) | | [https://otr.im/ Off The Record] (OTR) | ||
| <abbr title="End-to-End Encryption">E2EE</abbr> | | <abbr title="End-to-End Encryption">E2EE</abbr> | ||
− | | | + | |- |
+ | | [https://f-droid.org/repository/browse/?fdcategory=Internet&fdid=org.telegram.messenger&fdpage=5 Telegram-FOSS] | ||
+ | | GPLv2 fork of the Telegram client | easy || No || Yes || Maybe || Maybe || Yes || Huh? | | ||
|} | |} | ||
+ | |||
+ | === Demoted === | ||
+ | |||
+ | '''Goldbug''' was demoted from '''OK''' messaging systems. Previous [https://www.mail-archive.com/cypherpunks@cpunks.org/msg05277.html investigation by gargramp on the cypherpunks mailing-list] revealed obscure origins and questionable ethics for this software. Golbug is a communication system for desktops using opportunistic routing over P2P. It lacks anonymity features and is not recommended at this point. | ||
== OK == | == OK == | ||
Line 174: | Line 215: | ||
| Required | | Required | ||
| No one else than you and your correspondent can read your conversation. | | No one else than you and your correspondent can read your conversation. | ||
+ | |- style="background-color: rgba(0,255,0,0.25);" | ||
+ | ! style="text-align:left" | Metadata Protection | ||
+ | | Required | ||
+ | | The social graph of people communicating among each other is protected from inspection (= digital freedom of assembly). | ||
|- style="background-color: rgba(0,255,0,0.25);" | |- style="background-color: rgba(0,255,0,0.25);" | ||
! style="text-align:left" | Authentication | ! style="text-align:left" | Authentication | ||
Line 186: | Line 231: | ||
| Optional | | Optional | ||
| Messages are guaranteed to be authentic during the conversation, but can be forged afterwards. | | Messages are guaranteed to be authentic during the conversation, but can be forged afterwards. | ||
+ | |- style="background-color: rgba(255,50,0,0.25);" | ||
+ | ! style="text-align:left" | Instant | ||
+ | | Optional | ||
+ | | Messages are delivered to the recipient in near real-time. This frequently reduces your metadata protection, so it's not necessarily a worthwhile aim. | ||
|} | |} | ||
{| class="wikitable sortable" width="85%" style="padding: 0.25em" | {| class="wikitable sortable" width="85%" style="padding: 0.25em" | ||
− | |+ Working Messaging Systems | + | |+ Mostly Working Messaging Systems |
|- | |- | ||
! rowspan="2" | System Name | ! rowspan="2" | System Name | ||
Line 199: | Line 248: | ||
! Mobile | ! Mobile | ||
|- | |- | ||
− | ! style="text-align:left" | [[ | + | ! style="text-align:left" | [[Bitmessage]] |
− | | | + | | Mail system based on blockchain broadcasting |
− | | | + | | Asynchronous conversation and forums |
+ | | Desktop | ||
+ | | No | ||
+ | |- | ||
+ | ! style="text-align:left" | [[Briar]] | ||
+ | | Mail system based on opportunistic encounters | ||
+ | | Asynchronous conversation and forums | ||
+ | | Prototypical | ||
+ | | Prototypical | ||
+ | |- | ||
+ | ! style="text-align:left" | Cables over Tor or I2P | ||
+ | | Mail system using hidden services on either Tor or I2P | ||
+ | | Asynchronous conversation | ||
| GNU systems | | GNU systems | ||
| No | | No | ||
|- | |- | ||
− | ! style="text-align:left" | [[ | + | ! style="text-align:left" | Freemail over [[Freenet]] |
− | | | + | | Mail system based on distributed storage in an anonymity network |
− | | File | + | | File storage, Asynchronous conversation |
| GNU systems | | GNU systems | ||
| No | | No | ||
|- | |- | ||
− | ! style="text-align:left" | [[I2P]] | + | ! style="text-align:left" | [[I2P]]-Bote |
− | | Anonymity Network | + | | Mail system using a DHT on the I2P Anonymity Network |
− | | | + | | Asynchronous conversation |
| Desktop | | Desktop | ||
| Android | | Android | ||
|- | |- | ||
− | ! style="text-align:left" | [[RetroShare]] | + | ! style="text-align:left" | [[RetroShare]] over [[Tor]] |
− | | | + | | Social communications tool on an anonymity network |
− | | | + | | Serverless synchronous and asynchronous conversations and forums |
| Desktop | | Desktop | ||
| No | | No | ||
|- | |- | ||
− | ! style="text-align:left" | [[Tor]] | + | ! style="text-align:left" | [[Ricochet]] over [[Tor]] |
− | | | + | | Instant Messenger on an anonymity network |
− | | | + | | Serverless synchronous conversations only, end-to-end encrypted and forward secure |
| Desktop | | Desktop | ||
− | | | + | | No |
+ | |- | ||
+ | ! style="text-align:left" | [[secushare]] over [[GNUnet]] | ||
+ | | Social communications tool on an alternative Internet routing stack | ||
+ | | Anything social, in near real-time if necessary | ||
+ | | Prototypical | ||
+ | | No | ||
+ | |- | ||
+ | ! style="text-align:left" | [[Tox]] over [[Tor]] | ||
+ | | Social communications tool on an anonymity network | ||
+ | | Video conferencing | ||
+ | | Yes | ||
+ | | Yes | ||
|} | |} | ||
<references/> | <references/> |
Latest revision as of 14:58, 29 October 2015
Contents
How Secure Can Messaging Be?
Currently "secure messaging" is a loose term that according to Wikipedia is already achieved if your connection to your server or cloud is encrypted, regardless of the many intermediate nodes that could devise a way to intercept that communication and the server itself which most likely is obligated to provide surveillance interfaces by law or otherwise uses virtual machine technology or provides backdoor functionality in the hardware. That of course cannot be what we regard as Secure Messaging – software that protects the Secrecy of Correspondence as enshrined in most constitutions and human rights charters. With regard to the consensus developed in Berlin 2013 the criteria should be:
- End-to-end encryption
- Perfect Forward Secrecy
- Social graph and transmission pattern obfuscation (= Protection of Metadata or simply "Anonymity")
- Self determined data storage (= No cleartext data on servers)
- No software backdoors (= Free software or at least open source)
Unfortunately there are very few technologies capable of providing this mix of requirements.
Motivation
The Electronic Frontier Foundation published a Secure Messaging Scorecard as the first phase of a promising campaign about Secure and Usable Cryptography. That is a good first step, but in the wrong direction: it fails to take into account NSA blanket surveillance programs such as PRISM, as if the plethora of new spying information could cover the scandal of NSA corporate partners. The bulk collection of communication metadata is a threat to democracy, as it undermines several basic civil liberties such as the Freedom of Assembly. While encryption is about the thoughts being shared, metadata is about the actual people. The EFF scorecard does not even mention metadata protection and none of the listed solutions are truly capable of that.
Moreover, it provides a false sense of legitimacy to proprietary software that is audited independently by, wait for it: "an internal security team", while unticking most of the free software for not having received any formal security audit. This incentivizes companies into auditing proprietary software that users should not use in the first place (since most companies are by US law required to introduce surveillance backdoors while publicly claiming the contrary) rather than promoting the auditing of free software, the only that can by its transparency provide credible privacy.
When confronted with this, the EFF tries to minimize the situation--they have their reasons, explained at What Makes a Good Security Audit, and yes counting on extraordinaire individuals to do the right thing should be enough (unless they move on, etc.).
The scorecard can be useful for professionals who understand the implications, but to the casual user it is not at all clear how the availability of audits is completely pointless if the availability of source code and independently built executables is not given. In that sense the scorecard puts everyone and everything in the same bag, flattening the landscape of messaging solutions and ultimately achieves the unpleasant goal of whitewashing proprietary softwares which by design should not even exist as they try to provide constitutionally relevant functionality they cannot possibly fulfil such as secure private messaging. The supreme courts of the world should declare such software illegal.
Our approach will therefore focus on building upon existing community work, and focusing on threat models and core features to discriminate among messaging solutions. We understand the objective of the EFF's Secure Messaging Scorecard, and respect their choice of starting from where the users are. But we disagree on how to present such solutions. Hopefully our work will prove useful to the EFF at some point.
We'll be using the following sources for our scoreboard:
- the in-depth analysis of Secushare Capability Comparison.
- the rich and community-maintained catalogue of alternative solutions at PRISM ⚡ Break.
See also the related Comparison of Secure Mail technologies.
Which apps and tools actually keep your messages safe?
Quoting from EFF's scoreboard: In the face of widespread Internet surveillance, we need a secure and practical means of talking to each other from our phones and computers. Many companies offer “secure messaging” products—but are these systems actually secure? No, they are not.
In order to keep things simple, we consider two categories: #Compromised and #Broken (#OK is an extra one to show upcoming or geeky alternatives):
- COMPROMISED messaging systems are proprietary and "open" solutions without oversight on the software code, the system's operation, or presenting fatal flaws in their architecture. This category is a simple list of solutions that should be avoided because they won't deliver what they promise. If we have time and interest, we can describe why it is so more precisely, although most of them are documented elsewhere.
- BROKEN messaging systems are (mostly) free software solutions that can be fixed to provide an acceptable level of privacy, and those are compared for the kind of threats they can thwart, and the ones they cannot. This can be useful for users who want to defend against specific types of threats, and for developers to choose what direction to take depending on the objectives set forth among their communities.
- OK messaging systems are free software solutions that are designed with privacy in mind, but also with thwarting global surveillance as a primary objective. That means any two interlocutors using these systems could not be matched by an all-seeing-eye watching both sides of the communication, and doing black magic counting packets and monitoring flows.
Criteria
One important thing you need to remember at all times: this is not a restaurant order, where you pick numbers and receive food. Those criteria are there to help you discriminate tools according to your needs, but your wants will get the last supper if you let them. Choose convenience or the cake with the cherry on top at your own risk.
Threat model
Our goal is whatever it needs to impede bulk surveillance. Our solutions probably cannot protect you if you are specifically targeted by authorities, but we want to keep you out of the unreasonable dragnet which is currently threatening the ability of entire populations to enact their basic rights. Most technologies being advertised by best-intended experts and media, let alone companies, do not actually fulfil the necessary requirements.
Legend
Each Line has the following columns:
Acronym | Description | Correspondence with EFF's SM Scorecard | |
---|---|---|---|
SN | System Name | The name of the software, application, or service considered. | NA |
ST | System Type | Whether it's a proprietary or free software, a phone application, a web service, or else. | NA (Is the code open to independent review?) |
UX | Usability | Whether it's easy to use or requires skillz (easy, medium, hard). | ? |
MD | Metadata protection (Anonymity) | Whether the fact that you are having secret conversations is openly visible or properly protected. Whether your social graph can be harvested or not. | NA |
CV | Contact Verification | Whether you can verify the identity of your interlocutor, and ensure you are indeed talking to the right person. | Can you verify contact's identity |
FS | Forward Secrecy | Whether past communications are protected if the encryption key is compromised | Are past comms secure if your keys are stolen? |
DD | Documented Design | Whether the security design is properly documented and available. | Is security design properly documented? |
SA | Security Audit | Whether the code has been audited for security issues recently (linked to the report if it's public) | Has there been any recent code audit? |
We left EFF's "Encrypt in transit?" column out because any application that does not use any encryption at all is compromised, and not part of the table. We left out EFF's "Encrypted so the provider can't read it?" column as well, because any application that does not use end-to-end encryption is a serious threat, and considered #Compromised.
Here we go...
Compromised
There is one simple criterion for considering a compromised messaging system: it's made by a company that it depends on, and you don't know how it works. Security by obscurity is as good as you can't find the switch. Then, you're caught naked in the bright light.
- Apple Facetime
- malware company and PRISM target
- Apple iMessage
- malware company and PRISM target
- AOL AIM
- Legacy proprietary software from AOL, a PRISM target
- BlackBerry Messenger
- Proprietary software and hardware from Research in Motion
- Ebuddy XMS
- Adware: does not use end-to-end encryption
- Facebook Chat
- Spyware company and PRISM target. Does not use end-to-end encryption
- Google Hangout "off the record"
- Spyware company and PRISM target. Does not use end-to-end encryption, not to be confused with OTR
- Hushmail
- Good reputation. So what? Nixon had a good reputation too.
- iPGMail
- Proprietary PGP app for iOS. Great idea, that's better than nothing at all. Keep in mind that by putting your GPG key on your iThing, you're compromising it.
- Kik
- Adware: does not use end-to-end encryption. 150 million products love Kik.
- Mxit
- From the EFF's SMS: does not use any encryption in transit
- From the EFF's SMS: does not use any encryption in transit
Broken
SN | ST | UX | MD | CV | FS | DD | SA | |
---|---|---|---|---|---|---|---|---|
BlackBerry Protected | Proprietary platform (SW and HW) | easy | No | Yes | No | No | Yes | No |
ChatSecure+Orbot | GPLv3+ XMPP+OTR for Android | easy | Partial[1] | Yes | Yes | Yes | Yes | Yes |
Cryptocat | AGPLv3+ Web browser extension | easy | No | Yes | Yes | Yes | Yes | Yes |
Jitsi + OStel | LGPL application | medium | No | Yes | Yes | No | Yes | No |
Mailvelope | GPLv3+ Web browser extension | easy | No | Yes | Yes | No | Yes | Yes |
Off The Record (OTR) | E2EE | |||||||
Telegram-FOSS | easy | No | Yes | Maybe | Maybe | Yes |
Demoted
Goldbug was demoted from OK messaging systems. Previous investigation by gargramp on the cypherpunks mailing-list revealed obscure origins and questionable ethics for this software. Golbug is a communication system for desktops using opportunistic routing over P2P. It lacks anonymity features and is not recommended at this point.
OK
Woohoo! All is not bleak on Planet Earth! They are some people interested in addressing our electronic communications issues. Some of them actually think straight, long term, and are willing to find solutions that will last and actually improve our human condition beyond sharing cat pictures. No, there's nothing there yet. When we have a widely deployed 1.0, let's do that.
All OK messaging systems share the following features[2]:
Feature | Class | Description |
---|---|---|
Free Software | Required | A free license ensures the code is accessible for use, review, sharing, and modification. |
End-to-End Encryption | Required | No one else than you and your correspondent can read your conversation. |
Metadata Protection | Required | The social graph of people communicating among each other is protected from inspection (= digital freedom of assembly). |
Authentication | Required | You are assured your correspondent is always the same person. |
Forward Secrecy | Required | If you lose control of your private keys, no previous conversation is compromised. |
Deniability | Optional | Messages are guaranteed to be authentic during the conversation, but can be forged afterwards. |
Instant | Optional | Messages are delivered to the recipient in near real-time. This frequently reduces your metadata protection, so it's not necessarily a worthwhile aim. |
System Name | Type | Primary Use | Availability | |
---|---|---|---|---|
Desktop | Mobile | |||
Bitmessage | Mail system based on blockchain broadcasting | Asynchronous conversation and forums | Desktop | No |
Briar | Mail system based on opportunistic encounters | Asynchronous conversation and forums | Prototypical | Prototypical |
Cables over Tor or I2P | Mail system using hidden services on either Tor or I2P | Asynchronous conversation | GNU systems | No |
Freemail over Freenet | Mail system based on distributed storage in an anonymity network | File storage, Asynchronous conversation | GNU systems | No |
I2P-Bote | Mail system using a DHT on the I2P Anonymity Network | Asynchronous conversation | Desktop | Android |
RetroShare over Tor | Social communications tool on an anonymity network | Serverless synchronous and asynchronous conversations and forums | Desktop | No |
Ricochet over Tor | Instant Messenger on an anonymity network | Serverless synchronous conversations only, end-to-end encrypted and forward secure | Desktop | No |
secushare over GNUnet | Social communications tool on an alternative Internet routing stack | Anything social, in near real-time if necessary | Prototypical | No |
Tox over Tor | Social communications tool on an anonymity network | Video conferencing | Yes | Yes |