Conversations: Why was the OTR feature removed in version 2.0?

[drduh]

Hi there,

Thanks for a lovely app that I've been using to privately communicate and recommend to many others for the same. This morning, I checked why I was no longer receiving messages from any of my contacts - only to find that OTR support was removed entirely in an app update. I humbly submit these questions to you -

• Why was this feature removed from Conversations? Was it not realized this would break many existing chat sessions?
• Will OTR features ever be added back to Conversations, especially OTRv4?
• Why was OMEMO selected as the default replacement, especially since it's only a few years old?
• Will you be issuing refunds for users who purchased the app explicitly to use OTR?

Note, I am not opposed to OMEMO and understand it's more reliable and feature-full, but at the same time I just don't understand the reasoning and motivation behind removing other encryption standards.

[tjharman]

I was quite annoyed by this change too.
I understand the desire to push OMEMO, but removing all OTR support was a big move with little notification.
I'm disappointed by this enforced change too.

[ghost]

If I was the developer, I will certainly open a public discussion about why we drop OTR support. Not only because we should get user's input, but also show the RESPECT to the ones who are always using the function. It is thoughtless to make suprise to users by removing features (especially security related features) what they are always using without informing before that.

[SoyaLeaf]

Hi, maybe you can join the MUC to discuss this issue. :)

[email protected]

[momo42]

I really like Conversations and I already used OMEMO wherever possible but I have some family members and friends who use Pidgin on Windows/Ubuntu which doesn't support OMEMO out of the box. Installing "lurch" plugin (OMEMO implementation) seems to be a pain in the ass on debian based systems because it is not in the repos and there is also no *.deb Installer or ppa aviable. I cannot tell those people to use git or compile something. And forcing them to change their client is not an option! I know that Gajim supports OMEMO but it lacks other protocols like ICQ. The Windows version of "lurch" is difficult to install too and users report some unsolved bugs and other problems.

