Cleanup 2.0 instant messenger page #1836
Conversation
|
Deploy preview for privacytools-io ready! Built with commit b20cb66 |
| <ul> | ||
| <li>Other <a href="https://matrix.org/clients">Matrix</a> clients, that may however be less feature complete than Riot.im.</li> | ||
| <li><a href="https://xmpp.org/about">XMPP</a> (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). <a href="https://conversations.im/omemo/">OMEMO</a> is the most popular XEP (XMPP extension) for E2EE. Clients are developed by the community and not by the XSF (XMPP Standards Foundation). <span class="badge badge-warning" data-toggle="tooltip" title="VoIP and file transfers/names may not be end-to-end encrypted.">Inconsistent E2EE</span></li> | ||
| <ul> | ||
| <li>Other <a href="https://matrix.org/clients">Matrix</a> clients, that may however be less feature complete than Riot.im.</li> | ||
| <li><a href="https://xmpp.org/about">XMPP</a> (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). <a href="https://conversations.im/omemo/">OMEMO</a> is the most popular XEP (XMPP extension) for E2EE. Clients are developed by the community and not by the XSF (XMPP Standards Foundation). <span class="badge badge-warning" data-toggle="tooltip" title="VoIP and file transfers/names may not be end-to-end encrypted.">Inconsistent E2EE</span></li> | ||
| <ul> | ||
| <li><a href="https://gajim.org/">Gajim</a></li> | ||
| <li><a href="https://conversations.im">Conversations</a></li> | ||
| <li><a href="https://siskin.im/">Siskin</a></li> | ||
| <li>Other <a href="https://omemo.top">OMEMO</a> capable clients for XMPP.</li> | ||
| </ul> | ||
| <li><a href="https://www.kontalk.org">Kontalk</a> is a community-driven instant messaging network based on XMPP.</li> | ||
| <li><a href="https://gajim.org/">Gajim</a></li> | ||
| <li><a href="https://conversations.im">Conversations</a></li> | ||
| <li><a href="https://siskin.im/">Siskin</a></li> | ||
| <li>Other <a href="https://omemo.top">OMEMO</a> capable clients for XMPP.</li> | ||
| </ul> | ||
| <li><a href="https://www.kontalk.org">Kontalk</a> is a community-driven instant messaging network based on XMPP.</li> | ||
| <li><a href="https://status.im">Status.im</a> - Encrypted instant messenger with an integrated <a href="https://en.wikipedia.org/wiki/Ethereum">Ethereum</a> wallet (cryptocurrency) that also includes support for <a href="https://our.status.im/tag/dapps">DApps (decentralized apps)</a> (web apps in a curated store). Uses the <a href="https://our.status.im/status-launches-private-peer-to-peer-messaging-protocol/">Waku protocol (a fork of Whisper)</a> for P2P communication. Only available for iOS and Android.</li> | ||
| </ul> |
There was a problem hiding this comment.
I wonder if this should be alphabetized.
There was a problem hiding this comment.
- Users advanced enough to want to use another matrix client can find it themselves.
- Kontalk, a fork of XMPP, yay more fragmentation. Does anyone actually use this?
- XMPP, thinking of removing this when Declaring End-to-end Encryption stable and turning it on by default for private rooms. element-hq/element-web#6779 finally closes. We should in future not recommend clients/protocols that do not have E2EE on by default for private chat.
There was a problem hiding this comment.
Taking another look at Kontalk, it looks like it requires phone numbers, and additionally uses openpgp for group chat so that would indicate no PFS.
Also looks like the encryption is some custom thing not documented. They were looking at doing OpenPGP, but now that's looking like OMEMO.
There was a problem hiding this comment.
Removing XMPP recommendations, as all future clients must support E2EE by default. This is something we've discussed in the past thoroughly.
While Matrix does not at this moment, element-hq/element-web#6779 (comment) is imminent, so we make an exception for that.
There was a problem hiding this comment.
Wait, so you will delist xmpp (a protocol) because not all clients have it enabled by default, but leave matrix because atm pretty much only one client has e2ee and all the rest does not even have a support for it not to mention having it by default?
At the same time keeping and promoting matrix with all it's metadata stored indefinatelly in the database?
There was a problem hiding this comment.
Wait, so you will delist xmpp (a protocol) because not all clients have it enabled by default, but leave matrix because atm pretty much only one client has e2ee and all the rest does not even have a support for it not to mention having it by default?
We are referring to Riot specifically because it will very shortly have E2EE on by default.
At the same time keeping and promoting matrix with all it's metadata stored indefinatelly in the database?
Individual XMPP servers also store metadata (or can). High security environments where that is an issue will operate non-federating Matrix and XMPP servers.
There was a problem hiding this comment.
Individual XMPP servers also store metadata (or can).
Though on matrix they just DO regardless of whether you want it or not. And while others do it in logs, matrix does it in database.
We are referring to Riot specifically because it will very shortly have E2EE on by default.
Conversations already does have it on by default so not sure whats the logic behind it.
There was a problem hiding this comment.
Though on matrix they just DO regardless of whether you want it or not. And while others do it in logs, matrix does it in database.
The logic is if something can, then we assume it does. Particularly in a federated network. Better to assume that it does than pretend like it might not.
Unless you have a non-federating server there's really no way to know what remote servers do.
Conversations already does have it on by default so not sure whats the logic behind it.
Yes it does, but the issue is a lack of other high quality clients like it for other platforms.
Future discussion about XMPP should be in our issue https://github.com/privacytoolsIO/privacytools.io/issues/1838
dngray
added
[m]
There was a problem hiding this comment.
I disagree on delisting of XMPP as I understand Conversations to still fullfil the criteria.
In general I see XMPP as a bit complicated case as the specification doesn't require E2EE and will not be doing that as E2EE is not required for everything that XMPP does. I guess they could be asked if it could be required for client compliance.
|
|
||
| <ul> | ||
| <li>Other <a href="https://matrix.org/clients">Matrix</a> clients, that may however be less feature complete than Riot.im.</li> | ||
| <li><a href="https://xmpp.org/about">XMPP</a> (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). <a href="https://conversations.im/omemo/">OMEMO</a> is the most popular XEP (XMPP extension) for E2EE. Clients are developed by the community and not by the XSF (XMPP Standards Foundation). <span class="badge badge-warning" data-toggle="tooltip" title="VoIP and file transfers/names may not be end-to-end encrypted.">Inconsistent E2EE</span></li> |
There was a problem hiding this comment.
I think delisting XMPP from federated protocols is a disservice.
There was a problem hiding this comment.
It does hurt to de-list things we once recommended, really we owe it to our readers to make the best and most succinct choices. I think we must ensure that we keep in mind with our recommendations:
- security of the product, eg auditing, documentation of crypto etc
- user experience, (nobody is going to use air-gapped openpgp and pasting text files into pastebins, even though that would be "most secure")
- consistency, typically a criteria helps with this.
| <li><a href="https://xmpp.org/about">XMPP</a> (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). <a href="https://conversations.im/omemo/">OMEMO</a> is the most popular XEP (XMPP extension) for E2EE. Clients are developed by the community and not by the XSF (XMPP Standards Foundation). <span class="badge badge-warning" data-toggle="tooltip" title="VoIP and file transfers/names may not be end-to-end encrypted.">Inconsistent E2EE</span></li> | ||
| <ul> | ||
| <li><a href="https://gajim.org/">Gajim</a></li> | ||
| <li><a href="https://conversations.im">Conversations</a></li> |
There was a problem hiding this comment.
Has OMEMO enabled by default, but I am not willing to clear data on my setup to confirm.
There was a problem hiding this comment.
The issue is one client that does this isn't really enough.
We want to in the future make a criteria for the instant messenger page that all recommendations must have E2EE on by default for private chat. Allowing XMPP to remain means we can never do that.
There was a problem hiding this comment.
@dngray But XMPP is a protocol and you are talking about client feature. If you are listing only clients, then of course xmpp should not be there as its a protocol, but otherwise, why not. To my knowledge there is more xmpp clients supporting OMEMO then for example matrix clients with e2ee support.
There was a problem hiding this comment.
XMPP is a protocol and you are talking about client feature.
I am referring to the ecosystem of specifications. The issue is that we don't just recommend a protocol (that would be like recommending http, and not a specific web browser).
To put it more simply:
- a client that talks the XMPP protocol
- if we're not recommending those clients, then we're not recommending the protocol.
To my knowledge there is more xmpp clients supporting OMEMO then for example matrix clients with e2ee support.
This may be the case, the issue however is that not all streams of transmission are actually E2EE (eg voice/video) and we're looking at implementing a rule (we have been for a while) that all instant messenger recommendations must do E2EE by default for private communications. We wanted to avoid the footgun of "oops that particular action was not E2EE, sorry you didn't know about that" to our readers.
Incidentally this PR only recommends Riot, currently that is the most fully featured. Fortunately for any other client (which lets face it is an advanced user at this point) can make use of pantalaimon. (We don't mention that though).
There was a problem hiding this comment.
Does Riot do e2ee by default. Does it do e2ee for voip too?
There was a problem hiding this comment.
Does Riot do e2ee by default. Does it do e2ee for voip too?
Yes, it does for 1:1 VOIP.
Not for group meetings but nobody has that at the moment. We can't have a requirement for something that doesn't exist. Jitsi is working on that though https://jitsi.org/blog/e2ee/ (group meetings in Riot use Jitsi).
| <li><a href="https://status.im">Status.im</a> - Encrypted instant messenger with an integrated <a href="https://en.wikipedia.org/wiki/Ethereum">Ethereum</a> wallet (cryptocurrency) that also includes support for <a href="https://our.status.im/tag/dapps">DApps (decentralized apps)</a> (web apps in a curated store). Uses the <a href="https://blog.enuma.io/update/2018/08/08/decentralized-application-messaging-with-whisper.html">Whisper protocol</a> for P2P communication. <span class="badge badge-warning">Experimental</span></li> | ||
| <li><a href="https://retroshare.cc">Retroshare</a> - Encrypted instant messaging and voice/video call client. RetroShare supports both <a href="https://www.torproject.org/">Tor</a> and <a href="https://geti2p.net">I2P</a>.</li> | ||
| <li><a href="https://bitmessage.org">Bitmessage</a> is a decentralized, encrypted, peer-to-peer, trustless communications protocol that can be used by one person to send encrypted messages to another person, or to multiple subscribers.</li> | ||
| <li><a href="https://retroshare.cc">Retroshare</a> - Encrypted instant messaging and voice/video call client. RetroShare supports both <a href="https://www.torproject.org/">Tor</a> and <a href="https://geti2p.net">I2P</a>.</li> |
There was a problem hiding this comment.
The reason I left retroshare was because it appears to have continuous development. They haven't had a release in a while.
To be honest it looks more like a collaboration platform. It could very well be removed from this particular page. Maybe this would be better moved to another section in another PR?
There was a problem hiding this comment.
Retroshare is still listed as a self-contained-networks.html#L65 as it is appropriately a self contained network of its own, instant-messaging seems like it always a secondary functionality.
|
No Session, then? |
Out of scope for this issue see https://github.com/privacytoolsIO/privacytools.io/issues/1678 |
Closes: https://github.com/privacytoolsIO/privacytools.io/issues/1835
Some interesting articles about it (just for future reference, not linked on the site).
https://deploy-preview-1836--privacytools-io.netlify.app/software/real-time-communication/