De rerum chatura

Preamble

When dealing with data, and specifically in messaging, from a security and traceability perspective, one must consider the FBI paradigm. No wait, it was CIA:

• Confidentiality: what is said is read only by the interlocutors
• Integrity: what is said is not altered or alterable
• Availability (exactly, as you understood availability means availability. So High Availability means high availability and not high startability as some people from a well-known Italian Telco company tried to make me believe): what is said is readable when needed

then since we are at it, let's add:

• Authenticity: what is said has definitely been said by whoever claims to have said it
• Traceability (accountability): what is said, we know who said it, when they said it, and to whom.

The basics

I don't know if you've seen something like this. The network is a bit like that when it's encrypted. In practice, you see the truck, we see the driver, we see where it goes, but we don't know what's inside.

Okay, as an example, it kinda sucks, so let's go back to talking in the flattest way with Alice and Bob, the John Does of cryptography. These two lovely characters want to talk to each other. There are various ways:

• they talk to each other publicly, so everyone can know what they are saying
• they talk to each other on the phone, so they can be intercepted only by the telephone company (or by whoever has the authorization to lay their hands on it)
• they talk to each other on the phone using robber language (that kind of gibberish you used to speak as a kid)
• they communicate via mail: they take a piece of paper, write on it in gibberish, put it in an envelope addressed to the recipient, then slip it into another envelope addressed to the London post office, then slip it into another envelope addressed to the New York post office, then slip it into another envelope...)

By analogy:

• The first way is equivalent to a public chat, where potentially everyone reads everything: forums, websites, standard Telegram chats, etc.
• the second way is equivalent to private chats on centralized servers without end-to-end encryption (only transport encryption, like SSL): Rocket.Chat, Mattermost, Cisco Webex, and thousands of other mostly enterprise software
• the third way is equivalent to end-to-end encrypted chats: WhatsApp, Telegram secret chats (not the standard ones!), Matrix (in encrypted rooms, otherwise zilch), Delta Chat
• the fourth way is equivalent to end-to-end encrypted chats with onion routing

Now, assuming that there is integrity in every type of communication (i.e., we assume there is at least transport encryption and we are thus in SSL), we need to understand which type of communication suits our case.

Confidentiality

If we want confidentiality, the first method is out, and it would be good to exclude the second one as well: it's true that the communication is encrypted between Alice and the server and between Bob and the server, but whoever lays hands on the server sees everything in plain text (system administrators first and foremost).

Confidentiality requires at least E2EE (end-to-end encryption): only the sender and the recipient must be able to know what is written inside the message. This is possible thanks to the use of symmetric keys encapsulated in asymmetric keys. For the layperson, take this example.

Alice has a suitcase weighing 50 kg empty and a small 50-gram box with a combination lock.

Alice also has a key that opens padlocks which she deposits at the best newsstands.

Bob also has a key that opens other padlocks and he too deposits them at the best newsstands.

To deliver a message to Bob, Alice will follow these steps:

• she goes to a newsstand and takes one of Bob's padlocks
• she takes the box, slips it empty into the suitcase, and locks the suitcase with Bob's padlock
• she sends the suitcase to Bob via courier.

At this point:

• Bob receives the suitcase: he opens it with his key, takes the box, sets the combination, and leaves it open. In reality, Bob went to the toilet just when the courier passed, who therefore left a delivery slip in the mailbox; after various attempts to call customer service, he decided to take his car 3 days later to go to the distribution center which is no less than 10 km away and is open to the public from 10 to 11 on even Fridays of odd weeks.
• Bob takes one of Alice's padlocks from the best newsstands, puts the box back in the suitcase, and locks it with the newly purchased padlock
• Bob, not without effort, sends the suitcase back to Alice by mail

At that point Alice receives that monstrosity of a suitcase, opens it with her key, and finds the box with the combination set, but open.

From now on, both Alice and Bob know with which combination to open the box: they can send each other paper messages simply by mailing the box because the combination is known to both, and only to them, and they can save on the harsh intercontinental rates for weights over 45 kg. And the discount is only on odd Thursdays of even weeks in leap years, bad years.

Metadata

Now we enter the minefield of metadata.

What are they? They are those things surrounding the message content that serve to deliver it.

• Sender
• Recipient
• Country of origin
• Destination country
• Frequency of message exchange
• Time of message exchange and patterns (morning, evening, night)
• Group memberships

These metadata are often used by Big Tech (spoiler: not conspiracy theory, sad reality) to profile correspondents and - in the laxest case - to pitch purchase recommendations.

Suppose Alice talks to Bob, and both use WhatsApp. Suppose Alice also has a Facebook account. Now let's think of a third person, Charlie (for a change) who doesn't have WhatsApp, doesn't have Facebook, and has done nothing wrong other than having his phone number in Alice and Bob's address books.

Alice and Bob chat very closely on WhatsApp. Bob writes to Alice via Instagram.

