Closed Bug 1603809 Opened 4 years ago Closed 4 years ago

Unified account preferences for S/MIME and OpenPGP

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 76.0

People

(Reporter: KaiE, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(8 files, 13 obsolete files)

current-empty.png
100.92 KB, image/png
Details
current-filled.png
110.79 KB, image/png
Details
new-key-picker.png
44.07 KB, image/png
Details
Bug 1603809 - Unified account preferences for S/MIME and OpenPGP. r=PatrickBrunschwig,mkmelin
47 bytes, text/x-phabricator-request
Details | Review
e2e-prefs-8.png
157.45 KB, image/png
Details
1603809-fix-nopgp-v1.patch
2.92 KB, patch
mkmelin
: review+
Details | Diff | Splinter Review
Bug 1603809 - Follow-up, don't use .checked for menu elements. r=mkmelin
47 bytes, text/x-phabricator-request
Details | Review
1603809-pref-pack-v2.patch
1023 bytes, patch
Paenglab
: review+
Details | Diff | Splinter Review

When adding suport for OpenPGP, we'll have the following categories of preferences related to the encryption technologies:

(a) General for Encryption / Signing
(b) specific to OpenPGP
(c) specific to S/MIME

It might be overkill to have three separate sub-categories.

For comparison, today, with Enigmail installed, we have the separate categories:

  • security
  • openpgp security

Also considering comments from bug 1532575, following is my suggestion:

Have only one sub-category for account prefs, and rename it to "Encryption & Signatures".

Inside, have three tabs at the top, label them as:

  • General
  • OpenPGP
  • S/MIME

(Note that we'll want to continue to support both OpenPGP and S/MIME. A single account could be configured for both technologies. IMHO the user should be able to change the a default technology, both in prefs, and for an individual message.)

There are some prefs that will be shared by both, and which should live in the General tab:

  • the preferred technology for new composer windows, either s/mime or openpgp
  • (potentially for later, we might have an option that allows to automatically select the other technology, if the selected one cannot be used, but the other can be used)
  • if saved draft messages are encrypted
  • checkbox "sign by default"
  • a radio button for "don't encrypt by default" or "enable encryption by default for new messages"

The suggestion is to use a radio button, not a checkbox, because:

  • that's what we have today
  • we consider to have a third option at a later time, which says: "encrypt new messages only if possible". This will be more work from a UI and automatic behavior point of view, so I'd like to work on that later.

Inside the S/MIME tab we'd have:

  • "my certificate" for this account, selection
  • a radio button with the choices:
    "use a single cert for both encryption and signing"
    or
    "peers should use a different certificate for sending me S/MIME encrypted email"
    (trying to incorporate suggestions from bug 1532575.)

For the OpenPGP tab, here are several potential candidates:

  • selected openpgp key id
  • attach my openpgp public key to outgoing messages
  • when sending an encrypted message, also protect the subject
  • potentially later, a pref to control PGP/INLINE for signed only, simple plain text messages (bug 1602481)
See Also: → 135636

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

Inside the S/MIME tab we'd have:

  • "my certificate" for this account, selection
  • a radio button with the choices:
    "use a single cert for both encryption and signing"
    or
    "peers should use a different certificate for sending me S/MIME encrypted email"
    (trying to incorporate suggestions from bug 1532575.)

I'd like to delay this rework of S/MIME, and do it in a separate step. For now, I'd like to keep the existing options, to reduce the amount of work, and keep the current separate selections.

For the OpenPGP tab, here are several potential candidates:

  • selected openpgp key id

A status display: You currently own [number] private keys for your account's email address.

  • automatically select my private key based on my email address
  • use the following private key [select]

A button [create a new private openpgp key].

Also, we might want to introduce two new checkboxes, one in each of the the respective panels:

  • enable the use of of S/MIME when composing messages
  • enable the use of OpenPGP when composing messages

My suggestion above might not be best, because we currently don't have any nested tabs in the account manager configuration.

Here's a new idea. Use just one entry on the left hand side, named End-to-End Encryption.

On the right hand side, we have the general settings and a selection for the preferred technology. For both technologies OpenPGP and S/MIME, we each display a brief status text, that says if that technology has been configured and is usable, or not. And we offer two buttons, [Configure OpenPGP] and [Configure S/MIME]. When clicked, we'll open a modal dialog for the detail configuration.

Encryption Technologies

Preferred technology when sending messages from this account
( ) disable (never send end-to-end encrypted messages or digital signatures)
(*) select automatically based on the types of keys or certificates that I own
( ) prefer OpenPGP
( ) prefer S/MIME

OpenPGP

{{{status text, e.g. configured, not configured}}}
                              [Configure OpenPGP]

S/MIME

{{{status text, e.g. configured, not configured}}}
                              [Configure S/MIME]


When composing a new message, by default
(*) Do not encrypt the message
( ) automatically encrypt if possible -- choice will be added at a later time --
( ) Require encryption (can't send message unless you have keys/certificates for all recipients)

[ ] add my own digital signature

Configure OpenPGP button opens a modal dialog like this:

OpenPGP configuration

Status, either:
- you don't have a personal OpenPGP key configured. Either import your
  key from a backup, or create a new key using the button below.
or
- you already own a personal OpenPGP key. You can use it to send
  digitally signed email. If you give the public part of your key to
  others, they can use it to verify your digitally signed email
  and to send you encrypted email.

                                        [Import a personal OpenPGP key]

                                    [Create a new personal OpenPGP key]

Preferred personal key

(*) automatically select my own OpenPGP key based on my email address
( ) use the selected personal OpenPGP key
    {{{ key information }}} [select my preferred personal key]

When composing a new message, by default
[ ] attach my public key to messages I send, so correspondents can learn
    that I am able to receive encrypted email.

If the user clicks [select my preferred personal key], we'd show a modal
dialog that shows the list of personal keys the user owns.

If the user clicks [Import a personal OpenPGP key] we can offer
selecting from a file, or we could offer the user to import from GnuPG,
(if GnuPG software is available).

If the user clicks [Create a new personal OpenPGP key],
we'll show the key generation wizard. It should explain the consequences
of starting to use OpenPGP, e.g. encrypted sent folder, responsibility
to safeguard your own key, make backup, etc.

The Configure S/MIME button could open a modal dialog like the following. At this time, I'd prefer to skip improvements to the way S/MIME is configured, to remain focused on the OpenPGP parts. Therefore I'd suggest to simply reuse the existing S/MIME configuration approach, minus the flags that we have moved to the above unified parts.

S/MIME configuration

Digital Signing

Your certificate for sending digital signatures
[      ] [select] [clear]

Encryption

Your certificate for receiving encrypted messages
[      ] [select] [clear]

Certificates
[Manage S/MIME certificates] [S/MIME Security Devices]

Explanation why I suggested the configuration like this.

For "Preferred technology when sending messages from this account" I have the following requirements:

  • for users who had configured S/MIME in a previous Thunderbird version, we should still enable S/MIME for them. The choice "select (technology) automatically" can achieve that. We'll detect that a user has S/MIME certificates configured, then we'll switch a new message to S/MIME technology

  • I want to give users a choice to opt out of using encryption completely

  • some power users might configure both S/MIME and OpenPGP. For those users who do, we need to know which one they prefer

  • if OpenPGP or S/MIME isn't configured, we could try to disable (gray out) those choices

The section "When composing a new message, by default" refers to the settings, that are configured when opening a new composer window. This reflects what the user "wants" to do. The user will be able to change their choice for individual messages, using the dropdown of the security button menu (also available in the top menu bar).

Hi Alessandro, do you have thoughts on this suggestion?

I could change the existing account manager UI like this, and then we could go from there, changing incrementally as necessary.

Flags: needinfo?(alessandro)

Thanks for the ping.

There are a lot of strings and buttons here that it will be difficult to find the "perfect" solution without visually iterating or using those sections.
Overall, I think we should avoid situations where we end up opening a dialog from within a dialog.
I guess the S/MIME configuration will open another dialog when clicking [Manage S/MIME certificates], right?

Anyway, I think as a first time implementation it would be OK to go down this route, which we can later iterate to improve.

Flags: needinfo?(alessandro)

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

I guess the S/MIME configuration will open another dialog when clicking [Manage S/MIME certificates], right?

Yes. It's the same as we have today. It will open the certificate manager. However, that's basically just a shortcut to jump to global preferences.

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

Yes. It's the same as we have today. It will open the certificate manager. However, that's basically just a shortcut to jump to global preferences.

Well, no, not a jump to global preferences. It will open the modeless certificate management window.

I have a patch ready for review. But some explanations first.

I discovered that the right hand side of the preferences can scroll. In the ancient past, when I had worked on prefs UI last, this wasn't possible!

This means, we're more flexible. Given that the general layout of the prefs has increased anyway in the recent past (see discussion in bug 1619531), it seems acceptable if a pref pane is slightly larger than the user's screen (or the current window size).

Given that, I'd like to keep all the primary prefs for OpenPGP and S/MIME in a single pane. If we'll ever have to add more options, and don't like having to scroll down too much, we'll have the alterantive option to move a few prefs to an advanced popup dialog.

Having all prefs in a single pane has another benefit: We can enable/disable elements based on the user's configuration. (This is already done today, without having S/MIME certificates configured, it isn't possible to enable encryption or signing by default.)

While working on the prefs and thinking about them more, I made some adjustments to the plan I had presented earlier.

Instead of having a separate "enable OpenPGP" checkbox, I'd like to base the "enabled" status on having a key configured. That's similar to what we do today for S/MIME.

Also, there's a bit of code that controls "locking preferences", e.g. used in enterprise environments. I have removed this code for now. It was easier to do brainstorming without having to worry about that code. It isn't a lot of code, I suggest that we allow us some iterations with these new prefs in the next 2-3 months, and once we know it's final, we can add the "pref locking" ability back. I'll file a tracking bug for that.

I'll start by attaching some screenshots. Although the intention for TB 78 is to have both s/mime and openpgp enabled, we're not ready to do that for nightly/beta. Therefore I have tried to keep S/MIME working, if OpenPGP is disabled at build time. That's the reason why you'll get two different screenshots of the prefs.

Attached image current-empty.png —

The UI we currently have, in the empty state (not configured).

Attached image current-filled.png —

The UI we currently have, in the configured state.

Attached image new-nopgp-empty.png (obsolete) —

The new proposed UI, if OpenPGP is disabled at build time.
That's what nightly users get, until we're ready to enable OpenPGP.
This is the empty state (no user configuration).

Attached image new-nopgp-filled.png (obsolete) —

The new proposed UI, if OpenPGP is disabled at build time.
That's what nightly users get, until we're ready to enable OpenPGP.
This is the configured state.

Attached image new-empty.png (obsolete) —

The new proposed UI, if OpenPGP is ENABLED at build time.
This is the empty state (no user configuration).

Attached image new-smime-filled.png (obsolete) —

The new proposed UI, if OpenPGP is ENABLED at build time.
This is with S/MIME configured, and OpenPGP NOT configured.

Attached image new-pgp-filled.png (obsolete) —

The new proposed UI, if OpenPGP is ENABLED at build time.
This is with OpenPGP configured, and S/MIME NOT configured.

Attached image new-both-filled.png (obsolete) —

The new proposed UI, if OpenPGP is ENABLED at build time.
This is what a power users gets, who has configured both S/MIME and OpenPGP.

Attached image new-key-picker.png —

This is a helper dialog that is shown if the user clicks the "Set my personal key" button.

Right now, we'd go directly to this dialog.
I know it's looking ugly, but it's not yet clear if this is what we'll use.
We'll probably have a different dialog with more guidance later.

I think the new-both-filled.png looks good, bu the Advanced section should be split to show the OpenPGP and S/MIME buttons underneath the respective sections.
There are other UI related tweaks in terms of spacing and alignment I can take care of if you want.

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

Created attachment 9131258 [details]
new-key-picker.png

This is a helper dialog that is shown if the user clicks the "Set my personal key" button.

Yeah, this should open the properly styled subdialog we've been using in the account manager and preferences tab.

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

I think the new-both-filled.png looks good, bu the Advanced section should be split to show the OpenPGP and S/MIME buttons underneath the respective sections.
There are other UI related tweaks in terms of spacing and alignment I can take care of if you want.

That would be great. Not sure how we can avoid conflicts while working on the review for the patch. What approach should we use?

Strategy 1:

  • Kai doesn't ask for review yet
  • Alex takes the patch, tweaks it, and uploads a new version
  • Only after Alex is happy, Kai will ask for code review from Magnus/Patrick

Strategy 2:

  • Kai works on the code review with Magnus/Patrick
  • Kai updates the patch until they are happy and can commit the code
  • Alex works on the UI tweaks in a follow-up

What do you think?

You can go ahead and work on the patch to take care of all the architecture and "back-endy" stuff.
Once that patch gets an r+, I'll add a follow-up built on top seeking a simple ui-r.

Thanks Alex!

Some comments for Magnus and Patrick, that maybe can help with the review.

I'm removing the two old account manager prefs, and create a new one. That's why you'll see a lot of code being moved.

The code is close to the old S/MIME code, with some stuff added.
In particular, I added code that dynamically enables/disables the menu items for signing/encryption, based on the key/cert configuration we have. As a consequence, I removed the popup that said "not configured" when trying to enable an option in composer.

The prefs.js file hasn't changed much, just at the top.

Although enigmail already had a selection dialog, it didn't feel sufficiently close to what I needed, I specifically wanted to present only the subset of keys that match the identity's email address. That dialog also has a lot of configuration options that we might no longer need. I'm not yet ready to abandon it, but I wanted to create a new dialog, also as a way to refresh my knowledge about today's UI platform code.

FYI, I used the Firefox "permissions" dialog as a starting point for that key picker dialog, from which I removed everything I didn't need.

There are very few new strings. You can see them in the screenshots. I took care to change string IDs when text changed.

Blocks: 1621128

I'm replying to one of Magnus' more general review comments here in bugzilla, because it's easier with quoting etc.

Regarding

<!ENTITY encryptionCert2.message "Use this personal certificate for receiving encrypted messages:">

Magnus said:

Hmm, I wonder if this isn't wrong, also slightly so in the current code.
It's the certificate you want people to send you encrypted messages with.

Yes, it's signaled as the preferred certificate for self in outgoing messages.

But it isn't limited to that. That certificate is also used for encrypting outgoing messages to self, to make messages stored in the Sent readable for yourself.

On the other hand, AFAIK all the ones that's found in the certificates of yours will be used for that.

Not sure what you mean. Are you saying, the Thunderbird user might have multiple certificates, and might receive encrypted messages for any of those certificates?

In theory that's true. However, others still need to know about your certificates. You might have imported certificates, which you haven't configured in any of your accounts. Nobody might know about those.

Nevertheless, I'm not sure why you think it's necessary to mention that. Additional certificates are probably for separate email addresses. And here we're managing the certificate(s) for just one account/identity.

I believe there are some people using different signing and encryption certificates. Maybe it would be better for the special encryption certificate case, to

always import the one for signing (I'm assuming we do that already, and use it if it can be used for decryption)

I think very few people use "completely different" certificates. The usual scenario is, your CA gives you a pair of two different certificates, which are closely related to each other. They will usually have the same names in it, and the same validity period. They will usually differ only in the key material, in the serial number, and in the certified "allowed use". One will usually be for signing purposes, and the other will be for encryption purposes. A common use case is a corporate deployment, in which the company would like to escrow the secret key of the encryption certificate - to make it possible to read an employee's encrypted messages. However, the signing key/certificate usually isn't escrowed, to ensure nobody can "act in the name of the employee".

When you enroll for a certificate, and you're using two separate keys, the CA will usually give you a bundle of both certificates, so most likely you'll import both certificates at the same time.

for the receiving side, just pop up the certificate manager and let them import one.

Not sure what you imagine here. The person who owns the encryption certificate imports it at the time it receives it from the CA. Usually, imported together with the signing cert.

Everyone else, who just uses the public part of the certificate, will get it from LDAP, or from a signed S/MIME email, and it gets imported automatically by Thunderbird at the time of reading the signed S/MIME message.

Specifying one when many will be used is very unintuitive.

That's why the selection code assists the user "hey, you imported one for signing, do you want to also set the encryption one"? (This also works vice versa, if the users starts with selecting the encryption certificate.)

In most cases, we'll automatically find the matching certificate, and offer it to the user, so the user simply needs to confirm. If the user has just one certificate that is usable for both purposes, that's what we'll set. If there's a pair of two certificates, we'll identify the other one by the same names contained in the certificate.

Maybe this way we can even pretty much unify the OpenPGP and S/MIME sections?

Not sure what you envision here. I have a simplification in mind, but I want to postpone it to a future time, when there's less pressure around OpenPGP. We could have just a single certificate selection by default, which would select the user's certificate. We could have a radio button next to it (potentially hidden in an "advanced" area") that says "use separate certificates for encryption and signing". We could automatically assist the user, if we detect that the user selected a certificate that can be used for one purpose, only. But this will require some more rework in the preferences, which I'd like to avoid at this time.

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

I'm replying to one of Magnus' more general review comments here in bugzilla, because it's easier with quoting etc.

Regarding

<!ENTITY encryptionCert2.message "Use this personal certificate for receiving encrypted messages:">

Maybe better then: "Personal certificate for message encryption:"

... which avoids the "use..." - which is really about what other people will use.

On the other hand, AFAIK all the ones that's found in the certificates of yours will be used for that.

Not sure what you mean. Are you saying, the Thunderbird user might have multiple certificates, and might receive encrypted messages for any of those certificates?

Yes, a very clear case is all your old expired certificates.

Nevertheless, I'm not sure why you think it's necessary to mention that. Additional certificates are probably for separate email addresses. And here we're managing the certificate(s) for just one account/identity.

I don't think it needs to be mentioned in the UI, I'm just saying the UI is quite unclear.

I think very few people use "completely different" certificates. The usual scenario is, your CA gives you a pair of two different certificates, which are closely related to each other.

Maybe some companies do that. I've never seen if for any of the S/MIME certificates I've had from public providers.

Not sure what you imagine here. The person who owns the encryption certificate imports it at the time it receives it from the CA. Usually, imported together with the signing cert.

True. Maybe there is no need for the user to select in most cases. We could just find the first valid cert.

Maybe this way we can even pretty much unify the OpenPGP and S/MIME sections?

Not sure what you envision here. I have a simplification in mind, but I want to postpone it to a future time, when there's less pressure around OpenPGP.

Sure.

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

Regarding

<!ENTITY encryptionCert2.message "Use this personal certificate for receiving encrypted messages:">

Maybe better then: "Personal certificate for message encryption:"

Sounds good!

For consistency, I've changed the other one to:
"Personal certificate for digitally signing messages:"

Not sure what you mean. Are you saying, the Thunderbird user might have multiple certificates, and might receive encrypted messages for any of those certificates?

Yes, a very clear case is all your old expired certificates.

We don't use expired certificates. And they aren't offered when you click select, they are excluded.

Maybe some companies do that. I've never seen if for any of the S/MIME certificates I've had from public providers.

I remember the implementation might have been triggered by US gov requirements.

Not sure what you imagine here. The person who owns the encryption certificate imports it at the time it receives it from the CA. Usually, imported together with the signing cert.

True. Maybe there is no need for the user to select in most cases. We could just find the first valid cert.

Yes, agreed. We could have an option for that in the future.

Attached image e2e-filled-v2.png (obsolete) —

Updated new screenshot, now that we've changed the strings.

The additional introduction strings no longer made sense, the text was redundant, so I removed them for now.

Attachment #9131252 - Attachment is obsolete: true
Attachment #9131253 - Attachment is obsolete: true
Attachment #9131254 - Attachment is obsolete: true
Attachment #9131255 - Attachment is obsolete: true
Attachment #9131256 - Attachment is obsolete: true
Attachment #9131257 - Attachment is obsolete: true
Comment on attachment 9133421 [details]
e2e-filled-v2.png

Looks fairly nice, and cleaner than before.
I have some more thoughts though: for someone coming here with no background knowledge, it's not clear what they should do - "do I need to setup both OpenPGP and S/MIME". I think this all needs a explanation on top perhaps. 

For Digital signing, and I have both techs set up + select automatically, what would it be using?

It might be better to move things around a bit, so that you select which one to use as preferred, and leave the other one for optional usage. 

Maybe something like this.

---
For end-to-end encrypted email there are two technologies: OpenPGP and S/MIME. The keys/certificates for the technology you want to use needs to be configured below. The same keys/certificates must be present on all devices where you want to read the messages. Make sure to backup your keys/certificates locally. Nobody has access to them except you, so if you lose the keys/certificates all access to the relevant messages is permanently and irrevocably lost. 

Encryption technology:  (o) OpenPGP  ( ) S/MIME  ( ) None

--- Encryption Settings ---

End-to-End Encryption means that only the communicating users can read the messages. It protects the communication from potential eavesdroppers such as your mail provider or governmental agencies across the globe.

( o ) Do not encrypt messages I send
(    ) Require all messages I send to be encrypted

Signing messages tells the recipient's email client how to encrypt messages to you. It also enables the recipient to verify that your message was not changed by a third party after you sent it. The signature is not (usually) shown inside the message.

[   ] Sign my messages

--- OpenPGP Configuration ---


--- S/MIME Configuration ---
Status: NEW → ASSIGNED

Magnus, I appreciate that you try to optimize this further, and you have some valid points, but I also don't agree with everything you said. I think "make it perfect and easy" is beyond the scope of this bug. From my perspective, the purpose of this bug is to provide the minimal change to make the OpenPGP preferences usable, in a way that is aligned with what we have today. We have a lot of TODOs left, and I feel your suggestion to completely rehaul this requires more work and discussion, which would preferably be done later.

for someone coming here with no background
knowledge, it's not clear what they should do

It will take multiple rounds of discussions and work to figure out how we would best compress such an introduction into two sentences.

IMHO we should limit ourselves to describe what this preferences pane is about, and we should offer a "help" button that offers a document with more detailed explanations.

"do I need to setup both
OpenPGP and S/MIME". I think this all needs a explanation on top perhaps.

We also don't tell people in the "composition" pane, whether they should use HTML or not. The term HTML is also an advanced term for many people.

For Digital signing, and I have both techs set up + select automatically,
what would it be using?

You had already asked this question in phab, and I had responded over there.

Quoting myself:
In the future, this setting could be used to decide based on the recipient certificates you have.
For example, if the user composes a message to John, and the user only has an S/MIME certificate for John, but no OpenPGP key, then we could automatically decide to send an S/MIME message (not OpenPGP).
If we don't have the "select automatically" choice, we'd force the user to make a decision. And we'd be required to stick with this selection.
Offering "select automatically" gives us more flexibility in the future.

Encryption technology: (o) OpenPGP ( ) S/MIME ( ) None

In my model "none" is equivalent to not having any keys configured.

You're taking away the option to potentially let Thunderbird decide automatically, based on the keys that are available.

End-to-End Encryption means that only the communicating users can read the
messages. It protects the communication from potential eavesdroppers such as
your mail provider or governmental agencies across the globe.

I'd be careful with explicitly making such statements. The level of protection these mechanisms provide also depends on the operational security a user applies (such as taking care of their keys, full disk encryption etc.)

( o ) Do not encrypt messages I send
( ) Require all messages I send to be encrypted

That's not what this option does. It's simply how the checkmark for encryption on/off in new messages is initially set.

I've met with Magnus, and we agreed on the following:

The amount of dialog control elements, and their order, will remain as they are in the screenshot

We'd like to add some sentences to make it easier to understand what this dialog is about:

  • an introduction at the top, something like "configure the encryption technology that you want to use (one or both)"
  • a brief description text above the encryption choice
  • a brief description text above the signing choice

I think we need to adjust the wording that Magnus suggested, but I'll try to keep the spirit, and attach a new suggestion soon.

The challenge in finding a good wording is, to ensure we don't promise too much. Any protection is void, if users don't carefully protect their secret keys.

Here's my new suggestion:

=== introduction text on top ===

To send end-to-end encrypted or digitally signed email messages, you must configure at least one encryption technology, either OpenPGP or S/MIME.

If you're new to end-to-end encryption, please read the introduction. [Show Introduction]

*** note: the button [show introduction] opens a document that provides a reasonably long document that explains the most important aspects and consequences

=== text shown above the encryption control ===

End-to-end encryption can prevent adversaries from reading your email, if all recipients carefully protect their secret keys.

To send an encrypted email, you must have valid public keys or certificates for all email recipients.

=== text shown above the signing control ===

Digitally signing an email adds a strong confirmation about the sender of an email, assuming the sender carefully protects their secret key.

edit: changed "have received" to "have"

Attached image e2e-prefs-3.png (obsolete) —
Attachment #9133845 - Flags: feedback?(mkmelin+mozilla)
Attached image e2e-prefs-4.png (obsolete) —

I've shortened the text. It might be ok to remove the "assuming ... protect secret" if we explain that in the help/introduction text that can be opened with the button.

Attachment #9133845 - Attachment is obsolete: true
Attachment #9133845 - Flags: feedback?(mkmelin+mozilla)
Attachment #9133848 - Flags: feedback?(mkmelin+mozilla)

I'm still brainstorming to make it better...

For the middle text about encryption:

End-to-end encryption can prevent third parties from reading your email.
To send an encrypted email, you must have valid public keys or certificates for all recipients.

Comment on attachment 9133848 [details]
e2e-prefs-4.png

s/,you must configure at least one/you need to configure an/


For the "Show introduction", it would be better just just put links in the text, maybe link OpenPGP and S/MIME words. I would skip the last sentence of that intro.

Overall, I think you're using too technical language, like "adversaries". I don't think people get that. It's like from a security spec :)
For the digital signature, this is also true. I'd suggest more of something like I suggested earlier, in everyday language and not "strong confirmation" which is just not something the average user could relate to. 

For the encryption, maybe
End-to-end encryption keeps your email communications private. Without it the emails are easily exposed to you mail provider as well as to mass surveillance.
Attachment #9133848 - Flags: feedback?(mkmelin+mozilla)

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

s/,you must configure at least one/you need to configure an/

ok

For the "Show introduction", it would be better just just put links in the
text, maybe link OpenPGP and S/MIME words. I would skip the last sentence of
that intro.

Maybe that last sentence could be a link. And we could reword it. "Learn more about end-to-end encryption."
We do that in Thunderbird's general privacy/security preferences for remote content.

Your encryption wording isn't bad. But your wording seems very inviting. Everyone reading that would absolutely agree it should be used and probably click that checkbox to enable it. Unfortunately it's not as easy to use it, and enabling it causes trouble to users who don't know how to resolve missing keys. So I think we need to also put a word of warning there.

I don't think we should use your earlier signature wording, your complaint about my earlier wording being too technical can easily be given to your signature wording, too.

For the visual feedback, we use a signet on an envelope. That's what signatures are about. It removes the doubt about the origin of an email, which usually is missing in email. I think we should focus on describing that property.

New suggestions, trying to approximate what you'd like to see:

Introduction label

To send end-to-end encrypted or digitally signed email messages, you need to configure an encryption technology, either OpenPGP or S/MIME.
<a href="introduction-article">Learn more about end-to-end encryption.</a>

Encryption label

End-to-end encryption keeps your email communications private.
Without it the contents of emails are visible to your mail provider and to mass surveillance.
However, it can only be used with communication partners that are configured to use it, and who have provided you with their valid public key or certificate.

Signing label

Digitally signing allows recipients of your email to verify it was sent by you.

I'm sorry for making many comments in short succession. On one hand side I have the desire to get this done as quickly as possible, on the other hand, each time I submit text, I continue thinking and find further ways to improve it...

Attached image e2e-prefs-5.png (obsolete) —

Please see screenshot for latest text. I've also changed labels.

Attachment #9133421 - Attachment is obsolete: true
Attachment #9133848 - Attachment is obsolete: true
Attachment #9133889 - Flags: feedback?(mkmelin+mozilla)

Perhaps this has already been discussed, but for the sake of consistency, I've looked in account settings and preferences and there is a very clear preference for using "message" or messages" instead of "email".

Thanks Wayne, that's helpful, will attach an updated screenshot in a few moments.

But we'd still say "email provider"?

Attached image e2e-prefs-6.png (obsolete) —
Attachment #9133889 - Attachment is obsolete: true
Attachment #9133889 - Flags: feedback?(mkmelin+mozilla)
Attachment #9133892 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9133892 [details]
e2e-prefs-6.png

For the Learn more link, let's make it just "Learn more"

There are periods at the end of the encryption choices. We don't usually have that.

For the require enc description, I would change it slightly:
If you require encryption, you will not be able to send messages unless you have the public key or certificate of each recipient.

For signing, maybe:
A digital signature allows recipients to verify the message was sent by you, and that the content has not been changed.

For the last options, maybe just:
Preferred Encryption Technology:
Attachment #9133892 - Flags: feedback?(mkmelin+mozilla) → feedback+

Thanks Magnus, I like your suggestions, and will update screenshot and patch accordingly in a few minutes.

Attached image e2e-prefs-7.png (obsolete) —

The patch in phabricator has already been updated to look like this.

Attachment #9133892 - Attachment is obsolete: true
Comment on attachment 9133960 [details]
e2e-prefs-7.png

Wayne, do you see any english language errors in this screenshot?
Attachment #9133960 - Flags: feedback?(vseerror)
Comment on attachment 9133960 [details]
e2e-prefs-7.png

Sorry, I realized the "Preferred Encryption Technology" should probably not be all capitalized, only the P.

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

Sorry, I realized the "Preferred Encryption Technology" should probably not
be all capitalized, only the P.

fixed in phab

Comment on attachment 9133960 [details]
e2e-prefs-7.png

Under "default settings for sending, perhaps consider this shorter version "If you enable require encryption, to send a message you must have the public key or certificate of every recipient."

The last sentence, under encryption technology, seems incomplete.  Perhaps change to "that I have installed" ?
Attachment #9133960 - Flags: feedback?(vseerror) → feedback-

(In reply to Wayne Mery (:wsmwk) from comment #53)

Under "default settings for sending, perhaps consider this shorter version
"If you enable require encryption, to send a message you must have the
public key or certificate of every recipient."

The phrase "enable require" has two verbs following each other, is that fine?
Could we simply drop the word "enable" in your suggestion?

"If you require encryption, to send a message you must have the public key or certificate of every recipient."

The last sentence, under encryption technology, seems incomplete. Perhaps
change to "that I have installed" ?

The term "installed" isn't optimal. How about:

"Select automatically based on the keys or certificates that are available"

Flags: needinfo?(vseerror)

I'd prefer to have the term "valid" in that sentence:

"If you require encryption, to send a message you must have the valid public key or certificate of every recipient."

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

(In reply to Wayne Mery (:wsmwk) from comment #53)

Under "default settings for sending, perhaps consider this shorter version
"If you enable require encryption, to send a message you must have the
public key or certificate of every recipient."

The phrase "enable require" has two verbs following each other, is that fine?
Could we simply drop the word "enable" in your suggestion?

"If you require encryption, to send a message you must have the valid public key or certificate of every recipient."

I'm OK either way.

The last sentence, under encryption technology, seems incomplete. Perhaps
change to "that I have installed" ?

The term "installed" isn't optimal. How about:

"Select automatically based on the keys or certificates that are available"

Agreed. And can we switch that slightly to "Select automatically based on available keys or certificates"?

Flags: needinfo?(vseerror)
Attached image e2e-prefs-8.png —

Thanks Wayne. Patch in phab updated. Latest screenshot attached.

Attachment #9133960 - Attachment is obsolete: true

Magnus, do you think we're ready to go?
(Once this lands, I can also commit incremental bug 1621128.)

Flags: needinfo?(mkmelin+mozilla)

Commented on phab, but yes, basically ready to land.

Flags: needinfo?(mkmelin+mozilla)

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/586f1686ac4b
Unified account preferences for S/MIME and OpenPGP. r=PatrickBrunschwig,mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 76.0

(In reply to Wayne Mery (:wsmwk) from comment #43)

Perhaps this has already been discussed, but for the sake of consistency, I've looked in account settings and preferences and there is a very clear preference for using "message" or messages" instead of "email".

FWIW, I'm slightly worried that users might be confused by using "messages", given that Thunderbird offers multiple protocols to send messages.

That dialog is specifically about email preferences. The statement that either S/MIME or OpenPGP is required only applies to "email messages".

I doesn't apply to "chat messages", which use a different technology to send encrypted messages (OTR).

So, if this dialog here only says "messages" in general, without mentioning email, a user might be confused.

Blocks: 1624223

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

So, if this dialog here only says "messages" in general, without mentioning email, a user might be confused.

I don't disagree. "message provider" would sound quite strange.

I must admit, I was surprised that "email" is barely sprinkled in account settings and preferences. (There are a only couple places like junk settings where both terms are used - in that case "mail" and "email" is used four times and "message(s)" is used three times. again, rare)

Alessandro reported a JS error in the default non-pgp build.

We need to protect all uses of the pgp pref elements with the build flag.

Attachment #9135225 - Flags: review?(mkmelin+mozilla)
Attachment #9135225 - Flags: review?(mkmelin+mozilla) → review+
+  let stillHaveOther = false;
+  if (!MailConstants.MOZ_OPENPGP) {
+    stillHaveOther = gKeyId && gKeyId.value;
+  }

the ! is wrong, I'll remove it

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/8580c41d5e5a
Follow-up, don't access OpenPGP items if disabled at build time. r=mkmelin DONTBUILD

Magnus, you had recommneded that I use element.checked=true not setAttribute("checked", true").
However, in this place it doesn't work:
https://hg.mozilla.org/comm-central/rev/586f1686ac4b#l2.84

The radio box remains always unchecked, even if the assigned value is true.

Changing it to .setAttribute("checked", value) makes it work.

Do you know what's going on?
Is it ok if I change it back to use setAttribute("checked", val) ?

Flags: needinfo?(mkmelin+mozilla)

Answered in phab.

Flags: needinfo?(mkmelin+mozilla)
Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/0ddfc1c62fef
Follow-up, don't use .checked for menu elements. r=mkmelin DONTBUILD
Attached patch 1603809-pref-pack.patch (obsolete) — — Splinter Review
Attachment #9136565 - Flags: review?(richard.marti)
Comment on attachment 9136565 [details] [diff] [review]
1603809-pref-pack.patch

err, no, that was too hasty.
Attachment #9136565 - Attachment is obsolete: true
Attachment #9136565 - Flags: review?(richard.marti)

Richard reported a packaging failure when building with --enable-openpgp
We've moved the contents of old openpgp-prefs.js to new file e2e-prefs.js which is already included in the packaging manifest.
We must remove the old file from the manifest.

Attachment #9136566 - Flags: review?(richard.marti)
Attachment #9136566 - Flags: review?(richard.marti) → review+
Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/d0bec3d5e2e5
Follow-up, fix preferences packaging. r=Paenglab DONTBUILD
Regressions: 1626222

Are there plans to make keyPicker.ftl localizable?

Flags: needinfo?(kaie)

Yes, all the OpenPGP strings are still in content since many need work, and some are not used (leftovers from Enigmail). Once we clean up and stabilize we'll move the to localizable location.

Flags: needinfo?(kaie)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: