Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

🌐 Website Issue | Refinement to "Encrypted Instant Messenger", section: Centralized, Federated, Peer to Peer #1377

Closed
dngray opened this issue Oct 5, 2019 · 13 comments
Assignees

Comments

@dngray
Copy link
Collaborator

dngray commented Oct 5, 2019

The improvements to the instant messaging section has simplified things which has been overall an improvement. However I suggest further refinement to the "Worth Mentioning" section could be made.

I think we should have 3 sub categories under "Encrypted Instant Messenger". They should be:

  • Centralized
  • Federated
  • Peer to Peer

We would continue to use the "two card system" where we have with a brief description each recommended program. Note that the layout of the tables is not indicative of how it will look on the website. This is purely about the textual description.

This would also conclude https://github.com/privacytoolsIO/privacytools.io/issues/746, https://github.com/privacytoolsIO/privacytools.io/issues/729

Encrypted Instant Messenger

If you are using SMS or any of these instant messengers Telegram, LINE, Viber, WhatsApp, Facebook Messenger, Wechat, you should pick an alternative below.

This section only includes suggestions which support E2EE (End-to-End encryption), that is where the transmitted messages are encrypted before they are sent from your device. E2EE protects the authenticity (that your messages haven't been modified) in transit as well as the confidentiality as they pass through any part of the network (servers etc).

All the client programs/apps we chose are free and open-source software unless otherwise mentioned. This to ensure that the code can be independently verified by experts now and in the future.

Centralized

Centralized messengers are those where every participant is on the same server or network of servers controlled by the same organization.

Advantages:

  • Easier for developers to implement and push new features
  • Minimal complexity

Disadvantages:

  • Centralized services could be more susceptible to legislation requiring backdoor access
  • Restricted control, or access, this can include things like:
    • Being forbidden from connecting third-party clients to the centralized network that might provide for greater customization or better user experience. Often in Terms and Conditions of usage.
    • Limited to no documentation for third-party developers.
  • Ownership, privacy policy and running of the service can change easily when a single entity controls it, potentially compromising the service.
Signal Signal is a mobile app developed by Signal Messenger LLC. The app provides instant messaging, as well as voice and video calling. All communications are end-to-end encrypted with no option to send unencrypted messages. Warning Badge: Signal requires your phone number as an personal identifier. VOIP Badge
Wire Wire is a multi platform app developed by Wire Swiss GmbH. Wire provides instant messaging as well voice and video calling. All communications are end-to-end encrypted with no option to send unencrypted messages. Warning Badge: Wire stores some plaintext metadata about its users on their servers. This data includes profile names, profile pictures, usernames, and users' lists of connections and conversations. VOIP Badge

Worth mentioning:

  • Keybase Warning Badge: This software relies on a closed-source central server. End-to-end encrypted messaging with social verification.

Federated

Federated messengers are those where the servers talk to each other (like email servers). Federation also allows for system administrators to run their own server and still be a part of the communications network.

Advantages:

  • More inclusive of developers around the world who can contribute code and are not working for the company or organization.
  • Allows for third party clients providing a more native or customized experience
  • Server software (like open source client software) can also be verified that it matches public source code.
  • Greater control over your own data when running your own server.
  • A less juicy target for governments wanting backdoor access to everything as the trust is decentralized. (The server may be hosted independently to the organization who makes the software.)

Disadvantages:

  • More complex, development of new features is slower as standards documents need to be written to ensure a thought out implementation.
  • Some metadata may be available, who is talking to whom, but not what is being said if E2EE (End to end encryption) is used.
Matrix Popular clients include:
Matrix is an open source project that publishes the Matrix open standard for secure, decentralized, real-time communication. For more information see their introduction. There is a privacy-sprint to improve privacy for users. Riot.im which has a modern looking user interface with features similar to those used in other centralized products. It may have some rough edges as it is still an emerging technology under constant development. For example Riot.im on Android is currently undergoing a re-write and will be 6x times faster. RiotX aims to replace Riot.im on Android once it is feature complete.
XMPP Popular clients include:
XMPP (Extensible Messaging and Presence Protocol) is an open source communications protocol that began development in 1999. Since then XMPP has been extended by the publishing of XEPs (XMPP Extension Protocols). OMEMO is the most popular XEP for E2EE (end-to-end encryption). Some clients like those we suggest below can be more stable than their Matrix counterparts. XMPP client software is usually more mature and uses fewer resources (works faster on older computers and phones). However, this does come at the cost of some modern features eg: voice/video calling. Unlike Matrix, clients are only developed by the community and not by the foundation itself. This has resulted in some of inconsistency amongst implemented XEPs, an example of this being Jingle (the protocol for VOIP). Conversations A mature XMPP client for Android 4.4+ OMEMO Badge
Gajim A fully featured XMPP client for Windows and Linux) OMEMO Badge
Monal An XMPP client in active development for iOS and MacOS. OMEMO Badge

