Requirement			SVPN
Link Encryption	✓	⊕	⊕	⊕	✓	✓	✓	✓	✓	✓
Forward Secrecy	⊝	⊝	⊙	⊝	⊕	✓	⊝	✓	✓	⊕
E2E Encryption	––	✗	⊙	––	––	✓	✓	✓	⊙	✓
No Strangers	––	✗	✗	✗	✖	––	✓	✓	✓	✓
Secret Friends	––	––	⊕	––	✖	––	✗	✓	✓	⊕
Untraceability	––	––	––	––	✖	⊕	––	⊕	⊕	⊕
Unobservability	––	––	⊙	––	✖	⊕	––	⊕	✓	✓
Post Deniability	✗	––	––	––	✗	✗	✗	⊝	⊙	⊙
Lightweight	✓	✓	⊙	––	✓	✗	⊝	⊕	✗	⊕
Group Encryption	––	✗	––	––	✗	✗	✓	✓	⊙	⊕
Distribution	✓	✗	––	––	––	⊕	⊕	⊕	⊕	⊕
Relay Backbone	✓	⊝	⊝	⊝	⊕	✓	⊝	⊝	⊝	⊕
Usability	⊕	✗	⊙	⊕	⊕	✓	✗	✗	⊙	⊝
Features	✓	✓	✗	✓	✓	⊕	⊝	⊝	⊝	⊝

= Faceboogle = Most web-based social network services including Facebook, Human Connection, Google+ etc;

= XMPP-based open source federation projects such as BuddyCloud, movim

SVPN = SocialVPN, an XMPP-based tool that establishes virtual private networks among friends;

= Federated Social Web projects like Mastodon, Pleroma, Diaspora, Friendica and several more;

= isolated server-based installations operated in a trustworthy manner using a Tor onion service;

= Secure Scuttlebutt over Tor;

= RetroShare;

= RetroShare over Tor;

= Nightweb over I2P.

= stands for secushare's current status.

Link Encryption: Without it, anyone operating your DSL router, local network, your Internet connection, the Internet backbone or anyone hacking into any of the involved machines can read in on your activity. You can activate this with Facebook by using the https: prefix, or, even better, by using the Tor service at facebookcorewwwi.onion or m.facebookcorewwwi.onion (without Javascript). Federated systems use link encryption also in their interserver interactions, that unfortunately is frequently an easy target for man-in-the-middle attacks) given the difficulty to automate certificate checks.

Forward Secrecy: Traffic between endpoints cannot be decrypted at some later point in time if access to the private key was gained. Recently this has become the default behaviour of most TLS/SSL links, so it even applies to Facebook if enabled. Of course, since the data on Facebook exists in the clear and we now know of PRISM, that is rather pointless when using Facebook. Same situation with any federated social web or XMPP technology. Tor and GNUnet (as used by secushare) provide for end-to-end forward secrecy additionally to the link layer. DSNP, too, seems to do end-to-end forward secrecy. Some tools may be affected by the logjam attack.

E2E Encryption goes seamlessly from one person to the other person, end-to-end as provided by tools such as PGP, whereas Link level Encryption enables in-between nodes to access the content, which is quite unsatisfactory given that these in-between nodes are unlikely to maintain secure.

No Strangers: Most offerings require you to trust a company and the jurisdictions it operates in and to give it most or all of your data exchanged with friends. In the case of Diaspora and XMPP-based social networks you can choose to operate your own node or server. Still, as long as some of your friends use the Diaspora web interface, large parts of your data become visible to the operators of the web offering, while with XMPP, some of your friends may be using servers that spy on you. Consider also the virtual machine safety problem discussed in our 2011 paper. In any of these federation configurations you cannot expect your social interactions to be safe from bulk collection by global surveillance agencies.

Secret Friends: The additional privacy of keeping the information of who is your friend secret from companies and other complete strangers. You only want your friends to know, and maybe isolate some groups of friends from each other.

Unobservability: Traffic does not allow an observer to understand what kind of content is being sent.

Untraceability: Traffic does not allow an observer to understand who is talking to whom (also known as metadata protection). Untraceability and Unobservability may be considered pointless if you are trusting strangers in the first place. In the case of Diaspora and XMPP direct encrypted point to point connections are used that allow for analysis of who may be talking to whom and guessing on contents of messages. DSNP intends to omit TLS in interserver traffic for scalability reasons, with the session encryption that it employs it isn't however completely obvious who is talking to whom, only how much. Edward Snowden insistently points out that metadata is what we should protect the most. We think it attacks the foundations of democracy if the Freedom of Association is digitally foiled and the ability of developing new democratic thinking and consensus is threatened by manipulation and outside control.

