1669788 - Support encrypt/sign toggle buttons in compose window

Status: RESOLVED WORKSFORME

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[tobias.bengfort]

Attachment: 0001-imporve-compose-pgp-UI.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I recently switched from 68 to 78 and with that from enigmail to builtin PGP. I think there are some simple changes to the compose UI that could improve usability.

Actual results:

• It is hard to see whether the message will be encrypted and/or signed. You can find this either via a menu or from tiny icons in the statusbar. These icons do not have text labels.
• To encrypt a message I have to go through some menues.

Expected results:

Enigmail had toggle buttons in the toolbar that doubled as indicators and controls: It was easy to see whether the message will be encrypted and/or signed as well as changing that.

I realized that this concept is actually quite easy to implement with the new implementation. These buttons are added without changing anything about the default toolbar configuration.

While at it I also added tooltips to the status icons.

Comment 1

[tobias.bengfort]

Attachment: enigmail.png

Comment 2

[tobias.bengfort]

Attachment: native.png

Comment 3

[tobias.bengfort]

Might be related to bug 512927 but I am not sure given how old that one is.
Related to bug 1583754.
Related to bug 1667254

Comment 4

[Magnus Melin [:mkmelin]]

At the moment the status is shown, but only in the status bar at the bottom.
Probably the encrypt/sign buttons should not be separate: it would create confusion for implementing "encrypt if possible", and people should not really have to understand that when encrypting you also really need to sign. If you make the buttons separate, that becomes a mess.

Comment 5

[Alessandro Castellani [:aleca]]

Thanks for submitting this patch and proposing changes.
Visual proposals and updates for the compose UI are being explored in bug 1667254.

As Magnus said, we shouldn't separate the buttons for encryption and signature to avoid confusion and misguiding users.
We also already have a "Security" button, which gives access to the various encryption technologies available since users might be using OpenPGP and S/MIME at the same time.

Comment 6

[tobias.bengfort]

… to avoid confusion and misguiding users

I am not sure this applies here. I am not proposing to change anything about the existing UI, just to offer additional choices. I assume users who find and use the "customize toolbar" feature are also able to understand and use these buttons.

As this is only about additional choices I believe this is orthogonal to bug 1667254.

Probably the encrypt/sign buttons should not be separate: … when encrypting you also really need to sign

At the risk of sounding dumb: Is that true? I understand that it makes most sense to do both, but each one has merits of its own, don't they?

Whatever the reason, I believe this discussion is unrelated: Currently signing is automatically activated when I activate encryption, but I can manually disable it again. This does not change with my patch. It just offers buttons instead of radios/checkboxes in a menu.

Comment 7

[Alessandro Castellani [:aleca]]

Your proposal is not wrong, but it's limited to OpenPGP and it opens some possible confusions with what we currently have.
Here's some cases.

• The new encrypt and sign buttons don't allow the user to know or specify which technology to use (OpenPGP or S/MIME).
• The new buttons don't allow the users to check "Opportunistic encryption" when/if we decide to implement it.
• The toggable status doesn't allow us to specify which technology is currently active.
• Toggling those buttons should affect also the radio selection in the Security toolbar button?
• And if the user activates the encryption from the Security button or the menubar, are those button automatically checked without the user action?
• Adding more buttons to that toolbar as unique entry points or visual responses is not super recommended since that area is customizable, therefore users might remove buttons if they're on a small screen or they use a small compose window.

I don't think we should offer additional interaction points only targeting one specific technology, but we should improve the current implementation and make it more intuitive and scalable for future additions.

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to tobias.bengfort from comment #6)

At the risk of sounding dumb: Is that true? I understand that it makes most sense to do both, but each one has merits of its own, don't they?

Not required on technical level, but having an encrypted conversation without signing is setting both sides up for trouble. It's difficult to explain to someone why an encrypted email doesn't mean it's "secure".

Comment 9

[tobias.bengfort]

The new encrypt and sign buttons don't allow the user to know or specify which technology to use (OpenPGP or S/MIME).
The toggable status doesn't allow us to specify which technology is currently active.

Users who use only one of the technologies get a much simpler UI. Users who need both technologies can still access the full range of options from the menu bar.

And remember this is only an option. Users can still use the default security button.

The new buttons don't allow the users to check "Opportunistic encryption" when/if we decide to implement it.

I don't understand your point here. AFAIU opportunistic encryption would be a global setting and in the specific message I would like to (1) see if this specific message will be encrypted and (2) be able to change the default. The buttons I propose allow exactly that. Or did I misunderstand something?

Toggling those buttons should affect also the radio selection in the Security toolbar button?
And if the user activates the encryption from the Security button or the menubar, are those button automatically checked without the user action?

Sure, they are synced

Comment 10

[Robert Mader [:rmader]]

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

Not required on technical level, but having an encrypted conversation without signing is setting both sides up for trouble. It's difficult to explain to someone why an encrypted email doesn't mean it's "secure".

Somewhat off topic, but just wanted to drop in that deniability (encryption without signing) can be a very important feature for e.g. whistle-blowers etc. Modern protocols like the one used by Signal etc. offer deniable authentication, e.g. you can sign but still nobody but the receiving party can be sure it was send by you. (see https://en.wikipedia.org/wiki/Deniable_authentication)

So to paraphrase you: It's difficult to explain to someone why an encrypted/signed email can be more dangerous for you than a plain one ;)

Comment 11

[Magnus Melin [:mkmelin]]

Whistleblowing would be one in a million, so certainly not the typical use case (and even then, theoretical at best). Even then, I don't think deniability for a specific email would likely have any baring: you probably do want to be able to verify you sent it, if need be, so that the evidence could be taken seriously.

Comment 12

[Nicolas Falquet]

Our work on bug 1627956 will solve this. We decided NOT to have a toggle for signing on purpose.

Comment 13

[tobias.bengfort]

This exact proposal has been implemented for Thunderbird 102.