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

Cleanup 2.0 instant messenger page #1836

Merged
merged 12 commits into from
Apr 19, 2020
Merged

Cleanup 2.0 instant messenger page #1836

merged 12 commits into from
Apr 19, 2020

Conversation

dngray
Copy link
Collaborator

@dngray dngray commented Apr 18, 2020

@dngray dngray requested a review from a team April 18, 2020 04:40
@netlify
Copy link

netlify bot commented Apr 18, 2020

Deploy preview for privacytools-io ready!

Built with commit b20cb66

https://deploy-preview-1836--privacytools-io.netlify.app

jonaharagon
jonaharagon previously approved these changes Apr 18, 2020
Copy link
Contributor

@jonaharagon jonaharagon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

Comment on lines 125 to 136
<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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this should be alphabetized.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

@dngray dngray Apr 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@muppeth muppeth Apr 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 dngray self-assigned this Apr 18, 2020
@dngray dngray added [m] Matrix protocol XMPP Extensible Messaging and Presence Protocol 🗨️ instant messaging (im) labels Apr 18, 2020
nitrohorse
nitrohorse previously approved these changes Apr 18, 2020
Copy link
Contributor

@Mikaela Mikaela left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think delisting XMPP from federated protocols is a disservice.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has OMEMO enabled by default, but I am not willing to clear data on my setup to confirm.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Collaborator Author

@dngray dngray Apr 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Riot do e2ee by default. Does it do e2ee for voip too?

Copy link
Collaborator Author

@dngray dngray Apr 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is anyone using it?

Copy link
Collaborator Author

@dngray dngray Apr 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

@dngray dngray Apr 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Mikaela Mikaela mentioned this pull request Apr 18, 2020
4 tasks
danarel
danarel previously approved these changes Apr 19, 2020
Copy link
Contributor

@danarel danarel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

Copy link
Contributor

@jonaharagon jonaharagon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, I think this looks good

@dngray dngray merged commit 94629b7 into master Apr 19, 2020
@dngray dngray deleted the pr-p2p_cleanup branch April 19, 2020 05:51
@ian-tedesco
Copy link

No Session, then?

@dngray
Copy link
Collaborator Author

dngray commented Apr 24, 2020

No Session, then?

Out of scope for this issue see https://github.com/privacytoolsIO/privacytools.io/issues/1678

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🗨️ instant messaging (im) [m] Matrix protocol XMPP Extensible Messaging and Presence Protocol
Projects
None yet
Development

Successfully merging this pull request may close these issues.

🆕❌ Removal/cleanup 2.0 Real-Time Communication
7 participants