From paul at cypherpunks.ca Sat Dec 4 18:33:38 2010 From: paul at cypherpunks.ca (Paul Wouters) Date: Sat, 4 Dec 2010 18:33:38 -0500 (EST) Subject: [OTR-users] New OTR Development In-Reply-To: <1290108243.4487.57.camel@scspc293.cs> References: <1290108243.4487.57.camel@scspc293.cs> Message-ID: On Thu, 18 Nov 2010, Rob Smits wrote: > Date: Thu, 18 Nov 2010 14:24:03 -0500 > From: Rob Smits > Cc: otr-users at lists.cypherpunks.ca > To: otr-dev at lists.cypherpunks.ca > Subject: [OTR-users] New OTR Development > > [Please note that while I have included both the dev and users lists in > this message, only send your replies to the dev list] Please take a look at the git repository we made for last year's GSoC project. It has a lot of patches merged in already. (on gsoc.xelerance.com) The resource conflict is really an important fix to get out. Ideally before an entire redesign.... Paul From paul at cypherpunks.ca Thu Dec 9 16:19:54 2010 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 9 Dec 2010 16:19:54 -0500 (EST) Subject: [OTR-users] messages sent in Finished state get lost In-Reply-To: <4CE334E4.8090104@gmail.com> References: <4CE311B3.9040306@gmail.com> <4CE334E4.8090104@gmail.com> Message-ID: On Tue, 16 Nov 2010, Tom Metro wrote: >>> and your message goes into a black hole. It isn't logged. > Still, it isn't exactly user friendly. Yes. I've mentioned it in the past a few times as well, but I believe the pidgin implementation might make this one a little hard to implement. I think the issue is that OTR can only modify the message "in transit" but not tell do a callback. Paul From Byrd.B at insightcom.com Mon Dec 13 11:10:08 2010 From: Byrd.B at insightcom.com (Byrd, Brendan) Date: Mon, 13 Dec 2010 11:10:08 -0500 Subject: [OTR-users] Bug with auto-connection logic Message-ID: The logic for sending and receiving encrypted and unencrypted messages isn't automatic in all cases. For example, the "The following message received from XXXX was not encrypted" messages from the system don't spawn a private connection. The biggest issue with these messages is that they are considered system messages, not chat messages, so the window doesn't blink or alert you in any way. Therefore, entire conversations get missed because OTR isn't doing the job of establishing the connection right away. Here's the behavior of OTR in all of the scenarios (first person is the sender): 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 E-U - This gives out the "not expecting an encrypted message" and does auto connect U-U - Both parties are unencrypted, so there is no problem (except for the unencryption) 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 Remote side logs off - Does NOT auto disconnects Remote side logs on - Does NOT auto connect These desyncing problems are what cause the above issues in the first place. Both should be tackled, but the latter would help out a lot in fixing the former. Making OTR work automatically when you tell it to work automatically would make conversations painless. As it is now, this "missing entire conversations" bug is causing a lot of grief. -- Brendan Byrd > System Integration Analyst (NOC Developer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Tue Dec 14 08:02:01 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 14 Dec 2010 08:02:01 -0500 Subject: [OTR-users] Bug with auto-connection logic In-Reply-To: References: Message-ID: <20101214130201.GA31531@thunk.cs.uwaterloo.ca> On Mon, Dec 13, 2010 at 11:10:08AM -0500, Byrd, Brendan wrote: > The logic for sending and receiving encrypted and unencrypted messages > isn't automatic in all cases. For example, the "The following message > received from XXXX was not encrypted" messages from the system don't > spawn a private connection. The biggest issue with these messages is > that they are considered system messages, not chat messages, so the > window doesn't blink or alert you in any way. Therefore, entire > conversations get missed because OTR isn't doing the job of establishing > the connection right away. > > > > Here's the behavior of OTR in all of the scenarios (first person is the > sender): > > > > 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? > > 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. > 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. - Ian From Byrd.B at insightcom.com Tue Dec 14 10:48:47 2010 From: Byrd.B at insightcom.com (Byrd, Brendan) Date: Tue, 14 Dec 2010 10:48:47 -0500 Subject: [OTR-users] Bug with auto-connection logic Message-ID: 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 System Integration Analyst (NOC Developer)