[OTR-users] Bug with auto-connection logic

[Byrd, Brendan]

Ian Goldberg wrote:
> On Mon, Dec 13, 2010 at 11:10:08AM -0500, Byrd, Brendan wrote:
> > E-E - Both parties are encrypted, so there is no problem
> > 
> > U-E - This gives out the "not encrypted" message described above and
> > does NOT auto connect
>
> I see; in this case, the "not encrypted" message is considered a
system
> message, but *includes* the text of the unencrypted message, so you
> don't get your popup notification.  Is that right?  The tricky bit is
> that such messages need to be clearly different from "normal"
> (encrypted) messages, lest the user believe she received the message
> encrypted.  I suppose there could be one system message like "The
> following message was NOT ENCRYPTED:" and then the normal chat
message,
> but I'm worried about race conditions in situations where multiple
> conversations are going on in the same window.  Right now, pidgin
> doesn't spawn a thread per IM connection (I think), but it might in
the
> future?

Well, how about both -AND- a trigger to refresh the privacy link?  It
only gives out this message on a U-E link, so that E link should trigger
a privacy refresh, and then sender would physical resend the message as
an encrypted message or the receiver will simple re-display the message
as a non-system message.  Here's how it would play out:

(9:21:22 AM) The following message received from XXXXX was not
encrypted: [nothing]
(9:21:30 AM) Successfully refreshed the private conversation with XXXXX.
(9:21:30 AM) XXXXX: nothing

So, that covers both future messages from being unencrypted and the
current message that was not encrypted from not blinking the user.

Also, I've also seen this on a E-U conversation, but it's rare:

(8:58:42 AM) OTR Error: You sent encrypted data to XXXXX at XXXXX/spark,
who wasn't expecting it.
(nothing, had to refresh manually)
(8:59:00 AM) Attempting to refresh the private conversation with
XXXXX at XXXXX/spark...
(8:59:02 AM) Successfully refreshed the private conversation with
XXXXX at XXXXX/spark.
(8:59:02 AM) The last message to XXXXX at XXXXX was resent.

This was using a different protocol (XMPP, on a Spark server), but
otherwise, OTR works on this protocol, since it looks like it's
procotol-agnostic.  Not sure if it's specific to this protocol (or just
non-AIM), since I've mostly used OTR on AIM.  (Or maybe I was impatient,
but 20 seconds seems like enough time.)

> > Remote side logs off - Does NOT auto disconnects
> > 
> > Remote side logs on - Does NOT auto connect
>
> Losing your network connection also shouldn't automatically lose your
> OTR state.  You might close your laptop for a bit, then open it again,
> and want to resume your conversation.

(I'll cover this one first because the below situation has to do with
this one.)

Losing your network connection is one thing, but most people don't log
off because of a network connection problem.  It's usually either
because Pidgin (or other IM) was turned off, or because the PC was shut
down.  These cause desync problems, because what was once a private
conversation before the restart is now a NON-private conversation after
the restart, yet the other party is still in the same Private state.
This situation always seems to happen like this:

[Brendan's state - XXXXX's state]

[E-E] (9:20:42 AM) Brendan Byrd: okay, log off of Pidgin
[E-E] (9:20:46 AM) Brendan Byrd: and then log back on
[E-E] (9:20:49 AM) XXXXX has signed off.
[E-U] (9:21:00 AM) XXXXX has signed on.
[E-U] (9:21:22 AM) The following message received from XXXXX was not
encrypted: [nothing]

Now, the above fix I showed earlier would eventually fix that, but why
not be preemptive and refresh the connection on the "sign on" message
(if your client is set to Private)?  That would prevent that one message
from leaking through unencrypted.

> > Furthermore, the reason why these problems happen also has to do
with
> > actions that don't trigger OTR automatically, even with the
> > "Automatically initiate private conversations" option turned on.
> > Certain actions don't do anything automatically, like:
> > 
> > Open new chat window - Does NOT auto connect (it may say Private,
but
> > does NOT tell the other side)
> > 
> > Close chat window - Does auto disconnect (naturally), but does NOT
tell
> > the other side
>
> Chat windows opening and closing aren't meant to correspond to
> conversations starting and stopping.  Lots of people close their
> windows in the middle of the conversation, and let them pop up again
> when new messages arrive.

True, but there's no confirmation, and there's the possibility of
desync.  I think most of the desync issues are caused by the
sign-off/shutdown issue, and I think I'm wrong about the auto disconnect
from chat window closures.

However, let's say that both users close their window, and one person
logs off and on.  That's already a desync.  I'm not sure if OTR would be
able to track the "sign on" without a system message showing it in a
chat window (or if you would want it to).  If not, then it would be
desynced and either a E-U or a U-E conversation would start (depending
on which party opens up the first chat window).  Here's how it would
play out:

[Brendan's state - XXXXX's state]

[E-E] (Brendan Byrd closes chat window)
[E-E] (XXXXX closes chat window)
[E-E] (XXXXX logs off)
[E-U] (XXXXX logs on)
[E-U] (XXXXX opens chat window)
(Brendan Byrd's chat window auto-opens with first message:)
[E-U] (10:45:13 AM) The following message received from XXXXX was not
encrypted: [hi]

--
Brendan Byrd <byrd.b at insightcom.com>
System Integration Analyst (NOC Developer)