Closed Bug 1624676 Opened 4 years ago Closed 4 years ago

OpenPGP and S/MIME message status icons

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

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

Tracking

(thunderbird_esr78+ fixed, thunderbird81 fixed)

Status:
RESOLVED FIXED
Milestone:
82 Branch
Tracking Flags:
Tracking Status
thunderbird_esr78 + fixed
thunderbird81 --- fixed

People

(Reporter: KaiE, Assigned: aleca)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 18 obsolete files)

Message Pane icons.png
38.65 KB, image/png
Details
1624676-openpgp-icons.diff
58.90 KB, patch
aleca
: review+
aleca
: ui-review+
wsmwk
: approval-comm-beta+
wsmwk
: approval-comm-esr78+
Details | Diff | Splinter Review

Today, when reading an email, to show if an email was digitally signed or encrypted, we show icons in the header area.

The current icons apply to S/MIME. We need to decide how to visualize OpenPGP, in a consistent way, and create the possible enhancements.

Let me start by explaining what we have today.
Currently, we have the following 4 states:

== no icon ==
used if there's no signature at all

== envelope with question mark (questionable signature) ==
Used if there's a signature, and the signature seems to match the contents, but we don't know if the sender of the email matches the owner of the key/certificate that was used to create the signature:

  • if the email address listed in the certificate doesn't match the email sender
  • if the certificate that doesn't even list an email address.

We also the icon for an additional technical scenario. It's possibly that emails aren't completely downloaded immediately, when the user clicks an email. This can happen in some configurations that save bandwidth. However, in order to verify the signature, it's necessary to fully download the email first. In this scenario, a click on the icon offers to download the whole message, and afterwards we'll calculate the real status.

== envelope with a red X (bad signature) ==
This icon is shown whenever we discover a failure when trying to verify. For example, if there's a clear mismatch between the signature and the message contents, or if the key/certificate is untrusted/invalid, and several related technical errors.

== envelope with a signet (good signature) ==
We use it, if everything matches and looks good.

For encryption, we use three states:

== no icon ==
there was no encryption

== good padlock ==
Message was encrypted and consistent, and we were able to decrypt it without failures.

