[Greg Troxel] [OTR-dev] finished converstations a bad UI choice!

Ian Goldberg ian at cypherpunks.ca
Tue Aug 21 20:45:35 EDT 2007


On Tue, Aug 21, 2007 at 10:29:30AM -0400, Greg Troxel wrote:
> The scenario I described in the attached message happened again today.  
> 
> Any thoughts?  Do people disagree with how I think things should work?
> Is it just a question of not enough round tuits to implement it?
> If I send a patch to do behavior 2 below, will it be accepted?
> 
> I'm on the verge of stopping using OTR.

There's certainly always the tuit problem, and I'm sorry I haven't had a
chance to reply sooner.  I'm still not totally convinced your solution
is strictly better, though.

> There are then two cases:
> 
>   OTR is enabled, with automatic initiation, but not required)
> 
>     Here, we know that OTR recently worked with this peer.  So choices
>     are
> 
>        0) send in clear - dangerous, violates user expectations
>        1) fail (current behavior)
>        2) try to initiate, and send message if negotatiation is successful
> 
>   OTR is enabled, with automatic initiation, and further is required)
> 
>     Here, there are two choices
> 
>        0) send in clear - against stated policy, dangerous
>        1) fail
>        2) try to initiate, and send message if negotatiation is successful
> 
> 
> In the required case, note that these are the same options as in a "not
> private" state.  But in "not private", otr-gaim does option 2, which is
> useful and what the user expects.  In the 'not required' case, option 2
> seems preferred - a savvy user can always 'end private' if that's what
> they want.
> 
> I have no objection to "Conversation is in state finished; trying to
> initiate private conversation" message.
> 
> I realize this is work to change.  But does anyone really think that the
> current behavior is useful and reasonable?  To me it's gratuitously
> difficult when there's a better behavior without security problems.

The problem occurs when your buddy ends the private conversation and
then logs in again, when they're *not* set to "required".  What with the
limited set of clients that currently support OTR (more now than when
the feature was implemented, admittedly), it's totally possible that
your buddy does not in fact support OTR any more.  So at best,
libotr could send an automatic OTR Query message (which would annoy
your buddy if that's indeed the case).

If libotr stashed the plaintext in the same way as when you type
something in "required" mode, it would in fact get automatically sent if
your buddy does support OTR, but something mysterious would probably
happen otherwise, that could probably only be detected by a super-ugly
timeout or something like that.

So it's not so much that there hasn't been a tuit to implement a
solution to this problem, but rather that there hasn't been one to spec
it, I think.

Does that make sense?  All that having been said, I'd be totally happy
to see someone spec a solution, or better, supply both a spec and then a
patch. ;-)

Thanks,

   - Ian



More information about the OTR-dev mailing list