1595227 - [OpenPGP tracker] Mail Reader - Displaying message status and sender key information

Status: NEW

(MailNews Core :: Security: OpenPGP, enhancement)

Comment 1

[Kai Engert [:KaiE:]]

Let's use this bug to track the user interface for displaying received OpenPGP messages.
We should identify individual work items, and track them in separate bugs.

Also in scope are the adjustments to the existing implementation for displaying received S/MIME messages.

I want to give my initial thoughts on this topic as a starting point, in comparison to Enigmail.

TB shouldn't attempt to hide the details of encryption/signatures. It should empower the user to discover and understand what's going on.

It might be good to introduce a structured presentation, as part of the message reader interface, that informs the user about the security attributes of the shown message.

Above the message content area we have the header area, with from/subject/to/date, signature/encryption status icons, and reply/forward/etc buttons.

While brainstorming with Alex, the idea came up to split the "header" area into two rectangles. The left hand side part could be used for general message attributes. The right hand side area could be dedicated for the "end-to-end" encryption/signature attributes.

Here's an incomplete list of things we can consider for the right side area:

• type of message security mechanism used in this message, OpenPGP or S/MIME
• encryption status / plaintext
• was the message subject also encrypted or not
• digital signature presence and the status of the correctness / integrity check
• what is the trust status of the sender's key, is it an unknown key, a key I have seen before, or is it an unexpected key that introduces ambiguity?

(We'd also offer a way to obtain more details, and some of the above items could potentially go directly to an interactive configuration for the attribute.)

Potentially the trust status of the sender's key shouldn't be shown on the right hand side area, but could possibly be combined with the "from" display on the left hand side. We might decide to show the username found in the key. Probably show some kind of warning icon if there's a mismatch between the key's user ID and the "from" field.

Regarding the attributes shown by default in the right hand side area, it could be useful to have consistency between the message reader and the message composer window. In the compose window, the same attributes could possibly be shown in the same location of the window, however, in composer those attributes could be interactively changed (while in message reader they are fixed).

Comment 2

[Kai Engert [:KaiE:]]

Also, we should inform the user about the presence of alternative presentations. If a message has both a plaintext part and an html/css part, and possible allow the user to switch between those presentations. (Currently we don't tell the user. And user must discover the abilty to switch using menu item "view / message body as".

Comment 3

[Kai Engert [:KaiE:]]

Also, which keys have been distributed to me as part of the message, which is independent of the signature/encryption status.

Comment 4

[Magnus Melin [:mkmelin]]

While I think we want to have a way (maybe even an option) to show more details, the default view needs to be pretty normal and not cluttered with too much information. We need to find a proper balance: the goal is that a regular end user who knows nothing about encryption should be able to encrypted emails easily.

Comment 5

[Kai Engert [:KaiE:]]

We already have a menu command "view / message security info". Today this shows only S/MIME information. I think we should keep that, and use it to show both S/MIME and OpenPGP details, based on the message.

Enigmail adds a opt level menu item named "Enigmail". I went through its items, and I suggest we don't add that menu.

Let's go through the commands it currently offers:

• an option "decrypt/verify automatically"; a command to manually "decrypt/verify"; a command to reload the current message. Let's try to omit those, and default to "auto". We can revisit later, if we discover a need to turn it off.
• clear saved passphrase. If we use the master password approach, we don't need this. (We'd have to implement a general mechanism to log out.)
• sender's key: this should be integrated in the header pane and in "view / message security info"
• decrypt to folder: This seems like an advanced feature, let's skip that initially.
• manage smartcard: if we ever support smartcards, this can be brought back, or it should be managed externally.
• per recipient rules: I'd like to drop those
• preferes: we should move all required preferences to the general prefs system
• setup wizard: this should either be triggered interactively, based on inviting the user to set up openpgp (1595234), or if we really need that, we could trigger it from account prefs
• help / debugging options / about: remove

With that, the only command that I consider necessary is "key management". I suggest that we add an entry to the Tools menu, at least initially, during development.

Comment 6

[Kai Engert [:KaiE:]]

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

While I think we want to have a way (maybe even an option) to show more details, the default view needs to be pretty normal and not cluttered with too much information. We need to find a proper balance: the goal is that a regular end user who knows nothing about encryption should be able to encrypted emails easily.

Agreed, we'll have to find a good balance. We'll work with Alex.

Comment 7

[Jens Müller (:tessarakt)]

Does bug 1637002 belong here?