1667254 - [OpenPGP] Improve the UI of the Compose window when encrypting emails

Status: RESOLVED DUPLICATE of bug 1627956

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Alessandro Castellani [:aleca]]

Attachment: Compose-openpgp.png

I'd like to propose a couple of improvements in the Compose window when dealing with encryptions.

Move the location of the encryption/signed status
I'd like to move the location of the encryption and signed flag from the status bar to the header area.
Other than being more discoverable, having it in the header area makes more sense context wise as the "success" of an encrypted message mostly depends on the recipients listed and their keys.

Pills are cool, let's extend them
We can leverage the awesome nature of the pills in order to highlight which recipient might be problematic.
If a message gets encrypted, we will check the keys of the listed recipients, and in case we don't have a key, or it's expired, or whatever other flag we currently use, we can implement an icon to highlight which recipient has issues.

The icon will have a tooltip and could be clickable to directly access the recipient's key acceptance/discovery dialog.

Comment 1

[Magnus Melin [:mkmelin]]

I'm not convinced putting sec icons in the pills will work out, but maybe it can. Some things to consider:

• key can be available, even if we don't yet have it. I'd like us to locally collect all the keys that we receive, even if we don't assign any trust to them yet. Key lookup from keyservers are also a source of information. I'd like not to make too much difference between keys these keys that "are there" or could be there. What matters is, did you give trust the key or not.
• you can have a mixed technology scenario where you have S/MIME key for a contact, but composing set to OpenPGP.

It's pretty common for applications (say WhatsApp et al.) to state in text "This message will be send encrypted". At least when we implement bug 135636, we should probably add something like this. Or potentially we want to phrase it the other way around: this message will be sent UNencrypted + offer to configure encryption at that point. There are up-sell possibilities to be had here.

Comment 2

[Alessandro Castellani [:aleca]]

I'm not convinced putting sec icons in the pills will work out, but maybe it can

I think we should try to leverage the flexibility that the pills give us.
Having some flags or visual ques to let the user know which recipients have "problems" I think is useful, but of course we need to see it in action. Do you have any specific worry about this approach?

key can be available, even if we don't yet have it. I'd like us to locally collect all the keys that we receive, even if we don't assign any trust to them yet. Key lookup from keyservers are also a source of information. I'd like not to make too much difference between keys these keys that "are there" or could be there. What matters is, did you give trust the key or not.

Do we have a bug for this? As we talked before, I think this might be a very good implementation to automate some steps for the user.

you can have a mixed technology scenario where you have S/MIME key for a contact, but composing set to OpenPGP.

How do we handle these scenario? Is it possible to send an OpenPGP encrypted email to a recipient by using its S/MIME key? Hopefully, this is not a silly question.

It's pretty common for applications (say WhatsApp et al.) to state in text "This message will be send encrypted". At least when we implement bug 135636, we should probably add something like this.

I like this idea, we could explore some non intrusive floating notifications int he message body.

Comment 3

[Magnus Melin [:mkmelin]]

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

I'm not convinced putting sec icons in the pills will work out, but maybe it can

Do we have a bug for this? As we talked before, I think this might be a very good implementation to automate some steps for the user.

Bug 1667564 for collecting.

you can have a mixed technology scenario where you have S/MIME key for a contact, but composing set to OpenPGP.

How do we handle these scenario? Is it possible to send an OpenPGP encrypted email to a recipient by using its S/MIME key? Hopefully, this is not a silly question.

They cannot really be mixed. The user needs to have key keys of all users in the same technology to be able to send encrypted

Comment 5

[Nicolas Falquet]

Our work on bug 1627956 will solve this.

Comment 6

[Kai Engert [:KaiE:]]

Alex, should we mark this as duplicate of 1627956 ?
Or is there anything of the original ideas that you still want to get done?

Comment 7

[Alessandro Castellani [:aleca]]

Yes, I agree.