5 ms·

Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?

by jolux 6y ago

mathnmusic 6y ago
Because there are too many users on SMTP/Email, but not many PGP users to worry about interoperating? I mean, Hey.com shows that people still like SMTP/Email.
- jolux 6y ago
  Does it? Or does it show that a small number of highly technical users are willing to pay more for a different email experience? It's a bit early to judge their impact on the ecosystem, and I'm skeptical they'll capture a significant user base in the way that Gmail did. People use email because everyone uses email; you're not going to get people to change how they use email entirely. Nobody cares that it's running on SMTP, they care that they can email everyone they know with an email address.
oconnore 6y ago
You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack -- and in those cases you want to maintain as much compatibility as possible. "Federated SecureEmail 2.0" would be dead-on-arrival, where "Secure Client on top of bog-standard email" is ever so slightly less DOA. You get to re-use the existing identity/routing system, existing servers, existing authorization, etc.
- jolux 6y ago
  >You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Why not just toss the whole shebang and rebuild it below that layer? Signal Protocol seems to be pretty successful here. >Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible.
  - toast0 6y ago
    > No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible. You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc.
    - jolux 6y ago
      >You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. That's right. >Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc. This would require changing all the clients.
      - toast0 6y ago
        > This would require changing all the clients. Not really, the old clients would never send (or receive) end to end encrypted messages, so they don't need new UI to tell you that. That's the cost of unbounded backwards comptability. If you want to have 100% coverage of email users, changing all clients is part of the deal. But, uhhh, good luck with that. Server based standards are an easier lift --- you could build a standard to require hop to hop encryption on mail and expect that to plausibly gain enough adoption to use over a managable time frame. Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years.
        jolux 6y ago
        >Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years. You're describing TLS, and this is already happening.
core-questions 6y ago
Aren't there specific legal protections for email in some places, distinct from other online communication?

Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?

by jolux 6y ago

Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?

Because there are too many users on SMTP/Email, but not many PGP users to worry about interoperating? I mean, Hey.com shows that people still like SMTP/Email.

jolux 6y ago
Does it? Or does it show that a small number of highly technical users are willing to pay more for a different email experience? It's a bit early to judge their impact on the ecosystem, and I'm skeptical they'll capture a significant user base in the way that Gmail did. People use email because everyone uses email; you're not going to get people to change how they use email entirely. Nobody cares that it's running on SMTP, they care that they can email everyone they know with an email address.

oconnore 6y ago

You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack -- and in those cases you want to maintain as much compatibility as possible. "Federated SecureEmail 2.0" would be dead-on-arrival, where "Secure Client on top of bog-standard email" is ever so slightly less DOA. You get to re-use the existing identity/routing system, existing servers, existing authorization, etc.

jolux 6y ago
>You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Why not just toss the whole shebang and rebuild it below that layer? Signal Protocol seems to be pretty successful here. >Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible.
- toast0 6y ago
  > No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible. You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc.
  - jolux 6y ago
    >You can't have strong security guarantees with backwards compatability, because backwards compatability requires plain text sending. That's right. >Unless you're OK with limited guarantees like the UI will tell you when the mail could be sent in plain text. Or if the UI tells you the message will be end to end encrypted, it won't fallback to plain text, etc. This would require changing all the clients.
    - toast0 6y ago
      > This would require changing all the clients. Not really, the old clients would never send (or receive) end to end encrypted messages, so they don't need new UI to tell you that. That's the cost of unbounded backwards comptability. If you want to have 100% coverage of email users, changing all clients is part of the deal. But, uhhh, good luck with that. Server based standards are an easier lift --- you could build a standard to require hop to hop encryption on mail and expect that to plausibly gain enough adoption to use over a managable time frame. Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years.
      - jolux 6y ago
        >Of course it would be trivial for a hop in the delivery path to subvert that and remove the request, and all hops in delivery would still have message content access; but if people like it, a large majority of servers might support it in 5-10 years. You're describing TLS, and this is already happening.

core-questions 6y ago

Aren't there specific legal protections for email in some places, distinct from other online communication?