Worth mentioning:

  • Kontalk A community-driven instant messaging network. Supports end-to-end encryption. Both client-to-server and server-to-server channels are fully encrypted.
  • Other Matrix clients, may be less feature complete than Riot.im.
  • Other OMEMO capable clients for XMPP.

Peer to Peer

These instant messengers connect directly to each other without an authoritative server in between. Peers (clients) usually negotiate connections through the use of some kind of distributed computing network. Examples of this can include the DHT (Distributed hash table), or Etherium's Whisper protocol.

Once a peer has found the correct route to it's partner, a direct connection to that contact is made. Another approach is proximity based networks, where a connection is established over WiFi or Bluetooth (eg Briar or the Scuttlebutt social networking protocol).

Advantages:

  • Minimal metadata exposed. Note however that your IP address and that of the contacts you're communicating with may be visible if you do not use the software in conjunction with an anonymity network like Tor or I2P many countries have some form of mass surveillance.
  • Always on E2EE (End to end encryption), no ability to disable.

Disadvantages:

  • Reduced feature set:
    • No offline messaging (Tox, Jami)
    • Less efficient battery usage on mobile devices (usually because of persistent network connections to the distributed network that allows other peers to find their contacts).
qTox Encrypted instant messaging and video calling software. Uses its own encryption protocol that has not yet been officially audited by cryptographers. Experimental Badge VOIP Badge
Jami Encrypted instant messaging and video calling software. Uses TLS for encryption. VOIP Badge
Briar Encrypted instant messenger that connects to contacts via Wi-Fi, Bluetooth, or Tor over the internet to synchronize messages. Technology such as this has proven to be useful when Internet availability is an issue, such as in times of crisis. Only available for Android.

Worth mentioning:

Recent news: Exploiting encryption key distribution of centralized networks

October 2019

July 2019

May 2019

January 2019

December 2018

@dngray dngray added high priority 🌐 website issue *Technical* issues with the website. labels Oct 5, 2019
@Mikaela
Copy link
Contributor

Mikaela commented Oct 5, 2019

I think XMPP, Matrix, Tox and Jami would also require warning on missing indepedent security audit.

Matrix is also currently not very privacy friendly judging by https://github.com/privacytoolsIO/privacytools.io/issues/1049 and I think it would require linking to at least https://vector-im.github.io/feature-dashboard/#/plan?label=privacy-sprint&repo=vector-im/riot-web&repo=vector-im/riot-ios&repo=vector-im/riot-android&repo=vector-im/riotX-android&repo=matrix-org/matrix-doc&repo=matrix-org/sydent but I would vote for not relisting them yet.

@dngray
Copy link
Collaborator Author

dngray commented Oct 5, 2019

I think XMPP, Matrix, Tox and Jami would also require warning on missing indepedent security audit.

Yes this is a good idea. Ultimately nothing is perfect so our position is to provide options, because there is no 'ultimate option that ticks all boxes' yet... 🙂

I was also under the impression Matrix did have an audit: Matrix’s ‘Olm’ End-to-end Encryption security assessment released - and implemented cross-platform on Riot at last! (2016).

Matrix is also currently not very privacy friendly judging by https://github.com/privacytoolsIO/privacytools.io/issues/1049 and I think it would require linking to at least privacy-sprint but I would vote for not relisting them yet.

Well i think we could link to it which would be appropriate. It should also be noted while there is a lot of issues there, most of them are marked as "done".

Many of those issues are the ones mentioned in https://github.com/privacytoolsIO/privacytools.io/issues/1049 I guess we just decide now at what point it should be re-added. They seem to be making continual progress Privacy improvements in Synapse 1.4 and Riot 1.4.

@Mikaela
Copy link
Contributor

Mikaela commented Oct 5, 2019

Remember also https://github.com/privacytoolsIO/privacytools.io/issues/987

I was also under the impression Matrix did have an audit: Matrix’s ‘Olm’ End-to-end Encryption security assessment released - and implemented cross-platform on Riot at last! (2016).

Were Riot and Synapse themselves audited? Does the Olm audit help while it's not used by default?

@Mikaela
Copy link
Contributor

Mikaela commented Oct 6, 2019

