Menu
▾
▴
#5 protocol wrapping improvement
The OTR Dev Team wrote:
> As a side effect, if anyone's got other enhancements to
> OTR in the wings that would require wire protocol
> changes, now's the time to speak up. :-)
I think that some changes to the protocol could do a lot to
improve the user experience presented by an OTR-enabled
client.
I've been playing with the OTR Gaim plug-in, and it's not
very smooth. Most of the work necessary to clean it up
is in
the plug-in user interface, I suspect. However, some
of the
problems could be improved by some changes to the way the
protocol is wrapped. Given that we seem to have a rare
window of opportunity here, let's take it.
Sometimes my conversation window displays a long message
from my buddy that is all base64-encoded--clearly an
encrypted message that didn't get decrypted before being
shown to me. Annoying. This happens when I start an OTR
private conversation, when I press the OTR button to
"refresh the private conversation", or (most annoying) when
my buddy presses the OTR button.
This could be guaranteed not to happen by sending the OTR
encrypted text as a hidden attribute of the message. Then
if my remote friend has OTR disabled, or even if OTR screws
up, no long garbage messages will clutter up our Gaim
screens.
For example, using gaim-encryption with AIM hides its
protocol messages in an HREF attribute, e.g.,
*** Encrypted with the Gaim-Encryption plugin <A
HREF=": Msg:S123457890:Ra1b2c2d4e5: Len
24:w82z4S1r3msIZzmT7LMFNUbSEt1gI2o9"></A>
Starting with this model, let's try to provide some
examples of
how OTR might work with this technique.
An encrypted message might look like this:
[Encrypted with OTR. See <a
href="http://www.cypherpunks.ca/otr/">http://www.cypherpunks.ca/otr/</a>.]<a
href="OTR: AAEKAAAAAHDh3ZsCjSG..."></a>
We might request a key like this:
<b>YourFriend</b> has requested an OTR private
conversation.
See http://www.cypherpunks.ca/otr/<a href="OTR: =send
key"></a>
(I intend the equal-sign to mean that the following text is
*not* base64-encoded.)
And we can add broadcasting "OTR capability", a feature
gaim-encryption uses, by appending hidden protocol text to
the first message we send a new buddy:
client's regular clear text message here.<a href="OTR:
=capable"></a>
Being able to advertise our capability/existence allows for
opportunistic encryption; we can start OTR private
conversations automatically (controlled by a config option,
of course) when we discover a buddy also runs OTR.
Of course the above protocol-hiding details are
AIM-specific,
and for other IM protocols a different place may have to be
chosen to hide the OTR messages.
Logged In: YES
user_id=113374
> Sometimes my conversation window displays a
> long message from my buddy that is all
> base64-encoded--clearly an encrypted message that
> didn't get decrypted before being shown to me.
This should never happen. If you've got gaim-otr enabled,
it will _never_ show you the raw base64 message. If you can
get it to, that's a bug you should file.
> Being able to advertise our capability/existence allows
> for opportunistic encryption; we can start OTR private
> conversations automatically (controlled by a config
> option, of course) when we discover a buddy also
> runs OTR.
gaim-otr *does* have opportunistic encryption, and it's in
fact on by default.
We'll keep the hidden attributes in mind, but as you note,
different networks will need to do this differently, so it's
unclear that gaim-otr has enough information to do this at
all (you may be using a protocol plugin it doesn't expect,
or something).
Logged In: YES
user_id=414932
The point of my suggestion is to be able to remove the
"if you've got gaim-otr enabled" qualification from your
statement and thus make that statement even stronger.
But I'm glad to hear that you consider the gaim-otr garbage
we are seeing to be a bug. It's pretty easy to get it to
happen: just load the gaim-encryption plugin before you
load the OTR plugin. The order of enabling matters. You
don't have to have any gaim-encryption features turned on or
be using it, it just has to be loaded into gaim.
No matter what order I load the plugins, gaim-encryption
never spews base64 garbage into my session.
Logged In: YES
user_id=113374
Are you using gaim-otr 2.0.2? That bug was reported back in
March, and fixed in the 2.0.2 release. I certainly can't
replicate it any more.
Logged In: YES
user_id=414932
I have gaim-otr 2.0.1 and gaim 1.2.1. (I apologize for
forgetting to mention that in my previous message.)
Upgrading to gaim-otr 2.0.2 fixes the problem. Thank you!
It will now be much easier to convince my buddies to use
gaim-otr.