Signal & Matrix
Whenever I challenge the experts in cialtroprivacy and say to stay away from Signal and the Matrix, people think that I am particularly angry with these two platforms for whatever personal reason. Well, no. I have it with these two platforms for specific reasons, namely that they advertise themselves as alternatives when they are authentic to those gafams that they want to oppose in words.
Spoiling Signal as an alternative to GAFAM is so simple that I shouldn't even put myself on it, but apparently people aren't able to go to a platform's website and get an idea (but they are experts in online privacy and "alternatives ethics "is clear):
So, this is the block architecture of the system that should protect you from GAFAMs and not give them data:
Apparently it would be enough to look at the actors involved to understand that this platform will be able to defend you from everyone except the GAFAM. But that's not really the problem. The problem is not in the actors above ((Twilio, Apple, Google, Amazon S3), but in what I see below.
"Postgres, Redis". Ok. Steps for redis which can auto-remove data after some time. I don't like it, but I tolerate it. But Postgres?
You will say: and why are you angry with postgres? Even without wanting to disgrace an obsolete product that seems to have been designed in the 70s by a former IBM programmer on acid, the problem is simple: “what is a persistent database doing in an instant messaging product”?
I know that if you are not a systems architect you do not realize that architectures "talk" and "talk" about the use you will make of the platform, so I will give an example.
Imagine picking up your cell phone and wanting to call your grandmother. Then go to the phone book, click on "grandmother" and the mobile phone tells you "to call, please start recording the voice".
And you say “no, I don't want to record the phone call, quite the contrary. I just want to talk to my grandmother ”. And the cell phone: "impossible to call if the call is not recorded".
Now, it doesn't take long to realize that a cell phone that needs to record the phone call and conversation is spying on you – you need two things to talk to someone. You, someone and an audio line. No recording of the call is needed, and a cell phone requesting or enforcing it is CLEARLY made to spy on you.
Now let's move on to a signal server. A chat system, or IM as they say today, is nothing more than a multiplexer. You can turn the call to one person or to a group, but work here and now. Maybe it is acceptable for him to hold a queue for some time, but nothing more.
But there is a whole database with persistence there. Which saves data. What's this. Thing? Dunno, because Signal server has been blacked out for about a year:
and then put back online:
Manuel Vonau 
So even as opensource there is a lack of transparency.
Let's go to the Matrix. To determine what is wrong with the matrix we have to do about the same thing: go and see if there is a database. Because if there is a database, we CLEARLY have a server created to spy on conversations.
Is the database there? It can be sqlite or Postgres, and if you want to know what it does for a moment, you can do this search:
Why Why does something multiplexing have to save states? Steps to authenticate users, but everything else? Even if we want a damn IM server to have temporary persistence or hold queues for some time, a memcached or a redis is more than enough.
But here we are evading the REAL question: why do we have to design an IM system from scratch? There is already everything you need to make one by designing interfaces to any queuing system: RabbitMQ, NATS / GNATS, Kafka, Pulsar, Macrometa. MQTT…. there are plenty of them. You don't need to write queuing, dispatching systems. All you have to do is write the interfaces and let the clients do their work.
Because if we talk about E2E encryption, the client does the job. Okay, do you want to verify identity? You need a keyserver, but it would be better if the client had an address book. In any case, at worst you need a NATS and a keyserver, and a few thousand SLOCs. The client does not have to do is encrypt the message with the recipient's public key and then sign the message with his own private key,
Do you want rooms with E2E? You have two choices:
- if anyone can enter the room, E2E is ridiculous. The attacker will just join and record everything. When you have checked that the sockets are SSL, the encryption is more than enough: anyone can come in and listen. The rest is cialtrocryptarian crap.
- if the room is accessible only by a few, then the access is managed by an administrator, human or not. The client just has to encrypt with the administrator's public key and sign with his own key. The admin bot does nothing but verify the signature, decrypt, and redistribute the message to everyone after encrypting it with THEIR public key, and signing it with their private key.
the implementations I see around room, on the other hand, are simply backdoors, and often poorly disguised.
The story "but we don't have to make phone calls and videoconferences" is ridiculous. Both are unnecessary: you have a phone in your hand, remember? He already makes the phone calls and even the videocalls. It is already part of the LTE protocol. And you can already encrypt them. The infrastructure already exists.
The truth, that is, is that after the birth of systems like RabbitMQ, NATS / GNATS, Kafka, Pulsar, Macrometa. MQTT, we don't need to write any other "IM servers". At most we have to write the bots that keep the stanzas, and then use a keyserver for the public keys, and write good clients. Point. If we want them to federate we have to write a robot (and a queue) that takes care of sending messages for another server and a TCP / SSL interface.
We don't really need anything else. There is no need to reinvent the wheel. Queue systems (clusterable, scalable, pub / sub or not) already exist. And they are SAFE because they are TESTED. And all of them allow you to write plugins in front of interfaces. We only need clients and at most one keyserver.
The mere fact that someone writes themselves a new IM server is suspicious because we already have mature and TESTED message queue systems also on the security profile. If they then put a persistent database in it, the suspicion is confirmed: spyware.
Of course, you will tell me that with E2E encryption your precious creature cannot save messages, only the metadata. I could tell you about that wife who, reading the metadata, discovered that her husband gave her ex a ring every time she went out to go football, but since you can't hear us, I'll draw you a sketch:
Here, this is what I think of Signal, the Matrix and all those like them:
- after the birth of systems such as RabbitMQ, NATS / GNATS, Kafka, Pulsar, Macrometa. MQTT, and others, writing your own, or proprietary, IM system is a suspicious act in itself.
- E2E encryption can only be done by the client. It must not and cannot require implementation complexity from the server
- there is no need to withhold user credentials, when a public key is enough to verify signatures.
- then if there is a persistent database, we are DEFINITELY faced with spyware.
And that's the point.
They are all spyware, which you are diving into with the false sense of security that comes from the "privacy experts" who recommend them.