Pasting here to avoid things getting forgotten into instant messenger.

SMS (short message service) is not encrypted. If you are using SMS or any of these proprietary (not open source) examples eg: Telegram, LINE, Viber, WhatsApp, Facebook Messenger, Wechat, you should pick an alternative below as the programming code is available and can be independently verified by experts:

Technically incorrect, Telegram has open source clients that the suggestion doesn't take into account

Can't have third party clients that might be more customisable or provide a nicer user experience.

How about making this "Possibly cannot have third party clients..." ?

Signal is free and open source.

Could the license be mentioned?

Wire is free open source.

Missing and

Backed commercially,

not necessarily, but I guess both of our suggestions are

and I still disagree with including of Matrix and especially putting XMPP as worth mentioning while XMPP currently has a better track record on privacy than Matrix AFAIK

is an open XML technology for real-time communication

I think it's also used for non-real-time-communication and why say that it's XML technology while you don't say Matrix as HTTP technology?

Originally developed in 1999,

How about development has originally begun in 1999?

XMPP has been extended by way of XEPs (XMPP Extension Protocols).

No, XEPs are part of XMPP standard, so "has been extended" is incorrect

It can be more stable than Matrix at the cost of modern features such as voice/video calling. Unlike Matrix, clients are developed exclusively by the community and not by the foundation. This can result in some of them supporting some XEPs inconsistently. End to end encryption is provided by OMEMO.

Are we recommending federated alternatives to propietary centralized messengers or having Matrix VS XMPP page with strong bias to Matrix?

Other OMEMO ready clients.

I think the word "capable" is usually used here instead

I wonder how come that Wikipedia link for distributed networking doesn't mention DHT which I think things are mostly using? https://en.wikipedia.org/wiki/Distributed_hash_table

Minimal metadata exposed. Note however that your IP address may be visible if you do not use it in conjunction with an anonymity network like Tor or I2P.

and the IP addresses of your contacts

I wouldn't list Tox, because I understand it to be a protocol and not a client, how about qTox?

Is Direct WiFi correct when talking about Briar? I confuse it with WiFi Direct, that I think is something to do with beaming content wirelessly onto a TV screen?

@dngray
Copy link
Collaborator Author

dngray commented Oct 6, 2019

Pasting here to avoid things getting forgotten into instant messenger.

SMS (short message service) is not encrypted. If you are using SMS or any of these proprietary (not open source) examples eg: Telegram, LINE, Viber, WhatsApp, Facebook Messenger, Wechat, you should pick an alternative below as the programming code is available and can be independently verified by experts:

Technically incorrect, Telegram has open source clients that the suggestion doesn't take into account

The client is yes. The issue is it has the same issue as Signal in regard to not being able to run your own server, if you do, you'll have to get everyone to sign up to it and compile your own version of the client with your address in there. No federation, and not designed to be used like that.

Can't have third party clients that might be more customisable or provide a nicer user experience.

How about making this "Possibly cannot have third party clients..." ?

Fair enough.

Signal is free and open source.

Could the license be mentioned?

Wire is free open source.

Everything we suggest is open source. Removing the "X is Open Source" next to every suggestion saves a bit of room and makes less reading for people.

I guess we could mention the license, but do we really need to? Is that part of our goal? They're both GPL-3.

Missing and

Backed commercially,

not necessarily, but I guess both of our suggestions are

I think it's rather inferred. I actually think we need to remove the "Open Whisper Systems" and change that to "Signal Messenger, LLC" to reflect the current status. https://en.wikipedia.org/wiki/Signal_Messenger

and I still disagree with including of Matrix and especially putting XMPP as worth mentioning while XMPP currently has a better track record on privacy than Matrix AFAIK

I have not made XMPP be listed under worth mentioning. Sorry if you got that idea. What I should do is move the bit about other matrix clients down under XMPP.

is an open XML technology for real-time communication

I think it's also used for non-real-time-communication and why say that it's XML technology while you don't say Matrix as HTTP technology?

I will refine that. I was a bit lazy and copied it from xmpp.org

Originally developed in 1999,

How about development has originally begun in 1999?

Very much so, because it has moved along with the times. Good feedback!

XMPP has been extended by way of XEPs (XMPP Extension Protocols).

No, XEPs are part of XMPP standard, so "has been extended" is incorrect

I will think about how to re-word this. I aim to simplify that a bit.

It can be more stable than Matrix at the cost of modern features such as voice/video calling. Unlike Matrix, clients are developed exclusively by the community and not by the foundation. This can result in some of them supporting some XEPs inconsistently. End to end encryption is provided by OMEMO.

