User mobility between devices not working properly

[netge]

General information

• Device: Moto G
• Android Version: Android 5.1 Cyanogenmod
• Server name: dukgo.com
• Server software: ?
• Installed server modules: ?
• Conversations source: F-Droid, version 1.12.4

Steps to reproduce

1. Alice starts a conversation with Bob. Bob and Alice are using the Conversations app. OMEMO is chosen as default.
2. Bob ends the conversations and signs out from his account (OK, normal people don't do this but let's be nice. The result is the same if you simply power off the device or cut the network connection). Alice ends the conversation as well.
3. Bob signs in to the same account using Pidgin with OTR plugin from a different device (with a different resource string).
4. Alice starts a new conversation from the Conversations app towards Bob.

Expected result

Conversations app on Alice's device should realize that now Bob's application (Pidgin) is not OMEMO capable and therefore choose OTR or unencrypted as default.

What do you see instead?

1. Conversations app on Alice's device chooses OMEMO as default.
2. Bob does not receive any of Alice's messages in Pidgin.
3. Alice remains unaware of what is happening.
4. Only if Alice manually selects OTR or unencrypted on her end, Bob receives all following messages.

How should Alice know that Bob changed device and what the capabilities are? This does not work!

[ghost]

Don't use Pidgin, it's pure shit.

[netge]

I spent countless hours testing different messaging apps both on Windows and Linux (Pidgin, Gajim, Jitsi, as well as combinations thereof and with different Android apps).
Pidgin was the one that worked best for me on Windows and Linux. YMMV.

[lovetox]

i noticed that too, jumping between devices who want to use different encryption or even no encryption at all, seems tricky.

for example if you have a client who doesnt support encryption at all, i dont know if you would want conversations to automatically jump also to no encryption.
but there is no indication for the conversations user that the chat partner isnt getting the messages.

with OTR its even more compicated, per definition only one client can get the OTR messages, but what if you have 2 resources online at the same time, one OTR capable the other OMEMO.
what should conversations choose? either way one resource will not get the messages.

i think you have to deal with that, or use Gajim with the OMEMO Plugin.

i dont think there is a good way to solve this.
instead of solving this it would be more efficient to make a better OMEMO capable Desktop Client.

@netge try gajim with omemo plugin for windows here then you dont have that problem
from a security standpoint the plugin is not finished but if you dont plan to overthrow the government, i think its ok for now

[sokai]

Thanks @netge for opening this issue!

I like the idea (enable OMEMO automatically if both clients are support it), but not yet/at this time. Only Conversations and Gajim are IMHO able to use OMEMO.
Many of my fellows use the really nice web-app Jappix and have the difficulties netge wrote about.

So: please make the auto-OMEMO optionable!

Thanks an best regards!

[sokai]

#1350 seems to be related to this issue …

[phrokton]

@sokai Were you able to use OMEMO on gajim without having to compile anything yourself?

[lovetox]

@phrokton
on windows you dont have to compile anything

on linux you have to install python-axolotl via packetmanager beforehand, but other than that it should work

@sokai
how has auto OMEMO have to do something with this?
conversations wouldnt switch encryption on itself even if there was no auto OMEMO.

OTR is not a multidevice protocol, so use it only when you have exactly one device, everything else will get messy

[sokai]

@phrokton: I never used Gajim with OMEMO, sry! I only read about OMEMO in Gajim and I tried it some months before. Pidgin is my desktop client (since some years) and I like the Unity integration, the XMPP admin features, …

@lovetox: Sry I don't understand your question … Since 1.12.3 there is „make omemo default when all resources support it“ in Conversations. After that I told a lot of Conversations fellows to turn of OMEMO for talking with me because I can't read the messages by switching between Conversations and Pidgin …

[lovetox]

you mean you never activated it in the first place, and after the update everyones client jumped to OMEMO.

so people write you unencrypted, you write from conversations to people unencrypted.
only on your pidgin you turn OTR on sometimes or always?

[netge]

My main point when opening this ticket was not whether one could find one other application that supports OMEMO.

The main reason why I prefer XMPP over other chat protocols is the fact that it is "confederated" in the sense that each participant can chose his/her own client application and OS platform. Therefore I argue that Conversations should continue to support this openness.

Version 1.12.4 obviously choses OMEMO even when the remote application does not support it and this leads to loss of messages. Even worse, the sender has no idea the messages got lost. (Unfortunately message receipts also don't work predictably in a confederated environment).

Maybe the fault lies with Pidgin in this case. Maybe it does not advertise some capability correctly (although I can't imagine it claims OMEMO support). But I have seen statistics showing that Pidgin is by far the most used chat app at least on Linux. And it works much better than Gajim in cases where I roam between networks/VPNs with changing firewall rules (Gajim just silently stays offline).

So I argue that there should be a safe fallback that ensures message delivery in mixed environments.

[lovetox]

Imagine you are online with both your clients but watching TV, and i want to write you a message.

how should my conversation know if it should use OTR to reach your pidgin, or OMEMO to reach your mobile? how should conversation know to which client you go after watching TV?

the fallback is always write unencrypted - and i guess most users dont want that.

this is in my opinion not a problem of conversations.
this is either a problem of OTR not mulitdevice capable OR that there is only one Desktop Client who supports OMEMO and you dont want to use that.

[netge]

I think I saw it showing me a popup where I could select which presence/resource to send to.
Now there's my lack of knowledge, but do resources (apps) advertise what encryption scheme they support?

[iNPUTmice]

The clarify a possible misunderstanding. Conversations only enables OMEMO if all resources support it. But it also sticks to that encryption once a message has been sent to avoid downgrade attacks.

So for contacts that regularly use clients that don't support OMEMO Conversations will never automatically enable OMEMO.

[netge]

Why "regulary"? Can't it tell what the actually used client supports at the other end?

[lovetox]

@netge
i dont think you understanding the problem.
imagine conversations does indeed know which encryption to use for which of your clients.

how should it decide on the encryption?

if it encrypts the message with OMEMO, your OTR client cant read it.
if it encrypts the message with OTR your OMEMO client cant read it.

how should it know on which client you want to receive messages, if you are not currently typing or sending from that client

[netge]

As I said, I think when my remote partner is logged in on two devices simultaneously, Conversations prompts me to select one of them. Then, if it knows what the chosen device supports, it could use that type of encryption.

I think "one-to-many" type of communication is not needed in a first step.

[lovetox]

and how do you know which resource to choose? how do you know if im out with my mobile and just left my computer running at home, or are at home and my mobile is turned silent cause im playing computer?

you simply dont. you have to guess to which resource to write.

for your case, either write unencrypted all the time, or with OMEMO all the time. or you stop using one client.

now i get that its a shame that there is no OMEMO support for pidgin, and that OTR is only a One on One encryption protocol, but mixing encryptions with different use cases will never work well.

[netge]

I am willing to accept certain compromises :)
But to come back to the initial error, here the remote partner was logged in only on one device at a time and messages were lost. So a much simpler case with bad outcome.

[iNPUTmice]

The clarify a possible misunderstanding. Conversations only enables OMEMO if all resources support it. But it also sticks to that encryption once a message has been sent to avoid downgrade attacks.

So for contacts that regularly use clients that don't support OMEMO Conversations will never automatically enable OMEMO.

As a follow up to this: It is fairly simple to build your own version of Conversations without OMEMO support. Just remove OMEMO from the ENCRYPTION_MASK in Config.java This will prevent your contacts from ever creating a OMEMO session with you.