💬 Discussion | Change Encrypted Instant Messenger to Zero Metadata IM. #746

New Issue

2019-01-28T09:26:58Z

ghost commented

2019-01-28 09:26:58 +00:00

(Migrated from github.com)

So, there's a fair bit of crossover between these two categories:

Encrypted Instant Messenger
Encrypted Video & Voice Messenger

Something that has become apparent to me is that there's a lot of "Matrix vs Tox" and "Ricochet vs Some other messenger that has servers". "Jami vs Linphone" etc.

A lot of instant messengers do support video these days, should we even bother with having a separate category for that? I think the only one there that doesn't is Ricochet. I think it's not really what we are about anyway, which is privacy, and security. Everything we suggest supports E2E.

There clearly is a need though for zero-knowledge peer-to-peer messengers that leave no metadata and thus have no servers. It isn't fair to compare these to instant messengers which do have servers. Having a server has pros and cons attached so I think we should use the site to educate people about the difference between these two categories, so that they can pick an option which is compatible with their threat model.

So I propose we change the categories to (note early draft so someone might think of a better category name/description), this is more to get a discussion going:

Zero Metadata Encrypted Instant Messenger

This category, contains distributed peer to peer messengers that do not have any kind of server.

Communication is usually initiated through a bootstrap process, Tor, DHT eg a decentralized network.

This has some downsides as there are certain features that aren't available such as, push notifications, server side logging/replay, server side last read marker, multi video chat (that requires the server to do the mixing), multi device/presence support. This would be the best suited for a hostile environment where the mere metadata of who is talking to whom would be incriminating.

Tox
Ricochet
Jami (formerly Ring) - when used with OpenDHT "Ring ID" not to a SIP server.

While we're at it we need to update "Ring" to "Jami" as the project has been renamed.

Encrypted Video & Voice Messenger

This category contains instant messengers which include voice and video, and contain end-to-end encryption support. For a lot of people they want to know their messages cannot be read and that is sufficient. If I am messaging with family members for example this is probably what I would use as it would have the best user experience.

Signal
Matrix
Linphone

Worth mentioning, XMPP (ChatSecure, Conversations, Kontalk), Jitsi, Wire, Cryptocat