Post Deniability: Do we like that things we said in a comment or status update can be used against us? Well, in the case of insecure systems like Facebook we could try to claim somebody else hacked our account. Or maybe we can delete our mistake before independent testimonies see it. Then again, Utah and KARMA POLICE are always there ready to haunt us. Some more evolved technologies make this worse, in particular DSNP that signs every stupid comment with our private keys. Still we can claim somebody broke into our computers and snooped our passwords.

Lightweight: To be of maximum use the technology implementing such essential jobs should be a part of the operating system or close to it, not require large language engines such as PHP or Ruby and also not require an entire web browser to be running all the time. This would make it viable for such a technology to be provided out of the box with certain operating systems on computers but also on smartphones and other gizmos. Skype probably fulfills this requirement, although it may not feel that way. Java is a special case - it qualifies as a large language engine, but if the hosting OS has chosen it as the sandboxing platform for its apps, then one more Java app doesn't make the difference. Thus some Java tools can be considered lightweight on Android but not on Linux. DSNP has a routing backend written in C++ but the social logic is currently implemented in PHP. Nightweb is web-based. By lightweight we also mean not having heavy duty obligations towards the network like needing to operate a DHT instead of using it remotely. This is the case with I2P and also with RetroShare unless operated over Tor.

Group Encryption: The strategy of sharing a group encryption key with all participants of a distribution context and occasionally refresh it, especially when a person leaves the group (or unfriends a person). This makes encrypted group messaging multicastable and generally more scalable, it also provides for forward secrecy if done correctly. DSNP implements this with temporary key pairs. SILC provides this kind of service with either a server- or client-based strategy. Some scientists have been considering more complex methods, such as mpotr, n1sec or how Matrix handles it. We think, these approaches are over-engineered, trying to make all participants equal in a chatroom. In secushare, pubsubs and chatrooms are owned by someone, and it is okay that the encryption is controlled by that owner. If you don't trust them, why are you in their chatroom? Still, advanced schemes can be added later, if anybody cares to.

Distribution: Efficient delivery to a large number of recipients. Cloud technology uses multicast-like distribution trees internally between its nodes, whereas multicasting and XMPP is a long sad story. Since 2009 there is XEP 0253, but it is rarely used. See XMPP for details. Unfortunately the ability to efficiently distribute data is frequently seen as a business opportunity, leaving the free world on a slippery slope towards the more efficient and thus user-responsive cloud technology.

Relay Backbone: Servers are nasty if they know everything about you, but relays are nice when they know nothing, but do everything for you. The Tor relay network is a fine example of how much it makes a difference if the service doesn't depend entirely on the peer-to-peer contribution of the end users from home. Commercial offerings usually have redundant servers or "clouds" of virtual servers while federation style systems depend on certain specific server nodes to be up or redundantly set-up. secushare would use relays in your social neighborhood and in a Tor-like infrastructure. RetroShare allows nodes to be run as servers, but not in an agnostic way, so they are likely to have social secrets unencrypted in unsafe memory.

Usability: Web-based offerings require users to maintain a password safely. Federation-based systems additionally require you to deal with domain names and server addresses. XMPP has the additional problem of not supporting encrypted contents and cryptographic authentication by default. Neither RetroShare nor secushare have any of these problems - in exchange RetroShare currently sports deployment challenges in either getting it to work with Tor or in fixing up the black- and whitelists for the insecure distributed hashtable, a problem which is too hard for most users to even understand. Since RetroShare's DHT is probably impossible to fix we hope that future versions will come with a more natural out-of-the-box Tor integration experience. In the Tor configuration, RetroShare uses Tor's DHT, which is also broken, but not as bad.

Features: Does the offering actually provide social network services or is it just primarily a social framework that needs further work?

How Secure Scuttlebutt and Manyverse compares to secushare is explained in further detail on the answers#scuttlebutt page. What about projects like Human Connection which detract so much attention from important projects? Well, it has a centralized architecture based on nodejs, therefore not terribly scalable. It will need a lot of money and can only serve serious numbers of people when run in a cloud. Therefore it puts a few people in charge of having complete access to the databases. In essence it is a redo of Facebook, even if well-intended, open-sourced and presumably non-commercial. There are dozens of projects of this kind. We were asked to express an opinion on this one, which, despite its appealing communication, does not appear to be of much use to society. Also, when it comes to voting you can no longer leave out liquid democracy without a good reason, these days.

