5 ms·

Does anyone have a tldr of why it took this long?

by hmate9 4y ago

bheadmaster 4y ago
I don't have any real information, but my guess would be the same as for any other feature in any other open source software: nobody stepped up and did the legwork until now.
- _cenw 4y ago
  Enigmail wasn't even part of core Thunderbird for most of those 21 years.
noirscape 4y ago
At first, a maintainer considered it to be a regression to implement (reading the bugzilla page), which caused it to be delayed for ~7 years. Then the issue went more or less inactive for almost a decade because the world at large dismissed OpenPGP encryption on mail as pointless (in part due to the complexity in actually getting it working since no mail client gave it a first class implementation, leading to a circular case of it not being implemented because nobody did it.) 2 years ago it was deliberately revived by Mozilla, then it devolved into bikeshedding about the design and now it's finally shipped.
- londons_explore 4y ago
  Basically, "delayed by human factors". I wonder how such human factors could be reduced/eliminated?
- jwr 4y ago
  > the world at large dismissed OpenPGP encryption on mail as pointless This is quite amazing, if you think about it. I'm not one to promote conspiracy theories, but if you look at how we horribly botched all implementations of E-mail encryption over the years (that includes lack of development, terrible UI, delays, bizarre and unimplementable in practice standards like S/MIME), it is quite an impressive story. Meanwhile, the HTTP world mostly got things done, and instant messaging is in a pretty good shape (although I'm still amazed that so many people are willing to sync their entire phone book to Facebook for advertising purposes without a second thought).
  - hannob 4y ago
    No conspiracy needed. HTTPS was already there and working more or less automatically, you just had to make it the default. E-Mail end-to-end encryption is inherently more complicated to make work, as you need to put the user in charge of key management. Browser vendors made a big campaign and invested effort into making HTTPS work. Noone did that for E-Mail. Also it should be mentioned that the same level of security that HTTPS has almost exists in E-Mail. You have transport encryption, it is largely enforced on C2S connections. S2S is a bit more complicated, but even that is mostly solved by now via MTA-STS, which at least the larger mail providers support.
    - einpoklum 4y ago
      > HTTPS was already there and working more or less automatically But that does fix the problem. That protects you against opportunistic tapping of wires. A bigger problem is the mass surveillance by POP, IMAP, SMTP and webmail providers (e.g. Google, Microsoft, Yahoo, Apple). They're not affected by HTTPS, because they're on one side of many of those HTTPS connections... and of course this is quite convenient for them. If you want to be conspiratorial, you could note that Google funded Mozilla for quite a while, albeit only at a fraction of what it owed them in gained income due to having Mozilla / Firefox' default search engine be Google. And while TB was developed integrally alongside Firefox, it got a very small fraction of the resources. --- BTW, Even E2E encryption doesn't resolve the surveillance problem properly, since those mass-surveillance operations get most of the headers / meta-data.
    - kebman 4y ago
      To me, this problem can be solved on a purely philosophical level. In other words, before delving into the technical aspects, one must address the fundamental question: “Do we want to encrypt as much as possible or not at all?” At first, the argument in favour of maximum encryption may seem compelling. However, upon closer inspection, it falls apart. Essentially, it only makes it harder to read your correspondence for those who give up early. Meanwhile, determined parties, such as large organizations and state actors, can still easily read your correspondence even with this type of encryption scheme. You might ask yourself, “But Mozilla told me that they would try to encrypt as much as possible!” Instead, the fact is that sometimes they will also have to forgo encryption, because the scheme can only encrypt most of the time. And it’s in those instances that determined parties strike! As such, this kind of “encryption” scheme really only serves to lull people into a false sense of security, and that is often more dangerous than simply letting people know that their e-mails aren't encrypted at all. So, for those of you who are inclined to believe in conspiracy theories, the real issue is not that e-mails have remained unencrypted until now. Once you understand that your e-mails are sent in the open, you can take appropriate precautions and avoid sharing sensitive information through e-mail. Meanwhile, if you think that your e-mails are confidential, you might be more inclined to let slip important secrets, when it’s actually being fully disclosed to any determined third party. The false maxim is that more encryption is better than no encryption. Meanwhile it does not follow that more encryption equals more security or better confidentiality.
- upofadown 4y ago
  The bikeshedding here came from a fundamental disagreement about usability. It really could not be helped. Some wanted the email client to automatically detect a situation where encrypted email was possible. Others felt that the risk of a user unknowingly sending a CC unencrypted was too high. Part of this ended up coming from the fact that Thunderbird was not clearly showing the user that the email to a particular recipient was or was not going to be sent encrypted. I am not clear from skimming the discussion that this fundamental issue has yet been fixed.
  - psychphysic 4y ago
    It would have been better to implement and then rachet up use. Just like happened with HTTPS. At the start not many noticed or cared if their connection was encrypted. Then companies started directing people to the encrypted site and pointing out the padlock icon browsers adopted. Now we're getting to the point that browser's might fuss about unencrypted connections. Same could have been done but they got caught up in well if we have any encryption. It should all be encrypted false dichotomy. Or am I just adding to the bike shedding?
  - kebman 4y ago
    The discussion is essentially about whether you want to lull people into a false sense of security by encrypting some e-mails, or having people self-censor because they know that all e-mails are sent in the open. As it is, encrypting some of the correspondence will only deter those third parties who give up early. Meanwhile any larger organization, such as a state actor, will still be able to easily read your correspondence even with such an "encryption" scheme.
