Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically end session when other person ends #69

Open
olabini opened this issue Sep 13, 2018 · 7 comments
Open

Automatically end session when other person ends #69

olabini opened this issue Sep 13, 2018 · 7 comments
Assignees
Labels
bug importance medium An issue that is medium level importance. It's good to have but not 100% necessary.

Comments

@olabini
Copy link
Contributor

olabini commented Sep 13, 2018

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

@claucece claucece added bug importance medium An issue that is medium level importance. It's good to have but not 100% necessary. labels Sep 20, 2018
@claucece
Copy link
Member

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

@claucece
Copy link
Member

claucece commented Oct 1, 2018

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

@olabini
Copy link
Contributor Author

olabini commented Mar 10, 2019

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

@olabini olabini self-assigned this Mar 10, 2019
@claucece
Copy link
Member

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
Copy link
Member

claucece commented May 9, 2019

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.

@claucece claucece assigned pedropalau and unassigned olabini Aug 5, 2019
@pedropalau
Copy link
Member

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.

pedropalau added a commit that referenced this issue Aug 8, 2019
- When one of the users close Pidgin unexpectedly close the OTR session
- Related to #65 and #69
pedropalau added a commit that referenced this issue Aug 14, 2019
- Get all OTR conversations and close each one
- Related to #65 and #69
pedropalau added a commit that referenced this issue Aug 14, 2019
This code is WIP and need revision
- Checks if the client conversation is encrypted
- Converts client conversation to plugin conversation in a better way
- Related to #65 and #69
@claucece
Copy link
Member

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.

@claucece claucece assigned claucece and unassigned pedropalau Sep 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug importance medium An issue that is medium level importance. It's good to have but not 100% necessary.
Projects
None yet
Development

No branches or pull requests

3 participants