The Meta company understands that they are all three friends: they have the address book (synchronized with WhatsApp by Bob and Alice), Alice and Bob talk to each other, Charlie is a mutual friend. The social graph is built so when Charlie goes around browsing and gets tracked via pixels, that information goes into the big pot of data collected by the company. If the system has already correlated Charlie to Alice and Bob (address book, mutual contacts, interactions), it is possible that similar signals reflect on them as well: not because "Charlie searched for X", but because they belong to the same cluster.

In practice, even without knowing the content of the messages exchanged by the 3 friends, the metadata are often enough to reconstruct relationships, habits, and context better than the content itself. No need to know what Alice and Bob are telling each other. It's enough to know they talk every night at 10 PM, for 40 minutes, from two different cities.

The use of metadata

Metadata therefore, unless we get into hardcore stuff (onion routing, communications without persistent identities or hard to correlate), are there. The difference lies in whose hands we put them: if they end up with someone who minimizes them, uses them only to run the service and then throws them away, so be it. If instead we give them to those who build models and business on data, the story changes. Because metadata don't sit still: they get aggregated, correlated, cross-referenced with other sources. And at that point, it's no longer just "whom you speak with", but what can be inferred from that. And yes, in certain cases, those data can also end up — directly or indirectly — in the hands of parties you might not have chosen yourself.

The content tells a conversation. The metadata tell the people.

So what?

And so the situation is a bit tragic, but I've made myself a guideline.

• Services linked to the phone number and managed by big tech: no, thank you. The moms' group, damn it, do it elsewhere.

• Services linked to the phone number but with a more respectful model: here we enter the grey area.

  • Telegram: meh. End-to-end encryption is not enabled by default, so for me, it's a no.
  • Signal: definitely better. It uses E2EE everywhere, it's open source, minimizes metadata as much as possible, and doesn't base its business model on profiling. The phone number is there, but it is treated in a less invasive way (hash, controlled discovery, possibility of pseudonyms).

• Services that do not require a phone number (username/password or equivalent): here things get interesting.

  • Delta Chat: very clean model. It uses email as transport, the relays (chatmail) tend not to retain data, and if you want, the server can be completely under your control.
  • Matrix: powerful but more complex. It can be self-hosted (Synapse, Conduit, etc.), but metadata exist and, in a federated environment, can be distributed across multiple servers. The advantage is that if the server is yours, you have control over retention, logs, and policies.

Do alternatives without metadata and encrypted exist?

Yes, they exist: Session and SimpleX Chat. For me, however, they are still rather immature projects.

• Session: focuses heavily on anonymity (no phone number, onion-like routing), but has several compromises. The architecture is more complex and this reflects on reliability: multi-device is unstable, messages can arrive late or in a weird order. Cryptographically it's solid, but the problem here is more practical than theoretical.
• SimpleX Chat: it is perhaps the most interesting model on the privacy and anonymity side. It has no persistent global identities, so there is no social graph to build. The flip side is usability: no real multi-device, limited synchronization, and non-trivial battery consumption.

Quick recap (CIA + AT + Anonymity)

Legend:
✔✔✔ = very good
✔✔ = good
✔ = acceptable
⚠ = depends / limitations
❌ = poor

Note:

• "Authenticity" = cryptographic authenticity of the peer (protection from MITM), not real identity.
  
• "Anonymity" = possibility of not being directly traceable to one's real identity.
  

Yes, but at the end of the day, what do we use?

Standard users, standard communications:

• If you don't care about being tracked like everyone else, go ahead with WhatsApp. The encryption protocol it uses is Signal's, so it is the gold standard. It's just that you will always have a big brother behind you and you provide your data to Meta. What drives me crazy, though, is that by doing so you also give Meta your address books, which might contain someone who wouldn't want to end up on their servers.
• The plug-and-play alternative is Signal. Personally, in the end, I think it's the best compromise: you'd just need your main interlocutors to have an account (either because they have one or because you make them create one).

Enterprise users:

• spin up a Matrix server and isolate it; it's true that there is metadata, but at least you are the one managing it. Don't use public servers (matrix.org, to be clear)

Shadow users:

• Session / SimpleX Chat: by shadow I don't mean they want to hide from nosy people, but from governments due to the type of activity they intend to carry out with others (activists).

I don't believe that in standard conditions extreme anonymity is necessary: public employees, corporate staff, families, friends don't need anonymity: they need integrity, confidentiality, and it's good to know who sent the message (my boss, mom, friend). You just need to be sure you are not profiled by whoever has no right to.

If you then want to join the Italian terrorists party, then things change and you will want anonymity: but know that even then, you will see that someone will track you down, mainly to ask you what is the math homework for tomorrow and what time does the bus leave for the school trip

[May the big mole be with you]

[EOF]

Discussion & Support

Discussion and support channel. To discuss configurations or other topics, join us on fluxer.dreadful.work.