== padlock with a red X ==
Message was encrypted, but we detect some kind of failure. For example, the message is incomplete, and a failure occurred while decoding. Or, we couldn't decrypt the message at all, for example because we don't have the required secret key (or the user has the key, but couldn't unlock it because of an incorrectly entered master password).

I think these states are pretty straightforward. I think we can probably use the same states for OpenPGP.

For OpenPGP signatures, I would like to start with a small first step, that reuses the existing icons, and add more icons if necessary.

There are obvious scenarios that are identical. If there's no signature, then don't shown an icon. If the cryptographic signature is technically incorrect and doesn't match the expectation, then we can show the same bad signature state, envelope with red X.

Let's look at the differences.

S/MIME and OpenPGP differ in how they trust a signer's key. With S/MIME, that's very simple: Either the signer has a valid certificate from a trusted third party, or not. If yes, the certificate is trusted, if not, it isn't trusted.

With OpenPGP it's more complicated, because there are no universally accepted third parties. If a key is trusted or not depends on many factors, like the trust model implemented by an application, the user's configuration, and potentially certifications by other people.

For Thunderbird the suggestion is to start with the following simple trust model, which has three states:

(1) The signer's key is unknown to the local user, the key and signature are untrusted.
A rogue sender can easily create a fake email with a new key claiming to belong to anyone.
This is the weakest state.
This includes two technical scenarios: A copy of the signer key is available, or isn't available.
(With S/MIME the signer certificate is always available.)

(2) The user has previously accepted the signer's key, but without verifying it.
This state is similar to the "unverified" state in OTR.
This state is stronger than (1), but weaker than (3).

(3) The user verified that the signer's key indeed belongs to the associated email identity.
This is the strongest state.

In all three scenarios, the signature might be technically consistent, it's just a different in how certain we are that the key belongs to the alleged owner.

We'll have to decide which icons we'll use to visualize these states, in a way that is consistent with S/MIME.
Ideally, the icons should also be consistent with OTR, so we don't confuse our users.

Because OpenPGP has several additional states, the Enigmail implementation used an extended approach to communicate message status to the user.

In addition to icons, an additional line of text was shown above the message header area, which showed a human readable explanation of the message status.

I'm not sure if Thunderbird should also do that.

I'd like to start with the icons, only, and have additional human readable details in secondary UI, which is visible if the user clicks the icon (opening a dialog with more details, like we do today for S/MIME).

So as a first step, we need to decide how to align the OpenPGP signature states to the S/MIME states.

Let's look at a good S/MIME signature. How reliable is that? The user hasn't verified the peer's key themselves. Often, in order to obtain a S/MIME certificate for an email address, it's sufficient to demonstrate access to the mailbox. This means, an adversary might be able to obtain a rogue S/MIME certificate by temporarily controlling a mailbox of the victim. IMHO this means, the certification status of an S/MIME certificate is weaker than the full verification of an OpenPGP key by comparing fingerprints.

If we agree on this, we could use a stronger icon for scenario (3).
For example, a person with a green checkmark could be shown next to the "envelope with signet".

OpenPGP scenario (2) might be considered weaker than S/MIME, because with S/MIME, usually someone has done a verification. But with OpenPGP scenario (2), it's simply a "hope" that the key owner is correct.

This scenario (2) is similar to an OTR chat, where the user is willing to proceed with the conversation, but the user cannot be convinced to perform the full verification.

It seems reasonable to remind the user that these signatures have limited reliability, in the hope the user will eventually be motivated to perform a full verification.

[ EDIT: The remainder of this comment is obsolete, the updated idea is in comment 5.]

Therefore I suggest that we use the "questionable signature" icon for scenario (2).

This brings me to the suggestion that we should align the presentation of "OTR unverified" with "questionable S/MIME signature" and "OpenPGP scenario (2)".

We could either change the OTR icon to display a lock with a question - or - we could change the questionable signature icon to no longer use a question mark, but the orange exclamation mark currently used for the OTR icon.

Finally, for OpenPGP scenario (1), we could start by reusing the "bad signature" icon. Sometimes this status is technically correct, for example, if we don't have a copy of the signer key. However, in some scenarios, the signer key might be available, for example in an attachment in the same signed email (or we might be able to find it elsewhere). If we have a copy, then we could verify that it's a technically correct signature, and showing it as a bad signature would be technically imprecise. However, because we haven't yet decided to trust that key, it might be sufficiently close to reuse the same icon, to avoid having too many icons. So initially, I suggest we start with the "bad signature" icon for OpenPGP scenario (1).

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

So initially, I suggest we start with the "bad signature" icon for OpenPGP scenario (1).

Well, it's complicated.

In scenario (1), I'd like to visualize to the use that "something can be done to fix it". If the signer's key is available, the user is able to proceed to verify the signer's key (reaching state 3), or to simply accept it (reaching state 2).

Showing the "bad signature" icon might not be sufficient to motivate the user to click it and discover that it can be fixed.

In other words, both scenario (1) and scenario (2) should motivate the user to discover and fix, which should suggest a similar presentation. However, we'd also have to visualize that scenario (1) is weaker than (2).

Ok, I have a new idea.

For scenario (1), show the "questionable signature" icon (envelope with question mark).

Keep the "questionable signature" icon for the existing S/MIME scenarios.

For scenario (2), we show the "good signature" icon, but in addition, next to it, we show a "human with yellow exclamation mark" icon. This would match what we should for the equivalent OTR state.

For scenario (3), we show the "good signature" icon, and as mentioned earlier, we'd show a "human with green checkmark" next to it, also matching OTR.

This way, only for OpenPGP, we'd distinguish between scenarios (2) and (3), while for S/MIME, we'd continue to just show the envelope without any humans.

Summary of the suggestion:

For S/MIME, keep the icons unchanged.

For OpenPGP, reuse "no icon" and "bad signature", and for equivalent scenarios, where it makes sense, also use the "questionable signature".

For "signature OpenPGP scenario 1" (signature from unknown key), also use the "questionable signature" icon.

S/MIME keeps using the simple "good signature (envelope with signet)" icon.

For OpenPGP, whenever we had a good signature, we also show the envelope with signet, but we show an additional icon next to it.
For scenario (2), we'll show a "human with yellow exclamation mark" (unverified).
For scenario (3), we'll show a "human with green checkmark" (verified).

Attached image good signature (obsolete) —

as a reminder, this is the current "good signature" icon for S/MIME

(We recently changed the signet from red to green)

Attached image hdrSignOkUnverified.png (obsolete) —

suggested icon for scenario 2, good signature from a key that was previously accepted, but is still unverified

Attached image hdrSignOkVerified.png (obsolete) —

suggested icon for scenario (3), good signature from a fully verified key

Alex, I used a human from openclipart, and used the orange and green things from your OTR icons.

Would you be OK in general to have an additional icon next to the envelope, to visualize the reliability status of the signature, which is separate from the technical correctness of the signature? (Only for OpenPGP we need to distinguish that, not for S/MIME.)

I have made these icons just as an initial idea and starting point, I'm very open to your suggestions to enhance these, or use a different idea.

The justification text in this bug got rather long, sorry. Hope it is helpful to understand why I'm making these suggestions.

Flags: needinfo?(alessandro)

These make sense, and I think the overall direction is accurate, showing extra information based on the verification status of the used key.
I'll work on these today and create SVGs so we can properly scale them without losing quality.

Flags: needinfo?(alessandro)
Assignee: nobody → alessandro
Status: NEW → ASSIGNED
See Also: → 1647039
Attached image Message Pane icons.png (obsolete) —

Proposal to modernize and improve the readability of the various encrypted and signed states.

This will be a toolbar button, which allows the user to immediately read the type of encryption and, upon clicking on it, opening a dedicated sidebar which will be implemented in bug 1647039.

Some of these buttons have variations, in order to explore the possibility of catching more the attention through colour variations.
All these buttons will have accessible tooltips to communicate the current status of the message.

Attachment #9164902 - Flags: feedback?(richard.marti)
Attachment #9164902 - Flags: feedback?(mkmelin+mozilla)
Attachment #9164902 - Flags: feedback?(kaie)

I find the signature icon ideal.
What if for "unable to decrypt" showing the lock and beside it a red striked key?

Comment on attachment 9164902 [details]
Message Pane icons.png

Looks good. I think, we should use the v.2 with the coloured buttons to better show the status. Also to support the small signature verified/unverified icon difference.

The button looks taller than the other header buttons. It should be the same - also to not make the message header too tall.
Attachment #9164902 - Flags: feedback?(richard.marti) → feedback+
Comment on attachment 9164902 [details]
Message Pane icons.png

Looks nice, but perhaps not fully correct. The "Message decrypted" should not really be green (I'd leave that gray). That it was decrypted but not signed/verified doesn't really mean any kind of security other than very technical such. "Any" spammer out there could find your key and send you an encrypted only email saying it's coming from your bank. We clearly don't want that to show green and secure just because it's technically encrypted.

The above also kind of ties into the icons. We shouldn't show a lock (to make the user think it's secure) for encrypted only. I would skip the double icons and show green + lock for properly encrypted and verified. Essentially, encrypted or not without verification means very little: we want to give access to that information but not prominently so, since it doesn't really matter at this stage (when the message has already made it into your inbox).
Attachment #9164902 - Flags: feedback?(mkmelin+mozilla)

I like your suggestion to use a combining box around the icons.

But for almost everything else, I think we need to be very careful with this.
We shouldn't introduce new color signaling at the last minute.
I think a complete redesign should go through a longer experiment and feedback process in nightly.

I agree with Magnus that we need to be very careful what deserves a green label.
The color green might give users a false sense of confidence, without the user trying to understand in detail what's going on.
I'd suggest to use a constant, neutral background color for the box, for all scenarios (at least initially).

The reality is that this is complicated stuff.
It isn't easy to simplify.

Your suggestion drops the visual difference between a signature from a verified key and from an unverified key, which in my opinion is a very important property and improvement of our new implementation.
(Currently indicated by the black human with either an orange warning or green checkmark.)

You're suggesting to use a clipboard to visualize a signature.
I think this might not be the correct icon.
On a clipboard, you'd sign a document that you approve.
However, the kind of signature we're working with here is more of a "seal", which shows that the contents couldn't have been tampered with.
Do you know of any security product that uses a clipboard to indicate a signature status?

Some messages need an OpenPGP related icon, although they don't have any security properties.
This is true for a message that was neither signed nor encrypted, but it has OpenPGP keys attached.
In that case, we still need a notification, but there's neither a signature nor encryption.

Some of the notifications have a higher priority than others.
The notification that the message contains a new, unexpected key, is a very high priotity.
I think it needs to always be shown, and not hidden behind a small number.

Please also note, whatever changes you implement here must also be fully done for S/MIME messages, too, at the same time.
I think that S/MIME and OpenPGP status should be presented in a visual consistent way.

I'd prefer to use a more conservative approach to improve this initially.

It would be good to keep the icons that signal for encryption and signature separate.

Today, the code to drive these two states is completely separate, and enables or disables the icons independently.
If you want to migrate these into a combined state in the very short amount of time we have for 78.2, then we'll have a high risk that we make mistakes.
I feel an attempt to produce combined states needs to go through a longer experimental phase on nightly.

I don't like that the question mark for uncertain signature is barely noticable. Users shouldn't have to rely on the color coding to understand there's something to worry about.

Attachment #9164902 - Flags: feedback?(kaie)
Attachment #9164902 - Flags: feedback-

Currently the icons are our primary status feedback mechanism. We use rather big icons, which means the different states can be easily distinguished - without having to rely on color coding.

IMHO we should either stay with clear icons, and keep them bigger as suggested in the mockup. Or we'd need to switch to start using text instead (like Enigmail did).

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

I agree with Magnus that we need to be very careful what deserves a green label.
The color green might give users a false sense of confidence, without the user trying to understand in detail what's going on.
I'd suggest to use a constant, neutral background color for the box, for all scenarios (at least initially).

The reality is that this is complicated stuff.
It isn't easy to simplify.

That's so wise, thank You to get me off my temptation to get in the simple perspective again, allthough I had written about that already in my suggestion of a "promise nothing" mode in Topicbox. So I came back to my own suggestion and am again at this point. Really temptating to get off it.
The most conservative statement would be: The message is encrypted with your public key and is signed by someone. Not one cent more. And this alone does not need to be an enhancement of security. In the best case this is a (but really worthful) enhancement of privacy.

To educate users to trust something has the really dangerous drawback, that if that used to be trust is one time betrayed, the impact is a nightmare.
E.g. if users get common to say: Hey, this comes from my bank, it is signed and green, so I trust the content. And it is decrypted, too.
When now an attacker has compromised the private key of the bank and sends e2ee mails with the "correct" signature to users, where the worst malware and clickable scamming URLs can be in it, because there is no virus scanner at the provider that can look into the mails content, then this is a security nightmare. And that could leed very fast, maybe only at one single case of such, to a fatal image of e2ee, propaganda could say: You see, this is an absolute bad and dangerous thing. Do not use this! Stay on clear text mail without signature like in the "good old times"! (paradoxon)

You surely know very good about this, but I only have heard, that Google and Apple are forcing TLS "trusted" certificates to be only one year old at maximum, ceritificates with longer duration would be classified as "untrusted" in their browsers as of October 2020, since it looks like they see the only chance to get some trust in certificates/keys, is to re-create them fresh often.

P.S. "propaganda" is a too harsh word. There is even just the clickbait media, only waiting for emotional headlines that make the round. An example of the past of this as You know was the "efail" case, where the headlines was "enigmail is insecure, your key is stolen, so not {use|trust} it!!!", something like this. Hypothetically efail impact was really only in the case, that the receiver did not disable "download external content" in TB, which every security-aware user should be have disabled in the first place (what me concerns, I even set the proxy settings to "1.2.3.4:1234" to be sure TB cannot reach the internet BTW, only via proxy exceptions to my mail mail provider URLs, there is no differenciation between www and POP3 access, unfortunately in TB BTW), the same also for displaying mail in html format, which is insecure at principle. But the headlines where there, that would be einigmail's fault, and trust is built only over long time only, and is lost very very fast.

Maybe there should be a disclaimer in TB that the user has to agree to when enabling encryption/signign, e.g. "TB makes attempts to establish trust relationships and make authenticy statements for the best, but I hereby agree, that in any case it is my own responsibility to decide about the trust and authencity of a received message"? (sounds really repellent, indeed)

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

IMHO we should either stay with clear icons, and keep them bigger as suggested in the mockup. Or we'd need to switch to start using text instead (like Enigmail did).

I do like the looks of attachment 9164902 [details] so hopefully we can just do some adjustments.
I wouldn't want to have too prominent indicators. Except for debugging, the indicators are not always that useful. You want to know when it's fully secure (encrypted + signed ok). Maybe when something is correctly signed (only). For other states, I'm not sure there's an easy display solution, likely one needs to click open a longer explanation.

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

That it was decrypted but not signed/verified
doesn't really mean any kind of security other than very technical such.

ISO/IEC 27000:2009 (E). (2009) defines information security as
"Preservation of confidentiality, integrity and availability of information.", so also encryption for itself is one part of information security.
(ISO/IEC 27000:2009 (E). (2009). Information technology – Security techniques – Information security management systems – Overview and vocabulary. )

Yes, on a technical level. But we need to think about what a user would consider secure. I think users would assume it's somehow verified if it's shown as "secure". Consider the encrypted-only scam mail you could easily get...

Yes, I took the definition wrong, the "and" is important, one or two aspects alone is a step in the right direction, but you really cannot buy something with it. All three aspects must come together.

Even these three aspects of the ISO definition together ensure just the technical baseline security.
The ISO definition adds the note:
"In addition, other properties, such as authenticity, accountability, non-repudiation and reliability can also be involved."
So, on top of the raw technical information security, it's up to decide what to do with it, how to interpret it, like to state it as authentic, to trust it, to check if the content could be dangerous etc.

Attached image Message Pane icons.png (obsolete) —

Here's another iteration on those icons.

Button technology
No matter if the message is encrypted or signed, a clickable button with the currently used technology will appear if the message has anything related to it (like an attached openpgp key).
This will play along bug 1647039 where notifications will be better handled.

Colours only for errors
As correctly pointed out, we don't want to give the false expectation of security by using green highlights to encrypted/decrypted messages.
Red and orange colours will be used to highlight warnings and errors.

Signed messages
We can use an envelope with a seal since almost any other email application uses this visual approach.
The icon will show a warning flag in case the signature is uncertain or unverified.

These simple icons, alongside proper colouring and tooltips, will greatly improve the readability of these flags even for first time users.

Attachment #9164902 - Attachment is obsolete: true
Attachment #9168295 - Flags: feedback?(mkmelin+mozilla)
Attachment #9168295 - Flags: feedback?(kaie)
Blocks: 1647039
Attached image Message Pane icons.png (obsolete) —

Another quick iteration after some technical discussion with Kai in the UX matrix channel.

Attachment #9168295 - Attachment is obsolete: true
Attachment #9168295 - Flags: feedback?(mkmelin+mozilla)
Attachment #9168295 - Flags: feedback?(kaie)
Attachment #9168324 - Flags: feedback?(richard.marti)
Attachment #9168324 - Flags: feedback?(mkmelin+mozilla)
Attachment #9168324 - Flags: feedback?(kaie)

I think this covers all the states we need. I think I like it.

Here are some optional thoughts regarding the red icons:

In a hypothetical future, in which email encryption might be the norm, it might be useful to warn the user if e2ee is missing.
In other words, maybe one day we want to show an icon for "is not encrypted".

Maybe the "padlock with red strike out" would the best icon for "is not encrypted". That's how this icon could be interpreted: "there is no encryption".

In our scenario, we want to tell the user "something is broken with the encryption, or we cannot interpret the encryption".

Similarly, the signature with the red strike out could be potentially interpreted as "no signature present at all", which is different from "that signature is broken/bad".

Another argument is, with the red line on top of the icon, it gets more difficult to understand what icon it is behind the red line. This is especially true with the small signature icon.

If these arguments make sense, then you could consider to use a different variation. For example, like we do today: Show a red cross in the lower right position, for both bad signature and bad encryption icons.

I mentioned this in chat, but because it hasn't been solved, let me document another concern:

I'm worried that users might see the dominant "OpenPGP" label, and make the incorrect conclusion that this label alone has the meaning of "message is secure".

As an inspiration, maybe a more general label could be used, for example "Protection Level".

(You could also say "Encryption Level", but then we'd really have to show a "no encryption" icon for all plain messages.)

Comment on attachment 9168324 [details]
Message Pane icons.png

I'd really like to avoid a) two icons, and b) having the lock when there is only technical security

  • decrypted and no signature: I don't think we should show a lock. It's only technical security, no real security.
  • unable to decrypt message: This is an error situation. I think red is not appropriate, because it's not something to be afraid off - you won't see anything of the message whatever it was. Maybe a yellow warning would be suitable.
  • decrypted and signature verified: would like not to have two icons. For this, I would use only the lock. Not sure why we didn't make this green?
  • decrypted and signature uncertain: just the lock, and a warning triangle next to that

The signature only ones seem fine, though "signature verified" could maybe be green.

Attachment #9168324 - Flags: feedback?(mkmelin+mozilla)

Comment on attachment 9168324 [details]
Message Pane icons.png

I think too, we should only use one icon and when it has an issue show the warning or question icons. For more information use a tooltip.

And when all is okay make the button or at least the icon green.

Is the same planned for S/MIME with using this button to make it consistent and not having two different information systems?

Attachment #9168324 - Flags: feedback?(richard.marti)

All right, if we want to only use 1 icon, we should approach it from the point of view of "Only show an icon when something is wrong/requires user attention".

With that, we can simplify a lot without hiding or missing important information.

Here's a proposal:

  • Lock with green checkmark: Message decrypted and signature verified.
  • Lock with orange warning: Unable to decrypt message.
  • Envelope with red warning: Bad signature.
  • Envelope with orange warning: Uncertain or unverified signature.
  • Envelope with green checkmark: Signature verified.

These icons will be mutually exclusive, meaning that each of them will have a priority and will never be listed alongside other icons.
In terms of priorities, we could have:

  • Lock with green checkmark will only appear if everything is fine.
  • Lock with orange warning will always appear if the message can't be decrypted, ignoring the signature state since it's not relevant in this case.
  • Envelope with red warning and Envelope with orange warning will appear only if the message is decrypted.
  • Envelope with green checkmark will only appear if the message is not encrypted and only comes with a verified signature.

Does this make sense?

Is the same planned for S/MIME with using this button to make it consistent and not having two different information systems?

That's the plan, keeping the iconography consistent and only changing the encryption label (OpenPGP - S/MIME).

Attached image Message Pane icons-2.png (obsolete) —

Here's some variations based on the comment above.
I personally like the grey buttons with colored checks and flags. Less jarring, consistent with the OTR icons, and more digestible.

For 78.x, I consider a change to a single icon risky.

Comment on attachment 9168564 [details]
Message Pane icons-2.png

Agreed with aleca, the "variation 0" with gray buttons is quite nice.

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

For 78.x, I consider a change to a single icon risky.

Not sure I see the risk. I think we must do it now. Many times guides etc. for new features are documented when a feature is first created, and the documentations tend to stick around and not get updated too quickly.

Comment on attachment 9168564 [details]
Message Pane icons-2.png

I like variation 2 but 0 is also good.

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

I am missing the icon for unencrypted, but with verified signature.
Would that be a closed, sealed envelope with a green checkmark?

I find the icon of a closed sealed envelope as icon for a signature intuitively misleading, because in physical historic experience everyone knows, you cannot read the content(letter) that is in a closed sealed envelope. So that would leeds intuitively more to be viewed the same as the lock symbol.

Therefore, a real "sign pencil" icon seems for me more understandable and the user understands that this is just authenticity, not read-protection.

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

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

For 78.x, I consider a change to a single icon risky.

Not sure I see the risk. I think we must do it now. Many times guides etc. for new features are documented when a feature is first created, and the documentations tend to stick around and not get updated too quickly.

The risk is that we must change the state machine for combining state into a single icon.

Currently the state for encryption and for signing is defined completely independently.

We'd require new logic that ensures that all old mappings are correctly mapped to combined icons.

In most scenarios, we have separate MIME layers for signature and encryption. That means, the state for those becomes available at different times.

I would be reluctant to define this last minute.

Also, with the separate icons, I think the status communication is very logical.

If we switch to a combined icon, we risk that we make logic errors in our thinking, producing incorrect feedback.

If having a combined icon is that important, why wasn't this done earlier in the development? This could have been done in the past, for S/MIME.

I don't see a requirement for fixing this now, because the current icons closely follow the logic of the past S/MIME implementation.

My recommendation is to take more time for a major rework of status feedback, and target this for Thunderbird 2021.

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

Also, with the separate icons, I think the status communication is very logical.

In a technical sense yes. But it's also clearly giving the user the wrong impression about security.

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

In a technical sense yes. But it's also clearly giving the user the wrong impression about security.

I don't understand why you think so.

Security is a very vague term. It's very difficult to make a general statement that something is secure.

My recommendation is that we should refrain from making general statements about security. It is more correct to describe the facts, and the facts can be described as states of signature and encryption.

Regardless of whether changing this would be an improvement, it sounds to me like a change of this magnitude is too late because can't safely be done in the remaining time with code implementation, UX, reviews, testing, user evaluation, etc.

Last minute code changes in a release often get us into trouble.

This could land on trunk and not get an uplift, so it can normally land on a future beta.
I'd like to continue the work on this even if it doesn't land on 78 as it's necessary for bug 1647039.

I am missing the icon for unencrypted, but with verified signature.

Yes, if the message is not encrypted but only comes with a verified signature, an envelope with a green checkmark will appear, without any encryption label to the left (no OpenPGP or S/MIME).

Therefore, a real "sign pencil" icon seems for me more understandable and the user understands that this is just authenticity, not read-protection.

We currently used the sealed envelope to reflect that the message comes with a seal, which is to represent an "official stamp" from the sender, therefore a signature. It's also what we currently use as PNG icons.
I'll explore visual variations to implement a "pen-sign" type of icon, and see how it looks.

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

I don't understand why you think so.

Because, you propose to show the lock icon (for the user, that means this is secure) for mails from any scammer who has obtained your public key and sends you something encrypted only. You're looking at it from a too technical perspective, as someone who understands the details about encryption and signing - that's not the case for many people on average.

I don't see a compelling case where anyone would need to be notified a message is encrypted only. They could look it up in the details, but why show it right in their face.

Security is a very vague term. It's very difficult to make a general statement that something is secure.

Then why do you insist we show a "secure" icon for something that's not? That is making a statement.

I really can't think this is such a large change.

Please allow me to list of some simple case email messages and their physical pendant that everyone knows, maybe this could help to find icons.
I think the sender address can be ignored.

  • unsigned, unencrypted -> postcard which text is written with typewriter, no handwritten signature

  • invalid signed, unencrypted -> postcard which text and signature are both written in unknown handwriting

  • valid signed, unencrypted -> postcard which text and signature are written in the same known handwriting

  • valid signed, encrypted -> closed envelope with a letter in it which text and signature are written in the same known handwriting

  • valid signed, encrypted, and encrypted message signed with the same key as the message text -> closed and sealed envelope, with a letter in it with text and signature are written in the same known handwriting, and knowing the seal on the envelope belongs to the letters handwriting.

Question.
Is the signature tightly related to the encryption?

I mean, a signature can be added to an email without necessarily being encrypted with either opengpg or s/mime, right?

I'm asking this because if the signature is tightly related to the encryption technology, then it's good to "hide" it and only show a "positive icon" to communicate that everything is good.
But, if the signature is completely unrelated to the type of encryption, and the two things aren't mutually exclusive, then I think 2 icons for these states are necessary.

Apologies if this is a silly question.

A digital signature is a like a verifiable check-sum proving that the message was not altered, and proving who sent it. To do this checksum/verification it uses cryptography (OpenPGP or S/MIME, and the crypto algorithms beneath it), but the message itself can be either cleartext or encrypted.

I'm not sure that answers your question. I think:

  • signed/unsigned is useful for unencrypted messages to verify the information has not been tampered with and it's the right sender
  • properly signed + encrypted is good to give recognition to: this communication is secure (you can trust the content to the extent you trust the sender)
  • unsigned + encrypted: the communication security can be anything (you can't trust the content at all since you have no idea who sent it)

Bad signature needs to be clearly shown, since otherwise users might think the message is secure when it's not.

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

Question.
Is the signature tightly related to the encryption?

Not at all.

I mean, a signature can be added to an email without necessarily being encrypted with either opengpg or s/mime, right?

Correct. A signature is a completely independent property.

We produce two independent layers of MIME encoding.

Chiming in here, since I think this is important to be addressed.

✅ +1 for version 0, that Alessandro proposed. The colors on version 1 grab too much attention and can be distracting.

✅ The placement on the header is good in terms of visibility.

✅ Since Thunderbird offers two options for encryption, It's good that you included the corresponding encryption type.
Curious to know how you're thinking to show the information(ex: "Unable to decrypt message") for each scenario. I'm assuming these are labels and the information will be shown on hover?

About the first label "OpenPGP"
Not sure how it's meant to work but on the first sight, it looks like a notification where a user would click to see another popup/window with the full information.
The label could easily lead users to think that the message is encrypted since there is no standard icon that is tightly related to OpenPGP encryption. Just seeing the label "Open PGP" would be enough for the user to assume that the message is encrypted and avoid exploring further to make sure.

About the icons
There is an inconsistency on the icon usage here, meaning, on these two cases "Message decrypted and signature verified" and "Unable to decrypt message" the signature state is represented with a lock or not represented at all but on the other cases the signature is represented by an envelope with a stamp.
On the other hand, the envelope icons are only showing the state for signatures and not encryption.

From the comments above I understood that encryption and signature are independent of each other but in certain scenarios, they give a unique understanding of the message when combined together, for example, the case where the message is unsigned but encrypted, etc).
Based on that, I think it's important to show both, the state of the encryption and the signature. Either on two separate icons or one single icon.

I was curious to have an external view on the icons here, so I asked a "potential user" to describe them without any context to where and why they are being used. (Should not be considered as usability testing :P)
The user described the lock ikon as "This tells whether the site is encrypted or not" and for the envelope icons "This tells me if a message is not sent or is having problems".

(In reply to Renata Gegaj from comment #51)

From the comments above I understood that encryption and signature are independent of each other but in certain scenarios, they give a unique understanding of the message when combined together, for example, the case where the message is unsigned but encrypted, etc).

But what is the understanding to convey, that's the question.
Why would anyone care if the message is encrypted (only)?
Super technical users could understand why that is not secure, but for others it's going to be interpreted as secure (=safe) if the lock is there.

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

Why would anyone care if the message is encrypted (only)?

The sender might be worried that digitally signing their message causes them trouble under a jurisdiction. Not signing can allow the sender to plausibly deny having sent a message.

The sender might be someone who wants to give you information, but doesn't want to disclose their identity.

The sender might not have their own key available, for example, they are temporarily using a different computer, and they really need to give you some confidential information. They might set up encryption to protect the message to you. If they sign it with a temporary key, they would confuse you into thinking that they want you to use that key.

I think there might be additional scenarios where seeing the encryption property could be useful, even if we don't immediately see them.

[edit: generalized last sentence]

In the scenarios I mentioned above, I think it is useful for the recipient to know that the information traveled with end-to-end encryption, and therefore its confidentiality was likely protected.

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

In the scenarios I mentioned above, I think it is useful for the recipient to know that the information traveled with end-to-end encryption, and therefore its confidentiality was likely protected.

Yes there are (odd) reasons for the sender to encrypt only. But why should the receiver care? We need to protect the receiver from getting the wrong impression. The exact security properties could still be checked in the details if the recipient really care, but we're now talking about the primary UI.

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

I think users would assume it's somehow verified if it's shown as "secure". Consider the encrypted-only scam mail you could easily get...

The question arose to me: Would You see any difference in security level between encrypted-only scam mail, and a scam mail encrypted plus signed with an unknown key (e.g. the authentic key of the spammer)?

If the signature is uncertain, it should not show green.
But, as successful scam entails tricking the recipient you're someone trusted. If you get an email from someone unknown, you're likely not to fall for the scam as easily. So, if I see it "secure" but from scam@example, that's not likely to cause problems. If i see it's "secure" and from my mother (unsigned, so no knowing), the chance of problems is higher.

I thought some more about icons and would like to suggest the following (relates to my mapping in comment 47):

<message type> -> <icons>

  • clear text, unsigned -> postcard

  • clear text, invalid signature -> postcard + letter-pen-sign with red triangle

  • clear text, unknown or untrusted signature -> postcard + letter-pen-sign with question mark

  • clear text, trusted (this implies known) signature -> postcard + letter-pen-sign with check mark

  • encrypted, unsigned -> closed envelope

  • encrypted, invalid signature -> closed envelope + letter-pen-sign with red triangle

  • encrypted, unknown or untrusted signature -> closed envelope + letter-pen-sign with question mark

  • encrypted, trusted (this implies known) signature -> closed envelope + letter-pen-sign with check mark

  • trusted signed+encrypted+trusted signed -> closed envelope with seal + letter-pen-sign with check mark

Two things here I would like to emphasize:

  • current standard mails (unencrypted+unsigned) get an icon, too. This is to show and remember the user that these type of mails are like postcards written with an anonymous type writer. It is a neutral little icon, not red, not alerting, there could be a tool tip saying "postcard information level". The users can decide for themselve, how they like this. Typically, initially 100% of mails will have this icon.
  • Closed envelope icon is also modest, no big security promise. If users at some point of time receive their first encrypted mail, that would have a simple closed envelope, the user recognizes the other icon. If they get a physical closed envelope, they also know, that is somehow secure, but not secure against tailored, expensive attack, e.g. nation state level attack. But it's commonly viewed as reasonable secure, private information. No big need to explain this.

The idea of having postcard icon for "normal" mail and broadly known envelope icon should have the following benefits:

  • Motivate the user to use encryption more often: When users start receiving first mails with closed envelope icon, they probably want get higher percentage of mails with this icon, than with the postcard icon. It's simple: Envelope is better than postcard, everyone knows. It turns "I need to hide something" into "I simply want to stop broadcasting everything to anyone"
  • The modest envelope icon takes also the nerdy "super secure" pressure. Receiving physically closed envelopes is completly normal, You don not make yourself suspicious if You like to get physical letters in closed envelope instead of postcard. I say this, because a friend of mine rejected e2ee mail because he said, "You only get in the focus with this and make yourself suspisious. I like it better to swim with the tide, in this case, and use unencrypted mail."
  • The focus moves away from having to point out encrypted mail as something special, more to the direction of "Compare for yourself between postcard and closed envelope. Decide for yourself". Idea is, that this could help reduce the pressure and risk of making security statements for encrypted/signed mails.

I have to admit, I came to the conclusion that physical mail is really not very secure. E.g. I assume it would be very easy to create a physically, good quality fake bank letter, and at least in europe, electronically created and machine printed letters are legally valid without human signature and people trust them. I think the only reason for so few physical spam + scam mail is that it is so expensive (paper, printing + post stamps). So, this big difference has to be taken into account, when comparing usage experience of physical with electronic mail.

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

If i see it's "secure" and from my mother (unsigned, so no knowing), the chance of problems is higher.

As I understand, You mean unknown signature is generally less problematic than no signature?
I think, the conclusion then would be, that in case there should an icon be used to indicate technically correct signature but from unknown signee, then there must also an icon be used in case there is just no signature.

Correct, since then you can't fake the sender without being noticed, especially if you had the key of the real sender.

Coming back here after 2 weeks off, apologies for the delay.

Renata, thank you so much for your feedback.

About the first label "OpenPGP"
Not sure how it's meant to work but on the first sight, it looks like a notification where a user would click to see another popup/window with the full information.

That's correct.
We're trying to move away from the "notification bar" paradigm since we're using those for many other things and we end up with 2 or 3 bars all visible at once far too often.

The label could easily lead users to think that the message is encrypted since there is no standard icon that is tightly related to OpenPGP encryption. Just seeing the label "Open PGP" would be enough for the user to assume that the message is encrypted and avoid exploring further to make sure.

That's a good point.
The idea here is to show that label only if there are notifications related to OpenPGP, but I guess an icon will always be present in order to represent the current status of the message.

About the icons...

I think we should try to use the lock to represent the encryption status since that's what we currently use in the OTR implementation.
I will explore other possible approaches for the signature icon.
All those icons will have descriptive tooltips to help users understand what they represents.

Regarding comment 58, I'd like to highlight the fact that we're trying to simplify our messaging by using less icons.

If an email is not encrypted nor as a signature, we don't need to show anything. Showing a "non existing" status is mostly noise and redundant.
The approach here is very simple and linear:

  • If something is wrong/incorrect/sketchy, we show an alert related to what's not correct.
  • If everything is correct, we show a positive icon.

That's it, this should be our objective, to remove noise and avoid the usage of 20 different icon+text combination.
Alert the user if something is wrong and invite him to click the label to learn more.
We don't want/need to communicate everything through icons, which is extremely complicated and not universally understandable.

The most recently uploaded icons are pointing towards the right direction, but they need a little bit more work, especially when needing to represent a signature that it's unrelated to any encryption.

Regarding this, is it possible to have a bad/uncertain/unverified signature without being related to openpgp or s/mime?
Will we ever have a case where we need to show the signature status without any encryption?

(In reply to Alessandro Castellani (:aleca) from comment #63)
Unfortunately we have the 3rd class too that needs to be accessible somehow: more or less informational messages that let's the user handle incoming keys from autocrypt headers, key updates and such.

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

Regarding this, is it possible to have a bad/uncertain/unverified signature without being related to openpgp or s/mime?

No.

Will we ever have a case where we need to show the signature status without any encryption?

Yes, a typical case is wanting to verify the signature of an unencrypted mail sent to a mailing list. E.g. package maintainers send out emails about and update and include the checksums for the new executables in the email text. To make sure those are correct, you can verify the signature of that email. If the signature is ok and you trust the key, you can trust that the content in the mail is ok.

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

  • If something is wrong/incorrect/sketchy, we show an alert related to what's not correct.
  • If everything is correct, we show a positive icon.

The point is only to define what "sketchy" and "correct" is.
Is a signed mail signed with an unkown key sketchy, while an unsigned, unencrypted mail is correct?

This remembers me of the paradox human behavior in companies I experienced regarding TLS:
Unencrypted HTTP? All fine, nobody asks.
HTTPS with a Cipher Suite component with a hypothetical weakness (e.g. SHA-1, it was possible to show one collision with extreme cpu power effort)? Alarm! Security problem! We need to fix this!

At least, browsers started to show an alarm icon when there are login forms in unencrypted HTTP-Sites last year, So I guess there will be an according shift in email triage of "correctness".

I think I have made my point last clear, and will not bother You further with it.

Attachment #9168324 - Flags: feedback?(kaie)
Attached patch 1624676-openpgp-icons.diff (obsolete) — — Splinter Review

I propose to go through small iterations in order to land the important icon updates on 78, and then use the extra time to properly optimize this section.

In this patch I simply replaced the current icons with visually consistent SVGs and kept all the various states of encryption and signature to not change the underlying mechanics.

No tooltip unfortunately, as we can't land new strings at this stage.

Attachment #9172900 - Flags: ui-review?(richard.marti)
Attachment #9172900 - Flags: review?(mkmelin+mozilla)
Attachment #9172900 - Flags: review?(kaie)
Attached image Message Pane icons.png (obsolete) —

Screenshot recap of the new icons for reference.

Attachment #9135507 - Attachment is obsolete: true
Attachment #9135509 - Attachment is obsolete: true
Attachment #9135510 - Attachment is obsolete: true
Attachment #9168324 - Attachment is obsolete: true
Attachment #9168564 - Attachment is obsolete: true

Feedback for image 9172901:

  • On the first look I could not recognize the seal icon. Wondered what this gear with two cascets attached to it could be. Took me some time to recognize.
  • I am not quite sure, does the signature verification state only mean the trust status of the signature key? Should that better be called "signee verified", "signee unknown" etc.?
    I think there is missing the status of the technical signature validation. Independently of the signee trust/known status, the signature itself can be valid (correct message hash) or invalid (wrong message hash). Invalid signature is a really bad case, since given error free implementation this means that the message was modified after signing. So, there could e.g. be the case "verified signee (key), but signature mismatch", which would be bad.

Maybe be it would be helpful to create a matrix with all of the different combinations of encryption/signature state, until really all cases are in it, then creating groups of these cases and finally decide about icon for each case group?

Comment on attachment 9172900 [details] [diff] [review]
1624676-openpgp-icons.diff

Review of attachment 9172900 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good and I think we can use this iconography for the first iteration.

ui-r- because of the issue with the message decrypted icon which is too tall and because of this blurry. Also looks the alignment not correct when both, encryption and signing, are shown. Screenshot follows. I also think that the icons are too much apart (only tested on Windows). Maybe you should give #signedHdrIcon and #encryptedHdrIcon a `padding-inline: 2px !important;` to make the buttons smaller.

::: mail/themes/shared/mail/icons/connection-secure-alt.svg
@@ +1,4 @@
> +<!-- This Source Code Form is subject to the terms of the Mozilla Public
> +   - License, v. 2.0. If a copy of the MPL was not distributed with this
> +   - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
> +<svg xmlns="http://www.w3.org/2000/svg" width="16" height="17" viewBox="0 0 16 17">

The height and viewbox should be 16.
Attachment #9172900 - Flags: ui-review?(richard.marti) → ui-review-
Attached image icon-align.png (obsolete) —

The screenshot shows the comparison of With your icon on top and my updated icon on bottom. Not changed is the spacing between the two icons.

Your icon is one px too high positioned. I moved it 1px lower. Also good visible is the blurriness.

Attached patch 1624676-updated-icons.patch (obsolete) — — Splinter Review

Updated icons. I fixed the height and the lock icon position of connection-secure-alt.svg and optimised all icons which are now smaller in size.

You can fold the patch together with your updated patch.

Comment on attachment 9172900 [details] [diff] [review]
1624676-openpgp-icons.diff

Review of attachment 9172900 [details] [diff] [review]:
-----------------------------------------------------------------

I think for "signature unverified" a yellow check-mark would be more appropriate. Now it makes it seem like a bigger problem than unknown signature. OTOH, almost not worth having a distinction between the two.

Other than the icons are nicer than what we have so it's a slight improvement. Still think we need to have just one icon and not show a lock unless everything checks out.

With the patch the technology (OpenPGP or S/MIME) doesn't show. I think it would be good to show and IIRC earlier patches did that?
Attachment #9172900 - Flags: review?(mkmelin+mozilla)

Here it shows if it's S/MIME or OpenPGP on the left of the icons.

Attached image brokensignature-linux.png (obsolete) —

What I'm seeing

Attached image SMIME-encryption.png (obsolete) —

In attachment 9172910 [details] you can see the OpenPGP title and in this attachment the S/MIME.

Maybe some element info was persisted? I tried safe-mode + reset toolbars, but that didn't make a difference.

Tested the patch under Linux and the label is shown here.

Strange. I tried a clean profile too now. Still doesn't show a label.

Thank you Richard for updating the icons, I implemented your fixes.

Replying to Magnus:

Other than the icons are nicer than what we have so it's a slight improvement. Still think we need to have just one icon and not show a lock unless everything checks out.

I agree with this, but I wanted to first iterate with a simple patch that updates the icons for pure visual consistency.
This simple update will allow us to uplift to 78 without worrying too much, and it will gives us time to properly discuss and find a streamlined solution for the various cases.

Quoting bugzilla0248

Maybe be it would be helpful to create a matrix with all of the different combinations of encryption/signature state, until really all cases are in it, then creating groups of these cases and finally decide about icon for each case group?

Indeed, we should do this and spend a little bit more time to cover all the cases.
I'd like to do this in a follow up bug.

With the patch the technology (OpenPGP or S/MIME) doesn't show. I think it would be good to show and IIRC earlier patches did that?

Is that email you shared the screenshot of, encrypted with OpenPGP or S/MIME?
I think I found the issue.

I think for "signature unverified" a yellow check-mark would be more appropriate. Now it makes it seem like a bigger problem than unknown signature. OTOH, almost not worth having a distinction between the two.

A yellow check-mark is a very unusual paradigm as it's not commonly used, and would also be misleading for color blind users as we can't rely only on colors to distinguish states.

If we want to avoid using different icons for those states, I suggest to keep the yellow exclamation mark for "unknown", "unverified", and "mismatch".

Attached patch 1624676-openpgp-icons.diff (obsolete) — — Splinter Review
Attachment #9172900 - Attachment is obsolete: true
Attachment #9172911 - Attachment is obsolete: true
Attachment #9172900 - Flags: review?(kaie)
Attachment #9173165 - Flags: ui-review?(richard.marti)
Attachment #9173165 - Flags: review?(mkmelin+mozilla)

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

If we want to avoid using different icons for those states, I suggest to keep the yellow exclamation mark for "unknown", "unverified", and "mismatch".

Mismatch is different. That means something might be really wrong.
Unknown or unverified are just slightly different levels of "it might be correct, or not".

So we could go with a question mark for "Unknown" and "unverified", and the yellow warning for "mismatch"

Yes, except for that mismatch should probably be red since that is an error which wouldn't happen by accident.

I'm not sure if we're using the "mismatch" attribute correctly in the OpenPGP implementation as it seems we assign that attribute for the UNCERTAIN flag, no matter if it's INVALID or MISMATCHED.
https://searchfox.org/comm-central/rev/e75f551c5deb7740ac08a13cb9e488b1c4ed3f82/mail/extensions/openpgp/content/ui/enigmailMsgHdrViewOverlay.js#569-581

Is this correct?

Flags: needinfo?(kaie)
Attached patch 1624676-openpgp-icons.diff (obsolete) — — Splinter Review

Meanwhile I'm uploading the updated patch so you can test it and review it.
I also removed all the old PNGs files.

Attachment #9173165 - Attachment is obsolete: true
Attachment #9173165 - Flags: ui-review?(richard.marti)
Attachment #9173165 - Flags: review?(mkmelin+mozilla)
Attachment #9173178 - Flags: ui-review?(richard.marti)
Attachment #9173178 - Flags: review?(mkmelin+mozilla)

Comment on attachment 9173178 [details] [diff] [review]
1624676-openpgp-icons.diff

digital-signature-unknown.svg is missing in this patch.

Attachment #9173178 - Flags: ui-review?(richard.marti)
Attachment #9173178 - Flags: review?(mkmelin+mozilla)
Attached patch 1624676-openpgp-icons.diff (obsolete) — — Splinter Review

Argh, sorry about that.

Attachment #9173178 - Attachment is obsolete: true
Attachment #9173225 - Flags: ui-review?(richard.marti)
Attachment #9173225 - Flags: review?(mkmelin+mozilla)

Comment on attachment 9173225 [details] [diff] [review]
1624676-openpgp-icons.diff

Looks good for me. Like I already reported earlier, I think the two icons should be together nearer. The buttons shouldn't so wide which isn't so bad as they are not many times used.

I'll let the encryption experts decide if the icons are correct for the different states.

Attachment #9173225 - Flags: ui-review?(richard.marti) → ui-review+

Looks good for me. Like I already reported earlier, I think the two icons should be together nearer. The buttons shouldn't so wide which isn't so bad as they are not many times used.

Thanks for the positive ui-r.
Indeed, as I wrote in a previous comment, this patch focuses purely on updating the icons to guarantee a consistent look for 78.
The work on unifying those states and rely on a single button needs more thorough discussion and approval, and will be done in a follow up bug.

Comment on attachment 9173225 [details] [diff] [review]
1624676-openpgp-icons.diff

Review of attachment 9173225 [details] [diff] [review]:
-----------------------------------------------------------------

Well now uncertain signature is a red triangle. I don't think it should, that should be "informational" blue or something. All that means is we don't have the signature yet so we don't know.

Hmm, or maybe it's working correctly. I see the button has signed="mismatch", but it shouldn't :/
Need to investigate that first.

The technology label is showing correctly now. But shouldn't the icons be inside a button for the technology, so that the whole OpenPGP is clickable?

::: mail/themes/shared/mail/smime/smime-compose.css
@@ +57,5 @@
> +  list-style-image: url("chrome://messenger/skin/icons/digital-signature-unknown.svg");
> +}
> +
> +#signedHdrIcon[signed="ok"] {
> +  list-style-image: url("chrome://messenger/skin/icons/digital-signature.svg");

could you rename the files to have -ok, -mismatch etc.?

The problem in comment 94 isn't seen on trunk because mismatch and unknown have the same icon (the question mark), which seems pretty bad actually. Looks like https://searchfox.org/comm-central/rev/78a165ed474d0278d4c23c947929d4bf17d6c593/mail/extensions/openpgp/content/ui/enigmailMsgHdrViewOverlay.js#581 is casting a way to large net into "mismatch"? Shouldn't it be "unknown" for some cases there?

Or did I misunderstand what mismatch is supposed to be? (Technically correctly signed, but using a key that is different from the one you have for this recipient.)

What I meant in comment 70 was the mismatch of the signed message hash and the actual message hash, so technically invalid signature (possible modification attack).

Magnus, indeed.
That's what I wrote in comment 88 as it seems to me that we're grouping different states under the same umbrella, which doesn't seem correct.

The text we show for mismatch makes me believe my understanding is correct:
https://searchfox.org/comm-central/rev/115cf24c0971773154a93009eb41a760a1cbeec9/mail/locales/en-US/messenger/openpgp/msgReadStatus.ftl#17. It doesn't seem right to group that under "unknown" when we clearly know it's not the right person.

Flags: needinfo?(patrick)

I don't like that you are combining the states (a) "signature from an unknown key" and (b) "signature from a known, but unverified key" into the same visual status.

I'd like an experienced user to be able to immediately distinguish these states by looking at the icons.

(a) means: "nothing done from my side yet". It's really an unknown state. It's something new. It's a correspondent using a new key. Or a correspondent starting to use a key for the first time.

(b) means, I have already done something. Namely, I have previously deliberately made the decision to accept the correspondent's key. I have seen this key before. That means, if I repeatedly see signatures in this state, we have a kind of continuity.

I strongly vote for using different visuals for these scenarios.

Flags: needinfo?(kaie)

Comment 99 is about the states "unknown" and "unverified".

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

Comment 99 is about the states "unknown" and "unverified".

Kai, I agree with this, and I think that's the direction we're going.
The problem is that we get a "mismatch" attribute when actually it should be unknown.

In the Acceptance radio group we have these 4 options which translate in the follow attributes:

  • No, reject this key. -> "notok" -> icon signature with red flag
  • Not yet, maybe later. -> "mismatch" -> icon signature with red flag
  • Yes, but I have not verified that it is the correct key. -> "unverified" -> icon signature with orange flag
  • Yes, I have verified in person this key has the correct fingerprint. -> "verified" -> icon signature with green flag

I think the problem is on the 2nd point, where instead of "mismatch" the code should apply the "unknown" attribute to get the icon signature with the blue question mark.

Attached image Message Pane icons.png —

These are all the icons with the proper corresponding cases.

Attachment #9172901 - Attachment is obsolete: true
Attachment #9172910 - Attachment is obsolete: true
Attachment #9173030 - Attachment is obsolete: true
Attachment #9173033 - Attachment is obsolete: true
Attached patch 1624676-openpgp-icons.diff (obsolete) — — Splinter Review

This is the updated patch with the single button and renamed icons.
I'm not asking for a full reivew due to the problem of an unknown signature being flagged as a mismatch.

Richard, I'm asking another ui-review due to the custom HTML button I created with span label and 2 images.

Attachment #9173225 - Attachment is obsolete: true
Attachment #9173225 - Flags: review?(mkmelin+mozilla)
Attachment #9173751 - Flags: ui-review?(richard.marti)
Attachment #9173751 - Flags: feedback?(mkmelin+mozilla)

Magnus asked about the meaning of the "mismatch" status.

Originally it was about a mismatch of the sender in the email header and the owner of an S/MIME certificate.
A mismatch in the meta information.

If the mismatch is the only problem we find, then it means the signature by itself is technically valid signature - but because of the mismatch, we don't know if the signature was made by the shown sender.

Previously this "meta/sender information mismatch" was mapped to the same visuals as a signature of "unknown" state. Both showed the same icon. I see the OpenPGP code currently makes a shortcut and uses the "mismatch" state for both scenarios.

If we have both the "unknown" state for other scenarios, and also the "bad signature" scenario, then I think the scenario "sender meta information doesn't match information in the key/certificate" is closer to the "unknown" state.

In theory, you could argue that showing the bad signature state makes sense for the mismatch scenario. The problem is that this doesn't play well with the current OpenPGP code, which uses the "mismatch" state also for some "unknown" scenarios.

If we don't want to improve the state mapping at the same time, I suggest that you continue to map the "mismatch" CSS state to the same icon as the "unknown" state.

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

The problem is that we get a "mismatch" attribute when actually it should be unknown.
...

  • Not yet, maybe later. -> "mismatch" -> icon signature with red flag
    ...
    I think the problem is on the 2nd point, where instead of "mismatch" the code should apply the "unknown" attribute to get the icon signature with the blue question mark.

I agree that we should make this change.
I'll check how to change that.

See Also: 1647039 → 1662881

Comment on attachment 9173751 [details] [diff] [review]
1624676-openpgp-icons.diff

Much better with only one button.
ui-r- because the button rules don't apply correctly on dark theme. You need to add here https://searchfox.org/comm-central/rev/115cf24c0971773154a93009eb41a760a1cbeec9/mail/themes/linux/mail/messenger.css#108 here https://searchfox.org/comm-central/rev/115cf24c0971773154a93009eb41a760a1cbeec9/mail/themes/osx/mail/messenger.css#105 and here https://searchfox.org/comm-central/rev/115cf24c0971773154a93009eb41a760a1cbeec9/mail/themes/windows/mail/messenger.css#140 a :root[lwt-tree-brighttext] .crypto-button,.

With this added you can set the ui-r+

Attachment #9173751 - Flags: ui-review?(richard.marti) → ui-review-
Attached patch 1624676-openpgp-icons.diff (obsolete) — — Splinter Review

Patch updated after bug 1662881 landed.

Attachment #9173751 - Attachment is obsolete: true
Attachment #9173751 - Flags: feedback?(mkmelin+mozilla)
Attachment #9173786 - Flags: ui-review+
Attachment #9173786 - Flags: review?(mkmelin+mozilla)

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

The text we show for mismatch makes me believe my understanding is correct:
https://searchfox.org/comm-central/rev/115cf24c0971773154a93009eb41a760a1cbeec9/mail/locales/en-US/messenger/openpgp/msgReadStatus.ftl#17. It doesn't seem right to group that under "unknown" when we clearly know it's not the right person.

I agree, it makes sense to display the text like that. Some mail applications do it in this way, others don't care at all.

Flags: needinfo?(patrick)
Comment on attachment 9173786 [details] [diff] [review]
1624676-openpgp-icons.diff

Review of attachment 9173786 [details] [diff] [review]:
-----------------------------------------------------------------

Looks quite nice now, thx! r=mkmelin with some technical adjustments per my comment below

The styles are all in mail/themes/shared/mail/smime/smime-compose.css now which is confusing. 
Might be worth just merging all the rules into mail/themes/shared/mail/messageHeader.css (or other general place, not sure what the compose window needs form these, if anything)

::: mail/themes/shared/mail/smime/smime-compose.css
@@ +4,5 @@
>  
>  /* ===== smime-compose.css ========================================
>    == Styles for the S/Mime in composer window.
>    ======================================================================= */
> +/*@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");*/

let's remove instead of commenting out

@@ +69,5 @@
> +  list-style-image: url("chrome://messenger/skin/icons/digital-signature-unknown.svg");
> +}
> +
> +#signedHdrIcon[signed="mismatch"] {
> +  list-style-image: url("chrome://messenger/skin/icons/digital-signature-insecure.svg");

I think we should be consistant with the naming, so -mismatch instead of -insecure

Well, all these names should preferable start with "signed", not signature, because it gets semantically confusing if the signature is technically ok but is not ok due to settings for the key (e.g. above the signature-unknown: it's not the signature that's unknown, it's whether the status of the signing that's unknown).

I'd propose signed-mismatch

@@ +78,5 @@
> +}
> +
> +#encryptedHdrIcon[encrypted="ok"] {
> +  list-style-image: url("chrome://messenger/skin/icons/connection-secure-ok.svg");
> +}

