K-9: Add option to disable "end to end" encryption warning for mails that are encrypted but not signed

[craftyguy]

Please add an option to disable this message, which must be dismissed every time to be able to view a message that has been encrypted but not signed.

[Valodim]

Hmmh, yes maybe.

I'm worried that hitting an "ignore this warning" button once will legitimize this mode of sending encrypted messages down the road, or worse, give users a false sense of security.

(see also https://k9mail.github.io/2017/01/30/OpenPGP-Considerations-Part-II.html)

[jeremiahmegel]

I use gpgit to encrypt all of my incoming email, so literally every message I receive is encrypted but not signed.

I can see why it's a good idea to disable this feature for the general public, but for me it's very inconvenient.

[Valodim]

is there a reason you can't also just sign those messages with a key made for this purpose?

[jeremiahmegel]

I'll certainly look into making the modifications to the script. Though either way, it'd be a bit of an undertaking to retroactively process thousands of messages.

_(Basically me right now: https://xkcd.com/1172/)_

[craftyguy]

I use another mechanism for encrypting mails that I am unable to modify for signing.

I totally understand the reasoning behind not making this the default for general users, so I'd support something like burying it somewhere in the settings menu surrounded by big fat warnings. I found the previous mechanism, which was changing the little lock to 'red' when either encryption or signing was missing, was effective in notifying me that an important message was not in a state I might expect it to be in. So this new mechanism is just an annoyance because I already _know_ it's not signed and I am not expecting the vast majority of my emails to be signed :)

[Valodim]

Hm. Can you say why you are unable to modify this mechanism for signing?

There are different use cases to disabling this warning. One would be to ignore per sender address, to get rid of warnings for those people who just don't want to follow proper cryptographic procedure. Another would be to ignore them altogether for some given account, but the potential for abuse is very high for that.

[craftyguy]

Sure, my email provider (mailbox.org) supports encrypting all emails
they receive with my public key. If I also wanted them to sign those
emails, I would have to supply my private key, which I do not want to
do (assuming their mechanism also supports signing, I don't know).

On Mon, Feb 27, 2017 at 04:50:45PM -0800, Vincent Breitmoser wrote:

Hm. Can you say why you are unable to modify this mechanism for signing?

There are different use cases to disabling this warning. One would be to ignore per sender address, to get rid of warnings for those people who just don't want to follow proper cryptographic procedure. Another would be to ignore them altogether for some given account, but the potential for abuse is very high for that.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/k9mail/k-9/issues/2286#issuecomment-282906253

[jeremiahmegel]

Was just thinking. If I did modify gpgit for signing, it would make it much harder for me to differentiate between messages signed by gpgit and those signed by the sender. Much more preferable to be able to turn off the security warning and pay attention to the color of the padlock.

Though I would also certainly support "burying it somewhere in the settings menu surrounded by big fat warnings".

[chadwickblane]

Is it wise to allow a third party to encrypt or decrypt your messages?

[craftyguy]

Irrelevant to this discussion (a 'red herring', you might say). We all
have our own standards, and, well, beauty is in the eye of the
beholder. I'd be willing to explain my position more, but I'm afraid
it would distract folks from this issue.

I might add that, in my particular use case, a 3rd party cannot (at least to my knowledge) decrypt my messages since I hold the private key..

[eeeeeta]

Did anyone end up making any headway on this issue? I encountered the "security warning" message today, and found it rather annoying.

[craftyguy]

Not sure, but I'm really close to just disabling encryption/signing altogether. That is probably the opposite effect that the developers here would like... sigh.

This 'warning' is super annoying especially since YOU ALREADY KNOW IF A MESSAGE IS SIGNED BUT NOT ENCRYPTED BY THE COLOR/STATUS OF THE ICON IN THE LOCK ICON AT THE TOP OF THE MESSAGE! This warning is literally useless!

[9662]

Sure, my email provider (mailbox.org) supports encrypting all emails they receive with my public key.

It sounds legitimate in this case to have non signed encrypted messages.

If I also wanted them to sign those emails, I would have to supply my private key,

I would expect that they would sign with their own key, not yours. Then again, in this case they would have to encrypt the whole message including headers then sign then forward the original message as an attachment (possibly itself signed and encrypted) which starts to take "impractical" to a whole new level. And it would still say nothing about what happened to the message before it reached your provider's servers.

In short, seems like a valid case for an encrypt-only approach.

[nicuh]

Hi @cketti, can you please tell me why you deleted my comment?
Did I offend anyone with my support for @craftyguy's request?

[Valodim]

Sadly, the way mailbox.org is doing this puts mail clients in an impossible situation. Displaying encrypted-only mails as "encrypted" in any way completely invalidates any reasonable model of authentication.

Please refer to my blog post on the matter (linked above). Nothing that has been said here so far has convinced me otherwise. I might write a follow-up that covers the mailbox.org case, though. Another thing I'm considering is simply showing the mail as "not encrypted", i.e. the same as a regular plaintext mail - this is only hard because it clashes with user expectations if they are asked for a password to display an email. More generally, I do want to get rid of those overlay warnings. It's just not a simple thing to do.

If anyone can come up with a nice concept that is not only "this is annoying, it needs to be different!" but actually takes the big picture into consideration, I'd be happy to hear it.

[craftyguy]

Thank you for responding. I did read your blog post a few months back. You made a sound argument for your decision to stop supporting encrypted-only emails, but honestly you forgot about (or did not account for) a legitimate use case for encrypted-only emails.

In a perfect world, all email senders/recipients would have PGP keys for signing/encrypting. Alas, this is ridiculously far from being the case. So, enter the 'mailbox.org' usage model, where my emails are stored encrypted with my key, and can ONLY be read by me (with my key). For the very (very) rare folks I interact with via email that have PGP keys, I will gladly encrypt & sign when sending to them. But the vast majority of emails I receive are from people/companies/etc that do not sign emails to begin with. No amount of K-9 developer crusading is going to convince them to change their workflow. I don't disagree with you, I wish they would, but I'm trying to be realistic based on the current situation today and current constraints (the difficulty for non-tech folks to manage PGP notwithstanding..)

Here's what this 'mailbox.org' approach protects against: if someone were to break into my mailbox.org account or somehow get access to my phone in the unlocked state or somehow get access to my PC in the unlocked state, they can see email subjects & sender in K-9 or in the mailbox.org web client or on my PC in mutt, but are unable to read any of the contents of the email. Period. That's a pretty damn good security measure IMHO over what traditional email offers, without having to rely on everyone to properly use PGP (unfortunately they all won't).

So back to the 'feature' of warning users in K-9 when they are opening an encrypted-only email... It's more than "this is annoying." It's borderline "this is infuriating" because I have a usage model for using encrypted-only emails (that you may/may not agree with), and I believe it is a good compromise between Ye Ole Email where nothing at all is encrypted and having to convince/support everyone from grandma to automated company mailers to start implementing PGP. When I see that warning, K-9 is basically saying "craftyguy, you're an idiot, we know what is best for you, trust us."

Anyways, I would absolutely really appreciate an option, hide it where ever you want, that allows me to say "I understand what I am doing may not adhere to @Valodim's philosophy, but I believe I know what I am doing and I'm willing to accept any (un)realized risks, so I want to disable this warning."

[Valodim]

I'm perfectly aware of the use case. But what you wrote is not a concept.

Maybe you're just barking up the wrong tree. Did you consider asking the mailbox.org guys to just sign those messages? The overarching issue is that there is no way to tell apart those mailbox.org-encrypted mails from ones that a) were sent by other people or b) had their signatures stripped by an attacker. It's a horrible idea to muddle these three together. I could imagine implementing a "consider mails signed by this key as mailbox.org-style storage encrypted" setting.

Anyways, I would absolutely really appreciate an option, hide it where ever you want, that allows me to say "I understand what I am doing may not adhere to @Valodim's philosophy, but I believe I know what I am doing and I'm willing to accept any (un)realized risks, so I want to disable this warning."

Well, you can always compile the project yourself? The warning should be trivial to remove.

[craftyguy]

Maybe you're just barking up the wrong tree. Did you consider asking the mailbox.org guys to just sign those messages?

Uhh, actually, no, I hadn't considered that, but that does seem like a good idea. I will contact them right now!

Well, you can always compile the project yourself? The warning should be trivial to remove.

Well, I'd rather not go this route, but I did find the commit to revert to get rid of this warning: a77a632b7225ed6fae1b23d953717b26bf25a07d (I know you know this, but just adding it here for reference for others that want to take you up on your 'fork off' offer 😄 )

[jeremiahmegel]

I _could_ imagine implementing a "consider mails signed by this key as mailbox.org-style storage encrypted" setting.

I would definitely be on board with this, since there are pretty much three types of signed+encrypted mail for me:

1. Signed+encrypted by my mail server with a signing key that doesn't matches the sender's address
2. Signed+encrypted by the sender with a signing key that doesn't match the sender's address
3. Signed+encrypted by the sender with a signing key that does match the sender's address

Currently I can't differentiate between types 1 and 2; that hypothetical setting would allow me to do so.

[craftyguy]

I could imagine implementing a "consider mails signed by this key as mailbox.org-style storage encrypted" setting.

After some emails exchanged with the mailbox.org folks, this is also their preferred route as well. They do not want to sign emails since they are not the original senders of those emails.

One other thing to consider is 'warning fatigue.' For mailbox.org users, if we have to tap 'ok' to dismiss the warning on every. single. email. we open in K9, are you really going to have the effect you would like on those users, or just train them to automatically dismiss warnings in your app because the previous 40 billion warnings were for something that we have to deal with because of our usage model?

[MartijnBraam]

I think the big problem here is that K9 thinks that encryption implies authentication (which is doesn't), are you also going to warn when a user sends a message that has no encryption (since that also isn't signed).

In the usecase provided by mailbox.org: if a message was received unencrypted by mailbox.org it gets encrypted, this shouldn't trigger any warnings but it should also not display in the user interface that the e-mail is in any way secure.

The other case is that someone sent an signed email to mailbox.org which then get encrypted, in that case it doesn't matter that the encryption is around the signed message or the other way around so K9 shouldn't complain and it should show that it is secure.

Mail software shouldn't confuse privacy with authentication.

[eeeeeta]

As far as I'm concerned, not including an option to accept encrypted-only messages (and displaying a big ol' warning every time someone tries to view one), whilst allowing encrypted & signed-by-the-wrong-key messages to pass through fine doesn't really make sense. Surely, if you're warning about encryption not being end-to-end, it's not E2E unless it's both encrypted and signed properly? Basically, my point is that K-9's current attitude of "encrypted-only bad, sign to fix" doesn't actually help anything (because I'm just going to configure my mailserver to sign messages with my key, which doesn't actually change how secure it is but satiates K-9's stupid random requirement), and acts as an annoying, unconfigurable dialog box that just irritates users of the software.

I just don't see why the K-9 devs couldn't add a simple checkbox to let users turn this (pointless, irritating) warning off themselves. IMHO, it's not their prerogative to try and push their own agenda wrt how people should implement GPG... I could understand if supporting encrypted-but-not-signed mail was a significant implementation overhead, but it's actually more effort to include this stupid warning!

[k0a1a]

perhaps the warning could be ignored on per sender basis?

[noguespi]

This warning is very annoying, we already have a big red warning so I don't understand the point of having a popup (popup = bad ux). Just show it the first time if you want but no need to show it for every email we did understand. By the way, why there is no warning for clear text unsigned email ? It is worst than encrypted unsigned email, they should have at least 3 popups and a pin prompt for every email :p

The fix is quick https://github.com/noguespi/k-9/commit/e24bdee1ff946e95ad0f75a0135b83f33b4b98da but now I will have to rebuild k9 regulary :/

[cketti]

This should already be fixed in 5.5xx versions. You can get them from Google Play by becoming a beta tester or download them manually here: https://github.com/k9mail/k-9/releases