xmpp-site/articles/x-as-in-freedom.md

# X as in Freedom #

> This text has been through *tentative* peer review by XSF members as well as
> a handful of IT and security specialists, but has *not* been reviewed in-depth.
>
> If you spot any mistakes, please [reach out](xmpp:security@phryk.net).

## Why dissidents have ample reason to use XMPP ##

Here at **phryk evil mad sciences, LLC** we get awfully frustrated whenever
leftists talk about secure messaging and extoll the virtues of *Signal*
and *Telegram* but don't even mention **[XMPP]** – the e**X**tensible 
**M**essaging and **P**resence **P**rotocol.

A grave injustice we aim to rectify in this text.

[XMPP]: https://xmpp.org/


## XMPP – a comparison ##

Let's get the executive overview and see how **XMPP** compares
to messaging solutions currently recommended in leftist circles;
Namely *Signal*, *Telegram* and *Matrix*.

For this comparison we chose only qualities that are relevant to
security, reliability and resilience – y'know stuff that *miiight*
be relevant for dissidents in the sort of cybrepunk dystopia we
somehow found ourselves in.

| Feature                       | XMPP    | Signal | Telegram     | Matrix  |
|-------------------------------|---------|--------|--------------|---------|
| Decentralization              | YES     | NO     | NO           | YES     |
| Strong E2EE                   | YES[^1] | YES    | NO[^2]       | YES     |
| Identity compartmentalization | YES[^3] | NO     | NO           | YES[^3] |
| Open standard                 | YES     | NO     | NO           | YES     |
| Extensibility                 | YES     | NO     | NO           | NO      |
| Strong ecosystem              | YES     | NO     | NO           | YES     |

[^1]: Via [OMEMO], [OpenPGP] and – historically – [OTR].
[^2]: Non-standard cryptographic protocol and only in direct messaging; "Secret" chats are not End-to-End encrypted, see [telegram manual](https://tsf.telegram.org/manuals/e2ee-simple).
[^3]: Possible when using the service **exclusively** via [TOR], *including for registration*.

[TOR]: https://torproject.org
[OpenPGP]: https://openpgp.org/
[OMEMO]: https://en.wikipedia.org/wiki/OMEMO
[OTR]: https://en.wikipedia.org/wiki/Off-the-Record_Messaging

If you know what all of this means – congratulations, you're done here!
Get yourself a cookie and pat yourself on the back, you're extremely
well informed.

For the rest of us, let's break down what all of this means, shall we?


## Tech Terminlogy Turnips ##

First, we need to make sure we're on the same page with a couple of terms.

### Server ###

A piece of software that provides a service over the internet. Common examples
are web- and mailservers but also ones people don't usually interact directly
with, like servers used to look up domain names like `chat.phryk.net` ([DNS])
or clock synchronization ([NTP]).

### Client ###

A piece of software made to communicate with a certain kind of server.
Common examples include browsers, e-mail programs and most messenger apps.
Diagrams on this page will depict clients using this triangly boi:
<img class="inline" title="I'm pointy!" src="/resources/diagrams/client.svg" />

### Protocol ###

An agreed-upon (usually standardized) way for software  to exchange data.
Basically the language that *clients* and *servers* use to talk to each other
in a way they understand. **XMPP** is a *protocol*. Another one is [HTTP] which
your browser and our server communicated in to deliver you this website.

To summarize in our context: **XMPP** is the *protocol* the [Prosody] *server*
running on this machine uses to talk with the chat programs used to access
the messaging features offered by it and these chat programs are **XMPP** *clients*.

[Prosody]: https://prosody.im/

### Encryption ###

Encryption is the act of making data unreadable to anyone but the intended
recipient of it. This is usually done by leveraging unsolved math problems.
Much of todays encryption is based on the unsolved problem of factorizing
the result of multiplying two large prime numbers – for computers, it is
trivial to multiply two large primes, but no algorithm to determine the
two primes used from only the result exists.

> Technically this is not exactly true. There is a known [quantum algorithm],
> that *might* be able to solve this problem, but current quantum computers are
> still far removed from running practical attacks. As this might change
> in the future, cryptographers have been actively working on inherently
> "quantum-safe" encryption schemes, an early example of which might be
> [Keccak].

[quantum algorithm]: https://en.wikipedia.org/wiki/Grover%27s_algorithm
[Keccak]: https://en.wikipedia.org/wiki/SHA-3#Security_against_quantum_attacks

### Compromise ###

When a computer is taken over or privileged access is gained
by malicious actors, we say the machine is *compromised*.

Comes in two basic flavors:

*   *Data* compromise: When data is exfiltrated from a running machine or the
    machine is taken offline for forensic analysis and has its data extracted
    (trivial if the machine is set up without disk encryption).
*   *Operational* compromise: When a machine is compromised and kept running.
    When done by state organizations, the goal is usually to identify and
    de-anonymize the users of services provided by said machine.
    An operational compromise always implies a data compromise.

### Vulnerability ###

A *vulnerability* is a special type of software bug that allows a would-be
attacker to do things with the software they aren't authorized to do. They
can range from inoccuous things like "allows users in the same network to
make the computer go *beep!*" all the way to "[allows users in the same network
to make centrifuges for nuclear enrichment explode][stuxnet]".

[DNS]: https://en.wikipedia.org/wiki/Domain_Name_System
[NTP]: https://en.wikipedia.org/wiki/Network_Time_Protocol
[stuxnet]: https://en.wikipedia.org/wiki/Stuxnet

Now, that we have that out of the way, let's dive in and untangle things.

## Decentralization ##

Decentralization means multiple things.

**Firstly**, the distribution of authority and control within a system.
This means that no one entity can decide over how and by whom a system
is used and leads to decentralized systems being much more resilient
to coercion by powerful actors like the pigs and "intelligence" orgs.

Simply put, it's easy to coerce one CEO, but coercing thousands of people
who run a network independently from each other in all parts of the globe
is a different story.

This is opposed to what we see on virtually all commercial[^*] online
communication services, which can be visualized like this:

[^*]: Do not confuse being a commercial service with charging a monetary price for
use. Services like WhatsApp, SnapChat and TikTok are very much commercial,
they're just "free" for you because *you* aren't their customer, but their
*livestock*. Your data is the product and shady organizations of all kinds
are their *actual* customers.

<section class="wide">
    <img src="/resources/diagrams/centralized.svg" />
</section>

Here, we can see how everyone (<img class="inline" title="I'm feeling talkative!" src="/resources/diagrams/client.svg" />)
has to go to **the one true authority** for a service they want to use,
like for Twitter, Discord or Spotify.

This authority can freely decide who gets to participate – *and to what degree*.
It can exclude people entirely or decide with what and whom they can interact.
From hiding posts that are inconvenient like labor abuses perpetrated by said
authority to censorship of LGBT++ issues to large-scale algorithmic
manipulation of information like defining "[filter bubble]s" for people,
this central authority can dictate who gets to see and do what.

Secondly, decentralization on a technical level means the distribution of a
system over multiple machines. For this, **XMPP** uses an approach called
*federation*, which looks like this:

<section class="wide">
    <img src="/resources/diagrams/federated.svg" />
</section>

As you can see, the system is split over a bunch of different servers, that
communicate with each other (that's those thicc green lines), in order to
facilitate interactions beyond the particular server someone uses – an
approach you might already be familiar with from e-mail, where you can send
e-mails between accounts on [riseup.net] and [disroot.org] without a problem.

This is also one of the reasons why **XMPP** addresses look exactly like
e-mail addresses.

> Did you know that [disroot] provides both e-mail *and* **XMPP** services?
> You can get the same address to be reachable through both mediums!

This sort of decentralization makes the **XMPP** network more resilient against
destructive interference (think government takedowns), since the network itself
has no single point of failure.

Short of global thermonuclear war, a monstruous solar flare frying all
electronics on the planet or a global collapse of the internet, the powergrid
or *both*, we are not aware of any threat that could really destroy a network
like this. And even *in* these cases, a decentralized network will fare better
because pockets of it can survive and eventually reconnect.

Technically, many commercial[^*] services look a bit like this under the hood
nowdays, being **technically** *somewhat* decentralized. The key difference is that
these services still act like the first diagram when it comes to authority and 
control, thus enabling an absolute dictate of what is sanctioned on their
platform and introducing an organizational single point of failure that is
beholden to the powers that be.

**XMPP** is better than that because it is decentralized in technology *as well*
as in authority and control. We can't dictate to the good folks at [disroot]
that they have to ban someone from their service or vice-versa. We can, however,
collaborate and for example share information on known threats in order to
help keep the people who entrust us with their private communications safe.

> The techies among you might now be a bit disappointed, that we didn't tout
> P2P as the most bestest mode of decentralization, but while it's true that
> it's the most technically resilient, it also makes a lot of problems like
> moderation much, **much** harder to solve, if not just outright placing the
> whole onus for it on everyone using it. We do think secure P2P messengers
> are a great boon for clandestine affinity groups, but at least for now not
> a good way to build community.

[riseup.net]: https://riseup.net/
[disroot]: https://disroot.org/
[disroot.org]: https://disroot.org/
[Delta Chat]: https://delta.chat
[filter bubble]: https://en.wikipedia.org/wiki/Filter_bubble


## Strong E2EE ##

End-to-End Encryption, also shortened to E2EE, refers to encryption of data
enacted at the two endpoints of a communication. This means the contents of
said communication won't be readable by any of the machines involved in
transmitting it.

<section class="wide">
    <img src="/resources/diagrams/e2ee.svg" />
</section>

This differentiates it from transport encryption like TLS, which you already
know – it's what's used whenever you access a site via `https://` like this one.
Transport encryption is enacted between client and server; meaning the server
can read the contents of communications between clients.

<section class="wide">
    <img src="/resources/diagrams/transport-encryption.svg" />
</section>

When just browsing a website to read something, this isn't a problem
and transport encryption is exactly what you want in that case – but as
soon as you have people communicating over a service, having only
transport encryption means that all communications exist in plainly
readable form on the server. An example of this would be the Twitter DMs,
which Twitter can and will give to state agencies and probably runs
automated analysis on to build more extensive profiling data of you.

E2EE is an **essential** feature for private communications.

**XMPP** offers a selection of not one, not two, but *three* different E2EE
schemes!

### OTR – Off The Record ###

Today, OTR is largely a historic thing, at least in the **XMPP** space.
It bears mentioning tho – for one, because there still are clients like
Gajim that support it; but also because it was the first widely deployed
cryptographic protocol that included *plausible deniability* as a feature.

> ***Plausible deniability*** means that even if a communication from you is
> decrypted, it can't be technically proven that you were the one
> actually sending it.

It should also not be considered secure by todays standards,
especially when dealing with state-actor adversaries.

> If you *must* have a techie explanation for this, it's because of a static
> key size of 128 bits and reliance on the SHA-1 hash algorithm that isn't
> considered collision-safe anymore.

OTR only works for direct messaging – i.e. not for chatrooms, file transfers
or calls.

### OpenPGP ###

Even today, PGP – the grandaddy of E2EE – is not obsolete and enjoys a
venerable and versatile existence – not only for E-Mail, but also for
encrypted storage, various communications services and, of course, **XMPP**.

Cryptographically sound and well-audited, PGP has truly stood the test
of time – for 30 years now.

*Plausible deniability* is **not** one of its features – in fact it
was created with the goal of being able to assure without a doubt who
you are and as such is probably the closest thing to trustworthy, legally
binding digital signatures out there.

The support situation of PGP in **XMPP** clients is a little messy as there are
two different ways of going about it with most clients that *do* support PGP
using the older one and often (reportedly) don't support the previously
mentioned identity assurance.

OpenPGP works for direct messaging, but more advanced features like
encrypted chatrooms, file transfers and calls are currently either
completely unavailable or not widely supported.

### OMEMO ###

For the last couple of years, this has been where the cool kids play.
In essence, *OMEMO* is a copy of the *cryptographic protocol of Signal*[^-].
In this regard it's similar to what *Matrix* is doing.

[^-]: Not to be confused with Signals network protcol. Sorry if that's confusing – tech often is.

This is good praxis – as the first rule of cryptographic engineering is
to "never roll your own" cryptographic protocol (hello, *Telegram*!) or,
even worse, encryption algorithm.

Additionally, Signals cryptographic protocol is one of the most
well-audited and generally looked at cryptographic protocols out there.

*OMEMO* is also the only E2EE solution for **XMPP** that works not only
for direct messaging and chatrooms, but also for file transfers and calls.

This, combined with  the fact that – unlike OpenPGP – *OMEMO* offers
*plausible deniability*, is why we currently recommend the use of
*OMEMO* for the E2EE needs of dissidents.


## Identity compartmentalization ##

*Anonymity* is commonly used to denote that the real-life identity of a
communications' sender is unknown.

Extending on that *true* anonymity – loosely paraphrased – means that it's
mathmatically impossible to figure out the real-life identity of the sender
from captured data. In short, this is what you want if you expect being
specifically targeted by state-level actors (i.e. not just by regular
mass surveillance).

> Linguistically, one could make the point that most things that are called
> *anonymous* should actually be called *pseudonymous* since they usually involve
> an identity that allows connecting different communications from the same
> sender. For the purpose of this article the difference in meaning is
> negligible, so we use the word *anonymous* the way it's commonly understood.

> If you want to know about how this distinction can actually make a
> difference, hit us up and we'll tell you all about affinity groups,
> decentralized sabotage and the propaganda of the deed. 😇

With that out of the way – *Identity compartmentalization* is how you achieve
*true* anonymity and describes the management of multiple independent identities
that can't be connected with each other by outside observers.

At the most basic level, practicing *identity compartmentalization* means
never creating any link between the identity to be protected and any
other held by the same person or group.

Today, basically all commercial[^*] services (as well as *Signal* and *Telegram*)
require providing at least one unique personal identifier that can be expected
to be easy to connect with your real-life identity – usually this is your
mobile phone number or e-mail address.

For services operating under the principles of [surveillance capitalism],
these identifiers are extremely valuable. This is especially true for phone
numbers as those can be used to connect online identities to peoples legal
identity with near-perfect reliability – even more so when we consider
widespread bans on anonymous SIM cards.

[surveillance capitalism]: https://en.wikipedia.org/wiki/Surveillance_capitalism

> As an aside, please do *not* expect "anonymous" SIM cards to protect
> your identity by themselves. Every SIM card is uniquely identifiable
> via its [IMSI] and every phone through its [IMEI]. Additionally,
> mobile phones (including "dumbphones") enable constant location tracking.
> To use an "anonymous" SIM card efficiently, you must *never* use it in
> a phone registered to your name and never at locations you frequently visit.
> The relevant data for this is already known to be given out by mobile service
> providers to state organizations. We might put out an [OPSEC] guide at some
> point going into this in more detail.

[IMSI]: https://en.wikipedia.org/wiki/International_mobile_subscriber_identity
[IMEI]: https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity
[OPSEC]: https://en.wikipedia.org/wiki/Operations_security

But when you're not beholden to the InCeNtIvE pReSsUrEs of surveillance
capitalism, you can just forego this data – after all…

<img 
    src="/resources/dank-memes/rollsafe-lessdata.png"
    title="rollsafe dot jaypeg: CAN'T LEAK DATA – IF YOU DON'T HAVE IT" />

And so, **XMPP** doesn't require you to provide any such identifier – a central
point in enabling people to create *truly* anonymous identities.

While this is more or less all that's needed for *true* anonymity on the protocol
side, actually achieving this level of anonymity necessitates more on the part
of the people using the service.

In short:

* **always** access the service through [TOR], *including for account creation*
* **never** communicate your real identity through the anonymous one
* keep your device free of malware
* avoid physical surveillance when using the service

> [TOR] is a tool to anonymize people on the internet. It works by
> passing data through multiple, randomly chosen intermediate machines
> on the internet.

## Free & Open standard ##

Like the technical specifications that standardize the web, the **XMPP**
[specification][xmpp-spec] and all of its [extensions][xmpp-xeps]
are publicly viewable for free.

The body governing **XMPP** is the [**XMPP** Standards Foundation][XSF],
usually called **XSF** for short.

[XSF]: https://xmpp.org/about/xmpp-standards-foundation/

Membership at the **XSF** is not needed to collaborate on the improvement
of **XMPP** – but if you *do* want to become a member, applications are open
to anyone actively working in the wider **XMPP** ecosystem, so collaboration
is *largely* possible independently of the usual axes of discrimination
like class, gender, race or sexual orientation.

> "largely" mostly because we're assuming that the **XSF**, like pretty much
> everything in tech, has a "representation problem". We are currently not
> an **XSF** member but might become one in the future. That said, our own
> impression of the **XMPP** community has been that it's a very welcoming space.

Standardization is done publicly, ensuring transparency so the risk
of bad actors smuggling in trojan horse "features" is counterbalanced
by all the privacy-minded hackers out there who would immediately cry
foul and probably set up an alternative standardization organization
for **XMPP** within a week should such a thing ever happen to one of
their favorite means of communication.

Furthermore, building software using these specifications does
not incur any licensing costs, which – let us assure you – are
a very real thing. They are just one of the many ways in which
"intellectual property" holds humanity back.

For these reasons **XMPP** is an extremely good fit for [Free & Open
Source Software][foss], which is essentially the only kind of software
[you can have any trust in][foss-trust]. 

From the roster of services we're looking at here, *Matrix* is the only
contender also coming defined as an open standard.

[xmpp-spec]: https://datatracker.ietf.org/doc/html/rfc6120
[xmpp-xeps]: https://xmpp.org/extensions/
[foss]: https://en.wikipedia.org/wiki/Free_and_open-source_software
[foss-trust]: /article/foss-socialism#trust


## eXtensibility ##

What *Matrix* doesn't have is a built-in extension mechanism in its spec.
This means that for every single new or changed feature, a new version
for the whole specification has to be released.

**XMPP** on the other hand, keeps its core specification slim, but defines
such an extension mechanism, allowing for broader experimentation and
gives the ecosystem a dimension of direct democracy by what extensions
the people writing the servers and clients as well as those running
**XMPP** servers choose to support.

This, we argue, leads to a strong ability to evolve the network into
new and unexpected directions and thus offers a greater capability for
it to adapt to new threats and challenges – in other words to keep
meeting peoples' needs in an ever-changing landscape.

You might have heard about [Jitsi] and it's a great example for this
in action. Jitsi is based on **XMPP** but extends it in ways which are not
standardized, meaning Jitsi services aren't usable with normal **XMPP**
clients (except for text chat). This has inspired the community to
collaborate on a set of extensions to bring the same features to the
wider ecosystem. Now, the first **XMPP** clients have integrated audio
and video calls with *OMEMO* encryption with encrypted a/v conferencing
slowly appearing on the horizon.

[Jitsi]: https://jitsi.org/


## Strong ecosystem ##

While *Signal* and *Telegram* have some third-party clients which,
to the best of our knowledge, aren't being persecuted out of
existence, they're likely never going to be officially supported.

This is yet another way in which most messaging solutions introduce a
single point of failure. With only one client and server implementation,
any vulnerabilities found in them are much more valuable for attackers
because every single user on the network is vulnerable at once.

**XMPP** and *Matrix* have a diverse software ecosystem supporting them
with multiple server and client implementations each, eliminating
this single point of failure.

When a critical vulnerability in the *Signal* or *Telegram* clients are found you
can't securely use these services until the vulnerability has been fixed in
the client. With **XMPP** and *Matrix* you can just switch to a client or server
that isn't affected by whatever the vulnerability of the day is.

Oh, did we mention that using multiple accounts in parallel is routinely
supported in all common **XMPP** messengers? If you are worried about staying
reachable, it's easy to have accounts on a bunch of different **XMPP** servers
and use all of them on all your different devices running different clients
*at the same time*.


## Caveats ##

There are of course also downsides to choosing **XMPP** over other messaging
solutions, with the one which is probably making itself felt the most being
that some newer or more advanced features like (end-to-end encrypted) audio
and video calls or stickers aren't supported over by all clients (and servers).

It's easy to overlook – especially if you're coming from a background of only
commercial[^*] solutions – that like most other *Free* and *Open* endeavours, the
**XMPP** ecosystem is created and maintained almost entirely by volunteer labor
and won't ever be able to give you the same level of polish as a multi-billion
dollar corporation, especially when considering that this labor is split up
between all the different clients and server implementations and not
centralized on just one of each.

> If you don't see why lefties should suck it up and bear with a **slightly**
> worse user experience to gain privacy, you should probably read up on what
> the fuck is actually happening in the technology space and what sorts of
> threats leftist dissidents can face.
>
> A couple good starting points to get you clicking through Wikipedia:
>
> * [Global surveillance disclosures (2013–present)](https://en.wikipedia.org/wiki/Global_surveillance_disclosures_(2013%E2%80%93present))
> * [ECHELON](https://en.wikipedia.org/wiki/ECHELON)
> * [Big Tech](https://en.wikipedia.org/wiki/Big_Tech#Opposition)
> * [Surveillance capitalism](https://en.wikipedia.org/wiki/Surveillance_capitalism)
> * [COINTELPRO](https://en.wikipedia.org/wiki/COINTELPRO)
>
> Please realize that by exclusively using privacy-breaking services, you
> are not only compromising your own privacy, but also that of your friends,
> families, lovers and comrades.

Luckily, with [Conversations], **XMPP** has an amazing client on the forefront
of what can be done with **XMPP** right on the most common operating system on
the planet: Android.

For most "real" computers, **XMPP** has [Dino] which isn't very far behind
and has quickly become one of the major players of the ecosystem.
We wholeheartedly recommend it.

And if you absolutely need ALL THE FEATURES, [Gajim] totally has your back.

On a security-related note, to our understanding XMPP services currently have
the choice between keeping peoples' contact lists on the server or breaking
some aspects of multi-client support, including for *OMEMO*.

The problem with this is that in case of a compromise, your entire contact
list would be known to the attacker. While this is true of most instant
messaging services (with the notable exception of *Signal*), it is still
something to keep in mind.

> We're looking to work on this aspect, but haven't read enough of the
> relevant extension specifications yet to properly reason about the
> technical feasibility and involved challenges.

[Conversations]: https://conversations.im/
[Dino]: https://dino.im/
[Gajim]: https://gajim.org/


## A bit of information on security audits ##

*OMEMO* as well as (parts of?) *Matrix*' cryptographic protocol have both been
through a security audit – which is a fancy way to say they were analyzed
for flaws by security experts. While this is an important step for any
cryptographic protocol to reach maturity, these are often misunderstood.

A security audit is neither an assurance that something is secure nor does
it mean any of the issues reported in them are still around. They are an
important tool to improve security – nothing more, nothing less.

If you're a curious and inclined techie, you
can read the results of these audits here:

* <https://conversations.im/omemo/audit.pdf>
* <https://www.nccgroup.com/globalassets/our-research/us/public-reports/2016/november/ncc_group_olm_cryptogrpahic_review_2016_11_01.pdf>


## Closing words ##

A key point resulting from many of the aspects we discussed here is that
unlike most commercial[^*] messengers (as well as *Signal* and *Telegram*!), **XMPP**
does not force you to have a mobile phone involved *at all*.

This is **extremely** relevant since carrying around a mobile phone means your
location is continually trackable. We know that this data is being shared
with state organizations in the wake of the COVID-19 pandemic and we also
know that this data is used for largely automated "targeted" killings with
drones.

> If this sounds overly dramatic to you, please watch the talk
> [The Global Assassination Grid] by US Air Force whistleblower
> Cian Westmoreland, ponder the adage of *"One man's terrorist
> is another man's freedom fighter"* and realize that a) not all
> of our comrades live in The West™ and b) circumstances change
> with signs not exactly pointing to global peace for the future.

[The Global Assassination Grid]: https://media.ccc.de/v/33c3-8425-the_global_assassination_grid


This mass surveillance of virtually everybody's movements is, in our honest
opinion, one of the most worrying (and dystopian) developments of the century.

In this context, the wide reliance on phone-bound messengers acts not 
only to keep people trackable, but also to coerce people who wouldn't
normally use them to *make* themselves trackable or face broad social
exclusion – in other words, if you're only reachable in a way that
requires a mobile phone, you require others to give up privacy to
contact you and thus reinforce the systemic erosion of liberties
through mass surveillance.

Concerning *Matrix*, we would like to point out that we chose **XMPP**
over it not only because *Matrix* lacks an extension mechanism, but
also because it tries to do datastreams on top of [HTTP]. HTTP is
inherently pull-based, but built on top of TCP which is explicitly
designed to handle datastreams – this means *Matrix* had to re-invent
datastreams which duplicates a lot of effort, adds overhead in
computation and bandwidth while also introducing a new venue for
bugs and vulnerabilities. Additionally, most *Matrix* clients are
fucking [Electron] apps, which basically ship an *entire fucking
browser* which hogs an insane amount of resources and is *always*
outdated and thus much more likely to contain known vulnerabilities.

*Signal*-wise, unless you actually want to get rid of your mobile
phone to avoid the constant location tracking, we don't advocate
you necessarily get rid of it, but rather that you should also
have a secure messaging solution that *isn't* bound to your phone.

As for *Telegram*… don't use it? 🤷

[HTTP]: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
[Electron]: https://en.wikipedia.org/wiki/Electron_(software_framework)


## Honorable Mentions ##

While **XMPP** is what *we* espouse, we do think there are other messaging solutions
more leftists should know about:

* [Deltachat] is *Free & Open Source Software* for E2EE messaging based on
e-mail with integrated creation of burner e-mail accounts
* [Tox] is a free and open protocol for peer-to-peer (serverless) E2EE messaging

[Deltachat]: https://delta.chat/
[Tox]: https://tox.chat/