But if this is a feature of a mail service rather than a mail client, then the service has the keys and, given GPG has no perfect forward secrecy, they have the ability to decrypt all emails you send and recieve.
If you go down the road of the mail service owning a mail client that promises e2e, then the issue moves to worrying about the code that runs on your device. If it's webmail, the JavaScript can easily be changed, so you really want a thick client. Then you need to worry about the thick client sending data that it's really not supposed to i.e. can it read your key and send it to $vendor?
Even then, GPG without Perfect Forward Secrecy means that when your key is brute forced or side channel attacked, which we assume will happen, you lose all your secrecy, so you need to think about this as a temporary state.
I learned this the hard way when using gpg+mutt back in 2001. All my Sent mail was being encrypted only with the recipient's key, so I couldn't read it myself. There's an option to also encrypt outgoing email with your own GPG key.
I like their inbox encryption feature, all inbound mail is automatically encrypted with your gpg key. This means that mails downloaded to clients must be decrypted with your gpg key, and it's impossible to read mails in your inbox with their webmail thing. This means that if your device is stolen, your emails (their contents) are still encrypted.
You are right, the FAQ is probably not right at this point, In fact, the box uses keys it knows about, and tries to get keys when receiving encrypted mail. But of course you can send unencrypted email.
(Otherwise you would have to use a specific email not only for contacts that don't use GnuPG, but also for registration with 99% of all the websites out there.)
There's nothing about Gmail that prevents you from encrypting your subject lines.
The most important metadata however is whom your communicating with. And there's nothing in GPG that can protect the addresses of your recipients, because it's not possible due to the email protocol.
You're knowingly sending your data to a 3rd party. You're not encrypting. It's not through the USPS (special protections).
It seems bloody evident that, of course, your email provider can read your emails! Unless you're encrypting with GPG, then they can (and they can still read the signing keys).
Yahoo, Google, and friends all scan, dedup, and all sorts of tricks to determine marketing and quality content (spamming). If you're worried, run your own mailserver. It's what I do, along with using gmail. But I know that, at any time, people/scripts/ai are reading everything sent and received.
edit: I'd much prefer to hear commentary/how wrong/how right/how crazy I am, rather than -1's.I'd like to hear a discussion about the "Secrecy of text written on postcards"....
https://gpgtools.org/ GPGtools. If you use a mac, it can hook into your native mail app and encrypt/sign things with your private key. Sure, whatever provider you use knows you send or receive encrypted mails, and the metadata will always be unencrypted, but these are always the case regardless of email provider.
There seem to be other GPG mail tools out there for different contexts (maybe one that runs in the gmail web interface?) too.
Not sure what OP was getting at (maybe the difficulty of deniability using GPG/GPG-encrypted mail defaults), but you'd still be sending to a recipient's long-lived public key.
That's practically different than a system like OTR that has forward secrecy by default.
Well, you should be able to encrypt the subject/body of the email without encrypting the headers, so the mail vendor never sees the content of the email, only the to/from addresses and such. But that encryption has to happen in the browser/application. ie Mailvelope plugin for Chrome and others like it. and I think there is an android mail client that will also do pgp/gpg encryption/decryption.
Just use a procmail rule to call gpg on every incoming email before it's stored using your public key, then your client (configured with your private key) can decrypt every email as normal.
reply