<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jason Wittlin-Cohen wrote:
<blockquote cite="mid:4950D4D4.2010903@gmail.com" type="cite">Dear List,<br>
<br>
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.<br>
<h2><b>1. OTR's behavior is inconsistent and suboptimal when the
following occur:</b></h2>
1. User A and B establish a private OTR conversation.<br>
2. User A logs off.<br>
3. User A logs logs back on before User B logs off or manually ends the
private conversation. <br>
4. User B sends user A a message.<b><br>
</b>
<h3><b>Scenario A (more likely scenario):</b></h3>
1. User A and B establish a private OTR conversation<br>
2. User A logs off (closes Pidgin). Pidgin informs User B that User A
logged off but the conversation remains in "Private" mode.<br>
3. User A logs logs back on before User B logs off or manually ends the
private conversation. <br>
4. User B sends A a message and receives a string of messages (see
below)<br>
<br>
User B: <font color="#000000"><span style="font-weight: normal;"><font
size="2">Hello</font></span></font><br>
<span style="font-weight: normal;"><font size="2"> (5:23:01 AM) </font></span><font
size="3">OTR Error: You sent encrypted data to User A, who wasn't
expecting it.<br>
</font><span style="font-weight: normal;"><font size="2"> (5:23:02
AM) </font></span><font size="3">Successfully refreshed the private
conversation with User A.</font><br>
<span style="font-weight: normal;"><font size="2"> (5:23:02 AM) </font></span><font
size="3">Suco</font><font size="3"> last message to User A was resent.<br>
<br>
5. User B receives the following messages from OTR before receiving the
message from User A.<br>
</font><font size="3"><br>
</font><font color="#000000"><span
style="font-weight: bold; color: rgb(204, 0, 0);"></span></font><font
color="#000000" size="3"> User B: The encrypted message received from
User B is unreadable, as you are not currently communicating privately.</font><font
color="#000000"><br>
<span style="font-weight: normal;"><font size="2">(05:23:07 AM) </font></span></font>
<font color="#000000" size="3">Private conversation with User B
started.</font><font color="#000000"><br>
<span style="font-weight: normal;"><font size="2"> (05:23:07 AM)
User B: [</font></span><span
style="font-weight: bold; color: rgb(204, 0, 0);"></span></font><font
color="#000000" size="3">resent] Hello<br>
<br>
<b>Expected Result:</b><br>
<br>
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</font><font size="3"> when User A logged off, User B will
not be sent any warning messages.<br>
<br>
User A expects to receive messages properly when he logs back in
without receiving warnings about unreadable messages.<br>
<br>
<i>There are two main problems with the current situation:</i><br>
<br>
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. <br>
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.<br>
</font><br>
<b>Pidgin-Encryption Behavior:<br>
</b><br>
1. User A and B establish a secure conversation.<br>
2. User A logs off.<br>
3. User A logs logs back on before User B logs off or manually ends the
secure conversation. (un-checking the lock icon)<br>
4. User B sends user A a message. User B receives a one line warning
message:<br>
"Last message not received properly - resetting"<br>
5. User B resends the message<br>
6. User A receives the message and no warning. <br>
<br>
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.<b><br>
</b>
<h3><b>Scenario B (less likely scenario):</b></h3>
1. User A and B establish a private OTR conversation<br>
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.)<br>
<br>
<b><span style="font-weight: normal;"><font size="2">(5:54:08 AM)</font></span></b><span
style="font-weight: normal;"><font size="2"><font size="3"> User A</font></font></span><font
size="3"> has ended his/her private conversation with you; you should
do the same.</font><br>
<br>
3. User A logs logs back on before User B logs off or manually ends the
private conversation. <br>
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.<br>
<br>
<font size="3">Your message was not sent. Either end your private
conversation, or restart it.<br>
<br>
5. User B must manually restarts the connection before sending his
message.<br>
<br>
</font><font color="#000000" size="3">Private conversation with User
A
started.<br>
User B: Hello<br>
</font> <font size="3"><br>
6. User A receives a message stating that a private conversation was
started as well as the message from user B.<br>
<br>
</font><font color="#000000"><span style="font-weight: normal;"><font
size="2">(05:23:07 AM) </font></span></font>
<font color="#000000" size="3">Private conversation with User B
started.</font><font color="#000000"><br>
<span style="font-weight: normal;"><font size="2"> (05:23:07 AM)
User B: </font></span></font><font color="#000000" size="3">Hello</font><br>
<br>
<b>Expected Result: </b>Same as above<br>
<br>
<b>Problems with this Result: </b>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.<br>
<br>
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.<br>
<br>
<b>Pidgin-Encryption Behavior: </b>Same as above. This problem
doesn't
occur.<br>
<h2><b>2) Repeated messages about unreadable messages.</b></h2>
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:<br>
<br>
1. User A and B establish a private OTR conversation.<br>
2. User A logs off.<br>
3. User A logs logs back on before User B logs off or manually ends the
private conversation. <br>
4. User B sends user A a message.<br>
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.<br>
<br>
<b>Pidgin-Encryption Behavior: </b>This has never occured in
Pidgin-Encryption. I have only encountered two annoyances in
Pidgin-Encryption:<br>
<br>
1. The "Last Outgoing Message Not Received Properly - Resetting"
message informing the user to resend the message - rather than doing so
automatically. <br>
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.<br>
<br>
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. <br>
<h3>Conclusion:</h3>
1. When User A disconnects, User B should be informed that the
connection has been terminated. <br>
- IfUser A reconnects with a client that supports OTR, a new
connection should be established as normal. <br>
- 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.<br>
2. There should be an option to disable informational messages and
warning messages that are not necessary to the security or
functionality of OTR.<br>
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.<br>
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.)<br>
<br>
Regards,<br>
<br>
Jason Wittlin-Cohen<br>
</blockquote>
>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.<br>
<br>
Jason<br>
</body>
</html>