5 ms·

Not having improvements is a feature. Yes, please leave email the way it is, because it works fine. It’s one of the few things that does. The only feature I w

Not having improvements is a feature. Yes, please leave email the way it is, because it works fine. It’s one of the few things that does. The only feature I want is end to end encryption. Google will never make encryption easy on their own because they’ve got perverse incentives not to.

euyyn 9y ago
It works fine for some definition of "fine".
- benrbray 9y ago
  What's wrong with it?
  - euyyn 9y ago
    That come to mind: Hard to separate pending tasks from just conversations. Hard to split conversations into separate threads when two topics diverge. Leaving a conversation isn't just your decision: you have to both reply all and hope that no one else replies all using a previous email in the thread. In a corporate email, inability to prevent mass emails from other employees. Hard to do for personal email too. EDIT: I'm a huge fan, e.g., of the "travel bundles" Inbox creates. It's a giant win in usability for the use case of getting confirmation emails of booked trips. But you can see how it's a battle uphill that Inbox fights against the protocol, as the AI isn't always able to bundle all relevant information together, or extract key pieces of info from the email bodies.
    - pjmlp 9y ago
      Those are email client specific issues.
      - euyyn 9y ago
        How would you solve them in the client, that GMail hasn't been able to?
        pjmlp 9y ago
        > Hard to separate pending tasks from just conversations. Emails aren't tasks. In any case, Outlook allows for assigning tasks to emails and organize them. > Hard to split conversations into separate threads when two topics diverge. An UI/UX design issue. If the subject is no longer the same, one could provide an UI feature that allows them to be viewed separately. > Leaving a conversation isn't just your decision: you have to both reply all and hope that no one else replies all using a previous email in the thread. Leaving a conversation is my decision. I just stop replying and create a rule to delete all further emails using the same topic from the group of senders. > In a corporate email, inability to prevent mass emails from other employees. Hard to do for personal email too. In some emails clients, specially corporate ones, it is possible to customize how send, reply and reply-all work, either via group policies or custom plugins. GMail has not wanted to, which is quite different from being able to.
        euyyn 9y ago
        > Emails aren't tasks. Your use of email must be vastly different from mine then. Corporate email is pretty much a way for other people to add stuff to one's TO-DO list. > If the subject is no longer the same, one could provide an UI feature that allows them to be viewed separately. Many times an email conversation forks into two topics, each of which is only relevant to some of the people in the recipient's list.
        pjmlp 9y ago
        I use email for exchanging messages with other people. Jira is for ToDo list. So each people is free to organize on their own email client as they want to see their email threads, provided the UI provides aggregation by topic.
JasonFruit 9y ago
Email does work fine. We have a similar solution for encryption: PGP. If you do the encryption yourself instead of relying on your email client to handle it, it works fine. Type your text, encrypt it, then put it in an email; get a response, decrypt it, and read it — it's easy, and it works. People who say PGP is too hard to use are usually relying on a plugin for their email client, or some other unreliable, "encryption magic" tool that tries to hide how PGP works behind an incompatible abstraction. Simple tools that do one thing well are almost always best.
- KozmoNau7 9y ago
  That is absolutely not the way to get people to use it. Very few people can be bothered to muck about with PGP manually. The few geeks who want it or need it are already doing that. What we need is a way to make E2E encryption easy and straightforward, like Signal or Wire, where it's easy, automatic and default enabled.
  - JasonFruit 9y ago
    Did I say that was the way to get people to use it? No. I said it's the way to make it work. I want it to work when people need it, not to get more people to encrypt their shopping lists.
    - KozmoNau7 9y ago
      The more people encrypt their everyday communication, the easier it is for your confidential emails to hide in the noise.
  - rakoo 9y ago
    That's what autocrypt (https://autocrypt.org/ https://autocrypt.org/) is going to solve. Automatic opportunistic encryption using existing standards.
