It’s a feature I prefer. Anything I leave open all the time but only click rarely (like messaging apps) I prefer in the tray. This separates “apps I’m actively using” in the main area of the taskbar and “apps that are technically open but I’m not really using”
It’s also worth nothing there’s an option to disable hiding everything in the popout menu thing, a setting i usually change. Saves a click and that space is otherwise unused in the taskbar anyway
I think the philosophy here has sort of changed with newer versions of Windows, this is why the taskbar now has quicklaunch icons and regular app icons the same size and place. I keep all my "stuff that just stays open" like thunderbird, spotify, mumble and firefox to the left.
> It’s been 16 years and they still haven’t implemented ‘minimize to
task tray’ function. God I hate their philosophy so much.
Why was this so heavily down voted? If this is a bug report for 16
years, I would understand the frustration. After all, an email-program
should put an icon next to clock in the taskbar.
Theoretically this is a good thing, but it's way, way too late, since most people use web or mobile clients now.
Mozilla should include a proper PGP implementation in their browser. In fact, I have no idea why a browser that positions itself as pro-privacy doesn't already have a way to sign, verify, encrypt and decrypt text.
As far as I can tell, there wasn't even a discussion about this, which is ridiculous, considering the web (if you count it as a single system) is clearly the biggest communication platform in the world today.
> doesn't already have a way to sign, verify, encrypt and decrypt text.
I know it's not exactly that, but if anyone wants to use PGP in the browser with webmail clients, there's Mailvelope[0].
What I like about it is that you can use it with GnuPG as a backend[1], so I can sign and decrypt emails in the browser with an OpenPGP smartcard without importing private keys.
Yeah, that's the thing: once you get a full suite of PGP tools as a standard feature of your browser it would make a whole bunch of other features possible.
> Mozilla should include a proper PGP implementation in their browser. In fact, I have no idea why a browser that positions itself as pro-privacy doesn't already have a way to sign, verify, encrypt and decrypt text.
Maybe something built on top of Webauthn is possible? I guess we have to wait and see.
The comments here are overwhelmingly negative so far, so I'll say something positive: even if this comes rather late for Thunderbird, I appreciate that Mozilla chose to add this functionality. Any feature that makes PGP easier to use for the average person (especially better integration into a platform) is a win my book.
Firefox does seem to attract that demographic, or it could be just a symptom of open source entitlement. I've received some of the rudest personal attacks via extension reviews on Firefox Add-ons.
It definitely feels like there's a double standard at play sometimes. It's pretty routine for people here to announce after any mistake Mozilla makes that it's the last straw and they're done with it, and going back to Chrome. That just boggles my mind.
In my mind, the biggest value for PGP is _proving_ your identity, not encrypting communications (unless said properties of PGP are desirable).
That being said, I wish PGP had at least a casual PFS Extension. I've imagined ideas like an ephemeral key server that can deletes keys after awhile (you could run your own), and/or including futures keys to use in replies in the signature block.
That article states why PFS for email isn't really all that useful:
> As far as I know, Brown et al.'s proposal is not often used. One reason for this is that forward secrecy is not always desired. For instance, if you encrypt a backup using GnuPG, then your intent is to be able to decrypt it in the future. If you use forward secrecy, then, by definition, that is not possible; you've thrown away the old decryption key.
They are two different tools for two different jobs.
> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
In 2020, someone should know better than to to add pretend encryption to email. The metadata leaks alone should lead you to conclude that this isn't worth doing.
Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.
> even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen).
I agree with the other complaints but not this one.
If my human client, who demanded I use PGP, does something stupid with the email, that is not my problem (The bits are colored blue like you asked--the fact that you uncolored them again is your fault).
People forget that computer tasks in the real world are often more about liability transfer than actual security.
Whoever wrote what you quoted avoided to mention that the plugin (and I’d expect this new implementation) can protect the user from replying in plaintext to the encrypted message.
And using PGP in some scenarios has an advantage for the users and is indeed less convenient for eavesdroppers. It seems that the later are especially motivated to promote fear against PGP.
The point isn't that you forwarded the secret (indeed, that was on purpose).
The point is that you forwarded the secret in plaintext, because email is plaintext by default, and the forwarding person probably didn't realize that, because no email client (even with GPG plugins) posts a big red warning label saying "stop! this is plaintext" because that's 99% of all emails.
> because no email client (even with GPG plugins) posts a big red warning label saying "stop! this is plaintext"
I've used a plugin that did exactly that: warned when the encrypted e-mail is replied to or forwarded as plain text.
If such a plugin is not commonly used with e-mail clients that can't be a proof that e-mail encryption is inherently bad, just that that feature should exist.
That'd be me, and I avoided to mention that because it doesn't matter. People aren't making up the plaintext-reply problem; a person on HN that tells me they've never seen it is more loudly communicating that they rarely actually use PGP.
> The metadata leaks alone should lead you to conclude that this isn't worth doing
I don't buy that argument. Every time I can remember where I've wanted to use email encryption has been a situation where I was fine with the metadata leaks. E.g., it was email to someone I regularly correspond with, on a subject we regularly correspond on, at a time when we would be expected to be corresponding on this subject. It only differed from our normal correspondence in that I had one or two things I wanted to include in the body that were more sensitive than normal.
Like Key Compromise Impersonation in a serious cryptosystem, metadata leaks are just a design flaw. They might not matter in most or even many situations, but when they do matter, they matter a lot. There is no reason to have them; we accept them in PGP because we unduly venerate a 1990s protocol that people have used to organize IRL parties.
The two real reasons to avoid encrypted email are:
1. There's no realistic way to do it with forward secrecy, so any point-in-time compromise of a key --- which is inevitable --- will decrypt every message ever sent through that user.
2. Email is default-plaintext, and most people who have used PGP or S/MIME "at scale" have seen people repeatedly forget or misconfigure and send plaintext replies to encrypted emails, often with the plaintext of previous messages quoted.
To be clear: the argument for "worse than nothing" is:
1. PGP email is easy to screw up, even with client support.
2. If you need PGP to work, those screwups are life-threatening.
This isn't an abstraction or a just-so argument. PGP team members have, in the recent past, discussed how DoS attacks on their keyservers were upsetting because dissidents in specific, murderously authoritarian countries were ostensibly relying on PGP.
(They mostly aren't, by the way; they use Telegram, which I trust even less. At least I believe the PGP people mean well.)
Saying you shouldn't use PGP isn't the same as saying an email client shouldn't support it.
There are few exceedingly narrow use cases for secure email (where "thou must use email" is requirement #1). So minimal support for decryption of email (and understanding application/pkcs7-signature) isn't necessarily a bad thing. And while you're doing it, you might try to make the UX harder for people to do things like quote encrypted text in plaintext messages.
But I do think it's improper to make ease of PGP or S/MIME use a primary touted feature, and I wouldn't recommend its use to lay users. In other words, support it, but don't advocate it. (I am probably in disagreement with the rest of the Thunderbird team here).
With things like MTA-STS and DANE we're only gonna get metadata leaks really to the mail servers themselves.
> Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.
This assumes you're okay in giving everyone your phone number. What if you do that and then one of your contacts starts calling you all the time?
So then it's suggested to have two SIM cards. Here in my country that either means post paid paying a monthly bill or pre paid, and having to recharge it or lose it.
It's not like we haven't seem SIM jacking related attacks either.
Phone numbers are a really terrible identifier.
I am also curious to know what will happen if the US/UK ever passes laws like Australia did. Signal LLC is American, and therefore would have to comply with the laws there if they ever passed something like Australia did.
Realistically if we're going to throw PGP out, we shouldn't be suggesting centralized systems as an alternative. Has anyone forgotten about William Barr? He's been trying all year to get backdoor in Whatsapp E2EE, the same E2EE used by Signal.
> The same as if they start emailing you all the time: you block them.
> And since phone numbers are harder and costlier to just generate and use, that block is more meaningful blocking an email address.
You might think that but throwaway phone numbers can be bought cheap for the purpose of spamming.
I cannot think last when I got spam emails in my inbox. I can however think of when I got spam SMSes. It's also obviously cheap enough they can use robots to say things too.
Could this be because someone who knew my number had a compromised phone? quite possibly. I am not very happy about Facebook having my phone number even though I don't have an account with them.
This is is the Thunderbird Project's announcement. That group did the work, Mozilla provides a legal and financial framework for Thunderbird. Mozilla's work for Thunderbird is similar to projects like the Software Freedom Conservancy or Apache Software Project.
User donations account for a lot of the work that has been done in the last year. It has allowed them to hire full time and contract workers for Thunderbird. If you want to see the project continue to progress dropping them a recurring donation would be awesome [2].
> Thunderbird is unable to bundle GnuPG software, because of incompatible licenses (MPL version 2.0 vs. GPL version 3+). Instead of relying on users to obtain and install external software like GnuPG or GPG4Win, we intend to identify and use an alternative, compatible library and distribute it as part of Thunderbird on all supported platforms.
IMO this is great news. GnuPG is, IMO, awful. Every time I use it I dislike it more. I recently set up a new subkey using a hardware token and the whole experience made me wish that someone would implement a better way to deal with OpenPGP messages.
Every time I try to set up an email client I end up going back to gmail.com. What are the advantages of the hassle? They never seem to do what I want them to.
In Denmark, due to the GDPR, almost non of the digital letters we receive from the government can be sent by email (since they would contain personally identifiable information such as Social Security Numbers), so instead we just get a notification by email that tells us to log into a special 'secure' hosted mailbox. Except it's not hosted by the government, but some company that won a contract to build and host this - but now it's going to be built and hosted by another company that won the latest contract. This all seems kinda crazy to me, the public paying private companies to build and run one proprietary solution after the other. Does anyone know if there is some modern protocol/system that provides an alternative to email, and guarantees end-to-end encryption and other privacy-improvements?
I'm not quite sure about your characterisation of "due to GDPR" in this instance. Personally identifiable information does and can flow to regular email, though obviously it is better that it doesn't where possible.
Really? It was my impression that not being able to guarantee encryption along the way (basically you might be sending a postcard instead of a letter) made it a non-starter.
> In Denmark, due to the GDPR, almost non of the digital letters we receive from the government can be sent by email (since they would contain personally identifiable information such as Social Security Numbers), so instead we just get a notification by email that tells us to log into a special 'secure' hosted mailbox.
I doubt GDPR has anything to do with this. We don't have GDPR in my country and they use offerings from Symantec Encryption Server.
I believe the actual reason for built-in PGP/GPG support is due to TB dropping support for XUL addons and going the same road with WebExtensions as Firefox.
The current PGP/GPG implementation Enigmail is XUL, and been available for years.
> To process OpenPGP messages, GnuPG stores secret keys, public keys of correspondents, and trust information for public keys in its own file format. Thunderbird 78 will not reuse the GnuPG file format, but will rather implement its own storage for keys and trust.
First reaction: Yay! We'll get to manage everything twice!
Second reaction: I am hopeful they'll support private keys stored on smartcards (i.e., Yubikeys, "real" smartcards, and OpenPGP cards) although, if the support in Firefox is any indicator, I wouldn't bet on it actually being "usable".
54 comments
[ 2.4 ms ] story [ 117 ms ] threadGod I hate their philosophy so much.
It’s even not that hard to implement, it’s just they are valuing their stupid politics and philosophy over user experience.
It’s also worth nothing there’s an option to disable hiding everything in the popout menu thing, a setting i usually change. Saves a click and that space is otherwise unused in the taskbar anyway
> It’s been 16 years and they still haven’t implemented ‘minimize to task tray’ function. God I hate their philosophy so much.
Why was this so heavily down voted? If this is a bug report for 16 years, I would understand the frustration. After all, an email-program should put an icon next to clock in the taskbar.
It's made to replace the old firetray extension.
The fundamental question is: why not implement this stupid feature in the first place?
Mozilla should include a proper PGP implementation in their browser. In fact, I have no idea why a browser that positions itself as pro-privacy doesn't already have a way to sign, verify, encrypt and decrypt text.
As far as I can tell, there wasn't even a discussion about this, which is ridiculous, considering the web (if you count it as a single system) is clearly the biggest communication platform in the world today.
I know it's not exactly that, but if anyone wants to use PGP in the browser with webmail clients, there's Mailvelope[0].
What I like about it is that you can use it with GnuPG as a backend[1], so I can sign and decrypt emails in the browser with an OpenPGP smartcard without importing private keys.
[0]: https://www.mailvelope.com
[1]: https://www.mailvelope.com/en/faq#gnupg
Maybe something built on top of Webauthn is possible? I guess we have to wait and see.
Like take their rewrite of their android browser. It's faster than Chrome and is currently in preview.
Add-on support is work in progress but they got plenty of snarky attacks that it's not in MVP.
The whole DNS over HTTPS attacks seemed focussed on Firefox, a browser with a tiny marketshare compared to Chrome who also implements it.
Take a look: https://addons.mozilla.org/en-US/firefox/addon/search_by_ima...
That being said, I wish PGP had at least a casual PFS Extension. I've imagined ideas like an ephemeral key server that can deletes keys after awhile (you could run your own), and/or including futures keys to use in replies in the signature block.
> As far as I know, Brown et al.'s proposal is not often used. One reason for this is that forward secrecy is not always desired. For instance, if you encrypt a backup using GnuPG, then your intent is to be able to decrypt it in the future. If you use forward secrecy, then, by definition, that is not possible; you've thrown away the old decryption key.
They are two different tools for two different jobs.
The thing is about forward secrecy it's only really useful in situations where the communication is real time. Email is not.
https://arstechnica.com/information-technology/2016/12/signa...
If you're concerned about that storing it on a hardware key (like a Yubikey) is the way to go.
> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
In 2020, someone should know better than to to add pretend encryption to email. The metadata leaks alone should lead you to conclude that this isn't worth doing.
Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.
I agree with the other complaints but not this one.
If my human client, who demanded I use PGP, does something stupid with the email, that is not my problem (The bits are colored blue like you asked--the fact that you uncolored them again is your fault).
People forget that computer tasks in the real world are often more about liability transfer than actual security.
Instead, you both should have used a secure messaging app like Signal, which doesn't have a prominent UI button to forward messages in plain text.
And using PGP in some scenarios has an advantage for the users and is indeed less convenient for eavesdroppers. It seems that the later are especially motivated to promote fear against PGP.
The point isn't "use non-PGP email", the point is "don't use email at all for secure communications. Use a secure messaging app instead."
The point is that you forwarded the secret in plaintext, because email is plaintext by default, and the forwarding person probably didn't realize that, because no email client (even with GPG plugins) posts a big red warning label saying "stop! this is plaintext" because that's 99% of all emails.
I've used a plugin that did exactly that: warned when the encrypted e-mail is replied to or forwarded as plain text.
If such a plugin is not commonly used with e-mail clients that can't be a proof that e-mail encryption is inherently bad, just that that feature should exist.
Mozilla implementers, I hope you're inspired.
I don't buy that argument. Every time I can remember where I've wanted to use email encryption has been a situation where I was fine with the metadata leaks. E.g., it was email to someone I regularly correspond with, on a subject we regularly correspond on, at a time when we would be expected to be corresponding on this subject. It only differed from our normal correspondence in that I had one or two things I wanted to include in the body that were more sensitive than normal.
The two real reasons to avoid encrypted email are:
1. There's no realistic way to do it with forward secrecy, so any point-in-time compromise of a key --- which is inevitable --- will decrypt every message ever sent through that user.
2. Email is default-plaintext, and most people who have used PGP or S/MIME "at scale" have seen people repeatedly forget or misconfigure and send plaintext replies to encrypted emails, often with the plaintext of previous messages quoted.
Both of those reasons are, for me, dispositive.
1. PGP email is easy to screw up, even with client support.
2. If you need PGP to work, those screwups are life-threatening.
This isn't an abstraction or a just-so argument. PGP team members have, in the recent past, discussed how DoS attacks on their keyservers were upsetting because dissidents in specific, murderously authoritarian countries were ostensibly relying on PGP.
(They mostly aren't, by the way; they use Telegram, which I trust even less. At least I believe the PGP people mean well.)
There are few exceedingly narrow use cases for secure email (where "thou must use email" is requirement #1). So minimal support for decryption of email (and understanding application/pkcs7-signature) isn't necessarily a bad thing. And while you're doing it, you might try to make the UX harder for people to do things like quote encrypted text in plaintext messages.
But I do think it's improper to make ease of PGP or S/MIME use a primary touted feature, and I wouldn't recommend its use to lay users. In other words, support it, but don't advocate it. (I am probably in disagreement with the rest of the Thunderbird team here).
Often who you're talking to is not sensitive. What you were talking about on the other hand might be.
https://arstechnica.com/information-technology/2016/12/signa...
With things like MTA-STS and DANE we're only gonna get metadata leaks really to the mail servers themselves.
> Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.
This assumes you're okay in giving everyone your phone number. What if you do that and then one of your contacts starts calling you all the time?
So then it's suggested to have two SIM cards. Here in my country that either means post paid paying a monthly bill or pre paid, and having to recharge it or lose it.
It's not like we haven't seem SIM jacking related attacks either.
Phone numbers are a really terrible identifier.
I am also curious to know what will happen if the US/UK ever passes laws like Australia did. Signal LLC is American, and therefore would have to comply with the laws there if they ever passed something like Australia did.
Realistically if we're going to throw PGP out, we shouldn't be suggesting centralized systems as an alternative. Has anyone forgotten about William Barr? He's been trying all year to get backdoor in Whatsapp E2EE, the same E2EE used by Signal.
The same as if they start emailing you all the time: you block them.
And since phone numbers are harder and costlier to just generate and use, that block is more meaningful blocking an email address.
> And since phone numbers are harder and costlier to just generate and use, that block is more meaningful blocking an email address.
You might think that but throwaway phone numbers can be bought cheap for the purpose of spamming.
I cannot think last when I got spam emails in my inbox. I can however think of when I got spam SMSes. It's also obviously cheap enough they can use robots to say things too.
Could this be because someone who knew my number had a compromised phone? quite possibly. I am not very happy about Facebook having my phone number even though I don't have an account with them.
User donations account for a lot of the work that has been done in the last year. It has allowed them to hire full time and contract workers for Thunderbird. If you want to see the project continue to progress dropping them a recurring donation would be awesome [2].
[1] https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-fu... [2] https://donate.mozilla.org/en-US/thunderbird/
IMO this is great news. GnuPG is, IMO, awful. Every time I use it I dislike it more. I recently set up a new subkey using a hardware token and the whole experience made me wish that someone would implement a better way to deal with OpenPGP messages.
- PGP isn't always the proper solution.
- Yes, you do need to be aware of what metadata is involved and what it exposes. This applies to all systems.
- Secure communication is much more than key selection.
- Mozilla taking steps to integrate it into Thunderbird should be applauded.
I doubt GDPR has anything to do with this. We don't have GDPR in my country and they use offerings from Symantec Encryption Server.
The current PGP/GPG implementation Enigmail is XUL, and been available for years.
> To process OpenPGP messages, GnuPG stores secret keys, public keys of correspondents, and trust information for public keys in its own file format. Thunderbird 78 will not reuse the GnuPG file format, but will rather implement its own storage for keys and trust.
First reaction: Yay! We'll get to manage everything twice!
Second reaction: I am hopeful they'll support private keys stored on smartcards (i.e., Yubikeys, "real" smartcards, and OpenPGP cards) although, if the support in Firefox is any indicator, I wouldn't bet on it actually being "usable".
[0]: https://wiki.mozilla.org/Thunderbird:OpenPGP:2020