2 added 15 characters in body
source | link

Does there exist cross-platform email handlers following these basic guidelines based on some very limited experience?

  1. Generate new key at first startup, rather than asking the user if they have an existing key. "Use existing key" could be a button somewhere isolated on the form.
  2. Secure defaults. Just stick with some general recommendations, and let the advanced users (and those who want to shoot themselves in the foot) tweak.
  3. Don't even include completely insecure options, or combinations which are known to be insecure. If it's already broken, it doesn't belong in an end user application.
  4. Display only the text that the user wrote in the text output widget (be it a curses interface, web page or application window). That is, if I

    1. create two emails with identical subject and body,
    2. encrypt and sign one of them, and
    3. send both to myself,

    the subject and body text for both should be identical. PGP metadata is still metadata, so it belongs in other widgets.

  5. Lots of context-sensitive help. For example:
    1. What does it mean to mark a signature as "somewhat trusted"? How is signature trust different from how much I trust the person?
    2. How to I increase the trusted level? For example, if the person is sitting next to me or is on the other side of the globe, what are practical ways to maximize the trusted level of the signature?
    3. Ballpark guesstimates for generating and cracking keys. For example, I'd like a warning if it's going to take 5 days to generate an N bit key, if the resulting key can be cracked by any organization in less than a year, or if the extra metadata is going to take up a megabyte in each tweet-size email.
  6. Simple up-/downloading of keys to common servers.

Does there exist email handlers following these basic guidelines based on some very limited experience?

  1. Generate new key at first startup, rather than asking the user if they have an existing key. "Use existing key" could be a button somewhere isolated on the form.
  2. Secure defaults. Just stick with some general recommendations, and let the advanced users (and those who want to shoot themselves in the foot) tweak.
  3. Don't even include completely insecure options, or combinations which are known to be insecure. If it's already broken, it doesn't belong in an end user application.
  4. Display only the text that the user wrote in the text output widget (be it a curses interface, web page or application window). That is, if I

    1. create two emails with identical subject and body,
    2. encrypt and sign one of them, and
    3. send both to myself,

    the subject and body text for both should be identical. PGP metadata is still metadata, so it belongs in other widgets.

  5. Lots of context-sensitive help. For example:
    1. What does it mean to mark a signature as "somewhat trusted"? How is signature trust different from how much I trust the person?
    2. How to I increase the trusted level? For example, if the person is sitting next to me or is on the other side of the globe, what are practical ways to maximize the trusted level of the signature?
    3. Ballpark guesstimates for generating and cracking keys. For example, I'd like a warning if it's going to take 5 days to generate an N bit key, if the resulting key can be cracked by any organization in less than a year, or if the extra metadata is going to take up a megabyte in each tweet-size email.
  6. Simple up-/downloading of keys to common servers.

Does there exist cross-platform email handlers following these basic guidelines based on some very limited experience?

  1. Generate new key at first startup, rather than asking the user if they have an existing key. "Use existing key" could be a button somewhere isolated on the form.
  2. Secure defaults. Just stick with some general recommendations, and let the advanced users (and those who want to shoot themselves in the foot) tweak.
  3. Don't even include completely insecure options, or combinations which are known to be insecure. If it's already broken, it doesn't belong in an end user application.
  4. Display only the text that the user wrote in the text output widget (be it a curses interface, web page or application window). That is, if I

    1. create two emails with identical subject and body,
    2. encrypt and sign one of them, and
    3. send both to myself,

    the subject and body text for both should be identical. PGP metadata is still metadata, so it belongs in other widgets.

  5. Lots of context-sensitive help. For example:
    1. What does it mean to mark a signature as "somewhat trusted"? How is signature trust different from how much I trust the person?
    2. How to I increase the trusted level? For example, if the person is sitting next to me or is on the other side of the globe, what are practical ways to maximize the trusted level of the signature?
    3. Ballpark guesstimates for generating and cracking keys. For example, I'd like a warning if it's going to take 5 days to generate an N bit key, if the resulting key can be cracked by any organization in less than a year, or if the extra metadata is going to take up a megabyte in each tweet-size email.
  6. Simple up-/downloading of keys to common servers.
    Post Closed as "not constructive" by Ayrx, Scott Pack, Rory Alsop
1
source | link

User friendly PGP email

Does there exist email handlers following these basic guidelines based on some very limited experience?

  1. Generate new key at first startup, rather than asking the user if they have an existing key. "Use existing key" could be a button somewhere isolated on the form.
  2. Secure defaults. Just stick with some general recommendations, and let the advanced users (and those who want to shoot themselves in the foot) tweak.
  3. Don't even include completely insecure options, or combinations which are known to be insecure. If it's already broken, it doesn't belong in an end user application.
  4. Display only the text that the user wrote in the text output widget (be it a curses interface, web page or application window). That is, if I

    1. create two emails with identical subject and body,
    2. encrypt and sign one of them, and
    3. send both to myself,

    the subject and body text for both should be identical. PGP metadata is still metadata, so it belongs in other widgets.

  5. Lots of context-sensitive help. For example:
    1. What does it mean to mark a signature as "somewhat trusted"? How is signature trust different from how much I trust the person?
    2. How to I increase the trusted level? For example, if the person is sitting next to me or is on the other side of the globe, what are practical ways to maximize the trusted level of the signature?
    3. Ballpark guesstimates for generating and cracking keys. For example, I'd like a warning if it's going to take 5 days to generate an N bit key, if the resulting key can be cracked by any organization in less than a year, or if the extra metadata is going to take up a megabyte in each tweet-size email.
  6. Simple up-/downloading of keys to common servers.