4 ms·

If you care enough about privacy to sign up for protonmail, why not just learn how to use pgp? It's not perfect, but it works. And... oh goodness, I'm looking a

by denova 11y ago

If you care enough about privacy to sign up for protonmail, why not just learn how to use pgp? It's not perfect, but it works. And... oh goodness, I'm looking at this [support page][1]; If you send encrypted mail to non-protonmail addresses, the recipients have to open the message in a web browser and enter in a password to read it. So instead of exchanging public keys, you have to send them a password, probably over an unencrypted channel. I guess it's easier than asking them to generate a keypair. But if your recipient is too lazy to set up pgp, they're probably going to be just as annoyed at having to open your message in a browser and enter in a password, right? It seems like an awkward compromise. [1]: https://protonmail.com/support/knowledge-base/encrypt-for-outside-users/ https://protonmail.com/support/knowledge-base/encrypt-for-ou...

modernerd 11y ago
Even Phil Zimmermann, PGP's creator, says it's too hard to use: “I hardly ever run PGP. When people send me PGP encrypted mail I have to go through a lot of trouble to decrypt it. If it’s coming from a stranger, I’ll say please re-send this in plain text, which probably raises their eyebrows.“ http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-big-privacy-problem-qa-with-silent-circle-co-founder-phil-zimmermann/ http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-bi... I tried the ProtonMail password protection feature today (which is optional; you can just send plain text email to non ProtonMail accounts if you wish – this is the default, but you can click a lock to password-protect any outgoing message). The feature is well done, and I can see people using it to exchange secure mail, particularly if the recipient does not have a ProtonMail account. It has a built-in 'send secure reply' feature once you've entered the password as the recipient. This allows you to read the message and reply in-browser without returning to your email client, and without having a ProtonMail account, so both the outgoing message and the reply stay more secure than regular email throughout your conversation. This could be helpful for a wide range of uses, including support email that involves transferring login info and logs. The read and reply flow looks like this to the logged-out recipient: - Email with “view secure message” prompt: http://d.pr/i/1cwZ8 http://d.pr/i/1cwZ8 - Click “View secure message”: http://d.pr/i/13GlI http://d.pr/i/13GlI - Enter password to view message: http://d.pr/i/11Gg9 http://d.pr/i/11Gg9 - Click to reply in same tab: http://d.pr/i/WWWB http://d.pr/i/WWWB You still have to communicate the password securely somehow, but it's a much more user-friendly approach than PGP. I'm not saying it's a replacement for https://securedrop.org/ https://securedrop.org/, but it still has value.
- tptacek 11y ago
  "PGP is hard to use" is more memetic than accurate. What makes PGP hard is that it has a million options, and its vocal users (and detractors) seem insistent on availing themselves of as many of them as possible. In reality, 80% of PGP's value (which is more value than you'll get out of any webmail system), you can get with three command lines: gpg -sear recipient@addr document.txt Encrypt and sign a document, ASCII armored for inclusion in a 7-bit email, to a specific person or persons gpg -a --export my@addr Dump your public key for out-of-band transmission to the peer you're exchanging messages with gpg document.txt.asc Decrypt a message sent to you by someone else. No keyservers. No subkeys. No crazy formatting. No exotic key types. Send a message to someone, read a message back from them. You don't get forward secrecy (unless you manually rotate keys). You don't get peer validation unless you do it manually. You don't get real time chat. You can't encrypt a videoconference. On the other hand: you won't be the subject of someone's amusing blog post a year from now, either, because PGP used this way has been reliable for something like 15 years running. Everyone I know who actually uses PGP, like for real, more than a couple times a year, uses it pretty much this way.
  - pdkl95 11y ago
    > 80% of PGP's value ... you can get with three command lines: While I completely agree that those commands are all that is needed most of the time, it's this part that unfortunately makes pgp/gpg so unpopular: > command lines Even on HN I find people that hate the command line (even though they use it). The problem is the complete lack of front ends wrappers around those commands in every other email tool. The enigmail plugin for thunderbird is surprisingly nice. It even does a decent job at key management (including the web of trust), but it made the "80% of PGP's value" completely transparent. If you have the key for an address, emails are automagically piped through gpg, and it handles decryption for you similarly (with pgp-agent support for less passphrase typing). Of course, that was only useful for the handful of us that used thunderbird; with Mozilla dropping the project, it's questionable if this has a useful future. Almost all of the complexity with pgp/gpg can be hidden behind a nice GUI and opportunistic[1] enabling of the crypto. Unfortunately development has been focused on walled gardens and tying people to artificial dependencies[2] instead of writing useful client-installed software. [1] Fallback to plaintext that people use currently is necessary until a critical mass of keys have been shared. [2] why write a client app when you can make it hard for people to switch to other services by tying them to your domain name? /sigh/