So, there's a fair bit of crossover between these two categories: - Encrypted Instant Messenger - Encrypted Video & Voice Messenger Something that has become apparent to me is that there's a lot of "Matrix vs Tox" and "Ricochet vs Some other messenger that has servers". "Jami vs Linphone" etc. A lot of instant messengers *do* support video these days, should we even bother with having a separate category for that? I think the only one there that doesn't is Ricochet. I think it's not really what we are about anyway, which is privacy, and security. Everything we suggest supports E2E. There clearly is a need though for zero-knowledge peer-to-peer messengers that leave no metadata and thus have no servers. It isn't fair to compare these to instant messengers which do have servers. Having a server has pros and cons attached so I think we should use the site to educate people about the difference between these two categories, so that they can pick an option which is compatible with their threat model. So I propose we change the categories to (note early draft so someone might think of a better category name/description), this is more to get a discussion going: # Zero Metadata Encrypted Instant Messenger This category, contains distributed peer to peer messengers that do not have any kind of server. Communication is usually initiated through a bootstrap process, Tor, DHT eg a decentralized network. This has some downsides as there are certain features that aren't available such as, [push notifications](https://en.wikipedia.org/wiki/Push_technology), server side logging/replay, server side last read marker, multi video chat (that requires the server to do the mixing), multi device/presence support. This would be the best suited for a hostile environment where the mere metadata of who is talking to whom would be incriminating. 1. Tox 2. Ricochet 3. Jami (formerly Ring) - when used with OpenDHT "Ring ID" not to a SIP server. While we're at it we need to update "Ring" to "Jami" as the project has been renamed. # Encrypted Video & Voice Messenger This category contains instant messengers which include voice and video, and contain end-to-end encryption support. For a lot of people they want to know their messages cannot be read and that is sufficient. If I am messaging with family members for example this is probably what I would use as it would have the best user experience. 1. Signal 2. Matrix 3. Linphone - Worth mentioning, XMPP (ChatSecure, Conversations, Kontalk), Jitsi, Wire, Cryptocat

👍 3

jmichael2497 commented

2019-05-16 19:25:51 +00:00

(Migrated from github.com)

this categorization division would be helpful.

i've been trying to figure out a good way to manage some casual affinity groups without requiring people to provide a phone number or email address to join the group chats.

though conversely someone else wants to setup a group where people must provide a phone number to the admins to help enforce accountability of behavior.

so there you go, two use case categories:

anonymized-decentralized-metadata-free
identifiable-and-likely-centralized messaging apps

also while i did like the idea of LinPhone as a cross platform SIP client in the past, i noticed the file transfer seems not to be E2E encrypted and hosted on their server for a week, unless the system has changed, so maybe add a note, since there are better options.

https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Features/File%20transfer/

this categorization division would be helpful. i've been trying to figure out a good way to manage some casual affinity groups without requiring people to provide a phone number or email address to join the group chats. though conversely someone else wants to setup a group where people must provide a phone number to the admins to help enforce accountability of behavior. so there you go, two use case categories: * anonymized-decentralized-metadata-free * identifiable-and-likely-centralized messaging apps also while i did like the idea of LinPhone as a cross platform SIP client in the past, i noticed the file transfer seems not to be E2E encrypted and hosted on their server for a week, unless the system has changed, so maybe add a note, since there are better options. * https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Features/File%20transfer/

blacklight447 commented

2019-05-16 19:53:25 +00:00

(Migrated from github.com)

Ehhh, I would more like it if we were to focus more on threatmodeling rather then making even more sections.

😕 1

jmichael2497 commented

2019-05-16 22:46:29 +00:00

(Migrated from github.com)

focus more on threatmodeling rather then making even more sections.

but wouldn't threat modeling necessitate more sections or differentiation somehow?

at the very least, the "gold standard" featured items could be most private by default such as decentralized, anonymous, no metadata...

while just below have an "honorable mentions" could be included in the same section for super simple but not maybe centralized and not so anonymous with at least some metadata avoidance.

> focus more on threatmodeling rather then making even more sections. but wouldn't threat modeling necessitate more sections or differentiation somehow? at the very least, the "gold standard" featured items could be most private by default such as decentralized, anonymous, no metadata... while just below have an "honorable mentions" could be included in the same section for super simple but not maybe centralized and not so anonymous with at least some metadata avoidance.

blacklight447 commented

2019-05-17 04:39:42 +00:00

(Migrated from github.com)

@jmichael2497 Most private doesnt make it the best, don't forget the usability is a major component of secure messaging.

jmichael2497 commented

2019-05-17 18:52:25 +00:00

(Migrated from github.com)

of course usability is important, which is why i suggested (ideally having several) "gold standard" and "honorable mention".

for example pgp may be "the best" but usability not so much.

some tools that are "less than ideal", but make it easy or invisible to the user in using something like pgp, with maybe less effectiveness of course should be considered.

just added for clarification, but basically i generally like the current format, while some sections could be combined due to feature or function overlap, maybe just moving some to honorable mention bullet point list below featured icon suggestion list... specifically as mentioned the messengers and voice/video messengers.

of course usability is important, which is why i suggested (ideally having several) "gold standard" and "honorable mention". for example pgp may be "the best" but usability not so much. some tools that are "less than ideal", but make it easy or invisible to the user in using something like pgp, with maybe less effectiveness of course should be considered. just added for clarification, but basically i generally like the current format, while some sections could be combined due to feature or function overlap, maybe just moving some to honorable mention bullet point list below featured icon suggestion list... specifically as mentioned the messengers and voice/video messengers.

ghost commented

2019-05-18 05:21:22 +00:00

(Migrated from github.com)

It's not about making a "best" or "worst" list.

The more secure messengers are likely to come at the cost of certain features. This should purely be about a user being able to easily decide what is good enough for them.

for example pgp may be "the best" but usability not so much.

That would not even come into it. PGP is not an instant messenger firstly, secondly for instant messaging it's actually not a very good option. The reason is because there is no perfect forward secrecy.

For non-real time things like email it makes sense but not when you've got things like the double ratchet or off-the-Record Messaging.

At this point in time though, Ricochet may be removed entirely.

The reason for this is because I was not able to substitute the latest Tor binary and operate it. More details https://github.com/privacytoolsIO/privacytools.io/issues/474#issuecomment-473632617

It's not about making a "best" or "worst" list. The more secure messengers are likely to come at the cost of certain features. This should purely be about a user being able to easily decide what is good enough for them. > for example pgp may be "the best" but usability not so much. That would not even come into it. PGP is not an instant messenger firstly, secondly for instant messaging it's actually not a very good option. The reason is because there is no [perfect forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy). For non-real time things like email it makes sense but not when you've got things like the [double ratchet](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm) or [off-the-Record Messaging](https://en.wikipedia.org/wiki/Off-the-Record_Messaging). At this point in time though, Ricochet may be removed entirely. The reason for this is because I was not able to substitute the latest Tor binary and operate it. More details https://github.com/privacytoolsIO/privacytools.io/issues/474#issuecomment-473632617

This repo is archived. You cannot comment on issues.