Sorry for nagging at the end of the year, but I kindly ask for possible
reproduction of this issue, since it clearly affects usability of OTR:
Using intentionally multiple session with different session priorities
in OTR chats results in weired behavior of Jitsi, also multiple sessions
without OTR lead to chat delivery to all participants even if only one
particular session was selected.
Latest nb used on Mac OS 10.8.5 and Debian testing, latest Android
version on Samsung tablet and HTC mobile phone.
Testing OTR chat with following scenario:
using two account (A and B), where be is online on 3 devices with
different priorities, same intranet:
Jit.si account A on MacBook (priority 30): “A-Mac-30”
Jit.si account B on Debian (priority 30): “B-Debian-30”
Jit.si account B on Android tablet (priority 25): “B-AndroidTablet-25”
Jit.si account B on Android Mobile phone (priority 20): “B-Mobile-20”
1) activating OTR from A-Mac-30 to B (but not specififying/selecting
particular B, but just “B”
2) reply from B-Debian-30: “jitsi-debian sent you a message that was
intended for another session. If you are logged in multiple times
another session may have received this message”
OTR padlock with “strike-through” (not encrypted)
Result: all three “B” buddies receive the unencrypted message. Behaviour ok.
3) Now: activating OTR from B-debian-30 to A-Mac-30 : padlock at B shows
running points, not encrypting…??
if message is sent during this “running dots” message never arrives at
4) Now from A-Mac-30: selecting B-Debian-30 session from dropdown menu
and activating OTR:
message received at A-Mac-30:
“B is logged in multiple times and OTR has established multiple
sessions. You can select an outgoing session from the menu below.
Unverified private conversation with B/jitsi-android tablet started.
B/jitsi-debian sent you a message that was intended for another session.
If you are logged in multiple times another session may have received
However at B-Debian-30 only a cryptic message arrives
“?OTR:AAICAAAAaljeoulkk…..” and the padlock is “strike-through at
OTR padlock at A-Mac-30 (strike-through) and strangely the selection
from the dropdown menu is again at the “B-general” contact (but not at
the previously selected B-Debian-30)
5) trying to sent not encrypted message from A-Mac-30 to selected
B-Debian-30 results that ALL (!) B-contacts (debian, tablet, mobile)
receive the message (but not the selected B-debian alone…) ???
6) starting OTR chat from B-mobile-20 to A-Mac-30:
B-mobile-20 establishes OTR successfully, but for A-Mac-30 shows a
“strike-through” padlock even if the correct session was selected from
the dropdown menu
7) sending OTR chat from B-mobile-20 to A-Mac-30 results in correct
message at Mac but session selection at Mac jumps back to “common B” session
8) selecting correct session at A-Mac-30 to B-mobile-20 and sending
message results in correct message but padlock at A-Mac-30 stays
9) establishing OTR chat from A-Mac-30 to B-Android-tablet-25 results in
correct establishing of OTR but for authorization the drop down menu
looked very weired (see screenshot below):
the B-sessions “B-Mobile” and “B-Debian-30” are shown DOUBLE in
A-Mac-30, why ???
I did not look the secure chat menu before (as a secure chat was not
established) so I have no idea when this doubling occurred.
IMHO this behaviour of Jitsi using OTR intentionally in multiple
sessions with different priorities is not correct, similar to the
messages reported previously multiple times when this “multiple session”
messages appeared even without a multiple session has been started.
Please consider this issue - if reproducible - before releasing the next
screenshot below from A-Mac-30:
jitsi-htc = B-mobile-20 and jitsi-debian = B-Debian-30
PGP.sig (489 Bytes)