1636290 - Initial user assistance for OpenPGP problems in message composer

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert (:KaiE:)]

We need to help the user when composing a message, and we cannot send the message because of OpenPGP problems.

I have a patch that provides the following initial assistance.

On send, if signing is requested but isn't possible because the user's own key is not usable (e.g. expired) show a useful error message.

On send, if encryption is requested but isn't possible, because there are issues with the public key of at least on message recipient, show a useful error message.

Allow the user to view the details of the problem we have with message encryption. This is the purpose of the "security info" dialog that can be opened from within the composer window (click the security button, or use the view menu).

Similar to the existing dialog for S/MIME, the new OpenPGP dialog shows information for the keys of the recipients of the current message.

The dialog will show a listbox with multiple entries.

For each recipient email address, a line with an overall status is shown:

• ok
• !! no key available !!
• !! no accepted key !!

After each list with an email address, a variable number of lines will be shown, either zero, one or multiple lines, depending on how many "potentially valid" keys are available for that address. Potentially valid means, keys that aren't expired and aren't revoked. For each such available key, the current "acceptance" status is shown, which is the user's own decision (remembered) for that key.

Two buttons are shown.

• The button "View details and edit acceptance" can be used to open the key details dialog (same as shown on import or from key manager), which allows the user to change the acceptance status.
• The buton "Discover new or updated key" can be used to query Internet directories for keys of the given email address.

(In a future revision we could allow the "discover" button to specifically search for an updated key of the selected key ID.)

Ride along fixes:

• fix expiry status of keys in key manager and the key object
• remove obsolete code for gnupg validity/trust

Comment 1

[Kai Engert (:KaiE:)]

Attachment: Bug 1636290 - Initial user assistance for OpenPGP problems in message composer. r=PatrickBrunschwig,mkmelin

Comment 2

[Kai Engert (:KaiE:)]

Attachment: compose-sec-info.png

Comment 3

[Kai Engert (:KaiE:)]

Magnus, could you please r+ the patch in phab?

Comment 4

[Kai Engert (:KaiE:)]

After discussing with Magnus, the dialog is too complex to understand. It seems better to introduce another dialog level.

When opening, we'd show a simpler list, with only two columns. Recipients, and the overall status for that recipient (ok, no key available, not accepted key). There we'd have a button "view keys for selected recipient".

Another dialog would open on top, specifically for the selected recipient. It shows the list of keys, has the discover button, and view details button. Clicking details will open the common key details dialog.

Comment 5

[Kai Engert (:KaiE:)]

Patrick raised a concern about the use of the term "personal key" vs "own key".

We currently use the term "personal" in the sense of "your own" in OpenPGP preferences and in S/MIME preferences.

The intention of the term "personal key" or "personal certificate" is to describe a key your is owned by yourself.

Patrick is worried that the term "personal" might not sufficiently express that, because it could be interpreted as "a key related to a person, which might be another person".

Is that a valid concern?

Should we avoid the term "personal" and use a better term, like "own key" and "own certificate" everywhere?

Comment 6

[Kai Engert (:KaiE:)]

I asked on Matrix. Standard8 thinks that the personal "personal key" is clear. He also said, for the meaning that Patrick suggested, one would rather use the term "a person's key".

So should we stay with the term "personal key"?

Or is the potential ambiguity for non-native speakers a reason to prefer the term "own key"?

Comment 7

[Patrick Brunschwig]

I'm fine with "personal key" if native speakers think it's clear. But then we should consistently use it throughout the whole application.

Comment 8

[Magnus Melin [:mkmelin]]

I guess there is a bit of risk such things would get translated wrongly too.
Is there a need to state that it's the "personal key". Could we just use "key"?

Comment 9

[Magnus Melin [:mkmelin]]

At least personally (hah!) I didn't get that it meant a key I owned myself.

Comment 10

[Kai Engert (:KaiE:)]

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

I guess there is a bit of risk such things would get translated wrongly too.
Is there a need to state that it's the "personal key". Could we just use "key"?

I'd prefer to have "personal key". If we just say "key" then the user might wonder: "I have all those keys showing in key manager, but why is almost none of them offered in the selection?".

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

At least personally (hah!) I didn't get that it meant a key I owned myself.

Yes, your use of the term "personally" seems to confirm, you think that term refers to yourself :)

Comment 11

[Kai Engert (:KaiE:)]