Not sure what connection has to do with this. Name it encrypted-ok.svg?

@@ +81,5 @@
> +  list-style-image: url("chrome://messenger/skin/icons/connection-secure-ok.svg");
> +}
> +
> +#encryptedHdrIcon[encrypted="notok"] {
> +  list-style-image: url("chrome://messenger/skin/icons/connection-insecure.svg");

encrypted-notok.svg?

And maybe even add a message- prefix to all the names
Attachment #9173786 - Flags: review?(mkmelin+mozilla) → review+

Names and CSS files updated.
In the messangercompose we need a couple of standard icons for encryption and signature to reflect the user's preferences.
Moved those declarations in the proper CSS file.

Attachment #9173786 - Attachment is obsolete: true
Attachment #9173880 - Flags: ui-review+
Attachment #9173880 - Flags: review+
Keywords: checkin-needed-tb
Target Milestone: --- → 82 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/1ef7d4265492
Improve the OpenPGP icons in the Message Pane. r=mkmelin, ui-r=Paenglab

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED

(dunno what draft comment got sent here)

status-thunderbird81: --- → affected
status-thunderbird_esr78: --- → affected
tracking-thunderbird_esr78: --- → +
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/b33e0bb01348
followup - fix packaging bustage. rs=bustage-fix DONTBUILD