acters 4y ago
The ethics of how to properly allow users to send both encrypted and unencrypted emails was an issue. Sending encrypted messages and plain text at the same time will defeat the idea of security and privacy. if there is a thread with many members that have both unencrypted and encrypted-capable messaging, then the encryption is unnecessary and becomes worthless. Eventually there was an agreement that having unencrypted as default is bad. There had to be a way to increase the amount of users enabling encryption. Implementation was halted as the brainstorming of how to make this feature was sidelined as it was lower priority. 19 years later, users made another push to bring this feature into mainstream. Developers saw that they had enough time to brainstorm this low priority feature. the larger user base allowed this feature to be brainstormed faster. after a year and half of feedback, the main developers were able to have this fully featured. This final implementation will allow users to be encrypting messages more often and not need to disable the encryption. More users will be able to use this client and less frustration from users who are unknowledgeable of technology. If there is a need for only encryption, then it is possible. This "automatic" feature is more desirable than forcing the sending unencrypted to all. There is a chance a thread will only have encrypted-capable members, and accidentally sending an unencrypted message in the thread is a bigger problem to privacy and security. The final consensus is that sending of messages should be the responsibility of the user, not the application. The applications should always try to send encrypted messages. Unencrypted messaging should be the users responsibility as there is now a possible way to discern a thread has encrypted-capable members or not. TLDR: people argued whether it is bad or good feature, this was sidelined as low priority, users 2 years ago made a last push to implement this feature, They came to an agreement that responsibility of encryption is on message thread members and having unencrypted only is a worse option than the application sending encrypted where possible, feedback was collected on how the user experience should be implemented, and lastly the automatic selection feature was implemented. Users should still look into how this was implemented and give feedback on possible security/privacy concerns that may need to be implemented when the automatic feature is enabled. types of toggleable features that should be implemented and may not be is confirmation dialogues, message encryption per recipient/thread, visual indicators of received/sent messages being encrypted/unencrypted, and more. This is up to the developers to implement this to the GUI. I have not explored the new feature in its entirety.

Does anyone have a tldr of why it took this long?

by hmate9 4y ago

Does anyone have a tldr of why it took this long?

I don't have any real information, but my guess would be the same as for any other feature in any other open source software: nobody stepped up and did the legwork until now.

_cenw 4y ago
Enigmail wasn't even part of core Thunderbird for most of those 21 years.

noirscape 4y ago

At first, a maintainer considered it to be a regression to implement (reading the bugzilla page), which caused it to be delayed for ~7 years. Then the issue went more or less inactive for almost a decade because the world at large dismissed OpenPGP encryption on mail as pointless (in part due to the complexity in actually getting it working since no mail client gave it a first class implementation, leading to a circular case of it not being implemented because nobody did it.) 2 years ago it was deliberately revived by Mozilla, then it devolved into bikeshedding about the design and now it's finally shipped.