BEST CURRENT PRACTICE RECOMMENDATION: Despite the usability criticism above, RetroShare over Tor is probably the least bad metadata-preserving social network experience available currently. If the functionality it offers is too rudimentary for you, the safest bet for privacy unfortunately still is to use or install a Silo open source project where all data is in the clear on the web server. Some silo social services are getting popular on the Tor network as we speak. This means you need a very high degree of trust in the administrators and even more in the physical placement of the servers. Servers in data centers may already be integrated in the XKEYSCORE indexing program without anyone, not even the systems administrator of the project, taking notice. We discussed that in the 2011 paper. Federation networks (FSW, XMPP) likely make it worse as all the private data is sent to even more servers, raising the likelihood of falling into the wrong hands. Secure Scuttlebutt is a fine choice if you're just looking for a distributed Twitter replacement. Twister could be another interesting pick for the same purpose. We still need to look at it, so it isn't listed in the table.

Requirement					I2P					CJD
Link Encryption	⊕	⊕	✓	✓	✓	✓	✓	✓	✓	✓
Forward Secrecy	✗	✗	✓	⊙	⊙	✓	✓	⊝	⊕	✗
No Strangers	––	⊕	✓	⊕	✓	✓	✓	✓	✓	⊕
Secret Friends	––	––	✓	⊕	✓	✓	✓	✗	⊕	––
Untraceability	––	––	✓	⊙	⊝	✓	✓	––	⊕	––
Unobservability	––	––	✓	⊙	✓	✓	✓	––	✓	––
Effectivity	✗	✓	⊕	⊕	––	✓	✓	⊝	⊕	✗
Lightweight	––	✓	⊕	⊕	––	⊕	⊕	✗	✓	✓
Group Encryption	✗	✗	⊙	⊙	⊙	––	✓	✓	⊕	––
Distribution	––	––	✓	✓	✗	––	✗	⊕	✓	✗

= E-mail over SMTP with TLS and PGP or S/MIME;

= GNUnet's GAP-based file sharing service;

= Tribler;

I2P = BitTorrent over I2P;

= Tor Onion Service using onionshare, Nextcloud or similar tools;

= RetroShare over Tor Onion Services;

= Tools making direct connections between friends such as RetroShare, Jami and Tox;

CJD = FTP or HTTP over cjdns or yggdrasil.

Link Encryption: Without it, your file transfers can be observed, recorded and even modified in transit. TLS between SMTP servers can be enforced for email, but it isn't transparent to the end user when an email was transferred safely or when it wasn't. Files could be transmitted wrapped into PGP, but then the user and her mail software have to actually do it. In XMPP, direct file transfers are usually not encrypted. When sent via servers, basic wire encryption may be in use on the links, but the servers still receive the files unencrypted. Not talking of the inefficient encoding. PGP could be applied to XMPP file transfers, too. See BitTorrent protocol encryption about BitTorrent's very basic encryption features.

Forward Secrecy: Again this is usually only given if standard TLS implementations are in use, and only on the link from node to node. PGP encrypts end-to-end, but does not provide forward secrecy - in fact it tends to be a forever proof of your deeds online. Traffic in the cjdns network is only forward secret from malevolent cjdns nodes if the application protocol offers it (https for example). Yggdrasil however does offer forward secrecy in its protocol.

No Strangers: BitTorrent usually requires a directory service to connect its users, which is usually run by a stranger on a server. But it doesn't have to be that way.

