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?