paxys 9y ago
Email does not work fine. There is no standard for encryption or any other information security mechanism. No server identity verification. No delivery confirmation. No push standard. No concept of groups or other ways to categories and manage access between users in a domain. Every provider has their own implementation of threaded conversations. No major provider supports non-ASCII addresses. Servers can't even agree on simple message formatting. Most things that make email actually useful are outside the spec and tacked on by each individual provider. Email is one of the last widely used open communication protocols, and it is sad that people are so resistant to its evolution because that is exactly what is accelerating its demise in favor of proprietary software.
- yjftsjthsd-h 9y ago
  > There is no standard for encryption or any other information security mechanism. I agree that SSL in transit and GPG could stand to be improved, but they do exist. > No server identity verification. What do you want that SPF+DKIM doesn't cover? > No delivery confirmation. Good? That sounds like asking for abuse. And in any event, it's no different than inline remote images (which of course are blocked for the same reason that delivery confirmation is a bad idea). Unless you just mean being sure that the message got to the target server, in which case I agree that the best we can do is delivering it directly to the target MX and see that it confirmed that it received the message. > No push standard. Temporarily true, pending JMAP (which I suppose strengthens your point about needing innovation). > No concept of groups or other ways to categories and manage access between users in a domain. Not quite sure what this means. Do you want something like shared mailboxes and tags? > Every provider has their own implementation of threaded conversations. True, though in a message-centric format I'm not sure that it's a bug. > No major provider supports non-ASCII addresses. Not a bug in email, only arbitrary restrictions by certain providers. Also opens you up to unicode normalization attacks (phishing is easier if you can fake characters). > Servers can't even agree on simple message formatting. I'm not sure what formatting servers even care about (email is just some blobs of text strung together), but I can't really refute this without knowing what you refer to more specifically. > Most things that make email actually useful are outside the spec and tacked on by each individual provider. Email is useful because it lets us send arbitrary stuff (usually a text body and zero or more attachments) between federated providers. It's a simple-ish protocol that is stable and just works. EDIT: In summary, I vastly prefer email as it is: A simple protocol that can include arbitrary information, which allows people to extend it however they want. Of course, this means that extensions are arbitrary and at best non-required, but that keeps it flexible and back-compatible.

euyyn 9y ago

It works fine for some definition of "fine".

benrbray 9y ago
What's wrong with it?
- euyyn 9y ago
  That come to mind: Hard to separate pending tasks from just conversations. Hard to split conversations into separate threads when two topics diverge. Leaving a conversation isn't just your decision: you have to both reply all and hope that no one else replies all using a previous email in the thread. In a corporate email, inability to prevent mass emails from other employees. Hard to do for personal email too. EDIT: I'm a huge fan, e.g., of the "travel bundles" Inbox creates. It's a giant win in usability for the use case of getting confirmation emails of booked trips. But you can see how it's a battle uphill that Inbox fights against the protocol, as the AI isn't always able to bundle all relevant information together, or extract key pieces of info from the email bodies.
  - pjmlp 9y ago
    Those are email client specific issues.
    - euyyn 9y ago
      How would you solve them in the client, that GMail hasn't been able to?
      - pjmlp 9y ago
        > Hard to separate pending tasks from just conversations. Emails aren't tasks. In any case, Outlook allows for assigning tasks to emails and organize them. > Hard to split conversations into separate threads when two topics diverge. An UI/UX design issue. If the subject is no longer the same, one could provide an UI feature that allows them to be viewed separately. > Leaving a conversation isn't just your decision: you have to both reply all and hope that no one else replies all using a previous email in the thread. Leaving a conversation is my decision. I just stop replying and create a rule to delete all further emails using the same topic from the group of senders. > In a corporate email, inability to prevent mass emails from other employees. Hard to do for personal email too. In some emails clients, specially corporate ones, it is possible to customize how send, reply and reply-all work, either via group policies or custom plugins. GMail has not wanted to, which is quite different from being able to.
        euyyn 9y ago
        > Emails aren't tasks. Your use of email must be vastly different from mine then. Corporate email is pretty much a way for other people to add stuff to one's TO-DO list. > If the subject is no longer the same, one could provide an UI feature that allows them to be viewed separately. Many times an email conversation forks into two topics, each of which is only relevant to some of the people in the recipient's list.
        pjmlp 9y ago
        I use email for exchanging messages with other people. Jira is for ToDo list. So each people is free to organize on their own email client as they want to see their email threads, provided the UI provides aggregation by topic.