by denova 11y ago

modernerd 11y ago

Even Phil Zimmermann, PGP's creator, says it's too hard to use: “I hardly ever run PGP. When people send me PGP encrypted mail I have to go through a lot of trouble to decrypt it. If it’s coming from a stranger, I’ll say please re-send this in plain text, which probably raises their eyebrows.“ http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-big-privacy-problem-qa-with-silent-circle-co-founder-phil-zimmermann/ http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-bi... I tried the ProtonMail password protection feature today (which is optional; you can just send plain text email to non ProtonMail accounts if you wish – this is the default, but you can click a lock to password-protect any outgoing message). The feature is well done, and I can see people using it to exchange secure mail, particularly if the recipient does not have a ProtonMail account. It has a built-in 'send secure reply' feature once you've entered the password as the recipient. This allows you to read the message and reply in-browser without returning to your email client, and without having a ProtonMail account, so both the outgoing message and the reply stay more secure than regular email throughout your conversation. This could be helpful for a wide range of uses, including support email that involves transferring login info and logs. The read and reply flow looks like this to the logged-out recipient: - Email with “view secure message” prompt: http://d.pr/i/1cwZ8 http://d.pr/i/1cwZ8 - Click “View secure message”: http://d.pr/i/13GlI http://d.pr/i/13GlI - Enter password to view message: http://d.pr/i/11Gg9 http://d.pr/i/11Gg9 - Click to reply in same tab: http://d.pr/i/WWWB http://d.pr/i/WWWB You still have to communicate the password securely somehow, but it's a much more user-friendly approach than PGP. I'm not saying it's a replacement for https://securedrop.org/ https://securedrop.org/, but it still has value.

tptacek 11y ago
"PGP is hard to use" is more memetic than accurate. What makes PGP hard is that it has a million options, and its vocal users (and detractors) seem insistent on availing themselves of as many of them as possible. In reality, 80% of PGP's value (which is more value than you'll get out of any webmail system), you can get with three command lines: gpg -sear recipient@addr document.txt Encrypt and sign a document, ASCII armored for inclusion in a 7-bit email, to a specific person or persons gpg -a --export my@addr Dump your public key for out-of-band transmission to the peer you're exchanging messages with gpg document.txt.asc Decrypt a message sent to you by someone else. No keyservers. No subkeys. No crazy formatting. No exotic key types. Send a message to someone, read a message back from them. You don't get forward secrecy (unless you manually rotate keys). You don't get peer validation unless you do it manually. You don't get real time chat. You can't encrypt a videoconference. On the other hand: you won't be the subject of someone's amusing blog post a year from now, either, because PGP used this way has been reliable for something like 15 years running. Everyone I know who actually uses PGP, like for real, more than a couple times a year, uses it pretty much this way.
- pdkl95 11y ago
  > 80% of PGP's value ... you can get with three command lines: While I completely agree that those commands are all that is needed most of the time, it's this part that unfortunately makes pgp/gpg so unpopular: > command lines Even on HN I find people that hate the command line (even though they use it). The problem is the complete lack of front ends wrappers around those commands in every other email tool. The enigmail plugin for thunderbird is surprisingly nice. It even does a decent job at key management (including the web of trust), but it made the "80% of PGP's value" completely transparent. If you have the key for an address, emails are automagically piped through gpg, and it handles decryption for you similarly (with pgp-agent support for less passphrase typing). Of course, that was only useful for the handful of us that used thunderbird; with Mozilla dropping the project, it's questionable if this has a useful future. Almost all of the complexity with pgp/gpg can be hidden behind a nice GUI and opportunistic[1] enabling of the crypto. Unfortunately development has been focused on walled gardens and tying people to artificial dependencies[2] instead of writing useful client-installed software. [1] Fallback to plaintext that people use currently is necessary until a critical mass of keys have been shared. [2] why write a client app when you can make it hard for people to switch to other services by tying them to your domain name? /sigh/