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.
claucece
commented
5 years ago
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:
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.