Closed Bug 1518185 Opened 6 years ago Closed 6 years ago

Agree on initial user interface for OTR

Categories

(Chat Core :: Security: OTR, task)

Product:
Chat Core
Component:
Security: OTR
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: KaiE, Unassigned)

References

Details

Attachments

(22 files, 2 obsolete files)

01-otr-inline-status.png
105.44 KB, image/png
Details
not-private.png
1.47 KB, image/png
Details
unverified.png
1.61 KB, image/png
Details
private.png
1.55 KB, image/png
Details
finished.png
1.57 KB, image/png
Details
02-otr-button-menu.png
8.04 KB, image/png
Details
03-otr-status-genkey.png
12.99 KB, image/png
Details
04-otr-genkey-failed.png
8.42 KB, image/png
Details
05-otr-notification-request-to-verify.png
41.19 KB, image/png
Details
06-otr-verify-dialog-with-options.png
49.03 KB, image/png
Details
07-otr-verify-question-answer.png
28.69 KB, image/png
Details
08-otr-verify-shared-secret.png
24.80 KB, image/png
Details
09-otr-verify-manual-fingerprint.png
46.69 KB, image/png
Details
10-otr-incoming-validation-request.png
16.77 KB, image/png
Details
11-otr-buddy-popup-menu-add-fingerprint.png
7.52 KB, image/png
Details
12-otr-manuall-add-fingerprint.png
14.66 KB, image/png
Details
13-otr-preferences.png
36.83 KB, image/png
Details
14-otr-known-fingerprints.png
34.27 KB, image/png
Details
15-otr-prefs-no-key-yet.png
34.32 KB, image/png
Details
OTR-side-panel.jpg
859.75 KB, image/jpeg
Details
otr-ui-update.patch (moved to bug 1518172)
140.68 KB, patch
KaiE
: feedback+
Details | Diff | Splinter Review
otr-notification.png
245.93 KB, image/png
Details
The code from bug 1518172 comes with some UI already, which was available in Tor messenger. We already identified a mandatory set of changes, because Tor Messenger used a separate window for each chat, while Thunderbird uses a single chat window, which contains all active conversations, in separate tabs. With OTR, each conversation has a certain OTR state, for example: - not using OTR - using OTR with opportunistic encryption (peer not authenticated/verified) - encrypted and authenticated (there might be more states) With the above code, a lock icon was used, that can appear in different states. When clicked, a menu appeared, that can be used to trigger a change of the above states, for example, start an interactive authentication of the peer. Previously, each conversation window contained its own status/action button. We'll need a new place for this button. One option is to use a single status icon and button, which changes its state, whenever the user switches to a different conversation. Another option is to add a separate button for each conversation on the left hand side, that lists all conversations. In that list, each line already displays an icon for the protocol type, like an XMPP icon. The OTR status icon/button could be displayed next to it. There's additional UI, dialogs that interact with the user to perform mutual authentication, or that display technical information about the OTR session or the peer, or that control preferences for each contact (e.g. forbid unencrypted conversations with a contact). We'll also require a new menu item, that can be used to open the same popup actions that the lock icon button offers. The intention of this bug is to discuss the UI we're OK to use initially. It might be easiest to wait until some initial porting has been completed, and nightly can be setup to interactively test OTR and the imported UI. Or, if you'd like to, I could attach screenshots of the UI as it was offered by the old Tor Messenger application.

In order to bootstrap thinking about this, it could be good to attach screenshots of how it worked in Tor Messenger.

