🌐 Website Issue | Refinement to "Encrypted Instant Messenger", section: Centralized, Federated, Peer to Peer #1377
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#1377
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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:
Disadvantages:
Worth mentioning:
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:
Disadvantages:
Worth mentioning:
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:
Disadvantages:
Worth mentioning:
Recent news: Exploiting encryption key distribution of centralized networks
October 2019
July 2019
May 2019
January 2019
December 2018
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.
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).
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.
Remember also https://github.com/privacytoolsIO/privacytools.io/issues/987
Were Riot and Synapse themselves audited? Does the Olm audit help while it's not used by default?
Pasting here to avoid things getting forgotten into instant messenger.
Technically incorrect, Telegram has open source clients that the suggestion doesn't take into account
How about making this "Possibly cannot have third party clients..." ?
Could the license be mentioned?
Missing and
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
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?
How about development has originally begun in 1999?
No, XEPs are part of XMPP standard, so "has been extended" is incorrect
Are we recommending federated alternatives to propietary centralized messengers or having Matrix VS XMPP page with strong bias to Matrix?
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
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?
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.
Fair enough.
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.
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
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.
I will refine that. I was a bit lazy and copied it from xmpp.org
Very much so, because it has moved along with the times. Good feedback!
I will think about how to re-word this. I aim to simplify that a bit.
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?
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.
Perhaps we should link to https://en.wikipedia.org/wiki/Peer-to-peer#Structured_networks instead?
Yes I think this is a good idea, that will be an improvement to the current section.
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.
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.
I think I commented this on Wire and that my concern was related to being unsure on licensing of Signal server.
If I recall correctly that version of the page read "Matrix\n h2 worth mentioning\n XMPP"
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
nowadays2005, 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?
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.
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.
According to https://github.com/signalapp/Signal-Server it is AGPL-3.0.
That was a typographical error which has been fixed.
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.
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.
I think it will look a lot better when some of the information is hidden behind badges.
That does need re-wording. Signal does not allow for third party clients https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165
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.
We could fix that by listing Riot instead, and not mentioning anything about XMPP clients. Realistically when https://github.com/vector-im/riot-web/issues/6779 is complete it's going to be a much more privacy friendly.
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.
Moved further stuff to pull request https://github.com/privacytoolsIO/privacytools.io/pull/1500