Untraceability: Should you decide to trust Microsoft or Skype (which in the light of PRISM isn't very reasonable, but this document was originally written before Snowden), observers may still be able to find out who you are sending messages to. Statistical guessing of file transfer contents is probably feasible, too. When using I2P, consider that so-called eepsites are easy to de-anonymize. The GAP protocol makes GNUnet the best choice for censorship-resistant anonymous file sharing. Tribler has developed a UDP variant of Tor to plug into the distribution torrents, but we don't know if that is actually deployed among the thousands of current users.

Effectivity vs. Overhead: secushare may feel less heavy on people's devices than traditional file sharing and P2P applications as it grants resources to people in your extended social network rather than random strangers. Therefore there is better motivation to contribute backbone relay resources. Many tools using DHT technology have no adequate protection against sybil attacks, therefore sender or recipient could be isolated from the network by an attacker.

Distribution: Although optimized for file sharing, BitTorrent creates a kind of multicast distribution tree. Hence its extreme success and popularity. Several tools such as Tribler, GNUnet and Maidsafe mimick this replication on-demand approach, which is sufficient for efficient file sharing. Although I2P mentions multicast in its design documents, so far it has not provided a native implementation. File sharing using Bittorrent over I2P is rather tedious. Tor has no support for one-to-many communication patterns and actively disincentivates the use of such tools. This is also discussed in anonymity. Retroshare can act as a distribution overlay on top of Tor's onion services, but the efficiency should be similar to using Bittorrent over Tor. cjdns could provide for IP Multicast within the limitations of that protocol.

Things left to consider: Reliability, Recovery of incomplete file transfers, Decentralized redistribution, Usability.

BEST CURRENT PRACTICE RECOMMENDATION: Don't entrust sensitive files onto rented servers. Running a web server on a Tor onion service in your home is a pragmatic way to let people have access to files, but expect that your host can be de-anonymized if it is running too long. You can use web-based tools such as Nextcloud or practical ones such as onionshare or Retroshare. Using Retroshare without Tor is more efficient but currently not recommendable with all the attacks taking place on the Retroshare DHT. Tox is facing similar challenges, in both cases the friend-to-friend (F2F) topology exposes who is friends with whom to observers. cjdns too does not hide who is talking to whom and even makes it possible to guess at the contents of messages by their formats. Also the deterministic routing of cjdns allows central nodes to keep complete history of all traffic for possible later decryption. Additionally the cjdns DHT is waiting for attackers to abuse it, as it always is the case with DHT technology that hasn't been specifically protected against attacks. GNUnet file sharing works great and has anonymity integrated by design, but it is a long way until you have it successfully installed. To just have a pleasant and successful experience, Tribler is probably the tool of choice for now.

Requirement				SVPN	SILC	I2P
Link Encryption	✓	⊕	✓	⊕	✓	✓	✓	✓	✓	✓
Forward Secrecy	✗	⊕	⊙	⊙	⊙	✓	⊝	✓	✓	⊕
E2E Encryption	––	⊕	✓	⊝	⊙	⊕	✓	✓	⊕	✓
No Strangers	––	⊕	––	✗	––	⊕	✓	✓	✖	✓
Secret Friends	––	––	––	⊕	––	✓	✗	✓	✖	⊕
Untraceability	––	––	––	––	✗	✓	––	✓	✖	⊕
Unobservability	––	––	––	⊙	✗	✓	––	✓	✖	✓
1-1 Deniability	––	✓	✗	✓	––	––	––	✓	✗	⊕
Reliability	✓	⊝	✓	⊙	✗	––	⊙	✓	⊝	✓
Lightweight	✓	✓	✓	⊙	✓	––	⊙	⊕	⊕	✓
Group Encryption	––	⊕	––	✗	✓	✗	✓	✓	✗	⊕
Distribution	✓	––	✓	––	⊕	––	––	⊝	⊕	⊕

= Facebook, Facetime, Google Hangouts, Whatsapp, Snapchat, Skype etc;

= XMPP-based (Jabber) tools combined with OTR or OMEMO;

= cloud-based systems that offer end-to-end encryption in dedicated clients: crypto.cat, Telegram, Signal, Session;

SVPN = SocialVPN;

SILC = Secure Internet Live Conferencing protocol, a protocol meant to be a replacement for IRC;

= Tools using the friend-to-friend topology such as Tox, Jami and RetroShare;

= RetroShare over Tor onion services;

= Isolated chat server (be it IRC, XMPP, psyced) over Tor onion services. Conversations over Orbot can be employed this way, as Orbot is the Tor router for mobile phones.

Forward Secrecy: OTR provides for safe passage of messages over troubled waters with end-to-end encryption and forward secrecy. It can be applied to XMPP, IRC, PSYC and several ancient proprietary networks. This flexibility comes at the price of not being natively integrated into those communication systems. There is a risk of messages traveling unencrypted and both Untraceability and Unobservability aren't given. Also the user experience of OTR is clearly inferior to applications that do end-to-end encryption by nature. For example if one user shuts down his laptop the other user will not be informed that her messages got lost. Also, many clients have outdated or buggy OTR integration. You may find yourself unable to do authentication by shared secret. OTR cannot be applied to other data than chat, therefore it cannot be used for file transfers or social network event exchange, which is usually not what users expect, with potentially desastrous consequences. OMEMO tackles that problem at least. F-Droid sponsors several XMPP clients with OTR support for Android devices but no IRC clients capable of OTR. Tox and several of the cloud-based apps provide forward secrecy by nature, using Axolotl or similar ratcheting implementations. secushare will do so, too (it's already in GNUnet). This approach is clearly more advanced than OTR.