From memory (so I'm probably wrong), I thought the states were more of:

  • Unencrypted
  • Encrypted, not verified
  • Encrypted, verified

I don't think whether the encryption was done opportunistically factors into the state.

I believe that Florian didn't love the old UI, but I'm not sure if he had ideas of how to make it better.

My initial gut is that adding more icons to the conversation list will make it cluttered.

I'm going to add many screenshots (at least 15), and will write a comment for each, which describes it.

Please wait with adding comments, until I have added all screenshots.

With OTR enabled, status messages related to the OTR connection will automatically be displayed into the the conversation window. This is an example of status messages. Usually, you'd see the messages that were exchanged in between those messages.

01 also shows the lock icon that was mentioned earlier.

It may have 4 states. I'm using the names that were used as the filenames for the respective icons of the states.

  • not-private
    This is the default. It means "no active OTR session, not encrypted"

  • unverified
    An OTR session has been established, and both sides are using encryption for sending messages.
    However, it hasn't been verified/validated, if the encryption keys really belong to the intended communication partner.

  • private
    OTR session is active, encryption is used. The key ownership has already been successfully verified.

  • finished
    This state indicates that the peer has ended their encrypted OTR session.

BTW, Florian has suggested that we could add this button to the toolbar in the Thunderbird chat window.
If we do, the icon must automatically get updated whenever the user switches to a different conversation.

Attached image not-private.png —
Attached image unverified.png —
Attached image private.png —
Attached image finished.png —
Attached image 02-otr-button-menu.png —

When clicking the lock icon, this menu is shown.

It can be used to:

  • start or end an OTR encrypted session
  • trigger a verification of the contact's key
  • open OTR preferences

Not shown, but we should add a new menu item to the regular menu bar (top menu bar), where the OTR preferences can be accessed from, too.

When using OTR for the very first time with your own account (not once for buddy), a private key for yourself will be randomly created.

On slow computers, this could take a couple of seconds. This dialog will be shown during the random key generation. (The DONE button is disabled during generation.)

It will automatically be closed as soon as the key generation is completed.

On a fast, modern computer, it's difficult to notice this dialog, it flashes up very shortly.

If the key generation failed for whatever reasons, this dialog will be shown, and hopefully contain a helpful message (instead of the text "an error message"), which the code will dynamically insert.

Most users will probably never see this window. It could mean a software installation problem or system failure.

If a conversation with a buddy is started, this notification will popup at the top of the conversation window.

It's a good mechanism to educate the user about the recommendation to verify the peer.

Note that if a user ignores the popup, it might remain shown for a while.
Given that we don't have a dedicated window for each conversation, I wonder what should happen if the user switches between conversations. I think we must hide the notification as soon as the user switches to a different conversation. What should we do if the user switches back to an unverified conversation, that previously had this notification open? It might be easiest to keep it hidden.

If the user accepts the suggestion from the previous screenshot, to verify the peer, or if the user later uses the popup menu and selects "verify your contact's identity", this dialog will open.

It offers multiple mechanism for verifying. By default, the first option is selected. If the user clicks the top list, the shown menu of options will be shown.

The contents of the dialog will change, depending on the user's selection.

06 is for the previous comment 13

verification mechanism "question and answer".

dialog is self explanatory

verification mechanism "shared secret".

Dialog is self explanatory.

verification mechanism "manual fingerprint verification".

A fingerprint is a shorter human readable display of a user's private/secret key (which is much bigger). The fingerprint is automatically created using some mathematical procedures.

This dialog shows both the user's own fingerprint, and the buddy's fingerprint. As explained in the dialog, it can be used to compare both sequences with the communication partner, e.g. over the phone, or in person.

Potentially, the local user might have decided to ignore the notification (05).

However, the buddy could potentially make the first move, and request the verification. If that happens, a dialog like this will appear.

I think this dialog should be improved. The local user might be very surprised what this dialog means, because it might appear unexpectedly. The top window bar is too short, might be insufficient to explain the situation to the user.

I suggest that we add some more text at the top, inside the window, such as:

"Your buddy from@host has sent you a request to verify your shared encrypted communication channel, to ensure nobody else is listening."

There might be other messages involved to the previous verification sequence. For example, error messages will be shown if unsuccessul. I haven't gone through all potential iterations yet.

In addition to the verification mechanisms explained above, which all seem to happen during an interactive session with the buddy, there's an additional mechanism, apparently non-interactive.

The right click menu in the buddy list opens a popup menu, and OTR adds the command "Add contact's fingerprint", as shown in this screenshot 11.

If the previous menu item is selected, this dialog 12 appears, which allows the user to enter a fingerprint.

It might be useful if you have received a business card with the peer's fingerprint, and you want to enter and store it immediately. It will probably be stored locally, and used during the next conversation.

BTW, I haven't yet tested the UI that will be shown if a previously verified buddy switches to an unkown key.

Attached image 13-otr-preferences.png —

This OTR preferences dialog shows, if the users selects the preferences command in the menu shown in screenshot 02.

At the top, the fingerprint for the user's own OTR key is shown.
Using the dropdown list, a different local account can be selected. This way, the fingerprints for all local accounts can be inspected, one at a time.

The "known fingerprints" section allows the user to open another dialog, which will display the fingerprints for all buddies the local user has communicated with, and manage them. I'll explain that with the next attachment.

In the bottom section are other global preferences.

I'm guessing the preference "require encryption" will prevent all unencrypted message from being sent or displayed.

The "always nudge" preference probably means to always show the notification reminder from screenshot 05, whenever a conversation with an unverified peer starts?

The "view" button from screenshot 13 will open this dialog. It contains a list of all remembered buddy fingerprints, and whether or not they have been verified. This could be helpful to double check which keys the user has verified in the past, and potentially re-verify them. Or, if you know a buddy has lost their old key and is switching to a new one, to delete it here.

Selecting an item, and clicking the verify button, will trigger the same action as the verify button from 05, or as the verify menu command from 02.

14 is for the previous comment 23.

This shows a slight different preferences dialog.

If a local account is selected, which has never used OTR before, there might not yet be a local private key associated to it.

In that scenario, no local fingerprint will be shown, but instead a button will be shown, that can be used to generate the private key.

Although this can usually happen automatically, the user might prefer to prepare by generating this key early, prior to communication. The generation will trigger the same status dialog 03, and potentially error 04, as explained earlier. Once the key generation is completed, the dialog will update, and look similar to 13, with the "generate" button removed, and the new local fingerprint shown.

Thanks for your patience, I'm finished adding the screenshots and initial set of explanations.
The bug is now open for your comments.

Regarding the button and state that is shown in screenshots 01 and 02.
It is a state related to the selected conversation.

On the right hand side of the window, to the top right of the conversation text, and above the "previous conversations", we have the rectangle that shows more details related to the current conversation.

It contains the buddy's icon and the availability message.
It changes whenever a different conversation is selected.

I think this might be a good place to also show the OTR status icon.

Note that we must hide (or disable) the OTR status icon, whenever the user selects a converation that doesn't support OTR, such as a multi-user change window (e.g. an IRC channel).

If we display the OTR status icon in that top right section, the disappearing or appearing OTR status icon might appear natural, and be not very noticable.

Compare that with the idea to have the OTR icon in the toolbar, next to the "show accounts" button, or next to the availability icon. The OTR button would either appear or disappear whenever we switch to a conversation, and this flickering might feel like a visual disruption. We probably shouldn't keep the button visible, but disabled, while an IRC conversation is selected, because it isn't clear what state the disabled button should show, and it might be confusing, since it's non-applicable.

(In reply to Kai Engert (:kaie:) from comment #4)

  • finished
    This state indicates that the peer has ended their encrypted OTR session.

I don't see why the user would ever care that they used to be encrypted and now aren't. This really sounds the same as "not-private" to me.

(In reply to Kai Engert (:kaie:) from comment #10)

When using OTR for the very first time with your own account (not once for buddy), a private key for yourself will be randomly created.

I think we had a hope that this could be done in the background at some point instead of asking a user to wait there while data is generated.

(In reply to Kai Engert (:kaie:) from comment #18)

I think this dialog should be improved. The local user might be very surprised what this dialog means, because it might appear unexpectedly. The top window bar is too short, might be insufficient to explain the situation to the user.

It would be nice if the user was not completely blocked until answering this query. It might make more sense to look like attachment 9035027 [details] (where it pops down from the conversation, instead of being a dialog box).

(In reply to Kai Engert (:kaie:) from comment #27)

Regarding the button and state that is shown in screenshots 01 and 02.
It is a state related to the selected conversation.

On the right hand side of the window, to the top right of the conversation text, and above the "previous conversations", we have the rectangle that shows more details related to the current conversation.

I agree that this would likely be a good spot for this since it is related to the conversation. OTR, as you mention, does not support multi-user chats, but I believe there are other end-to-end encryption techniques that do, so this could easily be expanded in the future to support that!

Thanks for going through and dissecting the current UI!

(In reply to Patrick Cloke [:clokep] from comment #28)

(In reply to Kai Engert (:kaie:) from comment #4)

  • finished
    This state indicates that the peer has ended their encrypted OTR session.

I don't see why the user would ever care that they used to be encrypted and now aren't. This really sounds the same as "not-private" to me.

In my understanding, the "finished" state is protecting the user from accidentally sending a confidential message without encryption, although the connection state has changed to no longer being secure. As long as you are in the finished state, you are protected from sending messages without encryption, even if you type a message and hit enter.

Consider you have established the connection, and you noticed it has switched to private.
You start typing a confidential message.

All of the sudden, the other side disconnects, and the state of the connection switches to not-private. However, you don't notice, because you're still focused on typing your message.

If the UI automatically switched back to "not private", and you press enter, your message would be sent without encryption, thus leaking all the secret information you just typed.

Or consider that the connection switched to not-private just a few milliseconds before you hit enter. Your brain might not notice the change that quickly, and your hand might continue hitting the enter key.

To protect the user, it's required that the user explicitly ends the secure connection, by using the OTR state button menu. To allow the user to discover that, system messages are displayed in the chat window that explain it.

More thoughts on the finished state and possible behavior can be found here:
https://lists.cypherpunks.ca/pipermail/otr-dev/2009-August/001067.html

Screenshot 13 shows the old preferences popup dialog. I assume we want to integrate that into the global preferences.

One of the preference categories is "Chat", which currently has two sub-categories "General" and "Message Styles".

Questions:
(1) Do you agree to we add a third tab here?

(2) What label should be used for the tab?
Suggestions:
a: Security
b: Security (OTR)
c: OTR Security
d: OTR
e: Off-The-Record Messaging

Should we ever add support for additional security protocols in the future,
which also need preferences, it's unclear if a single tab will have sufficient
space for both OTR and other preferences.
Therefore it might be useful to include the term "OTR" in the heading.

If you prefer to use the official and full name (e), should it be marked as
translatable, or should the english term be kept in other languages?

(FYI, background on this protocol can be found at https://otr.cypherpunks.ca/
if you'd like to read more about the terms.)

(3) The above pane has a "view" button, which opens a popup, as shown in screenshot 14.
I assume we want to implement that similarly as other popups inside prefs,
for example, like in "Composition / General / Keywords"

(4) The old code made the OTR preferences discoverable at two places:
- in the dropdown menu that opens when the OTR button is clicked
(see screenshot 02)
- in the global window menu, in the Tools submenu

Should we remove the menu commands "OTR preferences" from both places?
As a result, users would be required to open the global preferences
to find the OTR preferences.
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(alessandro)

(In reply to Kai Engert (:kaie:) from comment #31)

Screenshot 13 shows the old preferences popup dialog. I assume we want to integrate that into the global preferences.
(3) The above pane has a "view" button, which opens a popup, as shown in screenshot 14.
I assume we want to implement that similarly as other popups inside prefs,
for example, like in "Composition / General / Keywords"

I really wish there was a way to make this less technical. The average user is going to have no idea what to do with that view..

(4) The old code made the OTR preferences discoverable at two places:
- in the dropdown menu that opens when the OTR button is clicked
(see screenshot 02)
- in the global window menu, in the Tools submenu

Should we remove the menu commands "OTR preferences" from both places?
As a result, users would be required to open the global preferences
to find the OTR preferences.

I think open the preferences can be necessary (we don't need it when the OTR button is clicked).

Do any of these options belong as options for each account? As opposed to in the global preferences?

(In reply to Patrick Cloke [:clokep] from comment #32)

I really wish there was a way to make this less technical. The average user is going to have no idea what to do with that view..

The upper half of screenshot 13 is an advanced view.

It's used to learn about the fingerprint of the user's own automatically generated private key, which is useful when you want to make a note of it. For example, you might decide to advertise it on your web page, or on a public profile page, or on your business card.

The "list of fingerprints you have seen" is for learning about your contacts that you have already setup a verified connection with, and it could be used to cleanup, if you have trouble communicating with someone.

Do any of these options belong as options for each account? As opposed to in the global preferences?

Yes, the upper half are settings for each account. The old code used a dropdown to select the account you'd like to configure.

Looking at the existing chat account preferences, we only have a single pane, and it seems already quite full.

If you prefer to have the "my key", "my seen fingerprints" in account preferences, then we'll have to decide if we want to add another sub-tab for these OTR prefs, or if we want to use a popup window. To avoid a double-popup, we could combine the upper half of 13 and 14 in a single panel or dialog (and avoid the "view" button).

Regarding the lower half of 13, these are currently global preferences. If they stay global, we'll have to add the global preferences chat tab, just for these two. (We should probably improve the labels, with a slightly longer explanation what the prefs are about.)
Or we could decide to allow their configuration per account.

Initial suggestions for more detailed text for the global preferences:

Require encryption:
Always require encrypted chat. If you enable this option, Chat communication
is limited to contacts that use OTR compatible software.

Always nudge to verify your contact's identity:
(It's a TODO for me to find out what exactly this does, but most
likely something like this:)

Always remind me to verify that the connection to my communication
partner is protected against Man-In-The-Middle attacks, if it
wasn't done yet.

(In reply to Kai Engert (:kaie:) from comment #30)

More thoughts on the finished state and possible behavior can be found here:
https://lists.cypherpunks.ca/pipermail/otr-dev/2009-August/001067.html

I agree that the finished state is important and a clear and visible alert should warn the user if an encrypted connection ends for whatever reason.

Ideally, these steps could happen in case of the scenario described in the link:

  1. The lock button/icon changes state to Finished
  2. A message should appear in the chat history to warn the user that the encryption as ended, explaining the reason (other user disconnected, or something else)
  3. If the user has the option Require encryption checked, we could maybe consider disabling the Send Button to completely avoid accidental message submits.
  4. If the user doesn't have the option Require encryption checked, we shouldn't disable the Send Button but we could instead trigger a one time confirm() dialog when the user submits the message to be sure he's aware that the message is sending will not be encrypted since the connection has been closed.

Maybe we could have an action in the dialog like "Try to re-established encrypted connection and send the message", or not have this option but avoid to clear the text area.(In reply to Kai Engert (:kaie:) from comment #31)

Questions:
(1) Do you agree to we add a third tab here?

If we put the third tab there, we should find a way to properly handle the per-account settings in this same area. It's better not to split the OTR settings in multiple location and allow the user to control everything from the same place, but with that, as you said, we could stumble upon the issue of having multiple popups.

Regarding the lower half of 13, these are currently global preferences. If they stay global, we'll have to add the global
preferences chat tab, just for these two. (We should probably improve the labels, with a slightly longer explanation what
the prefs are about.)
Or we could decide to allow their configuration per account.

Maybe we could consider allowing those two settings to be per account. What if the user wants Require encryption ON for his jabber account, but OFF for his IRC account?

(2) What label should be used for the tab?
Suggestions:
a: Security
b: Security (OTR)
c: OTR Security
d: OTR
e: Off-The-Record Messaging

Should we ever add support for additional security protocols in the future,
which also need preferences, it's unclear if a single tab will have sufficient
space for both OTR and other preferences.
Therefore it might be useful to include the term "OTR" in the heading.

What about the possibility of having the third tab called Security and then list there all the protocols we currently support? For now it would be only OTR, but at least we would have more space for a title and description and be more understandable for users that don't know the "OTR" acronym.

We could then have a Settings button which opens up a dialog with all the protocol related options, similar to how it's handled here: Display > Formatting > Advanced, and we could have a row per each account with its own Settings button.

Should we remove the menu commands "OTR preferences" from both places?
As a result, users would be required to open the global preferences
to find the OTR preferences.

If we do that, we could probably consider adding a quick "shortcut" in the chat panel to allow the user to quickly access those settings. It may be a natural thought process for the user to go in the Chat panel instead of the Global Preferences to check which security options can be set up.

Flags: needinfo?(alessandro)

I just skimmed the above comments and haven't read more than a few words from the long ones, but I'm worried that this currently seems headed toward a UI that assumes technical knownledge from the user.

I don't have time to fully think this UI through, but here are some guiding principals I would suggest:

  • no modal dialogs.

  • never require user actions on the UI for things that can be done automatically. Eg a "generate key" button is inappropriate. This can be done automatically in the background without interrupting the user.

  • the part that is hard in designing a good UI for this, is finding a way to authentify the user at the other end; encryption is pointless if you talk to the wrong person, but there's no automated way to identify the person at the other end.

  • I think the sensible default behavior of the UI is to opportunistically enable encryption if we detect the other end can support it, and auto-accept whatever key is presented. Then, in the future, if a key we are presented doesn't match what we saw before, make it very visible to the user. This could be with a message with a red background and a scary icon displayed in the conversation, saying something like:
    "Caution! While this conversation is encrypted, your contact doesn't appear to be using the same equipment as last time. If you are about to share any sensitive information, verifying first that you are talking to the expected person is recommended."

This phrasing intentionally doesn't say anything about a 'key'. The people who want to verify keys are the same as people who want to look at the hexadecimal fingerprint of the SSL certificate of their bank: they click on the lock icon in the urlbar, and look at the dialogs from there. It's find for the dialogs appearing at this point to target more technical users.

I assume when a conversation is encrypted there would be a lock icon in the top right area (where the contact's name and icon is displayed). Anything that's providing information about the current state of the conversation should go in that area.

Things used by the user to initiate actions could go in the toolbar. Eg. we could consider a "Start encryption" button if needed.

What I described is the default behavior meant to be usable for most users with as little friction as possible, to encourage broad adoption. We could have options to require encryption and refuse sending unencrypted messages for more privacy-conscious users (eg Tor users).

Attached image OTR-actionbar.jpg (obsolete) —

I tested and poked around the daily build with OTR, great job Kai, so far I didn't stumble upon any bugs.

I attached a quick mock-up to analyze and (I hope) improve the UX of activating a new Private conversation and handling messages and alerts.

Per-account toolbar
I'd like to propose the implementation of a per-account toolbar which will host the OTR button and any alert or action required related to that account.

Right now, whenever there's an action required or a warning, a full width alert bar appears and pushes the UI down. This approach creates some fundamental issues:

  • When the user is required to verify an account, that message remains globally visible, even when switching between conversations and users.
  • If the Verify account warning is visible, it covers other alerts like "You're invited to connect".
  • When multiple conversations require to be verified, it's impossible to know which alert belongs to which conversation.

Creating a dedicated per-account toolbar can solve all those issues, and allow to use the full width alert bar only for global notifications or connection requests.

Privacy button
I'd like to propose to have a more discoverable and readable button in the top left corner of the toolbar. The button should update its icon and text based on the current status of the conversation.
Dedicated colored warnings should appear alongside the button to catch the eye of the user and avoid confusion.

This type of button will solve the following issues:

  • Discoverability of the OTR feature
  • Always knowing the status of a conversation at a quick glance without the necessity of hovering over the icon
  • Resembling the currently used convention of a dropdown button to change email privacy

Thoughts?

I suppose you mean per conversation toolbar?

Anyway, the suggested UI looks good.

I'm not sure it's correct though: what requires thought is how (if at all) we want to say that the opportunistic encryption state is Private. The thing is, we can't really say if there's someone listening in or not (a MITM attack is very feasible), and I'd not want to give a false impression of security. On the other hand, many conversations aren't likely sensitive as such, but you might want to encrypt anyway... so there's a trade-off.

Regarding terms, I think perhaps using the terms as Complete Encryption is preferable over Private. While slightly nerdy, it's still used e.g. by Whatsapp, so people are likely used to seeing it. (My Whatsapp is not in English so I'm unable to check if that is exactly the term they use now.)

Flags: needinfo?(mkmelin+mozilla)

(In reply to Alessandro Castellani (:aleca) from comment #35)

Ideally, these steps could happen in case of the scenario described in the link:

  1. The lock button/icon changes state to Finished

Yes, that's happening today.

  1. A message should appear in the chat history to warn the user that the encryption as ended, explaining the reason (other user disconnected, or something else)

Yes, that's happening today. However, multiple events might be triggered, for example, a first event might say "private session ended", and then immediately afterwards "other user disconnected". The current UI automatically folds multiple system messages behind a + button, with only the last system message remaining immediately visible (unless the user clicks the + button).

It might be useful to change the collapsing behavior, to ensure that the most recent messages are always visible.

  1. If the user has the option Require encryption checked, we could maybe consider disabling the Send Button to completely avoid accidental message submits.

I don't see a send button in the user interface, I don't know if the chat UI deliberately doesn't have one.
The send action is triggered with the enter key.

I think you might not yet have had the chance to play with this configuration, because we don't have a preferences UI for this setting yet. If you want to play with this configuration, you can use the config editor and change the pref chat.otr.requireEncryption to true.

Today, if the user has Require encryption checked, the send action is accepted, information "not yet sent" is added locally to the system messages, TB automatically attempts to establish a private conversation, and if successful, TB will then send the encrypted message. What do you like better, the current behavior, or your suggestion to disable the send button?

  1. If the user doesn't have the option Require encryption checked, we shouldn't disable the Send Button but we could instead trigger a one time confirm() dialog when the user submits the message to be sure he's aware that the message is sending will not be encrypted since the connection has been closed.

We don't seem to have a send button currently. If we add one, it might it be confusing for the user the hide it. Changing a potential send button into a disabled state might potentially make it more obvious to the user that sending isn't possible. Anyway, as long as we don't have a send button, we don't need to solve that detail yet.

Let's talk about the equivalent, which is to hit the enter key.

If Require encryption isn't checked, and we're in the finished state, you suggest that the send action remains possible. The user is always able to hit the enter key, so we must decide what happens.

Today, the input text box will clear, and the following system message is shown: "... has already closed their private connection to you. Your message was not sent. Either end your private conversation, or restart it."

The message that the user attempted to send is not shown. That isn't ideal. If the user had typed a long message, the user might be very unhappy that it's gone and the user has to type it again.

It might be best to disable the send action, and to keep the message in the input text box. I'm not sure if we should show a dialog box, because no other action currently triggers a dialog box. All user information seems to be done by adding system messages to the chat window. Maybe it would be preferable to avoid a dialog popup, and instead add the system message "your message wasn't sent, because..."?

In addition, we have a timing issue. We might assume that the private conversation is still established, accept the send action, and attempt to send it. Exactly during these events, the connection might break, and we might be unable to send the message as intended. To cover this scenario, it might be useful to extend the above system message "... closed connection, message not sent" by adding the message text that the user tried to send. That way. the user has a chance to copy/paste the old message and try again.

Maybe we could have an action in the dialog like "Try to re-established encrypted connection and send the message", or not have this option but avoid to clear the text area.

because no other action currently triggers a dialog box
->
because no other error action currently triggers a dialog box, only actions that require a decision or interaction from the user

(In reply to Alessandro Castellani (:aleca) from comment #37)

Created attachment 9052142 [details]
OTR-actionbar.jpg

Thoughts?

There's already a per-conversation bar giving information about the current state of the conversation and the contact you are talking to. It's the area you see at the top of the right sidebar.

Creating a second bar of a different height looks really broken. Either you want to add your new UI to within the existing top bar we have on the right panel, or if you think this deserves more space, you need to move that area we currently have at the top of the sidebar so that it extends over the top of both the message area and the sidebar.

(In reply to Alessandro Castellani (:aleca) from comment #35)

Regarding the lower half of 13, these are currently global preferences. If they stay global, we'll have to add the global
preferences chat tab, just for these two. (We should probably improve the labels, with a slightly longer explanation what
the prefs are about.)
Or we could decide to allow their configuration per account.

Maybe we could consider allowing those two settings to be per account. What if the user wants Require encryption ON for his jabber account, but OFF for his IRC account?

Yes, we're technically able to make both per-account preferences.

Maybe that's the best approach, to have all preferences per account.
It gives the user more control, avoids a mix of global and per-account preferences, and we avoid the account dropdown that was used in the old fingerprint preferences.

If we agree, we'd no longer have any global preferences, but would introduce a new sub-category into account preferences, for each chat account.

What about the possibility of having the third tab called Security and then list there all the protocols we currently support? For now it would be only OTR, but at least we would have more space for a title and description and be more understandable for users that don't know the "OTR" acronym.

The same discussion applies to a new sub-category in chat account preferences.

Even if the title used the OTR acronym, we'd still have the option to explain the OTR acronym inside the shown tab.

If we label it Security, and if we'll ever add more security mechanisms that need their own global preferences space, we'd have to use another level of nesting for the individual Security sub-categories, which I think we'd want to avoid.

But for now, I'm OK to use the general "Security" label. Should we ever need additional security preference categories, we could still rename it to "OTR Security" in the future.

Inside the tab we could show:

Off-The-Record (OTR) Chats:

[x] Always require encrypted chat.

If you enable this option, sending a message requires that your
contact uses OTR compatible software.

[x] Always remind me to verify my communication partner's identity.

Verifying the identity protects you against Man-In-The-Middle attacks.

Your private key's fingerprint:
ABCDEF 123456 ...

Known fingerprints (of your contacts):
...

I'm unsure how we'd display and allow the management (e.g. removal)
of the remembered/verified fingerprints of chat contacts.
The dialog shown in screenshot 14 is rather wide, it seems to me it's
too wide to fit in the right hand side of the account preferences.
It might be best to continue to use the existing, separate popup
dialog for managing them.

Should we remove the menu commands "OTR preferences" from both places?

FYI, I've already removed the menu commands, because we seem to be in agreement that the OTR preferences will no longer use their own pop-up.

As a result, users would be required to open the global preferences
to find the OTR preferences.

If we do that, we could probably consider adding a quick "shortcut" in the chat panel to allow the user to quickly access those settings. It may be a natural thought process for the user to go in the Chat panel instead of the Global Preferences to check which security options can be set up.

Interesting idea, but I don't know if it's possible to directly
This optimization shortcut could be handled in a separate bug.

(In reply to Alessandro Castellani (:aleca) from comment #37)

Created attachment 9052142 [details]

I attached a quick mock-up to analyze and (I hope) improve the UX of activating a new Private conversation and handling messages and alerts.

Thanks for making a mock-up, it really drives conversation better than trying to describe what we're all talking about. I agree with Florian, however (see comment #41) that another notification bar is NOT the way to go here. This information should be added to the part of the UI that we already have for per-conversation UI elements. Door hangers could likely be used to display additional information / provide actions to be taken.

Privacy button

I think in this part you essentially are saying you want every conversation to say whether it is "secure" or not (purposefully not using the term "encrypted" here)? Is that accurate? I think this makes sense, as an icon, but belongs in the top-right section, as discussed above.

(In reply to Kai Engert (:kaie:) from comment #42)

Inside the tab we could show:

Off-The-Record (OTR) Chats:

[x] Always require encrypted chat.

If you enable this option, sending a message requires that your
contact uses OTR compatible software.

[x] Always remind me to verify my communication partner's identity.

Verifying the identity protects you against Man-In-The-Middle attacks.

I think this would make sense as a dropdown with three options (the words below aren't the best, but you get the idea):

  • Always require encrypted chat.
  • Opportunistically encrypt chats.
  • Never encrypt chats.

Note that "always" is not technically possible for chat rooms (e.g. an IRC channel or an XMPP MUC). It isn't really clear what to do in that case.

I'd like to see mock-ups of the preferences as well.

(In reply to Florian Quèze [:florian] from comment #36)

I don't have time to fully think this UI through, but here are some guiding principals I would suggest:

  • no modal dialogs.

The verification popups are dialogs, but they aren't modal.

  • never require user actions on the UI for things that can be done automatically. Eg a "generate key" button is inappropriate. This can be done automatically in the background without interrupting the user.

You're referring to the button shown in screenshot 15, if the user doesn't have a key yet.

Using that button isn't required, it's there for convenience.

The implementation already complies with your request, the key is automatically generated the first time it's required.

Because key generation can be a lengthy operation on slow computers, and we don't want to surprise the user with a non-responsive Thunderbird, I think it's reasonable to delay the generation to the time of first use.

(If a user updates to the Thunderbird version that supports OTR, and the user has 10 chat accounts, and the user opens the chat preferences, you don't want to automatically create 10 keys, which could slow down the computer very much, do you agree?)

This means, it would be safe to remove the button that you've seen in screenshot 15. We'd have to show the text "None yet".

However, having this button supports an additional use case. A user might decide to prepare for OTR chats, with a new account, which hasn't yet been used with any OTR contact. And the user might want to prepare, by knowing the OTR fingerprint in advance, so it can be written down and communicated to the potential future chat partner during a personal meeting. If we remove the button, we make this scenario impossible. The user would then require to have a successful OTR chat with anyone, prior to being able to write down the fingerprint.

Or, alternatively, we'd have to always generate the key in advance. But when? What's the right time to trigger the slow background operation?

IMHO having the button doesn't hurt.

  • the part that is hard in designing a good UI for this, is finding a way to authentify the user at the other end; encryption is pointless if you talk to the wrong person, but there's no automated way to identify the person at the other end.

  • I think the sensible default behavior of the UI is to opportunistically enable encryption if we detect the other end can support it, and auto-accept whatever key is presented.

Yes, that's how the current code behaves.

Then, in the future, if a key we are presented doesn't match what we saw before, make it very visible to the user.
This could be with a message with a red background and a scary icon displayed in the conversation, saying something like:
"Caution! While this conversation is encrypted, your contact doesn't appear to be using the same equipment as last time. If you are about to share any sensitive information, verifying first that you are talking to the expected person is recommended."

Yes, I agree. Even if the user has never verified the contact's identity, showing a notification for this scenario is important.
I believe the current code displays a simple system message, inline with the other system messages.

Making this more visible is sensible. We could even consider to block all outgoing messages to this account until the user acknowledges the change of key.

Maybe we should spin of this detail into its own bug, to avoid having everything in this one bug?
"OTR: Implement proper handling of key changes, for both verified und unverified keys."

I assume when a conversation is encrypted there would be a lock icon in the top right area (where the contact's name and icon is displayed). Anything that's providing information about the current state of the conversation should go in that area.

Yes, the current code does that. I invite you to try the experimental build I mentioned in email.

Things used by the user to initiate actions could go in the toolbar. Eg. we could consider a "Start encryption" button if needed.

Note that we cannot start the encryption in chat rooms, only in 1:1 chats.
This means, we'd either have to disable that toolbar button whenever the user switches to a chat room, or hide it.

Also, we need to agree on consistency for wording. The current UI always uses the term "private conversation". So we'd have to use the same text in the button. Are those texts maybe too long for a toolbar button?

We could have options to require encryption and refuse sending unencrypted messages for more privacy-conscious users (eg Tor users).

I think the use of Tor is orthogonal. A user might want to always send encrypted messages for confidentiality, but might not require the anonymity that Tor offers. Also, we don't know if Tor is being used.

(In reply to Kai Engert (:kaie:) from comment #44)

The verification popups are dialogs, but they aren't modal.

Maybe. The window in screenshot 15 doesn't seem well integrated for something that's no longer an add-on.

Either it's global preferences that should go in the Thunderbird preferences, or it's per-account preferences that should go with the other per-account preferences.

Because key generation can be a lengthy operation on slow computers, and we don't want to surprise the user with a non-responsive Thunderbird

Why is it slow? "non-responsive Thunderbird" implies this is done on the main thread; why is it done on the main thread?

(If a user updates to the Thunderbird version that supports OTR, and the user has 10 chat accounts, and the user opens the chat preferences, you don't want to automatically create 10 keys, which could slow down the computer very much, do you agree?)

No. Would you ever show more than one key at once? I suspect most users never want to see the key anyway... so maybe it's fine if the key itself is hidden in a sub dialog.

We could have options to require encryption and refuse sending unencrypted messages for more privacy-conscious users (eg Tor users).

I think the use of Tor is orthogonal.

With the mention of Tor, I was just saying that the fork of Thunderbird distributed by the Tor Project might have a different default setting here.

(In reply to Alessandro Castellani (:aleca) from comment #37)

I attached a quick mock-up to analyze and (I hope) improve the UX of activating a new Private conversation and handling messages and alerts.

I think using the term "Public" isn't ideal. Unprotected conversations still requires someone to actively monitor to read them. I think the term "not private" describes it well. On the other hand, are we worried that people miss the word "not"?

Instead of public, I'd suggest either "Not Private", "Insecure", "Unprotected" or "Unconcealed".

(In reply to Magnus Melin [:mkmelin] from comment #38)

what requires thought is how (if at all) we want to say that the opportunistic encryption state is Private. The thing is, we can't really say if there's someone listening in or not (a MITM attack is very feasible), and I'd not want to give a false impression of security.

That's a very good point that we haven't discussed yet.

Currently, the user interface uses the term "private" all the time, even when unverified, and I agree that it is imprecise, and can be misleading.

A precise description for the opportunistic/unverified state would be "Potentially Private", or "Unverified Privacy". I would welcome and encourage the use of a more precise term.

Regarding terms, I think perhaps using the terms as Complete Encryption is preferable over Private. While slightly nerdy, it's still used e.g. by Whatsapp, so people are likely used to seeing it. (My Whatsapp is not in English so I'm unable to check if that is exactly the term they use now.)

I looked at my Whatsapp, but couldn't find the term. Where do you see it? In Android, if I click the three dots, view contact, scroll down, there's a section "Encryption", and for an unverified contact, it says "Messages to this chat and calls are secured with end-to-end encryption. Tap to verify".

I get the same text for verified and unverified contacts, it doesn't change.

Using the term "End-to-End encryption" is technically correct, even though the other end could still be a MITM.

The following would be correct pairs of terms:

Idea No encryption Unverified Verified
(a) Not Private Potentially Private Private
(b) Unconcealed Unverified Privacy Private
(c) Insecure Opportunistic Encryption End-to-End encryption

(In reply to Kai Engert (:kaie:) from comment #46)

(My Whatsapp is not in English so I'm unable to check if that is exactly the term they use now.)

I looked at my Whatsapp, but couldn't find the term. Where do you see it?

On the very top of a conversation with someone (you may need to scroll up to the start) there is a yellow bar saying something like (freely translated) "Messages in this chat and calls are now secured using complete encryption. Click for further info".

(In reply to Magnus Melin [:mkmelin] from comment #47)

On the very top of a conversation with someone (you may need to scroll up to the start) there is a yellow bar saying something like (freely translated) "Messages in this chat and calls are now secured using complete encryption. Click for further info".

Thanks, found it, it can also be in the middle, if your conversation has a lot of history.
The english version doesn't say "complete encryption", it says "end-to-end encryption".

(In reply to Patrick Cloke [:clokep] from comment #43)

Thanks for making a mock-up, it really drives conversation better than trying to describe what we're all talking about. I agree with Florian, however (see comment #41) that another notification bar is NOT the way to go here.

You said "notification bar", but did you intend to say "toolbar"?

I think both you and Florian want to have a single per-conversation toolbar. I like Florian's suggestion from comment #41):

if you think this deserves more space, you need to move that area we currently have at the top of the sidebar so that it extends over the top of both the message area and the sidebar.

This information should be added to the part of the UI that we already have for per-conversation UI elements. Door hangers could likely be used to display additional information / provide actions to be taken.

Let's also agree on terms for the yellow notificiation bar that is occasionally be shown at the top, which notifies about events.

Alex called it "full width alert bar".

I think Patrick used the term "door hanger" for the same thing, is this right?

I think with a combination of the suggestions of everyone we'd have the following:

  • a top level "yellow notification bar", that's reserved for global actions,
    such as invites to approve a new contact

  • a new, combined, per-conversation toolbar, that sits below the global toolbar,
    that sits above both the message and the right hand sidebar (previous conversation),
    and which combines the new elements from Alex's mockup with the
    buddy icon, typing status, buddy name/address, protocol icon.

  • show notifications that are related to a specific conversation below
    the new per-conversation toolbar.

Graphically, we'd have this layout:

--------------- top toolbar ----------------------------------------------------
yellow notification bar - buddy wants to talk to you, confirm????????????

conversation tab | per-conversation-toolbar - privacy status - buddy name - etc.
contact 1        | 
contact 2        | yellow notification bar - verify contact ?????????????
...              |                                                 | prev conv.
...              | received message 1                              | this week
                 | sent message 2                                  | last week
                 | { system notice }                               | ...
                 | sent message 3

(In reply to Kai Engert (:kaie:) from comment #42)

Off-The-Record (OTR) Chats:

[x] Always require encrypted chat.

If you enable this option, sending a message requires that your
contact uses OTR compatible software.

[x] Always remind me to verify my communication partner's identity.

Verifying the identity protects you against Man-In-The-Middle attacks.

I think this would make sense as a dropdown with three options (the words below aren't the best, but you get the idea):

  • Always require encrypted chat.
  • Opportunistically encrypt chats.
  • Never encrypt chats.

The reminder is a separate preference, which applies if "always require encrypted" is off.
If it's off, that preference controls if you're always getting a yellow notification bar that reminds you to verify the contact.

With your suggestion to offer "never encrypt chats" you're adding a new configuration that we currently don't have.

To illustrate the meaning of the second checkbox more clearly, with your suggestion to use a single dropdown and to offer the additional choice, we'd have to offer these options:

 ( ) always require encrypted chat
 (*) opportunistically encrypt chats, always remind me to verify
 ( ) opportunistically encrypt chats, don't remind me to verify
 ( ) never encrypt chats

(I've added the * for the preference I'd suggest as the default.)

Note that "always" is not technically possible for chat rooms (e.g. an IRC channel or an XMPP MUC). It isn't really clear what to do in that case.

You cannot even encrypt opportunistically in chat rooms.

This is good reminder for us, that we'll have to make it clear that all OTR preferences only apply to one-to-one chats, but not to chat rooms used with this chat account.

(In reply to Kai Engert (:kaie:) from comment #49)

(In reply to Patrick Cloke [:clokep] from comment #43)

Thanks for making a mock-up, it really drives conversation better than trying to describe what we're all talking about. I agree with Florian, however (see comment #41) that another notification bar is NOT the way to go here.

You said "notification bar", but did you intend to say "toolbar"?

I'm talking about the bar that attachment 9052142 [details] shows. It looks like a notification bar to me, not a toolbar, but I don't think the word here matters that much.

I think both you and Florian want to have a single per-conversation toolbar. I like Florian's suggestion from comment #41):

if you think this deserves more space, you need to move that area we currently have at the top of the sidebar so that it extends over the top of both the message area and the sidebar.

We both want a single area in the UI for per-conversation UI elements. I don't think we need that much UI space for this and could just add it to the current area, but if more UI is needed we could expand it over the message area, yes.

This information should be added to the part of the UI that we already have for per-conversation UI elements. Door hangers could likely be used to display additional information / provide actions to be taken.

Let's also agree on terms for the yellow notificiation bar that is occasionally be shown at the top, which notifies about events.

Alex called it "full width alert bar".

I think Patrick used the term "door hanger" for the same thing, is this right?

A door hanger is very different, it is a pop-up that is context aware and lets the user interact with the element. An random example: https://mozilla.invisionapp.com/share/7XG2P3JSY46#/screens

I think with a combination of the suggestions of everyone we'd have the following:

  • a top level "yellow notification bar", that's reserved for global actions,
    such as invites to approve a new contact

  • a new, combined, per-conversation toolbar, that sits below the global toolbar,
    that sits above both the message and the right hand sidebar (previous conversation),
    and which combines the new elements from Alex's mockup with the
    buddy icon, typing status, buddy name/address, protocol icon.

  • show notifications that are related to a specific conversation below
    the new per-conversation toolbar.

I suspect we don't need this much space for the per-conversation toolbar (and that having more space for the message area is more useful), but in general I agree with this.

(In reply to Kai Engert (:kaie:) from comment #42)

Off-The-Record (OTR) Chats:

[x] Always require encrypted chat.

If you enable this option, sending a message requires that your
contact uses OTR compatible software.

[x] Always remind me to verify my communication partner's identity.

Verifying the identity protects you against Man-In-The-Middle attacks.

I think this would make sense as a dropdown with three options (the words below aren't the best, but you get the idea):

  • Always require encrypted chat.
  • Opportunistically encrypt chats.
  • Never encrypt chats.

The reminder is a separate preference, which applies if "always require encrypted" is off.
If it's off, that preference controls if you're always getting a yellow notification bar that reminds you to verify the contact.

Oops, I snipped the comment at the wrong spot. My point was that "encrypting" has three states, "always", "opportunistically", "never". I was not attempting to combine the reminder preferences here -- I suspect it should stay separate.

Note that "always" is not technically possible for chat rooms (e.g. an IRC channel or an XMPP MUC). It isn't really clear what to do in that case.

You cannot even encrypt opportunistically in chat rooms.

Of course, the accurate thing to say is "you cannot encrypt chat rooms". My point was that the setting for "opportunistically encrypt" still makes sense in chat rooms -- it doesn't encrypt because it doesn't have the opportunity to.

(In reply to Florian Quèze [:florian] from comment #45)

The verification popups are dialogs, but they aren't modal.

Maybe. The window in screenshot 15 doesn't seem well integrated for something that's no longer an add-on.

You're right, it we cannot embed this UI into the right-hand side preferences panel, then this preference sub-dialog would be modal on top of the account preferences dialog.

Why is it slow? "non-responsive Thunderbird" implies this is done on the main thread; why is it done on the main thread?

If it's done on a background thread, generating 10 keys sequentially in the background might still cause a noticable slowdown of the computer.
But I'm OK with doing it on the background. The most important question remains, when?

(If a user updates to the Thunderbird version that supports OTR, and the user has 10 chat accounts, and the user opens the chat preferences, you don't want to automatically create 10 keys, which could slow down the computer very much, do you agree?)

No. Would you ever show more than one key at once? I suspect most users never want to see the key anyway... so maybe it's fine if the key itself is hidden in a sub dialog.

You're suggesting that we create a key, only if the user clicks the OTR preferences for an account? That means, that the very first display of the chat preferences triggers key generation for that account, the preferences pane would still display "no key yet". Only if the user opens the pane a second time, we could display the key information.

(In reply to Kai Engert (:kaie:) from comment #51)

You're suggesting that we create a key, only if the user clicks the OTR preferences for an account? That means, that the very first display of the chat preferences triggers key generation for that account, the preferences pane would still display "no key yet". Only if the user opens the pane a second time, we could display the key information.

Of course, you don't suggest to generate it "only if the clicks the preferences", we'd still automatically create the key whenever it's needed the first time.

So, what I'm saying above is, if the user doesn't have a key yet, and the key isn't yet required for any OTR activity, what are good events that should trigger the key generation, too? Opening the preferences could be such an event. But as I said, there will be a race between the background key generation, and opening the preferences pane.

We could trigger the key generation when the user opens the prefs for an account, but there'll be the race I mentioned above.

I personally think having the button is more logical, because if we don't have it, some users will see a "no key yet", and I think that can be confusing.

Attached image OTR-side-panel.jpg —

I wouldn't recommend having an actionbar/statusbar spanning for 2/3 of the paned view as it looks quite weird and makes the entire chat UI feel out of balance.

I think we should explore the possibility of having all the OTR actions and warnings in the right panel, above the contact's information.

Attached you can find another mock-up exploring this approach.
I played a bit with the copy and mixed your suggestions, so, you can probably totally ignore the actual text as that will most likely not be the final copy.

Action Bar
This will be always present to allow the user to quickly check the current status of the Encryption and trigger other actions from the dropdown button.
We can potentially use the left area of this action bar to show/hide the loading spinner while something is happening in the background.

Also, we could add a last menu item in the dropdown called Settings which could open the OTR preferences related to the current chat account.

Alert Bar
This will appear only if we need to communicate more information to the user or an action is required.
In the mock-up I covered a couple of possible situations, like the request of verification, the wait for an answer, and the sudden end of an encrypted session.

Having that type of alert bar can help us to deal better with the copy, as we can have shorter and more compact terms in the button (Private, Insecure, Unverified), and more eloquent and explanatory titles + text inside the alert (End-to-end Encryption).

I took the liberty to refresh a bit the contact information and Previous Conversation bar to add a bit more space and make it less cramped.

Alessandro, your suggestion in attachment 9052456 [details] looks very good to me. What do others think?

(In reply to Kai Engert (:kaie:) from comment #51)

If it's done on a background thread, generating 10 keys sequentially in the background might still cause a noticable slowdown of the computer.

I still see no reason for generating 10 keys in a row. And I would like to see a profile to understand what you mean with "noticable slowdown of the computer".

But I'm OK with doing it on the background. The most important question remains, when?

Right after creating a new account when finishing the account wizard seems like a good time.

You're suggesting that we create a key, only if the user clicks the OTR preferences for an account?

For users upgrading from an older version of Thunderbird, that would make sense.

That means, that the very first display of the chat preferences triggers key generation for that account, the preferences pane would still display "no key yet". Only if the user opens the pane a second time, we could display the key information.

No, it doesn't mean that. It means you can display a spinner icon if it takes more than a second to generate the key, and once the key is available, you'll display it.

(In reply to Alessandro Castellani (:aleca) from comment #53)

I think we should explore the possibility of having all the OTR actions and warnings in the right panel, above the contact's information.

The contact's information should remain at the top, otherwise this area of the UI will annoyingly jump around when changing the selected conversation.

Attached you can find another mock-up exploring this approach.
I played a bit with the copy and mixed your suggestions, so, you can probably totally ignore the actual text as that will most likely not be the final copy.

I understand the copy isn't final, but please avoid the phrase 'verified user' here. 'user' usually refers to the person currently using Thunderbird, the person at the other end of the conversation is a 'contact'.

General feedback about the mockup:

  • in most cases, the UI related to encryption should be contained within an area that's the size of the toolbar you put at the top ("Action bar"). One line is enough.

  • the big area with a colored background ("Alert bar") that you designed looks great, but should be reserved for cases where the user's attention is required. That's cases like "Caution! While this conversation is encrypted, your contact doesn't appear to be using the same equipment as last time. If you are about to share any sensitive information, verifying that you are talking to the expected person is recommended."
    The cases currently illustrated in your mockup don't require attention. And the "Session ended" case is especially weird. Users have no notion of what a "session" is. Actually, even as an engineer I'm challenged to imagine what this means.

  • I'm not sure what clicking the drop down in your Action bar would do.

(In reply to Florian Quèze [:florian] from comment #56)

The contact's information should remain at the top, otherwise this area of the UI will annoyingly jump around when changing the selected conversation.

I disagree with this.
Priority wise, the encryption status and any possible warning or required action prompts from the user are more important than the contact's information. Colors and motions should be used to catch the eye and draw attention to that area.
Right now, whenever a prompt or an alert appears, the entire chat UI gets pushed down, which is "good" because the user won't miss it. Confining this motion and behavior to the right panel will help us making the experience less jarring without losing the eye-catching aspect.

I understand the copy isn't final, but please avoid the phrase 'verified user' here. 'user' usually refers to the person currently using Thunderbird, the person at the other end of the conversation is a 'contact'.

Thanks for pointing that out and sorry for the wrong copy.

The cases currently illustrated in your mockup don't require attention.

Sure, that's just a visual representation of how and where we could echo important information. As I said, the copy is just a placeholder.
We should probably define which messages, alerts, and prompts are worth showing there and in which cases.

  • I'm not sure what clicking the drop down in your Action bar would do.

It will show a menulist with all the items currently available in the daily build that Kai made.

* Start private conversation
* End private conversation
* Verify contact's identity
----
* Settings? (if we want to have a shortcut to access OTR settings)

(In reply to Alessandro Castellani (:aleca) from comment #57)

(In reply to Florian Quèze [:florian] from comment #56)

The contact's information should remain at the top, otherwise this area of the UI will annoyingly jump around when changing the selected conversation.

I disagree with this.
Priority wise, the encryption status and any possible warning or required action prompts from the user are more important than the contact's information. Colors and motions should be used to catch the eye and draw attention to that area.

Knowing which conversation is currently selected and having this information always available in the same place is important.

The encryption status, when there's nothing scary requiring immediate attention, is less important.

When there's something that requires immediate attention (eg. the contact's key has changed), I wonder if we should consider making it even more visible by showing something right above the input box where the user can type messages.

Right now, whenever a prompt or an alert appears, the entire chat UI gets pushed down, which is "good" because the user won't miss it.

I don't think that ever was the intended behavior. It's probably something that just happened to be the fastest thing I could implement for an edge case (receiving a contact invitation) that doesn't happen frequently. If I was designing that case today, I would attach this to the list of contacts, so to the left sidebar.

Some thoughts around this:

  • I agree with Alex, the encryption information seems appropriate at top like it is in the mockup.
  • would be nice to have the top notification bar only covering the conversation view, and not the left column
  • why would one ever end the encryption in a normal usage (except for testing)?
  • "Unverified". Somewhere we might want to add language like "Casual eavesdropping is not possible, but with some effort someone could be listening in." which probably is the real danger. Of course there could be someone totally different than expected at the other end of the line, but I'm not sure that's such a likely scenario. Or when it is, you'd want to verify anyway and an eavesdropping warning would prompt you to do so.
  • There's atm some confusion about encryption. There's even a setting for encryption in chat (meaning use SSL to the irc server). We somehow need to communicate that there's a difference between that and end-to-end-encryption

It could be useful to come up with around 5 usage scenarios and situations and go through how well they play out.

(In reply to Magnus Melin [:mkmelin] from comment #59)

  • would be nice to have the top notification bar only covering the conversation view, and not the left column

Do you mean the bar that appears when a contact is requesting a connection? Not the alerts I designed on the right bar, right?

  • why would one ever end the encryption in a normal usage (except for testing)?

I guess that could be useful if the user is stepping away from the computer and wants to be sure the contact won't send sensitive information until he's back.
I agree that it's probably an extreme case, but I'd say it's better having it than not.

  • "Unverified". Somewhere we might want to add language like "Casual eavesdropping is not possible, but with some effort someone could be listening in." which probably is the real danger.

Maybe this could be printed in the alert bar above the contact's info?

It could be useful to come up with around 5 usage scenarios and situations and go through how well they play out.

I agree.
If you guys could come up with some scenarios, I could create mock-ups to go over each one of them and have a visual workflow of how we'd want to handle them.

(In reply to Alessandro Castellani (:aleca) from comment #60)

(In reply to Magnus Melin [:mkmelin] from comment #59)

  • would be nice to have the top notification bar only covering the conversation view, and not the left column

Do you mean the bar that appears when a contact is requesting a connection?

Correct.

Attached image otr-notification.png (obsolete) —

Hello everyone.
Just a quick update to let you know the status of the OTR UI implementation.
I've updated the process to use the newly de-xbl'ed notification box, and started the creation of a dedicated otr-notification-box above the contact information.

This is a screenshot of the WIP.
I'l keep you posted with more updates and patches ready to test.

Cheers,

Attachment #9052142 - Attachment is obsolete: true

Thanks for making a mockup!

I still believe this pop-up should be below the user information. As florian said above, it is important that the context of the current conversation is always in a stable location in the UI.

I also think the current encryption status should be below the user -- it will help portray that it belongs to that conversation.

Hey Kai, I updated your OTR code to reflect the recent changes and apply the style like showed in the mock-ups.

Here's a quick recap of what I did:

  • Updated the notification to use the new notificationbox element from toolkit.
  • Updated the otr-auth.xul dialog to remove the deprecated ondialog... attributes.
  • Moved the chat top notification bar above the center conversation panel.
  • Created a dedicated otr notification box on a per-user based in order to handle multiple notifications for different users at the same time without overlapping.

Things missing:

  • A dedicated style for the successfully encrypted message after a user has been verified.

Issues I wasn't able to solve:

  • It seems that if you click on the speech bubble icon to open a conversation, the OTR doesn't get initialized unless you switch between conversation to force a window refresh. This doesn't happen if you double click on a user to open the cconversation.

I'll keep working to improve the overall styling, and probably create a dedicated encrypted.svg icon with a green checkmark on it, since the current private icon is a simple black lock and it's not really obvious at first glance.

Attachment #9063117 - Flags: review?(kaie)

(In reply to Patrick Cloke [:clokep] from comment #63)

I still believe this pop-up should be below the user information. As florian said above, it is important that the context of the current conversation is always in a stable location in the UI.

Hi, thanks for the feedback.
I'm not sure that would be a good location for the notifications as those elements are only temporary and appear when a user action is necessary.
I think it's important to give them higher visual priority.

I also think the current encryption status should be below the user -- it will help portray that it belongs to that conversation.

I can move this below the user, even tho I think it will look weird having the encryption status box attached to the prievious conversation box. It makes the section feel a bit cramped and non-curated, while with the current order we get a nicely paced and balanced series of containers.

With that said, I made the encryption and notification box independent so we can easily move them around to see where they sit better in context.
Would you be able to load this patch and give it a try to see how it feels interacting with those elements in those locations?

If the majority thinks those elements should be below the user, I'm ok with moving them.

Attachment #9063117 - Flags: review?(kaie) → feedback?(kaie)

(In reply to Alessandro Castellani (:aleca) from comment #65)

Please leave the part that exists for all conversations (including chat rooms) at the top so that it doesn't move up and down when switching between conversations.

Comment on attachment 9063117 [details] [diff] [review] otr-ui-update.patch (moved to bug 1518172) Review of attachment 9063117 [details] [diff] [review]: ----------------------------------------------------------------- A few drive by comments, I haven't actually looked at the code. ::: chat/content/otr-add-fingerprint.xul @@ +14,5 @@ > + ondialogaccept="otrAddFinger.add()" > + buttondisabledaccept="true"> > + > + <script type="application/javascript" src="chrome://chat/content/otr-add-fingerprint.js"/> > + <grid> See bug 1534249. ::: chat/content/otr-auth.properties @@ +1,2 @@ > +auth.title=Verify %S's identity > +auth.yourFingerprint=Fingerprint for you, %S:\n%S Placeholders in strings need localization notes explaining what they'll be replaced with. ::: chat/content/otr-generate-key.properties @@ +1,1 @@ > +priv.account=Generating private key for %S (%S) ... …, not ... ::: mail/components/im/content/chat-messenger.inc.xul @@ +119,5 @@ > + <hbox id="noConvBox" class="im-placeholder-box" align="top"> > + <vbox id="noConvInnerBox" class="im-placeholder-innerbox" flex="1"> > + <label id="noConvTitle" class="im-placeholder-title">&chat.noConv.title;</label> > + <description id="noConvDesc" > + class="im-placeholder-desc">&chat.noConv.description;</description> Intent is broken on this line and the other description elements in this file.
Comment on attachment 9063117 [details] [diff] [review] otr-ui-update.patch (moved to bug 1518172) Alex, thanks for making these changes. The base patch you used is work-in-progress from bug 1518172. I'm OK to use your updated patch as the new snapshot for that bug. Your changes look good to me, but we still need to get a full review of this patch done, let's do that in bug 1518172. I'll move your patch over, and address the comments we got so far.
Attachment #9063117 - Flags: feedback?(kaie) → feedback+
Attachment #9063117 - Attachment description: otr-ui-update.patch → otr-ui-update.patch (moved to bug 1518172)

(In reply to Florian Quèze [:florian] from comment #67)

  • <script type="application/javascript" src="chrome://chat/content/otr-add-fingerprint.js"/>
  • <grid>

See bug 1534249.

Magnus also requested this change, I've filed bug 1550070 to get this done after initial landing.

Placeholders in strings need localization notes explaining what they'll be
replaced with.

The next patch for bug 1518172 will have this done.

…, not ...

done

Intent is broken on this line and the other description elements in this
file.

done, fixed indent

Attached image otr-notification.png —

The entire OTR UI has been implemented. Here's a quick screenshot of the various encryption stages, with numbers if you need to give feedback on a specific stage.

P.S.: Ignore the Private button label of #3 because I was re-verifying an already encrypted conversation.

Attachment #9062058 - Attachment is obsolete: true

Looks pretty good. For #3, the label "Waiting for contact... " - well, waiting for contact to do what? I imagine we want to tell more about what we're waiting for.

I wonder about the "Encryption Status": the alignment seems a bit odd, and should there be an ":"? But anyway, it's about the conversation, right? Of course that's tied to the contact identity, but it's still slightly odd to have it UI-wise tied into the contact like this. (I don't have a suggestion no how it should be, whether that's changing the label, or placement.)

(In reply to Magnus Melin [:mkmelin] from comment #71)

Looks pretty good. For #3, the label "Waiting for contact... " - well, waiting for contact to do what? I imagine we want to tell more about what we're waiting for.

There's already text above it, that explains what's happening, but it seems like a good idea to make it more obvious.
I'll change the text to: "Waiting for contact to complete verification …"

Here's an idea, but I'll leave it to you, whether it makes sense or not.

Regarding the contents of the box that contains the "Previous Conversations" list, could it be bottom aligned? I mean, leave the size of the box as is, but all text is moved to the bottom of the window.

This way, there would be empty space between the encryption status and the prev conv list. Maybe the space below the encryption status could make it easier to stand out and get noticed?

Alex, in your patch, you stopped using a the separate icon for the "finished" state. In otr.css, you changed both .otr-not_private and .otr-finished to the same icon.

This seems contrary to your comment 35. Could you please create a new icon for the "finished" state?

(In reply to Alessandro Castellani (:aleca) from comment #70)

Created attachment 9063687 [details]
otr-notification.png

I think this is looking pretty good! How would this look for a MUC of some sort (where encryption is not possible with OTR)? I see a few options:

  • The UI is still shown, says "Insecure" and is in a disabled state.
  • The UI is not visible at all.
Type: enhancement → task

(In reply to Kai Engert (:kaie:) from comment #74)

Alex, in your patch, you stopped using a the separate icon for the "finished" state. In otr.css, you changed both .otr-not_private and .otr-finished to the same icon.

This seems contrary to your comment 35. Could you please create a new icon for the "finished" state?

Yeah, sorry about that, it was just a temporary edit to use icons with the same resolution and sizing. I'm creating a dedicated "finished" state icon with the same style.

(In reply to Patrick Cloke [:clokep] from comment #75)

I think this is looking pretty good! How would this look for a MUC of some sort (where encryption is not possible with OTR)? I see a few options:

  • The UI is still shown, says "Insecure" and is in a disabled state.
  • The UI is not visible at all.

We're currently not showing the entire UI, button and container, if OTR is not possible.

We could explore the idea of always showing it but enabling/disabling the button accordingly.
I think at that point we would need to have a descriptive tooltip to explain why the button is disabled in order to avoid users thinking there's something wrong with the chat.

Comment on attachment 9063117 [details] [diff] [review] otr-ui-update.patch (moved to bug 1518172) Ryan, as a native speaker with fresh eyes, can you look over the strings and comment/suggest improvements as needed.
Attachment #9063117 - Flags: feedback?(ryan)

(In reply to Magnus Melin [:mkmelin] from comment #78)

Comment on attachment 9063117 [details] [diff] [review]
otr-ui-update.patch (moved to bug 1518172)

Ryan, as a native speaker with fresh eyes, can you look over the strings and
comment/suggest improvements as needed.

The best place to look at the latest strings is the review request here:
https://phabricator.services.mozilla.com/D17691

(In reply to Magnus Melin [:mkmelin] from comment #78)

Comment on attachment 9063117 [details] [diff] [review]
otr-ui-update.patch (moved to bug 1518172)

Ryan, as a native speaker with fresh eyes, can you look over the strings and
comment/suggest improvements as needed.

Responded here: https://phabricator.services.mozilla.com/D17691#914768

Other than the phrase I pointed at, I didn't see anything that concerned me.

Comment on attachment 9063117 [details] [diff] [review] otr-ui-update.patch (moved to bug 1518172) Review of attachment 9063117 [details] [diff] [review]: ----------------------------------------------------------------- Have commented on the diff in Phabricator, see https://phabricator.services.mozilla.com/D17691#914768
Attachment #9063117 - Flags: feedback?(ryan) → feedback-
Comment on attachment 9063117 [details] [diff] [review] otr-ui-update.patch (moved to bug 1518172) I think you meant to just clear the feedback flag...
Attachment #9063117 - Flags: feedback-

Is there more to do in this bug? Bug 1518172 landed most of the initial UI. Could still want to change stuff, but maybe better to do that for specific cases in other bugs?

(In reply to Magnus Melin [:mkmelin] from comment #83)

Is there more to do in this bug? Bug 1518172 landed most of the initial UI. Could still want to change stuff, but maybe better to do that for specific cases in other bugs?

I agree this bug already has served its purpose, which was the pre-landing discussion.

Yes, let's close this one, and use new bugs for any remaining UI work.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Component: General → Security: OTR
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: