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

[Greg Troxel]

Ian Goldberg <ian at cypherpunks.ca> writes:

> On Tue, Aug 21, 2007 at 10:29:30AM -0400, Greg Troxel wrote:
>> 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?
>
> 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.

Thanks for replying.  I certainly agree that deciding on the proper
behavior is hard; my big point was the current behavior is a problem.

> 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.

For discussion, I'll assume that Alice is in state finished and Bob
has reappeared.

So if Alice has Bob configured to "required", do you agree that Alice's
OTR implementation should auto-initiate and send if a message is
entered?  I don't see any downside to that. (Except for maybe getting
fussy about private vs unverified and a downgrade attack there.  But
that's really not about finished - it's more general and I think should
be addressed separately.)

> 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).

I see your point.  It's a question of an OTR Query being annoying to Bob
(who has just used an OTR client and is now using a non-OTR client, so
he kind of deserves the poke :-), vs a baffling failure to Alice (who
isn't a cryptographer, and for whom Bob had installed OTR).

> 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.

While timeouts are ugly, they seem hard to avoid in all cases, and the
current behavior has led to failure to communicate in actual user
testing.  I won't suggest options to configure how to respond, as that
seems too hairy.

But, I do not understand how these two situations differ

  client in state not private, OTR required
  client in state finished, OTR required

It seems to me that the issues surrounding save text, initiate, send if
successful, are all the same.  It seems reasonable to have a timeout of
a minute or so and inform the user that negotiation failed - but even
without addressing that it seems that the same behavior as not private
is appropriate for finished.

I wonder if a popup dialog is in order in the non-required case, with
choices:

  try to re-initiate OTR
  end private conversation (warning: messages will be sent unencrypted)
  no change (stay in finished and discard message)

This seems hard, but the fundamental underlying issues really are hard.

> 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.

For the required case, do you agree that treating it like not private
(save message, initiate, send) is appropriate?  That's the case that's
causing me grief.

> 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. ;-)

Yes, makes sense - thanks for spending the time to think about this.