No Strangers: So far all chat and messaging applications for I2P depend on a server offering on the I2P network (which can be running on a machine at home however), that is why we removed I2P from the listing as it scores the same as any silo service over Tor.

1-1 Deniability: End-to-end messaging between two people should be deniable by default as it is in real life - otherwise you can't have a conversation off the record. OTR has a nice logic for that which should be emulated.

Reliability: Can you be sure the message made it to the other side? PSYC ensures this, or lets you know when it fails. So does XMPP when using the proper protocol extensions, but you also have to use so-called "encrypted sessions" instead of OTR. Only if all involved clients and servers do this properly, it can work out. Many other protocols aren't very reliable at all.

Group Encryption: The OTR developers are working on multi-party end-to-end encrypted chats. This affects various commercial messengers as well as XMPP and IRC. All participants need to be running an OTR-enabled client software.

Distribution: SILC uses the single tree multicast strategy inherited from IRC. Unfortunately it also took the dynamic distributed database problem with it, therefore it doesn't scale well enough for humanity-wide usage.

You are probably familiar with EFF's messaging scorecard which has received ambivalent appreciation even from within the EFF. Its greatest shortcoming is that it doesn't even mention metadata protection (untraceability and unobservability) as a criterion although that is an absolute requirement for constitutional compliance – there is no Freedom of Association if it is perfectly known who the people associating are. Also there is no clear endorsement of free or at least open source software – instead code audits of proprietary applications are accepted, which is ridiculous since we have no guarantee that the companies will actually execute the code that got the review. In fact, past experience with PRISM should teach us the opposite, and Whatsapp is just such an example as it depends on the server whether the end-to-end encryption code is allowed to execute, which can mean that it never actually does. Bart Preneel suggests, that Whatsapp stores unencrypted back-ups of messages in the cloud (article in German). Indeed, for reasons of easier usability a protocol backdoor is provided to do just that. Of course this will never be used for other purposes! EFF recommends several applications which we cannot find in F-Droid, instead it is missing some of the distributed and Tor-based tools listed here. See also the GNU/consensus secure messaging scoreboard for more doubts on EFF's scoring methods.

There has been plenty of criticism about Telegram making some beginner's mistakes while rolling their cryptography, but those mistakes got fixed. Crypto.cat went through similar pains, but for some reasons its even more embarassing mistakes are no longer talked about. Apparently it is okay to consider the code "audited" now, so that should also apply to Telegram. Yet, manipulatory false information keeps being published. We have not seen solid evidence of Telegram not providing safe secret chats, whereas there is no reason to expect proprietary builds of iMessage or Whatsapp to provide any secrecy at all, just because apparent whitepapers describe it that way (that's what the many acclaimed cryptographers that are praising the privacy of these tools use to judge them, not if the declared cryptography is actually in those tools at all) and source codes claimed to be used inside look genuine, but cannot be used or fully reproduced.

Since April 1st, 2016, Moxie offers a way to build Signal in a partially reproducible way for Android – that means any competent person should be able to recreate exactly the code that you get when downloading Signal from the Play Store. Unfortunately, even this reproduction includes non-free binaries that cannot be reproduced, so there is still room for a backdoor or change of behavior to be placed deeper in the architecture.

Swiss-made Wire App, a VC-funded company by a former Skype co-founder, is suffering from the same problem. As it stands we won't be seeing neither Signal nor Wire on F-Droid. In the past several security issues were found and confirmed by Waterloo University researchers. Those seem to have been addressed and fixed in the meantime. Another problematic aspect was that Wire's servers weren't located in Switzerland, they were running on Amazon in Ireland, allowing the Five Eyes to apply voice recognition and phoneme detection on most video calls (as the secure 'constant bitrate' setting is still not the default). Some open issues we haven't heard news of since 2016: The antique authentication method which makes cleartext passwords available to those insecure servers isn't nice. Other people noticed that Wire downloads the crypto code from the server each time it is used, so the server may not even provide a secure end-to-end implementation in the first place. Apparently, This situation hasn't improved, so there is no safe way to download a Wire client neither for desktop nor for mobile.

Whereas LibreSignal is available from Eutopia's F-Droid repository. Its use was tolerated for a while, but the project has been discontinued because of OpenWhisperSystems' unwillingness to provide a platform for free software. So much for "open". This could just be a sad combination of circumstances, or it could be a consequence of the U.S. "Freedom Act". Who knows if we will ever know. This isn't a new situation – back in 2012 OpenWhisperSystems did the same thing with TextSecure, the tool for encrypted SMS that doesn't need any servers. At least a liberated version still exists: SMSSecure is now called Silence.

