[OTR-dev] Flaw in OTR Protocol (with workaround!)

[Greg Troxel]

Ian Goldberg <ian at cypherpunks.ca> writes:

> Most popups are now inline in the CVS version.

I'm glad to hear that.  Another reason to release before the protocol
change :-)

> What is different about what you want vs. the current "end private
> conversation" functionality?

After reading the source I realized that end private is in the
OTR preferences menu and found it.  I was trying to right-click on
'otr: private' and looking in the buddy list context menu.

After playing with this, and reading the code, I find that it's pretty
close to what I want.  I'd like to see:

  ability to end private sessions from chat window (right-click on
  otr: and get menu of options such as refresh, end, show hash, otr
  options dialog?)  opening up global prefs, choosing otr, etc. is too
  hard.

  Ability to automatically end private sessions (for only online
  buddies, or perhaps all?) on client exit.  Easy UI operation to end
  all private conversations.  I think this is just invoking the
  existing functionality on the exiting side.

  Indication that state is private/broken on receiving side.  It seems
  to be in this state, as sending gets me a popup that I have to end
  or refresh.  Perhaps 'OTR: Private/x' would do.

  Make trying to send in private/broken try a refresh by default, just
  like 'otr required, no session'.
  
  Remove 'you should do the same' exhortation from has closed notice.
  This is policy, and I don't like it :-) I close sessions to avoid
  unreadable messages - my intent is to start a new one when needed,
  and with 'use' rather than 'require' policy this results in a
  cleartext message.  To me, ending a session to talk in non-OTR is
  rare, and indicates that my buddy has a non-OTR client now, and that
  should definitely we very manual.

  In 'private connection closed/message not sent' dialog, include
  local account in parens after 'you'.  This is confusing when talking
  to yourself to test without bothering others.

  
  I'd also like a way to expire private sessions after a long period
  of unuse if the buddy is offline, to proactively avoid the sending
  on old session problem when a new peer client starts.  But the
  auto-resend behavior works well enough that I think this is
  unwarranted.





-- 
        Greg Troxel <gdt at ir.bbn.com>