Are we recommending federated alternatives to propietary centralized messengers or having Matrix VS XMPP page with strong bias to Matrix?

The idea is to offer two competing federated networks. The fact of it is though Matrix probably offers a consistent feature set that is likely to be desired by most users coming from centralized messengers.

Stability wise I do think XMPP, such as Conversations and Gajim are incredibly mature, however that being said they haven't really had any new features recently. Perhaps this will change, competition is good right?

Other OMEMO ready clients.

I think the word "capable" is usually used here instead

Yes this is a good idea. I also wouldn't be recommending any clients which don't do OMEMO at this point. I don't think there's anything that actually implements OTRv4 yet.

I wonder how come that Wikipedia link for distributed networking doesn't mention DHT which I think things are mostly using? https://en.wikipedia.org/wiki/Distributed_hash_table

Perhaps we should link to https://en.wikipedia.org/wiki/Peer-to-peer#Structured_networks instead?

Minimal metadata exposed. Note however that your IP address may be visible if you do not use it in conjunction with an anonymity network like Tor or I2P.

and the IP addresses of your contacts

I wouldn't list Tox, because I understand it to be a protocol and not a client, how about qTox?

Yes I think this is a good idea, that will be an improvement to the current section.

Is Direct WiFi correct when talking about Briar? I confuse it with WiFi Direct, that I think is something to do with beaming content wirelessly onto a TV screen?

That is what is currently there. I admit I copy pasted that. I think I will also re-word the Status.im entry as it currently refers to "DAPPS" without saying what that is.

@dngray
Copy link
Collaborator Author

dngray commented Oct 8, 2019

I was also under the impression Matrix did have an audit: Matrix’s ‘Olm’ End-to-end Encryption security assessment released - and implemented cross-platform on Riot at last! (2016).

Were Riot and Synapse themselves audited? Does the Olm audit help while it's not used by default?

I asked @ara4n about this, and he said:

The NCC Group undertook the audit of Olm (2016). Olm has not changed at all since the audit as they got it right.

They want to turn on E2EE by default first, before auditing the whole stack. The French government is also doing an audit currently.

@Mikaela
Copy link
Contributor

Mikaela commented Oct 9, 2019

I guess we could mention the license, but do we really need to? Is that part of our goal? They're both GPL-3.

I think I commented this on Wire and that my concern was related to being unsure on licensing of Signal server.

I have not made XMPP be listed under worth mentioning. Sorry if you got that idea. What I should do is move the bit about other matrix clients down under XMPP.

If I recall correctly that version of the page read "Matrix\n h2 worth mentioning\n XMPP"

The idea is to offer two competing federated networks. The fact of it is though Matrix probably offers a consistent feature set that is likely to be desired by most users coming from centralized messengers.
...competition is good right?

I am not so confident on competition being good nowadays. I was recently reading a Finnish book on FOSS history which draw a conclusion that Linux is so successful nowadays 2005, due to developers focusing on what they enjoy rather than challenging Microsoft Windows, while there was also a distribution with that as it's sole purpose which name I don't remember anymore and which failed pretty quickly.

Both have their own sets of issues, and I wonder if it would be better to promote the interoperability in form of https://github.com/matrix-org/matrix-bifrost/ while it probably won't be getting E2EE support?

They want to turn on E2EE by default first, before auditing the whole stack. The French government is also doing an audit currently.

I guess we aren't in hurry to relist them, so they may take as long as they will for that.

PS. I am having serious problems with this discussion as the original comment keeps changing too much/often and there is no support for threads at GitHub. I would find it easier to reply to a draft PR which would allow me to comment especially on the changed lines and maybe (I am not sure) make the changes easier to read.

@blacklight447
Copy link
Collaborator

I think the advantages and disadvantage portions have way to much information imo, we need to remind ourselves that we are very likely to also get a lot not technical people, information about stuff like running other clients and hosting your own server may confuse them and skip over the more important parts.

Also about federated messengers: it says that you can have third party clients, but there are a few issues i have with the statement.
First of all there is nothing that fundamentally stops centralized chat systems from having third party clients. Also third party clients can be a bad thing security wise, even if the client you are using is doing all the crypto and other security stuff, the client your contact is using may not, which can pose a security risk. It can also give birth to lots of fragementation among supported features like we have with xmpp. So rather then a clear advantage or disadvantage, i would consider it personally more of a neutral point.

@dngray
Copy link
Collaborator Author

dngray commented Oct 10, 2019