So the situation is that breadcrumbs periodically come our way but no factual guarantees for privacy materialize as we still don't know how to trust anything that comes just from the Google Play Store, without independent verification of successful reproduction. Thus we can NOT join the choir of cryptologists and media in recommending the use of any of Signal, iMessage, Whatsapp, Wire or SureSpot as long as there is no informatical evidence confirming the cryptographic claims.

The new Google Allo seems to be just as untrustworthy as Whatsapp. And then there is a myriad of minor apps like Bubcon that you should keep your hands off. Too many to list here. Threema at least has better legal preconditions for a privacy-respecting operation. Again we are not granted any source codes to assert any of the claims to be factually true, let alone enjoy an independent copy from F-Droid. The "open source" mentioned on the website only allows you to make apps that use Threema, so it is like Skype's API.

In order to get a reasonable user experience together, most of the above apps share a need to build the initial network of people to communicate with, so they typically do an upload of the user's telephone contact register. Signal seems to have solved this in a more elegant way, using a bloom filter match-up, which means that the server only sees the numbers it already has from other users. Yet, it is the only one to have been observed to also match up e-mail addresses. This can lead to the embarassing situation that people, who you only had mail contact before, are given access to your phone number.

The good news about Riot.im is that you can get it on F-Droid. The not so good news is that it runs on Matrix, which is a federated architecture, not distributed. The resulting threat model is a bit scary as neither distributed nor cloud systems suffer from as many deficiencies. It's the same problem with XMPP and psyced, really.

F-Droid itself is not a long-term secure solution. There may be ways to influence how it operates or man-in-the-middle attack its communications with the repositories, so the really honest answer should be: Android devices are never really secure. Building your own Android packages (apk) and copying it over by USB is the best you can do. Even then you trust your device not to be preemptively backdoored, but so far we have no reason to assume such backdoors would be used for systematic bulk surveillance in a way akin to Microsoft Windows 10 whose contribution to society is that even that assumption has fallen.

BEST CURRENT PRACTICE RECOMMENDATION: The current situation is tricky: privacy-aware people are using OMEMO or OTR over very few XMPP servers in order to avoid XMPP federation which leaks metadata information and allows for timing and statistical attacks. Unfortunately these large servers are frequently collapsing under their load. Also, why should the meta data be safe on such servers? All the recommendable alternatives are very experimental: It is still not trivial to configure either RetroShare or psyced to operate over Tor onion services, yet the result is a trustworthy distributed chat system. There are also solutions over I2P and Freenet, each with their pros and cons. Recently Ricochet is getting more attention, as it operates in P2P over Tor. Probably the best choice at this given moment in time as it protects metadata and is very easy to install. Briar employs a similar strategy to Retroshare and Ricochet using Tor. If it has to be on a smartphone and almost hassle-free, then Telegram can be among the least worse: You should install an independently built binary from F-Droid.org, then ensure you are using "secret" chats and compare the graphical key representations between the devices to ensure the chat is indeed secret. Remember that your metadata is however exposed by such a set-up and group chats are unencrypted. Telegram also has that awful habit to upload your phone address book to the company, just like Whatsapp. Authorities can infiltrate your account, but that is a given with several of these tools – still, that doesn't empower them to read into your secret chats.

Requirement				Pond			BitM
Link Encryption	✓	⊕	⊕	✓	✓	✓	✓	✓	✓
E2E Encryption	––	––	✓	✓	✓	✓	✓	✓	✓
Forward Secrecy	✗	✗	✗	✓	⊝	✓	✗	✓	⊕
No Strangers	––	✗	✗	✓	✓	✓	✓	✓	✓
Secret Friends	––	––	––	✖	✗	✓	✓	✓	⊕
Untraceability	––	––	––	✖	✗	⊕	⊕	––	⊕
Unobservability	––	––	✗	✖	✗	⊕	✓	✓	✓
Post Deniability	⊝	⊝	⊝	⊙	⊝	✓	––	⊙	⊕
Reliability	––	✗	✗	⊝	✗	⊕	⊕	⊕	⊕
Effectivity	––	⊝	⊝	⊝	⊝	⊝	✓	⊝	⊕
Lightweight	––	✓	✓	✓	✗	⊕	⊝	⊕	✓
Group Encryption	––	––	✗	✗	⊝	⊕	✓	✓	⊕
Distribution	⊙	✗	✗	✗	⊕	⊕	✓	⊕	✓
Usability	⊕	⊕	✗	⊕	⊝	⊕	⊕	✓	✓

= Faceboogle and similar web-based cloud services;

