On March 30, 2023, Mozilla closed bug 135636 and fixed the error of automatically enabling/disabling email encryption depending on the current configuration of the sender and recipient (OpenPGP and S/MIME modes). There would be nothing strange about this, if not for one detail: the ticket was opened 21 years ago. In this regard, the question arises: why did it take more than two decades to close such a simple bug?
Bug history
On April 5, 2002, user Markus Gerstel noticed some inconvenience with the encryption settings in the Account Manager of the MailNews mail client in Netscape 4. There were two modes: 1) never encrypt messages or 2) require encryption (sending unencrypted mail is impossible).
Encryption enabled mode:
Encryption disabled mode:
This is actually inconvenient because you had to disable the encryption setting every time you wanted to send a letter to a user who did not have a certificate or public keys. Or vice versa, enable it every time you wanted to send an encrypted letter. The author expressed a desire to implement a third alternative option, "Encrypt when possible", which does not require the user to enable/disable encryption manually.
Thus, encryption will be enabled automatically when composing a letter to a recipient who has provided public keys. Indeed, it is very convenient. There are keys or a certificate - we encrypt. No keys - we do not encrypt.
The developers agreed that such an option should be implemented, but the implementation itself took exactly 21 years. Why?
At first, one of the maintainers, Charles Rosendahl, considered that this bug suggests a regression, that is, it requires fixing another related function. While others disagreed, it delayed the implementation by about seven years.
The regression issue was then dropped, but the topic itself lost relevance because OpenPGP email encryption in general was no longer perceived as necessary or mandatory. This was partly due to the interface complexity and because no email client provided a first-class, user-friendly implementation of encryption.
Two years ago, Mozilla reopened the debate, it escalated into a design debate, and it was not until 2023 that the option was finally implemented.
Email encryption should become the standard
The story with the bug in the Mozilla mail client makes one suspect that someone is preventing the developers from implementing normal email encryption. From a technical point of view, it is completely clear how strong cryptography and PGP should work, what ciphers to use. But from the point of view of interfaces, it is as if someone else was constantly putting spokes in the wheels and preventing this functionality from being deployed to a wide audience.
It is a common opinion that email encryption was and remains an inconvenient procedure. Everything could have been made much clearer for ordinary users. Especially for an important function. It is simply surprising that such an important technology has not yet become mainstream, and many people still send confidential letters without using strong cryptography.
Why not a single mail client has made a convenient implementation of PGP or S/MIME over the years is an open question. It seems as if someone was deliberately preventing them from doing this. Indeed, if we look at the decades of PGP and mail encryption development, we see many unsuccessful implementations, lack of proper development, terrible UI that is impossible to use, all sorts of implementation delays, the spread of various difficult-to-implement standards.
At the same time, web encryption (TLS) was implemented, there is progress for instant messages. But what is happening with email is puzzling, as if someone is really interfering from the outside.
Developers of popular OS could have organized the distribution of S/MIME certificates, implemented certificate storage for the convenience of email encryption. But they did not do this. Of course, managing personal certificates by users on a large scale is more difficult than managing website certificates, but this is a solvable problem.
Ideally, the entire archive should be stored encrypted on mail servers, and if the provider/hoster tries to read the text of the letter, they will see something like this:
This is probably one of the reasons why large email providers are reluctant to implement strong cryptography for everyone by default. After all, they would then lose the ability to implement contextual advertising and supplement user profiles.
Although this sounds a bit like a paranoid conspiracy theory, it cannot be denied that external forces also oppose the implementation of strong cryptography. According to some intelligence agencies, ordinary people should not be given this tool because then criminals will start using it. Even today, having cryptographic messengers like Signal on a person’s phone can be a cause for suspicion. Of course, the situation needs to be corrected. Many security experts say that email encryption should become the standard, because the privacy of email correspondence is protected by the Constitution and is one of the basic human rights.
Source