I guess we could mention the license, but do we really need to? Is that part of our goal? They're both GPL-3.

I think I commented this on Wire and that my concern was related to being unsure on licensing of Signal server.

According to https://github.com/signalapp/Signal-Server it is AGPL-3.0.

I have not made XMPP be listed under worth mentioning. Sorry if you got that idea. What I should do is move the bit about other matrix clients down under XMPP.

If I recall correctly that version of the page read "Matrix\n h2 worth mentioning\n XMPP"

That was a typographical error which has been fixed.

The idea is to offer two competing federated networks. The fact of it is though Matrix probably offers a consistent feature set that is likely to be desired by most users coming from centralized messengers.
...competition is good right?

I am not so confident on competition being good nowadays. I was recently reading a Finnish book on FOSS history which draw a conclusion that Linux is so successful nowadays 2005, due to developers focusing on what they enjoy rather than challenging Microsoft Windows, while there was also a distribution with that as it's sole purpose which name I don't remember anymore and which failed pretty quickly.

Both have their own sets of issues, and I wonder if it would be better to promote the interoperability in form of https://github.com/matrix-org/matrix-bifrost/ while it probably won't be getting E2EE support?

They want to turn on E2EE by default first, before auditing the whole stack. The French government is also doing an audit currently.

I guess we aren't in hurry to relist them, so they may take as long as they will for that.

XMPP doesn't use E2EE either by default so I don't think that can be considered a factor for listing or not listing. The fact of the matter is however Matrix has far healthier development, and things are getting fixed.

PS. I am having serious problems with this discussion as the original comment keeps changing too much/often and there is no support for threads at GitHub. I would find it easier to reply to a draft PR which would allow me to comment especially on the changed lines and maybe (I am not sure) make the changes easier to read.

I intend to make a PR soon, with how it should actually look. I have been unwell of late otherwise I woud have gotten to it earlier. (I will also be out of contact next week). That is usually my preferred way of doing things.

@dngray
Copy link
Collaborator Author

dngray commented Oct 10, 2019

I think the advantages and disadvantage portions have way to much information imo, we need to remind ourselves that we are very likely to also get a lot not technical people, information about stuff like running other clients and hosting your own server may confuse them and skip over the more important parts.

I think it will look a lot better when some of the information is hidden behind badges.

Also about federated messengers: it says that you can have third party clients, but there are a few issues i have with the statement.

First of all there is nothing that fundamentally stops centralized chat systems from having third party clients.

That does need re-wording. Signal does not allow for third party clients LibreSignal/LibreSignal#37 (comment)

It turns out Wire does allow it, You can now build your own Wire client, so this part will need re-working. I guess nobody is really interested in developing third party clients for an instant messenger that isn't federated. The Wire electron desktop app uses consistently a few more hundred MB RAM than Riot.

Also third party clients can be a bad thing security wise, even if the client you are using is doing all the crypto and other security stuff, the client your contact is using may not, which can pose a security risk. It can also give birth to lots of fragementation among supported features like we have with xmpp. So rather then a clear advantage or disadvantage, i would consider it personally more of a neutral point.

We could fix that by listing Riot instead, and not mentioning anything about XMPP clients. Realistically when element-hq/element-web#6779 is complete it's going to be a much more privacy friendly.

@Mikaela
Copy link
Contributor

Mikaela commented Oct 10, 2019

The fact of the matter is however Matrix has far healthier development, and things are getting fixed.

I disagree. To me it seems that Matrix development is focused on New Vector and the combination of Synapse + Riot, while XMPP has far more/diverse options without depending on a single commercial entitity.

@dngray
Copy link
Collaborator Author

dngray commented Oct 11, 2019

The fact of the matter is however Matrix has far healthier development, and things are getting fixed.

I disagree. To me it seems that Matrix development is focused on New Vector and the combination of Synapse + Riot, while XMPP has far more/diverse options without depending on a single commercial entitity.

By "matrix development" I was referring to the whole ecosystem, not just offerings from New Vector. This was an observation I had made from reading both the Matrix and XMPP RSS feeds.

Each week they do a blog post, "This Week in Matrix ...." (similar to the XMPP newsletters) and in that they have a portion dedicated to Spec, Servers, Bridges and Clients. These posts are quite detailed about the development of other people's work outside New Vector.

@dngray
Copy link
Collaborator Author

dngray commented Nov 17, 2019

Moved further stuff to pull request https://github.com/privacytoolsIO/privacytools.io/pull/1500

@dngray dngray closed this as completed Nov 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants