OTR in Pidgin?

[Casey Ho]

On Tue, Jan 13, 2009 at 12:30 AM, Kevin Stange <kstange at pidgin.im> wrote:
> Casey Ho wrote:
>> As the survey results indicated, encrypted IM support is as popular as
>> VV support [1].
>>
>> How do you all feel about including the OTR plugin by default in Pidgin?
>
> There are a few reasons we've historically rejected the inclusion of
> such a plugin.  The most prominent is that Pidgin and libpurple have
> traditionally made an effort to not transmit to users anything that an
> official client would not, so as to assure maximum compatibility with
> the server and other clients, unless it can be cleanly detected in
> advance which capabilities users have without negative impact.  This is
> extended to "magic formatting" features some third party tools use, and
> various features that result in gibberish being transmitted in plain
> text to users.
>
> We would also then be responsible to choose which implementation of
> security we feel is best, and such an endorsement would probably
> effectively kill off the efforts of other plugins with other goals.
> It's plausible that after internal discussion, for example, we might
> find OTR to be the least desirable implementation but the most widely
> deployed and be forced to choose between supporting something we don't
> like versus something relatively few care to use.  If we are interested
> in supporting an encryption plugin, this investigation would need to happen.
>
> Since such plugins are not currently maintained by us, it demands we
> adopt a set of developers and force them to comform to our development
> cycle and tools, which may not be of interest to them.  I can't imagine
> that most our own developers wish to be tasked with maintaining a new
> chunk of code they've never previously reviewed.
>
> From my experience with OTR as well, I think it would require a major UI
> redesign before I would want to subject our users to it.  Perhaps some
> of those shortcomings currently are due to failings of our API, which
> could be fixed.
>
> I think it's better to focus on making plugins easier to locate,
> distribute and install.  I'm not sure I would want such a heavy plugin
> distributed in Pidgin proper that we'd be forced to begin supporting
> when there are already other people out there seemingly happy enough to
> do it on their own terms.
>
> I know that developers have expressed problems with the designs of some
> of the encryption plugins in discussions that have come up before.  I'm
> sure they'll pop in with their comments.
>
> Kevin

[+ Ian Goldberg, who is the lead for OTR]

>From a cryptography standpoint, OTR appears to be the best solution
available.  Pidgin-encryption does not offer a mechanism for secure
key exchange, whereas OTR uses Diffie-Hellman.  Pidgin-Paranoia uses
one time pads, which have historically been vulnerable because no
computer can be truly random.  One weakness of the protocol is that it
could theoretically be blocked from the networks.  This hasn't
happened, but it would be feasible.

>From a usability standpoint, Pidgin-OTR is not the best solution
available.  The menus and buttons work reasonably well for the
simplest case- two OTR-enabled clients communicating.  However,
exception cases aren't handled as well- usually this involves the
conversation being closed and restarted, or having one of the parties
trying to communicate with encryption disabled.  There's definitely
some work to be done here, but it seems relatively lightweight when
compared to the task of developing a well secured protocol.  The OTR
team appears to be aware of at least some of these issues.

>From a development standpoint, OTR is written as part of a research
project.  Kevin is right when he says that there's a completely
different development cycle from Pidgin.  That said, the protocol
appears to be relatively stable and does not need major updates
(good).  I agree with John's point that libotr (the most complex part)
should be kept as an optional external dependency.

-Casey