ProtonMail / WebClients

Monorepo hosting the proton web clients
GNU General Public License v3.0
4.37k stars 556 forks source link

Warn about unencrypted mail in response to encrypted mail received #141

Closed vasyugan closed 3 years ago

vasyugan commented 5 years ago

Is your feature request related to a problem? Please describe.

When a protonmail user receives encrypted / signed mail from outside, the response is sent unencrypted without the user being warned - unless the user has "trusted" the key on receipt of his/her message. As there is no explanation what "trusted" means and what the implications are, the user, in my experience, simply ignores the "trust key" prompt. (Since encryption is completely transparent, when mail is sent between different protonmail addresses, the user does not have to have a concept of "trusted" keys. )

Describe the solution you'd like

I suggest to give the user a second chance to "trust" the key: Before sending out unencrypted mail in response to an encrypted mail received, there should be a clear message like "*You are about to send an unencrypted mail in response to an encrypted mail you have received. This mail will be sent to a recipient outside protonmail and be readable to anyone who intercepts it. Are you sure you want to do this? To encrypt this message, please trust the recipient's key first by clicking here, alternatively, if you know what you are doing, you can continue unencrypted"*

Describe alternatives you've considered

Have a clearer alert when you first receive encrypted mail, which makes it clear why you should "trust" the key. This alert should be, I think, still visible when reading the message. Like "In order to enable safe encrypted communication with this peer, you must add his/her key to your address book. Do so by clicking here". But again, there is no reason not to have another warning when sending an unencrypted response.

Additional context

This is a problem i.a. because typically, the original sender has used encryption for a reason, and the original text is typically embedded in the response. Therefore an unencrypted response may compromise one or both of the peers. This happened to me recently (not with serious consequences in my case, but clearly, this defeats the very purpose of protonmail)

Chawnise commented 4 years ago

@matehat

matehat commented 4 years ago

hello?

vasyugan commented 4 years ago

hello?

@matehat Are you a contributor of Protonmail? Would be great if someone were to address this issue.

PedroCorreiaArtwork commented 3 years ago

Yes, indeed. Make it only possible for the receiver to reply using encryption as well.

vasyugan commented 3 years ago

Yes, indeed. Make it only possible for the receiver to reply using encryption as well.

It is possible, it is just not intuitive, so that in my experience, most don't. This feature request is about making the interface more intuitive for non-technical users and prevent accidentally sending out unencrypted responses to encrypted messages received. It is very unfortunate, that the Protonmail team doesn't seem to care.

vasyugan commented 3 years ago

@mmso Why did you close this bug without explanation?

mmso commented 3 years ago

This issue was closed as part of the migration to the new React codebase and mono-repository for Proton webapps. You are welcome to submit feature requests to https://protonmail.uservoice.com/forums/284483-protonmail and bug reports to https://protonmail.com/support/

vasyugan commented 3 years ago

This issue was closed as part of the migration to the new React codebase and mono-repository for Proton webapps. You are welcome to submit feature requests to https://protonmail.uservoice.com/forums/284483-protonmail and bug reports to https://protonmail.com/support/

I have submitted it, but I guess the likelihood that anyone is going to address this is even smaller than here, where in two and a half year no one has.

mmso commented 3 years ago

Your submission is appreciated. We apologise for closing the ticket without an explanation, it was an unusual situation due to the migration. We are working on improving our response times, and while we are not always able to respond to individual features, they are valuable to us and that we take them into account when planning our roadmap.