Here is the thing about e2e encrypted messengers: They lock you and your data in and do not allow you control of your life. There is a right to data portability (at least in the eu) that they violate and there is no one fighting for it. Whenever i engage in conversation about this i get empty faces, hostility and vague references to features that are crippled or just don't work at all. There are people and institutions that have to archive the communication centrally and they don't have control over how they are contacted and cannot have conversation about the channel used in every interaction all the time. The solution is to finally force messengers to allow api access to all communication data and then show a sign similar to ssl warnings in browsers to the other side that this user is using an archival api service.
There's a difference between data transport and data hosting. Modern expectations of messengers seem to blur this line and it's better if it's not blurred.
Incidentally: The reason why they blur it is because of 2 network asymmetries prevalent since the 1990's that enforced a disempowering "all-clients-must-go-through-a-central-server model" of communications. Those 2 asymmetries are A) clients have lower bandwidth than servers and B) IPv4 address exhaustion and the need/insistence on NAT. It's definitely not practical to have a phone directly host the pictures posted in its group chats, but it would be awesome if the role of a messaging app's servers was one of caching instead of hosting.
In the beginning though: the very old IRC was clear on this; it was a transport only, and didn't host anything. Anything relating to message history was 100% a client responsibility.
And really I have stuck with that. My primary expectation with messaging apps is message transport. Syncing my message history on disparate devices is cool, and convenient, but honestly I don't really need it in a personal capacity if each client is remembering messages. I don't understand how having to be responsibile for the management of my own data is "less control of my life," it seems like more control. And ... I'm not sure I care about institutional entitlement to archive stuff that is intended to be totally personal.
I understand companies like to have group chats, and history may be more useful and convenient there, but that's why I'm not ever going to use Teams for personal purposes. But I'm not going to scroll back 10 years later on my messaging apps to view old family pictures. I'm going to have those saved somewhere.
> Those 2 asymmetries are A) clients have lower bandwidth than servers and B) IPv4 address exhaustion and the need/insistence on NAT.
There's a third asymmetry: C) power-constrained clients which are asleep most of the time. And this applies not only to battery-powered phones/tablets and laptops, but also to modern desktops which are configured by default to suspend on inactivity.
Molly is a fork of signal that is allowed to access Signals APIs and their APIs are much more open than any other similar service [1] . Signal is not really designed for communicating with people that you don't know in real life such that you can be beyond suspicion that they would be archiving messages but it is basically impossible to monitor if your conversations are being archived if someone is just taking pictures of their phone with another device.
I don't understand this: there's nothing intrinsic to e2e that makes interoperability particularly hard. There are multiple open-source e2e protocols that demonstrate this tidily, and my understanding is that there are governments in the EU that are adopting e.g. Matrix for this reason.
> show a sign similar to ssl warnings in browsers to the other side that this user is using an archival api service.
There is no sound way to do this and there probably never will be, especially if the protocol is interoperable and therefore the user can pick any client they please. The other client can always lie about what it's doing or circumvent detections through analogue means, e.g. pointing a camera at the screen.
If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface. Multiple critical SSL/TLS CVEs-- including some we know for a fact the NSA relied on-- came from cipher negotiation.
> If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface.
Not really. The degree of malleability in cipher negotiation is widely considered to have been a Bad Move in SSL/TLS's early design, and modern (well-designed) cryptographic protocols don't enable the kinds of parametric malleability that made SSL/TLS so exploitable at the time.
Signal's protocol, for example, is perfectly interoperable; the lack of interoperability comes from a (not unreasonable) constraint at the application layer, not the protocol itself. Another example would be MLS[1], which supports fixed suites rather than parametric malleability and uses the technique from RFC 8701[2] to prevent clients from getting clever and trying to add their own extensions that undermine the fixed suites.
