Make encrypted/signed information on sent mail coherent

[pixelated]

Make encrypted/signed information on sent mail coherent

[lqust]

Notes

• This is related to #59, which is about displaying encryption status in all other types of messages. It could make sense to wait until it is done to work on this one.
• We should split it in two, one for signature, one for encryption, unless there's a strong technical reason to do it.

Why we are doing it
Knowing after the fact if a given message I have sent is encrypted. Sent messages use a different wording than all others.

How do we know when it is done
When I open a message I have sent (in sent folder or in a tag), I can see messages telling me I have encrypted and/or signed the message or not. A table with the labels will be provided when the story is picked up. Look for @albogabriel or @lqust.

[bwagnerr]

This can be done as soon as Duda's pull request is released.

[oliviagj]

This issue is connected with #17
We will have to deal with multiple outcomes for multiple recipients (ex. for recipient A it was possible to encrypt, for recipient B it wasn't possible to encrypt and for recipient C address doesn't exist, etc.)

[dudadornelles]

So here is the situation:

Right now, it is possible to send an email to multiple recipients where not all of them have public keys available - resulting on encrypted mail for those that have a public key and plain text for those that don't (this is the default behaviour of leap mail).

To show the encryption information for the sender one option would be to say "This message was encrypted for some of the recipients" with the option to get more details on who got it plain and who got it PGP.

Other option would be to do not encrypt to the message anybody if at least one recipient doesn't have an available public key (this is harder to achieve given leap mail architecture).

Another option would be to not send the mail at all if at least one recipient doesn't have an available public key (easier to do since we can check for keys before entering leap mail code).

@olabini what you think? any other ideas?

[olabini]

So this is one of those cases where a holistic, coherent UX strategy around encryption and signing is necessary. My immediate reaction would be to say that allowing a person to send an email under these circumstances would be irresponsible. However, that depends on if we the user requires the encryption, or it's just a nice to have.

It's for questions like this where we need that whole experience designed - without taking current limitations of LEAP mail into account.

One alternative would be to have different profiles, such as

• Paranoid: never send email unless it can be encrypted to trusted/verified keys
• Prudent: never send email unless it can be encrypted (although it can be to unverified keys)
• Opportunistic/I don't care: do a best case effort, but don't fail if it doesn't work

These profiles could be choosable on an email-by-email basis as well.
Another alternative is to do something similar to Mailpile, which is to indicate which receivers we have encryption information on, before even pressing the send button.

I can't answer the question as such, since I think @albogabriel needs to design the experience. I would be unhappy if the opportunistic profile is the only available behavior.

[bwagnerr]

My take on this, is that we might lose the confidence of the whole system
if we allow mixed encryption.

If we do an all or nothing approach, someone that receives an encrypted
mail can be somewhat confident that the contents of the email were always
encrypted (anyone who saw it was a recipient).

If we allow the mixed case, receiving an encrypted mail doesn't guarantee
that the contents of the mail could not be intercept on the way to someone
else (that didn't have a gpg key), the person will be suspicious of every
encrypt mail it receives with sensitive content.

I would say, if someone doesn't have a key, warn before sending and send it
only on plain text, so everyone that receives will know the information is
public anyway and react accordingly (or don't).

Bruno W.G.
[email protected]

On 13 February 2015 at 19:38, Ola Bini [email protected] wrote:

So this is one of those cases where a holistic, coherent UX strategy
around encryption and signing is necessary. My immediate reaction would be
to say that allowing a person to send an email under these circumstances
would be irresponsible. However, that depends on if we the user requires
the encryption, or it's just a nice to have.

It's for questions like this where we need that whole experience designed

• without taking current limitations of LEAP mail into account.

One alternative would be to have different profiles, such as

• Paranoid: never send email unless it can be encrypted to
  trusted/verified keys
• Prudent: never send email unless it can be encrypted (although it
  can be to unverified keys)
• Opportunistic/I don't care: do a best case effort, but don't fail if
  it doesn't work

These profiles could be choosable on an email-by-email basis as well.
Another alternative is to do something similar to Mailpile, which is to
indicate which receivers we have encryption information on, before even
pressing the send button.

I can't answer the question as such, since I think @albogabriel
https://github.com/albogabriel needs to design the experience. I would
be unhappy if the opportunistic profile is the only available behavior.

—
Reply to this email directly or view it on GitHub
#28 (comment)
.

[olabini]

Hey,

If we allow the mixed case, receiving an encrypted mail doesn't guarantee
that the contents of the mail could not be intercept on the way to someone
else (that didn't have a gpg key), the person will be suspicious of every
encrypt mail it receives with sensitive content.
You can't stop this from happening as long as you use an open system like GPG. Since someone could use Enigmail and send a mixed email, you
received it in Pixelated - and you have no idea which one it was. The responsibility here has to lie on the sender, not the receiver,
although we might think about introducing some kind of header that indicates whether the content was confidential to all receivers or
something. However, that's a complicated new feature.

Cheers

Ola Bini (https://olabini.se)

"Yields falsehood when quined" yields falsehood when quined.

[dudadornelles]

Another alternative is to do something similar to Mailpile, which is to indicate which receivers we have encryption information on, before even pressing the send button.

I did some experiments around that today, see c52ce25

I like the profile idea though, it seems like a good way to include different kinds of user and make them understand what are the consequences of selecting each profile.

The responsibility here has to lie on the sender, not the receiver,
although we might think about introducing some kind of header that indicates whether the content was confidential to all receivers or
something. However, that's a complicated new feature.

That wouldn't be too complicated in our side, the problem here is to have the other MUAs implementing something to read that header and presenting that info to the user. If we understand that having the info in the message is already good for certain users that look at headers then this is something we should consider implementing for when the "Opportunistic/I don't care" profile sends mixed encryption (i'll just call it like that) messages.

[tiagoferraz]

#59 is closed. We still have problems with signatures ( #165 ) , so we could fix this one for encryption and create one for signatures?

[bwagnerr]

We decided we will not monkey patch Leap for these features anymore, so we'll have this for free when we or leap add support directly in Leap mail. Closing this in the user agent since this doesn't make sense anymore