= PGP over SMTP (E-Mail);

BitM = Bitmessage;

= Briar.

Effectivity in this case also means protection from SPAM and ability to deliver when two people aren't online at the same time.

Distribution: Bitmessage uses large subscription-based streams shared between many nodes peer-to-peer containing metadata-free ciphertext contributed from many sources. Recipients attempt to decrypt all messages in the incoming subscribed streams whereby it is not observable which messages were actually received by whom. A pretty rough but effective method to achieve unobservability. It comes at a price in terms of network overhead and proof-of-work computation. Briar and Retroshare use opportunistic replication of content, that means that if an intermediate node is not interested in a certain forum it may cut out people behind it from receiving the content.

With the current weaknesses in the Tor onion service implementation, Pond servers can easily be targeted for denial of service, infiltration or physical subversion – especially since most Pond users allocate their identity on the default server. As Pond's threat model states there are several possibilities to de-anonymize the social graph of users once the server is under an attacker's control. The actual content of the messages however is presumeably safe and the usability is pretty good. Also it is said to be easy to set up your own server, but that is not a solution to the federation dilemma.

Concerning usability, Bitmessage suffers from a lack of natural integration of the BM addressing, which when used for broadcasting actually is also the key information needed to access the content, making it too easy for people to accidently share cryptographic key material over unsafe means, exposing the content discussed in a working group to a global passive attacker without anyone knowing it has happened. Interestingly the metadata of silent listeners is still secured making Bitmessage more akin to radio or television. Retroshare's current usability problems were discussed earlier.

BEST CURRENT PRACTICE RECOMMENDATION: PGP is better than nothing, but there are several reasons why PGP over SMTP provides less safety than other tools. Various stop-gap strategies such as pEp, LEAP or keybase.io only address a few of that long list of problems with PGP. cjdns can wrap an outer encryption layer around the SMTP backbone, but it still relies on the safety of servers and the good-will of the other nodes in the cjdns network while allowing for de-anonymization and statistical analysis of mail patterns. Bitmessage instead is a metadata-protective communication tool that scales for thousands of recipients of a single message source (through the built-in "broadcast" feature). Retroshare and Briar can in theory be used in a similar way, using private invitation-only forums, but the method is actually very prone to attack traffic, which required Bitmessage to introduce proof-of-work computations as a deterrent. Regarding anonymity, Retroshare and Briar are placing their bets on Tor instead. It's easy to use Bitmessage the wrong way, like having law enforcement read your private discussion groups once any participant has forwarded its address over insecure means such as e-mail, SMS or Whatsapp, so don't use it for criminal purposes. It takes serious discipline of all participants to maintain Bitmessage groups secure. Another viable alternative is I2PBote for as long as nobody tries serious attacks against its unsafe DHT implementation, which is generally the problem with most tools that employ a DHT somewhere in the stack without taking dedicated safety measures. The usability challenges vary, none of the tools is free of problems.

See #youbroketheinternet for a more verbose overview of the mail replacement situation, including also technologies whose top priority is legacy compatibility.

Requirement	Flash				SVPN
Telephony	✓	✓	✓	✓	✓	⊕	⊕	⊕	✓	⊕
Conferencing	✓	⊕	⊕	⊕	––	––	✓	✓	––	––
Video	✓	✓	✓	✓	⊙	––	––	––	––	––
Multicasting	✓	✗	––	⊕	––	––	––	––	––	✗
Link Encryption	⊝	⊕	⊕	✓	⊕	✓	✓	✓	✓	✓
E2E Encryption	––	✖	✓	––	✓	✓	––	––	✓	✓
Forward Secrecy	✗	⊝	✓	⊙	⊙	⊕	✓	✓	✓	✓
No Strangers	––	✖	✗	––	✗	✓	––	✖	⊝	⊕
Untraceability	––	✖	––	––	––	––	––	⊝	––	✗

Flash = Adobe Flash's RTMP and RTMFP technologies;

= libre WebRTC-based tools such as Jitsi Meet and palava.tv;

= XMPP-based tools, typically using Jingle;

= Cloud-based platforms such as Skype but also including proprietary WebRTC-based ones such as Google Hangouts, Facebook Messenger, Whatsapp and FaceTime;

SVPN = SocialVPN;

= RetroShare;

= Mumble;

= Mumble over Tor onion services;

= Tox or Jami

= GNUnet's conversation (to be integrated into secushare).

