[OTR-users] Problematic OTR behavior

Tue Dec 23 07:08:52 EST 2008

Dear List,

I have been quite interested in OTR for some time and have used it off
and on for several years. I used pidgin-otr-3.2.0 over a period of three
months with my girlfriend but finally migrated to Pidgin-Encryption due
to several usability problems that led my girlfriend to consistently
complain about the software. I prefer OTR due to its deniability and
perfect forward secrecy features but OTR is simply too intrusive for the
average user. After reading "A User Study of Off-the-Record Messaging" I
have decided to share my opinions. Hopefully they will be of some use.

    *1. OTR's behavior is inconsistent and suboptimal when the following
    occur:*

1. User A and B establish a private OTR conversation.
2. User A logs off.
3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends user A a message.*
*

      *Scenario A (more likely scenario):*

1. User A and B establish a private OTR conversation
2. User A logs off (closes Pidgin). Pidgin informs User B that User A
logged off but the conversation remains in "Private" mode.
3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends A a message and receives a string of messages (see below)

   User B: Hello
    (5:23:01 AM) OTR Error: You sent encrypted data to User A, who
wasn't expecting it.
    (5:23:02 AM) Successfully refreshed the private conversation with
User A.
    (5:23:02 AM) Suco last message to User A was resent.

5. User B receives the following messages from OTR before receiving the
message from User A.

User B: The encrypted message received from User B is unreadable, as you
are not currently communicating  privately.
 (05:23:07 AM) Private conversation with User B started.
  (05:23:07 AM)   User B: [resent] Hello

*Expected Result:*

User B expects that when User A logs off, the private conversation will
be terminated (Not Private). When User A logs back on, User B expects
that OTR will indicate that there is no current private conversation and
that OTR's global or per-user settings will be used to decide whether or
not the message must, or simply can be encrypted. If for example, User B
set OTR to "Always Encrypt" then no messages will be sent to User A
unless encrypted. If User B automatically initiates encryption but
doesn't require it, then User B will still be able to communicate with
User A if he logs on using an IM client that doesn't  support OTR. In
addition, because the prior private conversation was terminated when
User A logged off, User B will not be sent any warning messages.

User A expects to receive messages properly when he logs back in without
receiving warnings about unreadable messages.

/There are two main problems with the current situation:/

1) The private conversation is not terminated when User B logs off.
Thus, if User A logs on with a chat client that doesn't support OTR he
will be greeted with encrypted gibberish.
2) Despite the fact that the private conversation can be re-established
without difficulty, both User A and User B are inundated with
unnecessary and bothersome messages. These messages clutter the IM box
and provide little useful information. As a regular user that expects
his IM client to "just work", why do I care that the encrypted session
had to be restarted or that the message had to be resent? There was no
fatal error. I don't want to receive any unnecessary output that I a)
don't care about and b) probably don't understand (Will the average user
know or care why the message was unreadable?). At the very least, there
ought to be a way to disable the messages. More advanced users can then
choose to continue viewing the verbose output.

*Pidgin-Encryption Behavior:
*
1. User A and B establish a secure conversation.
2. User A logs off.
3. User A logs logs back on before User B logs off or manually ends the
secure conversation. (un-checking the lock icon)
4. User B sends user A a message. User B receives a one line warning
message:
"Last message not received properly - resetting"
5. User B resends the message
6. User A receives the message and no warning.

