[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
>From reading the documentation, it appears that the expected behavior of
OTR is to change the conversation state to "Finished" when your chat
buddy logs off. However, for me, the conversation status remains
"Private" more often than not. What would cause such inconsistency? I am
testing with Pidgin 2.5.2 and pidgin-otr 3.2.0 on Ubuntu 8.10 and Pidgin
2.5.3 and pidgin-otr 3.2.0 on Windows XP SP3.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/2943c09b/attachment.html>