[tor-dev] Attentive Otter: Usability issues with existing OTR clients

[Derek Moss <dmts@xxxxxxxxxxxxxxxxxxxxx>]

>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" ?

Changing fingerprints seems like a big problem, because it's
reasonable for users to verify them when they first add a user to
their contacts (via phone or whatever) but they're not going to keep
doing that if the contact keeps changing their fingerprint and will
probably just click OK when warned that the fingerprint has changed. I
have no idea if this exposes a risk from a MITM attack or some other
compromise but it would seem like it might.

Certainly it should be easy to bring up a contact's fingerprint for
verifying, by right-clicking on their name for example and not buried
away somewhere in the preferences.

> > 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).

With Jitsi, I think it's not clear enough whether chats are secured or
not and there seems to be some bugs that cause it send unsecured
messages despite the "Force OTR" setting. I've had problems with it
sending unencrypted messages when starting a conversation from one end
but not in the reverse direction. Obviously this needs to be prevented
and I like the idea of just not sending any text until a secure
connection has been established. For Attentive Otter, hopefully the
"Force OTR" can be made rock-solid and so it should only need to
indicate unsecured incoming message (or maybe even block those but
perhaps there's not much benefit from doing so).

>Is "skull and crossbones" an easily understandable icon for "message
>received insecurely"?  It would certainly need a tooltip hint, or
>something like that.

I think a padlock icon is much more understandable for most users.

> > 7. 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.

On the issue of logging, I'd suggest it would be best to have no
logging features at all. That way, they can't be enabled accidentally
or deliberately and other than the other user running a hacked version
(either on purpose or unknown to them) both users can have more
confidence that their chat isn't being logged.

Of course, this won't prevent the other user cutting and pasting the
conversation to manually log it but that comes down to trusting them,
whereas logging features can cause a security breach without either
party intending to do so.

This was a big issue for a number of users on the Jitsi mailing list
and we were rather disappointed that the devs seemed more focused on
the convenience some users get from being able to refer back to old
conversations than the security from not having conversations logged.
Although the devs didn't really accept that logging could be a
security problem and felt that Jitsi's purpose was to secure chats in
transit and nothing else.

If you must have logging, at least encrypt the logs so that they're
not sitting around in plaintext for anyone to grab.

Despite the issues I've mentioned with Jitsi, I wonder if it might not
be an alternative starting point to InstantBird? I see that it's been
decided you don't want to use Pidgin/libpurple but wonder if other
alternatives, like Jitsi which I understand is free to be forked, have
been considered, where much of the required OTR work might already
have been done?
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev