Read on
Hive.Blog
Today I thought I would talk about messengers, specifically, the
different types of messengers and how they work. The goal here is to
help give an understanding of various privacy and security focused
messengers, but in order to make the right choice on which one you need
to understand how they work and the differences under the hood. I guess
I bring this up because often times in the privacy community you hear
about metadata and a few other aspects like registration requirements,
and then are given recommendations based on that. I don’t mean to throw
shade or anything, and understanding that stuff is important in picking
a private messaging platform, but personally I think it is vital to
understand how any given messenger works before you choose one.
There are effectively three types of messengers in the wild:
centralized messengers, federated & self hosted messengers, as well
as peer to peer messengers. Sure, things have a habit of not fitting
into neat little categories, but I hope I’ll be able to lay them out in
an understandable way. Also, this is completely focused on the niche of
private messengers, so for all these examples assume that end to end
encryption is active.
With that, before I break down the different types of messengers, lets
quickly go over how a message is sent. The structure obviously changes
across messenger structures, however, the concept is still the same.
The message starts on the sending device, which is typed up and then
encrypted so nobody can read it except the intended recipient. Lets say
we sent it from one phone to another, the message is encrypted on that
phone, sent through one or more servers, received by the intended
recipient, and then de-crypted by the recipient on their phone or other
device they are using. Now, I know you might be thinking, “but wait,
peer to peer messengers don’t go through servers,” and while it’s true
they don’t go through messenger servers they do go through the internet
which is made up of servers and switches that send that encrypted
message in packets, so there is still devices to consider.
With this understood, picking a messenger structure really comes down
to the following questions:
Does my messenger require identifying information to
setup?
How much metadata is created, and how much of it is
stored?
How easy can the messenger be taken offline?
Can the messenger intercept my data if it was
compromised or malicious?
Do I want to self host my messenger, or, would I
prefer a trusted third party unaffiliated with the messenger hosted my
data?
Is my IP hidden from the messenger host and/or from
the person I’m messaging?
Can my device be online 24/7, or, can I wait for
messages to be delivered?
How much data do I want to be in control of?
Centralized Messengers
Alright, now we can start getting into the three types of messengers,
starting with centralized messengers. These function when you register
with a centralized service which handles the distribution of messages.
In this case, the message would be encrypted on your device so only
your recipient can read the message, the message would then be sent
from your device through an ISP to the messenger host, which accepts
the incoming message. The messenger then holds on to the encrypted
message, but cannot read it, until it sees the recipient is online
where it send it through the recipient’s ISP to their device before
their device (and only their device) de-crypts it and reads the message.
A good example of this centralized messengers is Signal, which I’ll use
to demonstrate it’s pro’s and cons. First, like in Signal’s case, it’s
really easy to set up an account. You don’t need to try to host
anything or have a process on your device running 24/7, you just
register and Signal handle’s all the legwork in the background. It also
will hold any messages you send, and will deliver them the second the
recipient is online. With a server routing the messages the IP address
of the message sender is also not revealed to the receiver of the
message.
However, there are also some drawbacks with centralized messengers.
First off, when you register they usually require identifying
information, such as a phone number or email. Similarly, centralized
messengers by their nature get all of your metadata. Whether they store
it or not, because of their structure they get data such as when
messages come in, their size, times the user was online, and which IP
they connected with. Now, because centralized messengers have such a
weak point this is often a focus of their goals to store as little of
this information as possible, again using Signal as the example, they
seem to do well with it; but it’s inherent in their structure so it’s
still a risk since you are trusting all of your data to the people who
run the messenger.
Last, a centralized messenger is likely the easiest to compromise or
shut down. Even though a messenger is end to end encrypted, if the
messenger was compromised or malicious even though the data is
encrypted you could really be sending them to be unencrypted by the
server, which then re-encrypts the and sends it to the recipient (known
as a man in the middle attack). With that said, using Signal as an
example, though I haven't reviewed Signal’s code I doubt it would be
easy for Signal to be compromised by a man in the middle attack; but
it’s technically possible and may be more likely depending on the
centralized messenger of your choosing. Regardless, however, it’s still
the easiest form of messenger to block/attack, as Iran did with Signal
not that long ago since it’s one centralized group they had to block
instead of a loose and ever changing group of devices.
Self Hosted Messengers
Next, let’s talk about federated and self hosted messengers. Now, I
don’t mean to be confusing, since some messengers can fall into one
category but not the other, but lets break this down as well. Network
wise, these messengers work exactly the same as a centralized
messenger, data travels from a device to a server or group of servers,
which then route the message to the intended recipient. In this case,
however, the server is not operated by the messenger developers but
instead you or a third party.
Being self hosted or hosted by a third party is true of both self
hosted and federated messengers, however, being federated means that it
can communicate with other unaffiliated servers. This operates just
like email in where anybody can get a domain and a server, then can
send a message to anybody else who is using the same platform
regardless of whether they are on the same server or not. For example,
I could set up messanger1.com with Matrix and then register the account
member@messanger1.com. Then, somebody else could set up a server at
messanger2.com and the account on it member@messanger2.com and despite
the servers being hosted by different people the accounts on the
different servers could message each other or join the same groups.
So, what are the pros and cons of using a self hosted federated
messenger. More often than not, if you’re going to go through the
trouble, (in my opinion) federated self hosted messengers would likely
be the right choice because it’s nice to be able to talk people outside
of those to others you’ve invited to your server – but if you do end up
hosting a non-federated messenger then just disregard the applicable
federated pros/cons.
Firstly, the biggest benefit of self hosting systems is the fact that
you are in control of your data, or presumably, you have delegated
control to somebody who is trusted. In either case, you don’t need to
worry about what some unknown group is doing with your data. Similarly,
while it likely won’t prevent the government from giving a subpoena to
your ISP, hosting provider, and/or domain registrar – or from somebody
who has hacked into the server or those services from obtaining such
info, there would be no requirements to hand your personal details over
to other users of the service such as a phone number or email address.
Additionally, unlike centralized messengers, anything self hosted (be
it federated or not) is really hard to block or attack on a mass scale.
Sure, it’s easy to block one company and shut down everything, but it’s
really hard to find everybody who’s hosting a small server for their
family and get them to stop – even if that small server can communicate
with any other small and large servers on the network.
Last, similar to centralized messengers, the server does all the heavy
lifting. Once a server is set up all that you would need to do is
download an app, sign in, and use the messenger. If the intended
recipient isn’t online it will store the encrypted messenge and pass it
along once they’re online. Having such a setup where the server handles
the routing of messengers also prevents the IP address of the senders
device from being revealed to the receivers device.
There are, however, some drawbacks to this sort of messenger structure
as well – the first of which is cost and time. In the case of self
hosting, you will likely need a domain, and definitely will need to
either set up a home server and get a static IP or pay for a VPS.
The other main drawback to these messengers is metadata. Centralized
messengers often focus really hard on minimizing metadata, such as the
date of a message, size of a message, and who it’s going to; however,
the self hosted messenger projects often focus less on that. The
expectation is that if you’re self hosting then you’re the only one
with access to it, but that’s not always the case and one of the
biggest complaints about the federated messenger platform Matrix.
First, if you’re relying on a host that you are not providing and that
you don’t personally know the provider (say through Matrix.org) then
you can only trust them as much as you can trust any other centralized
provider, except there’s more metadata being stored. Similarly, if you
regularly message people on other servers, even if you run your own
server, the other server receiving messages from accounts on your
server is also getting the same metadata – while the other server is
presumably not in your control. While the message itself is still end
to end encrypted, and the dangers of metadata against your privacy are
largely dependent on the situation you are in, at the end of the day
more data you in other people’s hands you don’t necessarily trust is a
risk to privacy.
P2P Messengers
Last, there are peer to peer messengers. Unlike in centralized, self
hosted, or federated messenger, there are no servers involved in peer
to peer messengers. In this case the device which intends to send a
message looks to see if it can locate the device that is receiving the
message (usually through DHT), and then, if the recipient device is
online then it is sent strait to it without any servers involved aside
from ISPs.
Like with the other messenger structures, let’s start the pros and cons
with the benefits. First, there are no worries about metadata (aside
from general ISP logging). Since there’s no centralized server to route
messages, the sender and the receiver are the only ones to hold such
data, so as long as you trust the other person you’re messaging then
there’s no metadata being put in third party hands while also not
having to set up and operate any sort of server.
Next, there’s no need to worry about registering with identifying
details like a name, email, or phone. Since it’s decentralized it will
pretty much be guaranteed to require nothing but a private/public
key-pair generated on the device with no identifying information
whatsoever.
Last, it’s extremely hard to block or otherwise shut down peer to peer
messaging services. Not only are there no one group of centralized
servers, but there’s not even home servers or the like, it’s just a
bunch of random devices communicating with each other.
There are, however, drawbacks to such a messenger structure. First, and
likely the largest, is the fact that any messages sent cannot go
through unless both the sender and receiver have an internet connection
at the same time. Secondly, since there are no central servers routing
messages, the IP address of the sender is known by the receiver and
vice versa. IP addresses can be hidden by routing data through Tor like
the messenger Briar does; however, routing through Tor makes the
messenger easier to block and also prevents audio/video calls.
Last, because peer to peer messengers generally rely on DHT and
private/public key-pairs there’s no easy usernames. In this case, with
math and DHT, you would get your long username of random numbers and
letters and share it through a QR code or by copy pasting, then
somebody else would import it into their contacts and set it’s name.
Once the name is added to contacts it then becomes super easy to use,
but it’s still more complicated to get set up then a simple username or
email.
Quick Tangent
If you want to direct information to
a device, you need some way identify it, and then translate that
identification to it’s IP address. This, however, requires devices to
agree on one method of identification. Generally speaking, it can be
done in three different ways:
* You can delegate human memorable
identifies to a centralized service, just like ICANN who has ultimate
authority on which standard domain names point where. People then rent
domains according to the rules put fourth by that centralized service.
* You can delegate human memorable
identifies to a decentralized service like a blockchain, such as crypto
based domain names. In that event, you would use crypto to purchase an
unclaimed domain and update the decentralized ledger with location you
want it to point to.
* You can use math to generate
private and public keys, and then share those public key (or the hashes
of those) to a distributed table like Tor or I2P domain names. Those
keys can be generated by anybody anytime for free, but are long and not
human memorable.
P2P messengers generally use the
third for functionality, but those identities must copied and pasted or
shared with something like a QR code.
Summary
Well, that’s all in regards to talking about messenger structures. The
different structures of various messengers, as well as the different
ways you can use them, make them almost impossible to compare unless
you look at your specific needs. Now, hopefully when looking at your
messenger options you can understand how it will work and make the
right choice including structure in the qualities you compare it on. I
wrote this to help you understand what your options are and make your
own decisions, and this is where you can close this tab now if you
want. That said, I felt it wouldn’t be complete if I didn’t quickly go
over what I would personally choose for messengers in a handful of
situations.
My personal messenger highlights (as
of 2/4/23)
:
* If you want a messenger that is super easy to use and share, Signal
may be a great choice.
* If you want a centralized style (*see notes) messenger that does not
require any identifying information, Session may be a great choice.
* If you want to self host, and be able to join groups or message
anybody who is on the same platform, Matrix may be a great choice.
* If you want a lightweight self hosted messenger to message people
only on your server – or federated with a small list of handpicked
servers, XMPP may be a great choice.
* If you want a P2P messenger that allows voice/video calls, or Tor is
at risk of being blocked, then Tox may be a great choice.
* If you want a P2P messenger that hides your IP via Tor, or want to
message through Bluetooth or LAN in addition to through the internet,
then Briar may be a good choice.
*Note on Session
Session is not exactly a centralized
messenger. Session is run on the decentralized Oxen network, formerly
known as the Loki network. The Oxen network anonymizes your IP through
onion routing and then locates your device like a peer to peer
messenger would. However, the Oxen network will hold onto the message
on behalf of the sender until the recipient comes online – so even
though it’s structure is probably closer to a peer to peer messenger
then a centralized messenger, it operates from the users perspective
like a centralize messenger.
All content in /tutorials is
licensed Creative Commons
Attribution-Share Alike
unless otherwise specified. Feel free to share it around and re-use it,
but please give me credit if you do so (and would love if you sent me a
message or something). You can also
send me a tip if you found this helpful, but no
pressure - this is a hobby.
Contact Me:
Mastodon @natebowie@mastodon.social
Twitter @NathanBowie6