For now and the near future (1 - 2 Years) the only solution for me is to chat unencrypted to those people. I was so happy to have successfully pulled them away from WhatsApp and ICQ to encrypted messaging but starting from today the whole discussion about inconveniences with open source will start again. ;-(

I absolutely understand that you guys want to push OMEMO. It HAS some advantages indeed and everyone who is able to should use it but removing OTR completely is insane as it will decrease security level for many people. So PLEASE put it back in!

A warning/info box seems to be ok for me. "OTR is deprecated. Only proceed if you know what you are doing." or something.

[eku]

Home Automation software like FHEM supports XMPP messaging with OTR for notifications. I guess nobody will ever extend this to OMEMO.

[iNPUTmice]

TLDR: OTR was removed because it was highly unreliable, doesn’t work with multiple devices, was never really specified to work with XMPP. The codebase was a mess (There was an HTML parser in there for crying out loud to deal with the garbage some OTR clients would send). The way it was implemented meant it didn’t actually do any verification. Considering the previous points there was little to no desire from my point to fix the security issues (To clarify those exists only in Conversations and are not necessarily OTR specific. I don’t know how other clients handle that.)
People would 'accidentally' use it event to talk between two Conversations because they read somewhere on the internet that OTR is the cool shit.

If you don’t like the changes use Conversations Legacy which is currently on it’s way to the Play Store and will probably be available on F-Droid as well.

[JuniorJPDJ]

You totally should provide replacement..
It's only way to secure talk with people when using transports.

[jubalh]

doesn’t work with multiple devices

Which was actually a plus for me. Sometimes I want to have a conversation where I am sure my partner doesn't have another tablet lying around where someone else could read the conversation by accident. Then switch OTR off again and have normal OMEMO encrypted ones.

[drduh]

Can you clarify what is meant by this?

The way it was implemented meant it didn’t actually do any verification.

Does this mean that by default OTR conversations would not require verification? Or that even if both parties verified fingerprints, it was still possible to impersonate a user?

[iNPUTmice]

@drduh you can download Conversations Legacy for free from the PlayStore to restore the old behaviour https://play.google.com/store/apps/details?id=eu.siacs.conversations.legacy

[ghost]

@iNPUTmice I'm okay with your decision on dropping OTR support. But would you please add a notification or have formal announcement to inform users? And as well as tell everyone there is a legacy version available?

[iNPUTmice]

@wnereiz it was mentioned in the official changelog and announced four month ago on Twitter.

[drduh]

I know about the legacy version, but found your earlier comment about Conversations "not actually doing any verification" extremely worrying. Please explain what you meant by that. Does this mean the legacy app version with OTR support doesn't properly implement verification, or something else?

[drduh]

@iNPUTmice please acknowledge my last comment.

[rharvest]

So, the bottom line is that OTR in Conversations was knowingly poorly implemented for its lifetime, and now we should either continue using that legacy version or trust that this attitude won't apply to the current version going forward. Given the general opaqueness of the reasons for the decision and the continuing avoidance of questions posed above, I have no faith that the attitude has changed.

[xbtc-im]

@drduh you are writing a privacy guide, but you recommend using google cloud and google apps ? Really ?

[jensMF]

@iNPUTmice could you please reconsider the implementation of otr because of otrv4?
https://github.com/otrv4
https://media.ccc.de/v/35c3-9596-no_evidence_of_communication_and_morality_in_protocols_off-the-record_protocol_version_4#l=eng

[licaon-kter]

@jensMF _Not for multi-device, not mobile friendly_ and that's only what the devs said.

[iNPUTmice]

@iNPUTmice could you please reconsider the implementation of otr because of otrv4?

OTRv4 is not compatible to OTRv3 so it doesn’t solve the compatibility issues. I don’t expect OTRv4 to gain any relevant traction in the XMPP community since it offers not benefits whatsoever over OMEMO which in turn is relatively well established by now.

[jensMF]

I would not say omemo is well established. There is nearly no xmpp desktop-client that supports it, particularly not in a comfortable way.
All clients that support OTRv3 should upgrade to OTRv4.
OTRv4 should be more secure than OTRv3 and OMEMO, if they reach that goal.

[claucece]

Hey!

Interesting thread.

_Not for multi-device, not mobile friendly_ and that's only what the devs said.

OTRv4 is muti-device and mobile friendly, @licaon-kter . Since OTRv3, OTR has been multi-device; but it has been not fully implemented in some places, so that is why it does not work that way sometimes. It does not provide multi-device synchronicity though. The OTR protocol since the beginning has been protocol agnostic, meaning, that you can use it over any messaging protocol or client-type. With OTRv4, for example, it can be implemented over email, if wanted, as it supports offline conversations.

OTRv4 is not compatible to OTRv3 so it doesn’t solve the compatibility issues

OTRv4 is compatible with OTRv3.

I think that as a community we should respect the decision of client-developers to support some protocols or others. There will be other clients implementing OTRv4.

@jensMF thanks for watching our talk!

[ForkedLightning]

Although the issue is closed and the developer has firmly made up his mind on the topic I would just like to add a personal anecdote: I've had a fair number of acquaintances approach me for alternatives to proprietary services to try XMPP, only to return to Facebook or Whatapp because of how OMEMO is handled, especially when it just breaks completely with older and unmaintained desktop clients that only have OTR. It turns people away not just from Conversations but from XMPP (and even free software as a whole since it reinforces the existing "free software is bad" mentality that most tech apathetic users have).

[licaon-kter]

@ForkedLightning Aren't WA, Signal and Telegram actually blocking access to old apps after a certain timeframe?

Also, what has OMEMO to do with apps that do not support it?

[Hexawolf]

It is really funny that there is still no answer about issuing refunds. Surely, this software is provided with no warranties and it costs not that much etc etc - but, well, on a human level that was pretty inhuman.

I would not suggest anyone reading this buying Conversation, from a political perspective.

[Kashcheyeu]

I prefer OTR because I work across bridges with protocols other than XMPP (OMEMO is specific to XMPP, and OTR is not).

[licaon-kter]

@Sejd-BY To IRC you mean? Only IRC? OMEMO is not XMPP specific, in theory if the Matrix folks and XMPP folks would have joined forces and choose the same primes and whatnot, then OLM and OMEMO could have lived together.

[Kashcheyeu]

IRC and Matrix.
But the idea of OLM and OMEMO interacting is not bad.