(In reply to Patrick Brunschwig from comment #7)

I'm fine with "personal key" if native speakers think it's clear. But then we should consistently use it throughout the whole application.

Agreed. I'll fix.

Comment 12

[Magnus Melin [:mkmelin]]

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

I'd prefer to have "personal key". If we just say "key" then the user might wonder: "I have all those keys showing in key manager, but why is almost none of them offered in the selection?".

I'd think it's pretty understood that you don't use other people's keys for your own purposes - you don't do that physically either.

Comment 13

[Kai Engert (:KaiE:)]

Attachment: comp-sec-step1.png

I've implemented the new two-step approach, the patch is ready for review in phab.

I'll attach screenshots. This is the initial dialog that you get when you click the security info button. It's also used when you try to send encrypted, but can't, because of missing/unaccepted keys.

As you see, in this dialog, you only see an overall status for each recipient, whether the status is ok, or what problem there is.

In order to learn more about the keys for a specific recipient, select it and click the button. That will open another dialog, specific to the selected email address.

That second dialog will list the available keys, and their acceptance status, will allow you to change your acceptance decision, and will allow you to discover keys by searching directories. I'll attach screenshots for the second step for each of the recipients in this example.

Comment 14

[Kai Engert (:KaiE:)]

Attachment: comp-sec-step2a.png

Comment 15

[Kai Engert (:KaiE:)]

Attachment: comp-sec-step2b.png

Comment 16

[Kai Engert (:KaiE:)]

Attachment: comp-sec-step2c.png

Comment 17

[Kai Engert (:KaiE:)]

Attachment: comp-sec-step2d.png

Comment 18

[Magnus Melin [:mkmelin]]

Seems like a step in the right direction. The main dialog is now quite understandable.
For the subdialogs, having a large area with a listing seems quite odd. It would be better to just display the information and guide the user on from that. Displaying an empty area doesn't give the user proper input on what to do next I think. An area of this kind would only be appropriate if there are many keys, but the usual case would be one.

Comment 19

[Kai Engert (:KaiE:)]

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

Seems like a step in the right direction. The main dialog is now quite understandable.

I've made it less wide, see updated screenshot.

For the subdialogs, having a large area with a listing seems quite odd. It would be better to just display the information and guide the user on from that. Displaying an empty area doesn't give the user proper input on what to do next I think. An area of this kind would only be appropriate if there are many keys, but the usual case would be one.

Thanks for the feedback. I agree.

My initial question was about the general structure of the two dialogs, and IIUC they seem ok to you.

Changing the default size is fine. Also, I agree that we should add more guidance to this dialog.
I'll attach an updated suggestion for further discussion.

We can iterate on the best strings, but it would be nice to land something initially. Note that our strings are still kept separate from localization (in content), so for those strings, we currently can easily commit, then change them again in the upcoming days.

Comment 20

[Kai Engert (:KaiE:)]

Attachment: v2-comp-sec-step1.png

Comment 21

[Kai Engert (:KaiE:)]

Attachment: comp-sec-step2c.png

Comment 22

[Kai Engert (:KaiE:)]

Attachment: v2-comp-sec-step2c.png

Comment 23

[Kai Engert (:KaiE:)]

Attachment: v3-comp-sec-step2.png

documenting a screenshot of what I'd like to check in as the updated step-2 dialog, after trying to merge in Magnus' succestions.

Comment 24

[Kai Engert (:KaiE:)]

Attachment: key-details.png

updated key details dialog, that includes the "avoid to accept rogue key" warning above the acceptance selection.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/cca8ae03b543
Initial user assistance for OpenPGP problems in message composer. r=PatrickBrunschwig,mkmelin

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/c5efaf383dc1
followup - packaging was broken due to duplicate css files. rs=bustage-fix

Comment 27

[Kai Engert (:KaiE:)]

Attachment: merged for beta 77

Comment 28

[Kai Engert (:KaiE:)]

Attachment: 1636290-beta77-v2.patch

updated to include the follow-up fix

Comment 29

[Kai Engert (:KaiE:)]

Comment on attachment 9149652 [details] [diff] [review]
1636290-beta77-v2.patch

Request to uplift OpenPGP improvements to Beta 77

Bug 4 of 9

this is a backported patch, only minor merging in one place

[Approval Request Comment]
Testing completed (on c-c, etc.):  yes
Risk to taking this patch (and alternatives if risky): only affects openpgp

Comment 30

[Wayne Mery (:wsmwk)]

Comment on attachment 9149652 [details] [diff] [review]
1636290-beta77-v2.patch

Approved for beta

Comment 31

[Kai Engert (:KaiE:)]

https://hg.mozilla.org/releases/comm-beta/rev/a4c6822ef10da51179aea767abb0b4487e7b86c4

Comment 32

[User Dderss]

Thanks but it is still not clear how to find a way for user assistance.

There was a failure in key movement from Enigmail to TB 78 and as a result I can not send any emails at all since I always get "Unable to send the message because there is a problem with your personal key" error even though I have all "encrypt" and "sign" settings unchecked, which is really weird.

Is there a way to disable the whole PGP thing for now?

There are lots of "pgp" entries in "about:config" but which is a general one and why there is no regular setting in the user options menu?

Thanks in advance.

Comment 33

[Kai Engert (:KaiE:)]

Sorry for the inconvenience, you're are probably affected by the issue described in this message post, which also explains how to fix it:
https://thunderbird.topicbox.com/groups/e2ee/T30c6a3b85c865020/for-testers-of-openpgp-configuration-change-required

Comment 34

[Kai Engert (:KaiE:)]

(In reply to User Dderss from comment #32)

Is there a way to disable the whole PGP thing for now?

mail.openpgp.enable