Is it possible in a future release to support OTR-encryption?
In theory it is possible, but I see several problems, which are a showstopper for me:
If somebody wishes to implement OTR in yaxim, feel free and I will review the patches. However, I am not going to write the support myself anytime soon.
There are examples for OTR on android like Xabber, Gibberbot, Beem or ChatSecure.
Maybe that's useful.
Gibberbot/ChatSecure is doing "the right thing" by allowing encryption of all app data. This is a somewhat paranoid approach, but appropriate for the target group. yaxim can not compete with this level of security, by design.
My biggest problem (besides of the sync issues immanent to OTR with multiple/mobile/offline clients) is that by adding OTR to yaxim I would create a false sense of security for the other party.
By sending OTR-encrypted messages to you, the other user would expect these messages not to be stored in plain-text on your device. The only two options to achieve that are:
As far as I can see from here, both Xabber and Beem violate this expectation.
OTR has nothing to do with data at rest, only data on the move. This is one of the many ways that OTR is very different than OpenPGP. Mass surveillance has only to do with data at move. Mass surveillance, made famous by the NSA leaks but in use in many countries all over the world, has only to do with data on the move. OTR+Tor is the best existing solution to mass surveillance.
Think of OTR as like an envelope in old fashioned mail. It protects the contents of the message while its in transit. Once the envelope is opened and stored at a house or office, (e.g. like data on your phone) then anyone can break into it and steal the message.
TLS and a trustworthy XMPP server are already a good solution to prevent mass surveillance, OTR only adds to that if you use an untrusted XMPP server or a pair of servers without encrypted S2S. However, communication meta-data is of equal importance to the NSA and OTR does not protect that.
You really do not need to convince me, especially as you did not address my main point - with OTR there is an expectation that your communication party is not storing your messages ("off the record"), which yaxim can not fulfill. Instead, you can provide patches that implement OTR support in yaxim, and I will be glad to review and integrate them.
If you do not want to support OTR, can you filter OTR "garbage" and return a "OTR not supported" message to the sender?
I am not 100% opposing an OTR implementation, I just lack the time to do it myself and want to warn people about its side effects. Is there a standard way to inform the other party of missing OTR support?
Seems, that OTR-Clients detect if the other client has OTR. But if you are logged in from multiple locations, the client detects that pidgin uses OTR, and sends OTR to pidgin and beem.
So there should be two things:
The other client should be fixed so it does not assume OTR support from one XMPP resource just because a different XMPP resource supports OTR. Besides of that, even if different resources do support OTR, they do not automatically share the same key state, so they are not able to decode the same messages sent to them. I think OTR needs to be redone so that every chat is actually a "group" chat, with the "group" being the set of all resources of both users. However, this needs a way to add and remove resources to that "group".
When i recommend yaxim to a user, i do not care about other clients being broken. I care about the user seeing strange gibberish or not. I am a bit indifferent about OTR (i see your point in "we cannot provide the full privacy"), but i do care about the user experience for not so geeky users.
For the other thing: groupchat between all resources seems reasonable. And implementing OTR is of course one of the easiest things to avoid displaying raw OTR-messages to the user ;).
That is a great attitude. However, it is not yaxim's task to work around bugs in other clients. If you see a client sending OTR to a resource not supporting it (like yaxim), please file a bug with the sending client, not with yaxim.
If you really insist on this, i guess you cannot recommend yaxim to newbies. When somebody uses a broken client, the not so technical user is scared away.
Just like another client (do not remember, maybe chatsecure?), which displayed the whole ssl-certificate fingerprint on first connect. Good thing to do, but no good thing to do to support endusers.
Sorry for bothering you with such stuff, you and me do not really care about, but i am trying to get some users from proprietary messangers to xmpp, and would really like a client they can use :).
Seriously, if I imagine being an unsavvy user, and I get a gibberish message, I will blame the sender, not so much the client. And if the sender is tech-savvy, he should better be able to tell our user what went wrong. I have really limited time, and I can not work around implementation problems in every broken XMPP application.
Regarding SSL certs, yaxim is also showing a cert, and some people just do not understand what it is good for. Nevertheless, this is something that should not happen more than once and be taken care of by the user's tech-savvy friend. IT security is complicated, after all.
Sorry, the typical whatsapp user will then respond via whatsapp "your xmpp is shit, answer me here". You may have a second chance, but when the next contact sends gibberish, the frustration will accumulate ...
And anyway, it there are broken clients (i guess with the handling of multiple ressources, which is pretty transparent to the clients), the problem will occur often. And even the sender may not be fully aware how to fix it. When i install two friends yaxim and pidgin and one sends a message with pidgin and gets a answer "you send me a lot of broken stuff", he may not be able to find how to disable it. And when he manages to find it, he will advice others "disable the OTR plugin and you never have the problem again".
But if you set this to WONTFIX, okay. I just wanted to give some feedback with my opinion about newbie-friendly interfaces.
As I wrote in my blog post, this issue needs to be fixed in the sender client anyway. Whenever you, personally, encounter this issue, please spend your energy to open a bug report with the respective sender client. This issue is for implementing OTR in yaxim, not for working around broken OTR implementations in other clients (feel free to open a different issue for that, though; I would keep it open for a long time probably).
Agreed, the discussion got a bit out of the scope of this bug. I opened #118 for this issue.
With the advent of OMEMO, there is no more use in implementing OTR. OMEMO is more modern, allows multi-party communication and doesn't suffer from incorrectly implemented client plugins.