Here's the major usability pain points I've run in to with various OTR clients over the years. Feel free to chime in with any additional issues you've noticed.
1. The multiple client problem: If you have two devices online simultaneously under the same account, they will fight and endlessly renegotiate.
This issue may be specific to OTRv2 only. Arlo pointed out that this change in OTRv3 may solve a lot of these problems:
"Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions." -- https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
We should be sure we use these features properly, and make sure the js-ctypes wrappers are updated to support the new libotr v3 APIs with these instance tags. The current js-ctypes wrapper may still be v2 only.
If for some reason these tags in v3 can only be used if both parties support v3, perhaps we can add some additional code to track OTR state using XMPP resource/device info and tell the OTR lib underneath that different XMPP resources are actually different users, so that at least XMPP accounts won't have this problem.
2. Better TOFU support: We should track only one OTR key for a given XMPP resource/device ID.
Some people I communicate with are constantly rotating OTR keys for security and other reasons. However, this doesn't help me any: I have accumulated about 50 keys of unknown age and usage pattern in my OTR fingerprint list for them, and I have no idea which ones have been changed due to compromise, device loss, or simply due to reinstall. Worse, I have no idea which keys should correspond to which XMPP resources/devices.
If a user changes the key for a given XMPP resource ID, we should expire the previous key and loudly alert the user of the fact that the resource's key has changed, and ask them if they want to replace the old key with the new key. We should not simply accumulate more keys by default, especially for the same XMPP resource/device, and especially not for unverified keys.
At the same time, we should allow a different OTR key for each unique XMPP resource ID, and perhaps allow non-XMPP keys to accumulate at user option.
3. "Unreadable encrypted message" errors should be visible only to advanced users/in the error console, and the client should transparently renegotiate and resend.
It looks like OTR has an ERROR_START_AKE flag for this, but for some reason, some states of OTR in Pidgin still cause me to get and send these errors and miss messages though, usually if one client has crashed or restarted without properly ending the conversation. We should try extra hard to force key re-negotiation in these cases.
We probably also want an auto-responder after the renegotiation that informs the other party that N messages were missed (for clients that don't support OTR's built-in notifications).
4. OTR shouldn't get stuck in the "Finished" state when you end a conversation.
I've noticed in the past that OTR seemed to refuse to automatically negotiate/re-negotiate if it is still "Finished" regardless of your "Require/Force OTR" setting. This is just bad, and often causes plaintext to leak.
5. It should be impossible for our client to send a message in plaintext by default, and the client should discourage counterparties from sending more than one plaintext message.
Perhaps related to issue 3, I've not had very good results with the "Require OTR"/"Force OTR" options on many clients.
It also seems like many people's clients will still send the first message unencrypted (to get the handshake hint), and on all clients OTR doesn't seem to try very hard to negotiate if an unencrypted message is received.
On our side, we should hold those messages and send only the handshake initiation (ie our default OTR mode should be REQUIRE_ENCRYPTION).
We may also want to consider a plaintext auto-reply for when we receive unencrypted messages. Something like "Please install and enable OTR before sending further messages" as a separate message in *addition* to attempting an OTR handshake.
6. The UI should have per-message encryption indicators (send and receive)
For many clients, the UI is not clear which messages were sent encrypted, especially if the OTR state has changed due to autonegotiation or "Finishing". We should have per-message icons for both sent and received messages that indicate encryption status for that message in the chat scrollback window.
7. Logging should be off by default when OTR is on.
On Thu, Oct 17, 2013 at 1:03 AM, Mike Perry mikeperry@torproject.orgwrote:
Here's the major usability pain points I've run in to with various OTR clients over the years. Feel free to chime in with any additional issues you've noticed.
- The multiple client problem: If you have two devices online
simultaneously under the same account, they will fight and endlessly renegotiate.
This issue may be specific to OTRv2 only. Arlo pointed out that this change in OTRv3 may solve a lot of these problems:
"Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions." -- https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
We should be sure we use these features properly, and make sure the js-ctypes wrappers are updated to support the new libotr v3 APIs with these instance tags. The current js-ctypes wrapper may still be v2 only.
If for some reason these tags in v3 can only be used if both parties support v3, perhaps we can add some additional code to track OTR state using XMPP resource/device info and tell the OTR lib underneath that different XMPP resources are actually different users, so that at least XMPP accounts won't have this problem.
- Better TOFU support: We should track only one OTR key for a given
XMPP resource/device ID.
Some people I communicate with are constantly rotating OTR keys for security and other reasons. However, this doesn't help me any: I have accumulated about 50 keys of unknown age and usage pattern in my OTR fingerprint list for them, and I have no idea which ones have been changed due to compromise, device loss, or simply due to reinstall. Worse, I have no idea which keys should correspond to which XMPP resources/devices.
+10. This is huge.
As you point out, you get a "Unverified/Verified" when using OTR. Verifying fingerprints of anonymous chat is practically impossible -- every side channel I can think of (telephone, meeting in person, email - ha) either leaks the act of contacting, isn't practical or convenient, or requires some kind of Internet reputation. I'd bet that most OTR users don't verify fingerprints.
TOFU is a must, along with a dialogue that explains in simple terms what is going on, with a way to dismiss the dialogue (e.g. by correctly answering a security question).
Perhaps replacing "Unverified" with "In use for: x days" ?
If a user changes the key for a given XMPP resource ID, we should expire the previous key and loudly alert the user of the fact that the resource's key has changed, and ask them if they want to replace the old key with the new key. We should not simply accumulate more keys by default, especially for the same XMPP resource/device, and especially not for unverified keys.
I think you mean that the existing key is expired after the user has OK'd using the new key. The UI should not be something you can just click away or ignore; it should be slightly inconvenient, and perhaps bidirectional (the user whose key changed gets prompted as well).
At the same time, we should allow a different OTR key for each unique
XMPP resource ID, and perhaps allow non-XMPP keys to accumulate at user option.
I'd like the opposite -- I would like to be able to bind the nickname *to* the OTR key, but change the XMPP or IRC id, or to put it another way, be able to keep a persistent cryptographic identity but use whatever underlying transport or throwaway account is convenient.
Admittedly it's not as good as doing away with centralized resources completely, and I think a Hidden Service transport would be very interesting. (And it looks like the Tor network load testing results are looking good ;-) )
- "Unreadable encrypted message" errors should be visible only to
advanced users/in the error console, and the client should transparently renegotiate and resend.
It looks like OTR has an ERROR_START_AKE flag for this, but for some reason, some states of OTR in Pidgin still cause me to get and send these errors and miss messages though, usually if one client has crashed or restarted without properly ending the conversation. We should try extra hard to force key re-negotiation in these cases.
We probably also want an auto-responder after the renegotiation that informs the other party that N messages were missed (for clients that don't support OTR's built-in notifications).
- OTR shouldn't get stuck in the "Finished" state when you end a
conversation.
Yeah, I've seen this one too.
I've noticed in the past that OTR seemed to refuse to automatically negotiate/re-negotiate if it is still "Finished" regardless of your "Require/Force OTR" setting. This is just bad, and often causes plaintext to leak.
- It should be impossible for our client to send a message in plaintext
by default, and the client should discourage counterparties from sending more than one plaintext message.
Perhaps related to issue 3, I've not had very good results with the "Require OTR"/"Force OTR" options on many clients.
It also seems like many people's clients will still send the first message unencrypted (to get the handshake hint), and on all clients OTR doesn't seem to try very hard to negotiate if an unencrypted message is received.
On our side, we should hold those messages and send only the handshake initiation (ie our default OTR mode should be REQUIRE_ENCRYPTION).
I think it might be simpler to block input until the OTR handshake has completed. That is, the text input area is simply unavailable (in Force OTR mode).
We may also want to consider a plaintext auto-reply for when we receive unencrypted messages. Something like "Please install and enable OTR before sending further messages" as a separate message in *addition* to attempting an OTR handshake.
It might be better to not fingerprint the client that you are using. OTOH the pidgin-otr plugin does behave this way.
- The UI should have per-message encryption indicators (send and receive)
For many clients, the UI is not clear which messages were sent encrypted, especially if the OTR state has changed due to autonegotiation or "Finishing". We should have per-message icons for both sent and received messages that indicate encryption status for that message in the chat scrollback window.
That could be a little cluttered; I'd suggest background tinting or only flagging the unencrypted messages with skulls and crossbones.
- Logging should be off by default when OTR is on.
I guess people like logging for some reason, and I'll admit that pidgins "History" mode really enables asynchronous chat. Rather than require you *turn off* OTR to get this feature, an alternative would be to require a passphrase and automatically expunge encrypted logs after a configurable period of time. And, unlike other clients, perhaps telling the conversation counterparty that logging is enabled (e.g. the opposite of gchat "OTR" notifications ) at the start of the session would provide informed consent.
And:
8. Require (or at least allow) a passphrase to decrypt the OTR private key. Or, store the key on a hardware token.
The number of arbitrary file read bugs in pidgin makes me cry...
-- Mike Perry
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, Oct 17, 2013 at 09:35:14AM +0000, Aaron wrote:
On Thu, Oct 17, 2013 at 1:03 AM, Mike Perry mikeperry@torproject.orgwrote:
Here's the major usability pain points I've run in to with various OTR clients over the years. Feel free to chime in with any additional issues you've noticed.
- The multiple client problem: If you have two devices online
simultaneously under the same account, they will fight and endlessly renegotiate.
This issue may be specific to OTRv2 only. Arlo pointed out that this change in OTRv3 may solve a lot of these problems:
"Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions." -- https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
We should be sure we use these features properly, and make sure the js-ctypes wrappers are updated to support the new libotr v3 APIs with these instance tags. The current js-ctypes wrapper may still be v2 only.
If for some reason these tags in v3 can only be used if both parties support v3, perhaps we can add some additional code to track OTR state using XMPP resource/device info and tell the OTR lib underneath that different XMPP resources are actually different users, so that at least XMPP accounts won't have this problem.
Yes, OTRv3 solves this exact problem, but both sides need to support v3 for it to work.
- Better TOFU support: We should track only one OTR key for a given
XMPP resource/device ID.
Some people I communicate with are constantly rotating OTR keys for security and other reasons. However, this doesn't help me any: I have accumulated about 50 keys of unknown age and usage pattern in my OTR fingerprint list for them, and I have no idea which ones have been changed due to compromise, device loss, or simply due to reinstall. Worse, I have no idea which keys should correspond to which XMPP resources/devices.
+10. This is huge.
As you point out, you get a "Unverified/Verified" when using OTR. Verifying fingerprints of anonymous chat is practically impossible -- every side channel I can think of (telephone, meeting in person, email - ha) either leaks the act of contacting, isn't practical or convenient, or requires some kind of Internet reputation. I'd bet that most OTR users don't verify fingerprints.
TOFU is a must, along with a dialogue that explains in simple terms what is going on, with a way to dismiss the dialogue (e.g. by correctly answering a security question).
Perhaps replacing "Unverified" with "In use for: x days" ?
Oddly, on otr-users there was a recent thread *complaining* that some OTR clients only allow one OTR key for a given user, because users have multiple devices. But if you're only planning to support XMPP, you could indeed probably get away with one OTR key per resource. It's harder to get away with this for other IM protocols, though.
If a user changes the key for a given XMPP resource ID, we should expire the previous key and loudly alert the user of the fact that the resource's key has changed, and ask them if they want to replace the old key with the new key. We should not simply accumulate more keys by default, especially for the same XMPP resource/device, and especially not for unverified keys.
I think you mean that the existing key is expired after the user has OK'd using the new key. The UI should not be something you can just click away or ignore; it should be slightly inconvenient, and perhaps bidirectional (the user whose key changed gets prompted as well).
Every UI element you add, of course, makes it harder to use. What is it that you expect the user to know at runtime that the implementor does not at compile time? Identifying that specific thing will help target the UI.
At the same time, we should allow a different OTR key for each unique
XMPP resource ID, and perhaps allow non-XMPP keys to accumulate at user option.
I'd like the opposite -- I would like to be able to bind the nickname *to* the OTR key, but change the XMPP or IRC id, or to put it another way, be able to keep a persistent cryptographic identity but use whatever underlying transport or throwaway account is convenient.
That's consistent with the above: one OTR key per XMPP id+resource, but one user-visible nickname binds to one (or possibly more) OTR keys?
Admittedly it's not as good as doing away with centralized resources completely, and I think a Hidden Service transport would be very interesting. (And it looks like the Tor network load testing results are looking good ;-) )
A hidden service tiny XMPP server is quite plausible.
- "Unreadable encrypted message" errors should be visible only to
advanced users/in the error console, and the client should transparently renegotiate and resend.
It looks like OTR has an ERROR_START_AKE flag for this, but for some reason, some states of OTR in Pidgin still cause me to get and send these errors and miss messages though, usually if one client has crashed or restarted without properly ending the conversation. We should try extra hard to force key re-negotiation in these cases.
Do you still see this with pidgin-otr 4.x? Can you replicate it?
We probably also want an auto-responder after the renegotiation that informs the other party that N messages were missed (for clients that don't support OTR's built-in notifications).
It doesn't necessarily know, of course. The OTR Error messages are only advisory; they are not securely transmitted.
- OTR shouldn't get stuck in the "Finished" state when you end a
conversation.
Yeah, I've seen this one too.
That's done on purpose. The thing it's trying to prevent is that Alice and Bob are chatting, and Bob ends OTR just before Alice hits Enter on her message. If Alice's client went to "Not private" instead of "Finished", Alice's message would be sent in the clear, which is undesirable. Switching to "Finished" makes Alice have to actively acknowledge that the conversation is no longer secure.
I've noticed in the past that OTR seemed to refuse to automatically negotiate/re-negotiate if it is still "Finished" regardless of your "Require/Force OTR" setting. This is just bad, and often causes plaintext to leak.
I seem to remember fixing this bug. Does it still happen?
- It should be impossible for our client to send a message in plaintext
by default, and the client should discourage counterparties from sending more than one plaintext message.
Perhaps related to issue 3, I've not had very good results with the "Require OTR"/"Force OTR" options on many clients.
It also seems like many people's clients will still send the first message unencrypted (to get the handshake hint), and on all clients OTR doesn't seem to try very hard to negotiate if an unencrypted message is received.
Can you be more specific about "doesn't seem to try very hard"?
On our side, we should hold those messages and send only the handshake initiation (ie our default OTR mode should be REQUIRE_ENCRYPTION).
Yes, I think that makes sense for Attentive Otter.
I think it might be simpler to block input until the OTR handshake has completed. That is, the text input area is simply unavailable (in Force OTR mode).
We may also want to consider a plaintext auto-reply for when we receive unencrypted messages. Something like "Please install and enable OTR before sending further messages" as a separate message in *addition* to attempting an OTR handshake.
Plausible.
It might be better to not fingerprint the client that you are using. OTOH the pidgin-otr plugin does behave this way.
There's no way you'll be able to prevent fingerprinting the Attentive Otter client. It's a different client, and will definitely have different quirks. This is not a design goal as I understand it.
- The UI should have per-message encryption indicators (send and receive)
For many clients, the UI is not clear which messages were sent encrypted, especially if the OTR state has changed due to autonegotiation or "Finishing".
I can't speak to other clients, but pidgin-otr definitely outputs all changes of encryption state to the message window.
We should have per-message icons for both sent and received messages that indicate encryption status for that message in the chat scrollback window.
If the Attentive Otter client is going to be "Force OTR", then you'd only need a special flag for "received insecurely" (much as pidgin-otr has).
That could be a little cluttered; I'd suggest background tinting or only flagging the unencrypted messages with skulls and crossbones.
Is "skull and crossbones" an easily understandable icon for "message received insecurely"? It would certainly need a tooltip hint, or something like that.
- Logging should be off by default when OTR is on.
Agree (as with pidgin-otr 4.x).
I guess people like logging for some reason, and I'll admit that pidgins "History" mode really enables asynchronous chat. Rather than require you *turn off* OTR to get this feature, an alternative would be to require a passphrase and automatically expunge encrypted logs after a configurable period of time. And, unlike other clients, perhaps telling the conversation counterparty that logging is enabled (e.g. the opposite of gchat "OTR" notifications ) at the start of the session would provide informed consent.
Unfortunately, such counterparty notifications cannot be relied on, as you could have hacked your client.
And:
- Require (or at least allow) a passphrase to decrypt the OTR private key.
Or, store the key on a hardware token.
The number of arbitrary file read bugs in pidgin makes me cry...
How is private information (e.g. passwords) stored in InstantBird now?
-
Aaron -
Ian Goldberg -
Mike Perry