Pidgin-Encryption is not optimal in that it doesn't automatically resend
the message, however it doesn't bother User A with unnecessary
information (he merely receives User B's message), and User B is sent a
one line message informing him that the message was not sent properly,
inducing him to resend the message. In addition, User B is not forced to
manually refresh the connection as in the Scenario B.*
*

      *Scenario B (less likely scenario):*

1. User A and B establish a private OTR conversation
2. User A logs off (closes Pidgin). Pidgin informs User B that User A
logged off and that he has ended his private conversation with User B.
User B is told to do the same. (Note: User A did not manually end the
private connection.)

*(5:54:08 AM)* User A has ended his/her private conversation with you;
you should do the same.

3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends A a message and receives a warning telling him that his
message was NOT sent and that he either should end the private
conversation or refresh it.

Your message was not sent. Either end your private conversation, or
restart it.

5. User B must manually restarts the connection before sending his message.

Private conversation with User A started.
User B: Hello

6. User A receives a message stating that a private conversation was
started as well as the message from user B.

(05:23:07 AM) Private conversation with User B started.
  (05:23:07 AM)   User B: Hello

*Expected Result: *Same as above

*Problems with this Result: *User A simply disconnected his chat
session. He never manually ended the private conversation. OTR should
notify him that the conversation is over but then it should rely on the
user's global or per-user OTR settings as to compulsory or optional
encryption to decide how to proceed. There is no reason that User B
should be required to manually restart the private conversation. This is
not only unnecessary; it's extremely annoying. Clicking the OTR button
isn't sufficient. The user must click the OTR button and then select
"Start Private Conversation". OTR should be a transparent solution. Once
the user authenticates his buddy, he should be informed the state of the
connection, and ought to be bothered as little as possible. The more
intrusive OTR is, the less likely regular users will be willing to use it.

The average user just wants to send a message to his friend. He
certainly doesn't want to have to manually refresh the connection.
Informing the user that the conversation is no longer private after User
A logs off should be sufficient to notify B that the connection is no
longer secure and that he shouldn't send anything sensitive without
first ensuring the conversation has been refreshed. While requiring User
B to manually restart the conversation may prevent him from
inadvertently transmitting sensitive information, it does so at a high
cost. He may be dissuaded from using OTR in the future due to its
intrusiveness.

*Pidgin-Encryption Behavior: *Same as above. This problem doesn't occur.

    *2) Repeated messages about unreadable messages.*

I believe this is a result of one user logging on in two different
locations, but it may be an unrelated issue. I was never able to pin
down the root cause. Do to the inability to solve the issue without
restarting Pidgin, this was a major reason why we moved to
Pidgin-Encryption. I have not encountered this issue with
Pidgin-Encryption. Here is what occurs:

1. User A and B establish a private OTR conversation.
2. User A logs off.
3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends user A a message.
5. User A and B are both inundated by repeated and continuous warnings
about  unreadable messages. Refreshing the conversation does not work.
The only way to resolve the problem is to restart Pidgin.

*Pidgin-Encryption Behavior: *This has never occured in
Pidgin-Encryption. I have only encountered two annoyances in
Pidgin-Encryption:

1. The "Last Outgoing Message Not Received Properly - Resetting" message
informing the user to resend the message - rather than doing so
automatically.
2. If User A logs in on a client that doesn't support pidgin-encryption,
he receives a warning that Pidgin-Encryption has been used to encrypt
the message. This is certainly better than receiving the full encrypted
output which is what happens in an analogous situation with OTR. The
solution is for User B to uncheck the lock icon.

Pidgin-Encryption isn't perfect but my girlfriend much prefers it to OTR
for the simple reason that it is unobtrusive and doesn't bother her with
annoying messages she doesn't care about. She knows that if she receives
the "resetting" warning she just has to resend the message. She prefers
this to the repeated unreadable message problem and the verbose output
spit out by OTR. Pidgin-Encryption relies solely upon the lock icons for
an indication of the security of the connection (after the user's key is
authenticated). It does not output text when a secure connection has
been established nor when a session has ended. In its minimalist
approach, Pidgin-Encryption is able to achieve far more of a transparent
encryption solution. If the lock icons are green, and the user has been
authenticated, the conversation is secure. If not, it isn't. Normally
pidgin-encryption works without outputting any warnings or informational
messages. Since such messages are in my opinion unnecessary because the
user can rely on the less obtrusive and more user-friendly icons. Since
the OTR button informs the user of the state of the connection, I feel
that there should also be a way to disable OTR's informational messages.

      Conclusion:

1. When User A disconnects, User B should be informed that the
connection has been terminated.
    - IfUser A reconnects with a client that supports OTR, a new
connection should be established as normal.
    - If User A reconnects using a client that doesn't support OTR, User
B should still be able to communicate so long as he has not enabled
mandatory encryption. User A should not receive encrypted text.
2. There should be an option to disable informational messages and
warning messages that are not necessary to the security or functionality
of OTR.
3. The user should not be prevented from sending a message unencrypted
unless he has enabled mandatory encryption. The OTR button should inform
the user of the state of the connection. Requiring the user to manually
refresh the connection (requiring two mouse clicks) is user-unfriendly
and very obtrusive.
4. OTR should support chats where one user is logged on in multiple
locations or fail gracefully without the repeated warning messages. (if
this in fact not an unrelated issue. I'm not certain on this point.)

Regards,

Jason Wittlin-Cohen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/13b73f10/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 550 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/13b73f10/attachment.pgp>