Comment by eldude | Hacker News Reader

Comment by eldude | Hacker News Reader

It would likely have the following traits:

1. Decentralization 2. Realtime 3. Spam protection 4. Contextual

1. Decentralization typically generates wide adoption, once it's able to overcome the barrier of entry to wide adoption. An excellent example of this would be JavaScript. It thrives largely because nobody owns it, and contributing to its success it's often used as a means to stave off the advantages of competing platforms.

2. Realtime meaning push, just because it's a modern technological expectation. Email frequently is realtime, except IMAP/POP.

3. GMail et.al have gotten pretty good here. Future solutions would need to be as good, ideally with some built-in mechanism for unsubscribe as well.

4. Contextual messaging would be the defining feature. It's a broad term that simply means some manner of object graph between messages that would natively support arbitrary organization of messages (flat, nesting, topic stream, overlapping (for edits), etc...).

5. Encryption as part of the core protocol, always on.

Is it possible (in principle) to have an email-like-service with end-to-end encryption so that no one other than the sender and receiver can decipher messages?

Yes. Why not? You just have to encrypt the message before sending it and decrypt it after you received it.

https://github.com/google/end-to-end

I think the actual challenge is to do it with senders/receivers you do not know. I do not have enough secuirty experience to be able to answer how you can encrypt something on one end but decrypt it on the other hand without knowing the key? I guess something like HTTPS would work.

> I do not have enough secuirty experience to be able to answer how you can encrypt something on one end but decrypt it on the other hand without knowing the key?

You distribute public keys. That's what people do for PGP nowadays, and you have repositories of public keys you can access.

There's a myriad ways to do this. One approach would be "ecc-pub-key-in-hex+user@example.com" as email address, with user@example.com and whatever+user@example.com going to the same mailbox. This is even something gmail hasn't broken (prefix+user@gmail.com goes to user@gmail.com).

Why not just pubkey@example.com? Allowing for key rotation. Having the address be (part-of) the key may or may not be a horrible/good idea. It certainly is easy to bootstrap: smart MUAs could encrypt to the key, dumb/old ones could send plaintext, or use S/MIME or GPG).

There are plenty of attack-modes: for one - while the key/address need not be kept secret, the sender needs to know that it is corrrect/maps to the right user (eg: key1-e_smith@example.edu vs key2-eve_smith@example.edu).

What if I don't want to encrypt my email?

It would be a new standard so you could still use the former email standard anyway.

Why wouldn't you want to?

As long as we're talking about a hypothetical replacement, it's fair to assume that doing so would come with no usability disadvantages.

A few reasons..overhead, screwups if my key got compromised and I switched to another one, follwoed by problems decrypting older mail, not wanting to muck around with keys.

While I'm very much in favor of anyone having the ability to easily encrypt if they see fit, I'm not sure how much value it really delivers for most people.

I think people are talking about encrypting while it's in transit, not in local storage. So you would want to not encrypt email for the same reasons you'd want to not encrypt wifi - ie none.

We already have server-to-server and client-server encryption via ssl/tls. We just have to turn off plaintext. If gmail/outlook/yahoo and most universities started tagging all mail received over plain smtp as insecure and dumped it in a "folder-of-shame, turning off plaintext might become a realistic option soon.

But it solves very few problems. For that sender-sender encryption is needed.

See also: http://hypertekst.net/misc/anon-remail/

Maybe - OTOH I figure a lot of people would like a low-friction way to encrypt so that if they were investigated by police or something their whole inbox wouldn't be open to anyone for the cost of getting a subpoena. Anyway, I do think it'd be good to engineer for encryption rather than trying to bolt it on afterwards as we do now. Sorry if my whimsical question was a derailment.

Reply on news.ycombinator.com