search

otrv4 / pidgin-otrng

Fork of https://bugs.otr.im/plugins/pidgin-otr. This is a mirror of https://bugs.otr.im/otrv4/pidgin-otrng
GNU General Public License v2.0
16 stars 5 forks source link

Automatically end session when other person ends #69

Open olabini opened 5 years ago

olabini commented 5 years ago

See https://bugs.otr.im/plugins/pidgin-otr/issues/124

claucece commented 5 years ago

Unsure, when this happened, but now the 'End private conversation button' is not being active.

claucece commented 5 years ago

Right now, in the path I could test, we show to both sides: 'private conversation lost'.

olabini commented 5 years ago

Showing "private conversation lost" is not the right user experience in this case. It should say something better.

claucece commented 5 years ago

Agreed @olabini . I'll also send an email to Ian asking why in the past this was shown: X has ended his/her private conversation with you; you should do the same.

claucece commented 5 years ago

The reason for having this behavior if that:

In previous OTR versions, receiving a disconnected TLV would put the
state machine into a "FINISHED" state. A client in this state would
refuse to send new messages from the user until the user explicitly
indicated that they understood the conversation was over.

The rationale was to prevent the following scenario:
- Alice's client sends a disconnected TLV to Bob's client
- Bob types a secret message into his client's textbox and begins to move his hand toward the "send" button
- Bob's client receives the disconnected TLV and enters an "unencrypted" state
- Bob presses the "send" button
- Bob's client sends an unencrypted message that Bob intended to be sent securely

Previous OTR clients handled this situation by refusing to send Bob's message until he indicated that he understood the encrypted conversation was over, and then re-sent the message (or not). There are other UX choices that can be made here, but they must prevent this accidental leakage scenario.

We can do this:

  1. Show a warning that the message will be sent unencrypted
  2. Change the send button to a warning
  3. Refuse to send after some x time, in which the user is shown that the message will be sent unencypted.
pedropalau commented 4 years ago

This is very nice. @claucece what do you think about the following steps:

  1. Block the possibility to send new messages showing the user that the current status of the conversation is now Not private.
  2. Disable the Send button.
  3. If the user want to send new messages without encryption, give him the possibility to start a normal conversation.

About the first step, I prefer to block the sending of the message instead of sending it without encryption, because if the user was previously in a Private conversation, I think was because of the security properties of the protocol.

I don't know until what point could be tricky the fact to send the message without encryption and only show him a warning message.

claucece commented 4 years ago

Mmm.. so the implementation is correct; but at the end this is sent:

<message type='chat' id='purplea7529676' to='bob@localhost'><active xmlns='http://jabber.org/protocol/chatstates'/><body>?OTR:AAQDFoI4gD68Z+sBAAAAAQAAAAIAAAAA+oS77D++On5L8dGGOXYPsc1yIjX1F6c33DH0xOkb5Hw/se9+CHCyf2KefhB8//YkZeKLMLQc23wAAAABgAsXlOagMOCxZsaTSvTf1Aip45BN3aBt8LluiYMAc//vxX3EmDAl5Gk09dzhDuZN3qNrpbSPIM4zuZXHK4zxWZakrMMB1m8wxkTuFHBsVf6nK6MXtcTlcAmu9u0fI/8LZyEGrtQt7RuZPBBhauyilyg2/4RGpwM9iDouQUFmakwJS2Y3Lne6iL1w9VKrk2XGl3jS6KmTia72v9sukPKPL9iBaB4PoyVFdT0VOPCB/U04xz07cL9R2Cf0EaSj0k1DpBj4hkNrJzUhB3544Zzb/qTaZNTP9sR5xHgJn1kkNZXn7ncF69g/XMvAxRK++h1a5JVIpzglmiVj7nSRHE8uX5MAi7rULtGYFI1KOsYF1HZnACXRE+hb40OzLgH3WB+NzylAjxqJ+cvFKBGQLBM7IvSRa97ld3ZcwoA3gNazzw9DR9UfxdxMCP9Mo+eSGKQe92HjbKs7icnNc3FTLrSaI8dv72TLMryHk4rK9xdZv2o/7aaMLScEM67RblJ1XzorWqgeESmeqgIzVHlkkjswSxqBagnIH1JsWQAAAAXI18YlkHJQiWxNbDvU9b8HRhHqPJKv3Hl4yUjR1kUKKhNFd5t2HTcyKkmYEZWUB6Bd6iv7FmikFHbZfU0ky4o1nAP7Qs/RBH1285V+uU4J/HvGihq5ecDY1Vf5S3UDcdnCtnzF94W4s2pIqDGTqydPrjqIW57pypF7wv/5L1hk0q8RJJ6G.</body></message>

the disconneted message. I'll research this and see if there is problem with that.