I've looked at the checked in behavior, and my remaining concern is:

The blue "unknown" question mark icon is so tiny.
I cannot identify it on my screen as a question mark, it's only because I know it.

The "unknown" uses a harmless and cozy blue.
The "unverified" uses a warning orange.

I think the strength of the signaling should be reversed between these two.

The "unknown" should signal "hey you have no idea what's going on here, really be careful".
The "unverified" should signal "you already decided to put some trust into this, but please remember there are some doubts left".

Flags: needinfo?(alessandro)

followup - fix packaging bustage. rs=bustage-fix DONTBUILD

Argh, sorry for missing the duplicates and the bustage.

The "unknown" should signal "hey you have no idea what's going on here, really be careful".
The "unverified" should signal "you already decided to put some trust into this, but please remember there are some doubts left".

Sure, we can improve this in a follow up bug now that we're not pressured to land it on 78.
These icons perfectly reflect what we had before, with the unknown attribute returning an envelope with a blue question mark.

Flags: needinfo?(alessandro)
Blocks: 1663490

Comment on attachment 9173880 [details] [diff] [review]
1624676-openpgp-icons.diff

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: Replaces old and inconsistent icons for encrypted messages and improve the usability of the section.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Attachment #9173880 - Flags: approval-comm-esr78?
Attachment #9173880 - Flags: approval-comm-beta?

Comment on attachment 9173880 [details] [diff] [review]
1624676-openpgp-icons.diff

[Triage Comment]
Approved for beta.
Approved for esr78.

Attachment #9173880 - Flags: approval-comm-esr78?
Attachment #9173880 - Flags: approval-comm-esr78+
Attachment #9173880 - Flags: approval-comm-beta?
Attachment #9173880 - Flags: approval-comm-beta+
See Also: → 1731984
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: