3 ms·
I was going to write the same thing, but less eloquently! The solution seems simple. Create something much like signal, but with the user-interface of e-mail!
by rocqua 7y ago
I was going to write the same thing, but less eloquently!
The solution seems simple. Create something much like signal, but with the user-interface of e-mail! This addresses your points 1 and 2 perfectly.
I'd want my UI to include actual working archives. None of this 'this message will be deleted automatically after x days'. Because e-mail is non-ephemeral communication. Hence I want to be able to access it.
However, point 3 introduces a relevant technical difference between signal and e-mail that affects the user experience.
Federation.
This is what makes cold e-mailing possible. It is what allows anyone who controls a domain to start accepting e-mails at that domain without needing permission, or any central service.
I don't have enough of the infrastructure of signal's ephemeral key pre-sharing front of mind. But I really hope there is some way to get this to work in a federated system. I could eventually see this replacing e-mail.
Point 3 has one more side-effect that hurts any e2e encrypted form of communication: spam-filtering. Because content-based spam filtering essentially requires access to the plain text. And for it to be effective, you want to base your filtering on a large dataset.
Even if you were to move applying the spam filter to the endpoints (ignoring compute and trade-secret issues), you still need access to plain-texts to train your spam-filter.
Sure, you could probably share any false negatives back to some aggregator to train the spam filter. Because generally spam sent to you doesn't need to remain confidential. However, false-positives i.e. emails that are wrongfully marked as spam, are not things you'd want to share back to some aggregator. I suppose MPC could be of help here, but that would 1) fix the algorithm used and 2) have huge computational overhead.
In summary, if we can federate e2e encryption and get spam-filtering to work, we could and should replace the entire user experience of e-mail with an e2e encrypted protocol.
- loup-vaillant 7y ago> I don't have enough of the infrastructure of signal's ephemeral key pre-sharing front of mind. But I really hope there is some way to get this to work in a federated system. Well, there's one major hurdle: multiple devices. Pre shared keys (and one time keys, and ratchet keys) are generated on the user's computer. If there's several of them, say a Wintel desktop and an Android palmtop, messages sent with the desktop's pre-shared keys can't be decrypted by the palmtop¹. So we need a need to synchronise those keys between the devices. The easiest way to do it is to store the private half on the recipient's server. But then you need to encrypt them to prevent the server from breaking forward secrecy. The encryption key must then be shared across both desktop and palmtop. (UI wise, it's pretty easy: connect both devices to the server, then manually type on the new device some low-ish entropy secret the old device is displaying on screen.) [1] Commonly misnamed "phone"
- NoGravitas 7y agoIn theory, both Matrix and XMPP+OMEMO handle multiple devices. In practice, I've found it to be less than smooth.
- cyphar 7y agoMatrix has gotten much better about this. Most scenarios where device lists get out of date are caused by the device list cache for federared homeservers being out of date. But with synapse 1.10 (released a few weeks ago), homeservers will refresh the device list much more aggressively in circumstances where it's clear that the cache is old (such as receiving a new message from a federated user on an unknown device).