Multicast: Flash-based conferencing can use a push-to-talk user interface and decentralized servers in multicast configurations (at least that's what we do at symlynX), so it can be scalable. Other platforms typically provide for continuous stream conferencing which requires plenty of network bandwidth and has limits on the number of people that can take part. Again it's a question of multicast, so we consider it long-term feasible for secushare.

E2E Encryption (end to end) could be applied to telephony negotiated over XMPP, the way Jitsi does it, for example. Involved servers get to know who is calling whom, though. WebRTC has a notorious problem in authenticating communication counterparts in a cryptographically safe manner, so there's always a possibility for a man-in-the-middle attack during DTLS negotiation.

BEST CURRENT PRACTICE RECOMMENDATION: For an untraceable conversation, a torified Mumble can help, using a Mumble server on a onion service that is ensured to be safe from surveillance (that means, not on a cheap virtual hosting which can have XKEYSCORE-friendly automated server memory monitoring) or installed in a way that it cannot easily be found. This, thanks to push-to-talk, even works for conferences. Long-term use of such a configuration could however be detected by traffic correlation. If it isn't so important to hide who is talking to whom, then Jitsi over XMPP should be okay. Also using the telephony capabilities of RetroShare or SocialVPN. WebRTC's DTLS would be fine too, if you find a way to exchange authentication data safely. For example using a webserver on a Tor onion service. Or you can try classic VoIP technology over cjdns.

Requirement			IRC		SILC	I2P	CJD
Link Encryption	⊕	✓	✓	✓	✓	✓	✓	✓	✓	✓
E2E Encryption	––	⊕	⊕	⊕	⊙	⊕	––	✓	✓	✓
Forward Secrecy	✗	⊕	⊕	⊕	⊙	✓	✗	✓	✓	⊕
No Strangers	––	⊕	––	⊕	––	⊕	––	✓	✓	✓
Secret Friends	––	––	––	✖	––	✗	––	✗	✓	⊕
Untraceability	––	––	––	✖	✗	✓	✗	––	✓	⊕
Unobservability	––	––	––	✖	✗	✓	✗	––	✓	✓
Group Encryption	––	✗	––	✗	⊕	––	––	✓	✓	⊕
Distribution	✓	––	⊕	✖	⊕	✗	––	⊕	⊕	⊕
Moderation	✓	✓	⊕	✓	⊕	⊕	⊕	⊝	⊝	✓

= Facebook, Facetime, Google Hangouts, Whatsapp, Snapchat, Skype etc;

= XMPP chatrooms using MUC over federation;

IRC = oligarchic networks using the historic Internet Relay Chat protocol;

= an isolated chat service (be it IRC, XMPP, psyced) behind a Tor onion service operated in a trustworthy manner, not a P2P Tor application (none offer chatrooms yet);

CJD = an IRC server running on somebody's cjdns or yggdrasil node.

Moderation (also known as Conference Control) is the ability to manage behaviour of participants, which unlike in physical life is a true necessity in the digital domain for ensuring a productive environment (Insert suitable explanatory links to research papers here). This is frequently confused with censorship, although there is quite a difference. Retroshare by design cannot moderate its chatrooms. If there is a problem you have to make a new closed membership chatroom and make sure you only invite the right people into it. This is difficult if your policy is to let people in until they misbehave.

We removed Skype from the table as it essentially behaves like a Cloud offering by now. It apparently was a secure chat system in 2003, but that is long gone. The reasons why public IRC networks score pretty badly is described in the link. Similarly XMPP with its federation architecture. Standalone servers behind Tor or I2P score better than nothing while Retroshare currently is the only tool we know that offers truly distributed chat, but has terrible issues with its DHT instead. Also the distribution strategy is opportunistic and depends on the local social graph, so if your social uplink isn't running you may find yourself cut out from the chatroom. Retroshare people usually resolve this by adding a persistent server to the chatroom, but that defeats the whole purpose of having a distributed chatroom if once again a server needs to be trusted to keep all the conversation secret.

BEST CURRENT PRACTICE RECOMMENDATION: We are working on it, but secushare isn't ready yet, so until then the least worst configuration is a standalone chat server on a Tor onion service address. You can pick psyced which offers IRC, XMPP, telnet and webchat access protocols plus native PSYC - so it isn't as barebones as running a regular IRC or Jabber server.

¹) Footnote regarding the ✖ symbol in the tables: Trusting third parties is one thing, but that doesn't mean they took enough provisions for securing the involved server. Also consider that access to such a server may have been gained without the administrator knowing. Architectures that require trust in the administrator should not be developed further but rather sooner than later be replaced by fully distributed solutions that empower the user to not have to trust anybody.

Last Change: 2020-04-05