londons_explore 4y ago
Basically, "delayed by human factors". I wonder how such human factors could be reduced/eliminated?
jwr 4y ago
> the world at large dismissed OpenPGP encryption on mail as pointless This is quite amazing, if you think about it. I'm not one to promote conspiracy theories, but if you look at how we horribly botched all implementations of E-mail encryption over the years (that includes lack of development, terrible UI, delays, bizarre and unimplementable in practice standards like S/MIME), it is quite an impressive story. Meanwhile, the HTTP world mostly got things done, and instant messaging is in a pretty good shape (although I'm still amazed that so many people are willing to sync their entire phone book to Facebook for advertising purposes without a second thought).
- hannob 4y ago
  No conspiracy needed. HTTPS was already there and working more or less automatically, you just had to make it the default. E-Mail end-to-end encryption is inherently more complicated to make work, as you need to put the user in charge of key management. Browser vendors made a big campaign and invested effort into making HTTPS work. Noone did that for E-Mail. Also it should be mentioned that the same level of security that HTTPS has almost exists in E-Mail. You have transport encryption, it is largely enforced on C2S connections. S2S is a bit more complicated, but even that is mostly solved by now via MTA-STS, which at least the larger mail providers support.
  - einpoklum 4y ago
    > HTTPS was already there and working more or less automatically But that does fix the problem. That protects you against opportunistic tapping of wires. A bigger problem is the mass surveillance by POP, IMAP, SMTP and webmail providers (e.g. Google, Microsoft, Yahoo, Apple). They're not affected by HTTPS, because they're on one side of many of those HTTPS connections... and of course this is quite convenient for them. If you want to be conspiratorial, you could note that Google funded Mozilla for quite a while, albeit only at a fraction of what it owed them in gained income due to having Mozilla / Firefox' default search engine be Google. And while TB was developed integrally alongside Firefox, it got a very small fraction of the resources. --- BTW, Even E2E encryption doesn't resolve the surveillance problem properly, since those mass-surveillance operations get most of the headers / meta-data.
  - kebman 4y ago
    To me, this problem can be solved on a purely philosophical level. In other words, before delving into the technical aspects, one must address the fundamental question: “Do we want to encrypt as much as possible or not at all?” At first, the argument in favour of maximum encryption may seem compelling. However, upon closer inspection, it falls apart. Essentially, it only makes it harder to read your correspondence for those who give up early. Meanwhile, determined parties, such as large organizations and state actors, can still easily read your correspondence even with this type of encryption scheme. You might ask yourself, “But Mozilla told me that they would try to encrypt as much as possible!” Instead, the fact is that sometimes they will also have to forgo encryption, because the scheme can only encrypt most of the time. And it’s in those instances that determined parties strike! As such, this kind of “encryption” scheme really only serves to lull people into a false sense of security, and that is often more dangerous than simply letting people know that their e-mails aren't encrypted at all. So, for those of you who are inclined to believe in conspiracy theories, the real issue is not that e-mails have remained unencrypted until now. Once you understand that your e-mails are sent in the open, you can take appropriate precautions and avoid sharing sensitive information through e-mail. Meanwhile, if you think that your e-mails are confidential, you might be more inclined to let slip important secrets, when it’s actually being fully disclosed to any determined third party. The false maxim is that more encryption is better than no encryption. Meanwhile it does not follow that more encryption equals more security or better confidentiality.
upofadown 4y ago
The bikeshedding here came from a fundamental disagreement about usability. It really could not be helped. Some wanted the email client to automatically detect a situation where encrypted email was possible. Others felt that the risk of a user unknowingly sending a CC unencrypted was too high. Part of this ended up coming from the fact that Thunderbird was not clearly showing the user that the email to a particular recipient was or was not going to be sent encrypted. I am not clear from skimming the discussion that this fundamental issue has yet been fixed.
- psychphysic 4y ago
  It would have been better to implement and then rachet up use. Just like happened with HTTPS. At the start not many noticed or cared if their connection was encrypted. Then companies started directing people to the encrypted site and pointing out the padlock icon browsers adopted. Now we're getting to the point that browser's might fuss about unencrypted connections. Same could have been done but they got caught up in well if we have any encryption. It should all be encrypted false dichotomy. Or am I just adding to the bike shedding?
- kebman 4y ago
  The discussion is essentially about whether you want to lull people into a false sense of security by encrypting some e-mails, or having people self-censor because they know that all e-mails are sent in the open. As it is, encrypting some of the correspondence will only deter those third parties who give up early. Meanwhile any larger organization, such as a state actor, will still be able to easily read your correspondence even with such an "encryption" scheme.

acters 4y ago

The ethics of how to properly allow users to send both encrypted and unencrypted emails was an issue. Sending encrypted messages and plain text at the same time will defeat the idea of security and privacy. if there is a thread with many members that have both unencrypted and encrypted-capable messaging, then the encryption is unnecessary and becomes worthless. Eventually there was an agreement that having unencrypted as default is bad. There had to be a way to increase the amount of users enabling encryption. Implementation was halted as the brainstorming of how to make this feature was sidelined as it was lower priority. 19 years later, users made another push to bring this feature into mainstream. Developers saw that they had enough time to brainstorm this low priority feature. the larger user base allowed this feature to be brainstormed faster. after a year and half of feedback, the main developers were able to have this fully featured. This final implementation will allow users to be encrypting messages more often and not need to disable the encryption. More users will be able to use this client and less frustration from users who are unknowledgeable of technology. If there is a need for only encryption, then it is possible. This "automatic" feature is more desirable than forcing the sending unencrypted to all. There is a chance a thread will only have encrypted-capable members, and accidentally sending an unencrypted message in the thread is a bigger problem to privacy and security. The final consensus is that sending of messages should be the responsibility of the user, not the application. The applications should always try to send encrypted messages. Unencrypted messaging should be the users responsibility as there is now a possible way to discern a thread has encrypted-capable members or not. TLDR: people argued whether it is bad or good feature, this was sidelined as low priority, users 2 years ago made a last push to implement this feature, They came to an agreement that responsibility of encryption is on message thread members and having unencrypted only is a worse option than the application sending encrypted where possible, feedback was collected on how the user experience should be implemented, and lastly the automatic selection feature was implemented. Users should still look into how this was implemented and give feedback on possible security/privacy concerns that may need to be implemented when the automatic feature is enabled. types of toggleable features that should be implemented and may not be is confirmation dialogues, message encryption per recipient/thread, visual indicators of received/sent messages being encrypted/unencrypted, and more. This is up to the developers to implement this to the GUI. I have not explored the new feature in its entirety.