6 ms·

Why do you think that? What would yet another protocol nobody uses bring to the table, smtp and imap don't? It's reliable, stable, decentralized and can be used

by buster 6y ago

Why do you think that? What would yet another protocol nobody uses bring to the table, smtp and imap don't? It's reliable, stable, decentralized and can be used securely.

ajvs 6y ago
It's really hard to do E2EE in a user-friendly way with email for starters.
- buster 6y ago
  That's what the app does and simplifies.
smt88 6y ago
Email is not decentralized. It relies on the central authority of domain registries. You theoretically can send emails in a more P2P way by using IP addresses, but then you lose the "reliable" and "stable" parts for many users. It arguably can't be used securely. One of the prominent security researchers on HN actually wrote an article that promising E2EE for email is more harmful than helpful because it gives a false sense of security. And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it. In short, email security is a bolt-on, and it will never be part of the standard itself. https://www.csoonline.com/article/3224410/is-universal-end-to-end-encrypted-email-possible-or-even-desirable.html https://www.csoonline.com/article/3224410/is-universal-end-t...
- dane-pgp 6y ago
  > Email is not decentralized. It relies on the central authority of domain registries. By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS. In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead.[0] > And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it. The same is true of any system which is proposed as an alternative to email. Admittedly it will be difficult for a UI to convey the security properties of messages when you are interacting with users whose email clients don't support the recommended extensions, but there is always the risk that a recipient will copy-paste the plaintext of your securely sent message into an unsecured channel. [0] https://github.com/mailpile/Mailpile/wiki/SMTorP https://github.com/mailpile/Mailpile/wiki/SMTorP
  - smt88 6y ago
    > By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS. That analogy makes no sense. Email is centralized because every time I send an email, I'm doing a DNS lookup. By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records. > In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead. Yes, but then why are you using email at all? The whole point of email has been that it uses the domain registry as a routing mechanism. It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore. > The same is true of any system which is proposed as an alternative to email. I don't think you understand this topic. There are protocols with encryption schemes built into them. Email is not one of those. From the article I linked: > "A number of standards exist for end-to-end email encryption, but so far, none have reached critical mass with vendors. Take Symantec. It supports both the S/MIME and PGP/MIME encryption, says Symantec's Kriese. That doesn't mean that the system easily interoperates with those of other vendors." That is in contrast to Signal Protocol[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol. 1. https://en.wikipedia.org/wiki/Signal_Protocol https://en.wikipedia.org/wiki/Signal_Protocol
    - cyphar 6y ago
      > By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records. I don't disagree with your general premise but Signal is not decentralised at all, and I'm pretty sure they don't hardcode the Signal API server IPs into their binaries so you still depend on DNS (plus their centralised servers).
    - dane-pgp 6y ago
      > Email is centralized because every time I send an email, I'm doing a DNS lookup. And every time the Signal app connects to its centralized servers, you're doing a DNS lookup too. > By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records. But Signal isn't a true P2P solution. As your linked description of the Signal Protocol states: "It does not provide anonymity preservation and requires servers for the relaying of messages and storing of public key material." > It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore. If you're using HTTP and HTML and hyperlinks and URIs, then you are using the WWW. I suppose you could say that .onion addresses are the Dark Web, but saying they are not part of the web is pointless gatekeeping, like saying that HTTPS sites aren't part of the web because some web clients don't support TLS. > I don't think you understand this topic. That makes two of us then. > There are protocols with encryption schemes built into them. Email is not one of those. Again, this is an unhelpful observation. HTTP is a protocol that doesn't have encryption schemes built into it, but we didn't decide to throw it away in order to make the web secure. Similarly we don't need to throw away all existing email protocols and clients in order to have secure messaging. > That is in contrast to Signal Protocol[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol. No, email is exactly the same as the Signal Protocol in that regard, since all email clients' E2EE are compatible with each other as long as they're using the same (encryption) protocol. The fact that an SMTP server doesn't reject an email that isn't PGP encrypted is a feature, not a bug.

by buster 6y ago

Why do you think that? What would yet another protocol nobody uses bring to the table, smtp and imap don't? It's reliable, stable, decentralized and can be used securely.

ajvs 6y ago

It's really hard to do E2EE in a user-friendly way with email for starters.

buster 6y ago
That's what the app does and simplifies.

smt88 6y ago

Email is not decentralized. It relies on the central authority of domain registries. You theoretically can send emails in a more P2P way by using IP addresses, but then you lose the "reliable" and "stable" parts for many users. It arguably can't be used securely. One of the prominent security researchers on HN actually wrote an article that promising E2EE for email is more harmful than helpful because it gives a false sense of security. And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it. In short, email security is a bolt-on, and it will never be part of the standard itself. https://www.csoonline.com/article/3224410/is-universal-end-to-end-encrypted-email-possible-or-even-desirable.html https://www.csoonline.com/article/3224410/is-universal-end-t...

dane-pgp 6y ago
> Email is not decentralized. It relies on the central authority of domain registries. By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS. In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead.[0] > And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it. The same is true of any system which is proposed as an alternative to email. Admittedly it will be difficult for a UI to convey the security properties of messages when you are interacting with users whose email clients don't support the recommended extensions, but there is always the risk that a recipient will copy-paste the plaintext of your securely sent message into an unsecured channel. [0] https://github.com/mailpile/Mailpile/wiki/SMTorP https://github.com/mailpile/Mailpile/wiki/SMTorP
- smt88 6y ago
  > By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS. That analogy makes no sense. Email is centralized because every time I send an email, I'm doing a DNS lookup. By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records. > In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead. Yes, but then why are you using email at all? The whole point of email has been that it uses the domain registry as a routing mechanism. It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore. > The same is true of any system which is proposed as an alternative to email. I don't think you understand this topic. There are protocols with encryption schemes built into them. Email is not one of those. From the article I linked: > "A number of standards exist for end-to-end email encryption, but so far, none have reached critical mass with vendors. Take Symantec. It supports both the S/MIME and PGP/MIME encryption, says Symantec's Kriese. That doesn't mean that the system easily interoperates with those of other vendors." That is in contrast to Signal Protocol[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol. 1. https://en.wikipedia.org/wiki/Signal_Protocol https://en.wikipedia.org/wiki/Signal_Protocol
  - cyphar 6y ago
    > By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records. I don't disagree with your general premise but Signal is not decentralised at all, and I'm pretty sure they don't hardcode the Signal API server IPs into their binaries so you still depend on DNS (plus their centralised servers).
  - dane-pgp 6y ago
    > Email is centralized because every time I send an email, I'm doing a DNS lookup. And every time the Signal app connects to its centralized servers, you're doing a DNS lookup too. > By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records. But Signal isn't a true P2P solution. As your linked description of the Signal Protocol states: "It does not provide anonymity preservation and requires servers for the relaying of messages and storing of public key material." > It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore. If you're using HTTP and HTML and hyperlinks and URIs, then you are using the WWW. I suppose you could say that .onion addresses are the Dark Web, but saying they are not part of the web is pointless gatekeeping, like saying that HTTPS sites aren't part of the web because some web clients don't support TLS. > I don't think you understand this topic. That makes two of us then. > There are protocols with encryption schemes built into them. Email is not one of those. Again, this is an unhelpful observation. HTTP is a protocol that doesn't have encryption schemes built into it, but we didn't decide to throw it away in order to make the web secure. Similarly we don't need to throw away all existing email protocols and clients in order to have secure messaging. > That is in contrast to Signal Protocol[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol. No, email is exactly the same as the Signal Protocol in that regard, since all email clients' E2EE are compatible with each other as long as they're using the same (encryption) protocol. The fact that an SMTP server doesn't reject an email that isn't PGP encrypted is a feature, not a bug.