JasonFruit 9y ago

Email does work fine. We have a similar solution for encryption: PGP. If you do the encryption yourself instead of relying on your email client to handle it, it works fine. Type your text, encrypt it, then put it in an email; get a response, decrypt it, and read it — it's easy, and it works. People who say PGP is too hard to use are usually relying on a plugin for their email client, or some other unreliable, "encryption magic" tool that tries to hide how PGP works behind an incompatible abstraction. Simple tools that do one thing well are almost always best.

KozmoNau7 9y ago
That is absolutely not the way to get people to use it. Very few people can be bothered to muck about with PGP manually. The few geeks who want it or need it are already doing that. What we need is a way to make E2E encryption easy and straightforward, like Signal or Wire, where it's easy, automatic and default enabled.
- JasonFruit 9y ago
  Did I say that was the way to get people to use it? No. I said it's the way to make it work. I want it to work when people need it, not to get more people to encrypt their shopping lists.
  - KozmoNau7 9y ago
    The more people encrypt their everyday communication, the easier it is for your confidential emails to hide in the noise.
- rakoo 9y ago
  That's what autocrypt (https://autocrypt.org/ https://autocrypt.org/) is going to solve. Automatic opportunistic encryption using existing standards.

paxys 9y ago

Email does not work fine. There is no standard for encryption or any other information security mechanism. No server identity verification. No delivery confirmation. No push standard. No concept of groups or other ways to categories and manage access between users in a domain. Every provider has their own implementation of threaded conversations. No major provider supports non-ASCII addresses. Servers can't even agree on simple message formatting. Most things that make email actually useful are outside the spec and tacked on by each individual provider. Email is one of the last widely used open communication protocols, and it is sad that people are so resistant to its evolution because that is exactly what is accelerating its demise in favor of proprietary software.

yjftsjthsd-h 9y ago
> There is no standard for encryption or any other information security mechanism. I agree that SSL in transit and GPG could stand to be improved, but they do exist. > No server identity verification. What do you want that SPF+DKIM doesn't cover? > No delivery confirmation. Good? That sounds like asking for abuse. And in any event, it's no different than inline remote images (which of course are blocked for the same reason that delivery confirmation is a bad idea). Unless you just mean being sure that the message got to the target server, in which case I agree that the best we can do is delivering it directly to the target MX and see that it confirmed that it received the message. > No push standard. Temporarily true, pending JMAP (which I suppose strengthens your point about needing innovation). > No concept of groups or other ways to categories and manage access between users in a domain. Not quite sure what this means. Do you want something like shared mailboxes and tags? > Every provider has their own implementation of threaded conversations. True, though in a message-centric format I'm not sure that it's a bug. > No major provider supports non-ASCII addresses. Not a bug in email, only arbitrary restrictions by certain providers. Also opens you up to unicode normalization attacks (phishing is easier if you can fake characters). > Servers can't even agree on simple message formatting. I'm not sure what formatting servers even care about (email is just some blobs of text strung together), but I can't really refute this without knowing what you refer to more specifically. > Most things that make email actually useful are outside the spec and tacked on by each individual provider. Email is useful because it lets us send arbitrary stuff (usually a text body and zero or more attachments) between federated providers. It's a simple-ish protocol that is stable and just works. EDIT: In summary, I vastly prefer email as it is: A simple protocol that can include arbitrary information, which allows people to extend it however they want. Of course, this means that extensions are arbitrary and at best non-required, but that keeps it flexible and back-compatible.