[OTR-users] Problematic OTR behavior

[Jason Wittlin-Cohen]

Jason Wittlin-Cohen wrote:
> 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