Is WhatsApp Really Secure? The Problem of the Endpoints You Don't Control

WhatsApp series, 2/2. In the first article I told the story of how I nearly lost eleven years of messages because of a backup WhatsApp itself could not restore. When I asked for the key to my own file, support replied with the marketing copy for end-to-end encryption: "no one else, not even WhatsApp" can read your messages. That sentence is what this article is about.

TL;DR — I don't have time to read such a long text right now

WhatsApp keeps repeating that our conversations are protected by "end-to-end encryption" and that, therefore, "not even WhatsApp" can read them.

End-to-end encryption is real and it is a very important protection. But that claim hides a fundamental condition:

encryption protects the communication between the endpoints, but it does not guarantee that the endpoints themselves are trustworthy.

And "the endpoint" is not exactly you. It is the program running on your phone or computer.

If the provider controls that program, can update it, can decide which versions keep working with its service, and you cannot independently audit the binary you run, then you still need to trust the provider.

The thesis of this article is therefore:

No E2EE system can provide a strong guarantee against the provider itself if the user cannot know exactly what code the endpoints run, verify it, and — in the most demanding model — compile it and control when it gets updated.

This does not prove that WhatsApp spies on our messages, nor that a back door exists for governments or intelligence services.

It proves something more modest but important:

We cannot turn the claim "WhatsApp says it cannot read them" into the technical property "WhatsApp could not make our endpoint hand them over".

The difference is between trust and verification.

"Not even WhatsApp can read your messages"

One of WhatsApp's main privacy promises is end-to-end encryption, usually abbreviated E2EE.

The principle is excellent.

When Alice sends a message to Bob, the message should be encrypted on Alice's device and not decrypted until it reaches an authorised device belonging to Bob.

Simplifying:

Figura 1

This protects against very significant threats.

Someone intercepting the traffic should not be able to read it. A breach of certain servers should not directly yield the content of every conversation either. And the server carrying the messages does not need to know the plaintext.

WhatsApp also states in its privacy policy that delivered messages are erased from its servers, and that undelivered ones are kept, encrypted, for a maximum of 30 days.

All of that is an enormous security improvement.

The problem starts when we transform this claim:

"WhatsApp's servers do not normally have the content or the keys needed to decrypt it."

into this other one:

"WhatsApp could not obtain my conversations."

That is not quite the same claim.

What is "the endpoint", really?

In our imagination, E2EE means:

me  <====================>  you
          E2EE

But technically it looks more like this:

Figura 2

Encryption does not begin directly in my brain, nor end directly in yours.

It begins and ends in programs.

So, after asking:

"Is the communication encrypted?"

we should immediately ask:

"Who controls the program that constitutes each endpoint?"

That second question is the one that almost always disappears from E2EE marketing.

At some point the message has to be in the clear

There is an unavoidable limitation.

If I can read a message on the screen, my device must have decrypted it.

So at some point we have:

Figura 3

Cryptography has finished its job.

From that moment on, security depends on the endpoint.

And that means a hypothetically malicious app would not need to break the cryptographic protocol.

It would not need to brute-force a key.

It would not need to attack the Signal Protocol mathematically.

Conceptually, it would be enough for it to do:

decrypt(message)
display(message)

and, in addition:

send_copy(message)

That is:

Figura 4

The E2EE protocol could remain impeccable.

The server could still be unable to decrypt the ciphertext.

The keys could even formally never leave the device.

But the plaintext has already been obtained by the app.

The encryption has not been attacked. The endpoint has.

And what if the provider itself controls the endpoint?

Here is where WhatsApp's interesting conceptual conflict appears.

WhatsApp tells us:

"Our server cannot decrypt your messages."

But it is the same provider that distributes the program which:

• generates or manages the keys;
• receives the messages;
• decrypts them;
• accesses their content;
• queries the local database;
• displays the conversations;
• and communicates with its servers.

So:

Figura 5

E2EE prevents the server from attacking the cryptographic channel directly.

But on its own it does not guarantee what the software arriving at one of the endpoints will do tomorrow.

"But the app is signed"

Yes.

And that matters a great deal — against a different adversary.

An app's cryptographic signature helps prevent a stranger from building a modified APK and easily passing it off as a legitimate WhatsApp update.

But the signature roughly answers:

"Does this software come from the authorised chain?"

It does not answer:

"Does this software do exactly what the previous version did?"

If it is the same authorised developer publishing a new version, the new program will still be perfectly signed.

Figura 6

Signature and functional trust are different concepts.

"Then I just won't update WhatsApp"

At first glance that might look like a solution.

If I trust version 2.X and don't want anyone swapping it on me, I turn off updates.

The problem is that this only gives you partial control.

You can temporarily stop Google Play from automatically installing a new version, but you do not control WhatsApp's server or protocol.

The provider can change:

• the accepted protocols;
• the minimum supported versions;
• the registration requirements;
• the features that need server-side support.

So you have no guarantee that you will be able to keep using indefinitely an old version you decided to freeze.

That difference is essential:

"I can disable automatic updates" is not the same as "I control which client version will keep working".

In a system genuinely under your control you could decide:

Figura 7

In a centralised service, the server always has the last word on what remains interoperable.

Could they send a special version to just one person?

That is a possibility that needs some nuance.

Google Play offers "staged rollouts", that is, gradual deployments where a new version initially reaches only a percentage of users.

But according to Google's documentation, in ordinary staged rollouts users are chosen at random within the corresponding percentage. It would therefore not be correct to say that Play's normal system simply lets you order:

"Install this special APK on phone number X, exactly."

But that does not solve the general problem.

A program can contain features whose behaviour changes according to information supplied by the server:

• feature flags;
• remote configuration;
• A/B experiments;
• gradual activations;
• account-level parameters.

Figura 8

Naturally, remote configuration can only activate functionality the program is already able to execute.

And we have no evidence that WhatsApp contains a mechanism designed to secretly exfiltrate conversations.

That is not what I am claiming.

The point is a different one:

Auditing the E2EE protocol does not automatically tell us everything the client can do.

Stealing the database key wouldn't even be necessary

Sometimes we imagine an extremely convoluted attack:

1. steal the local database;
2. extract its key;
3. send it to the server;
4. decrypt the conversations there.

But a hypothetically malicious version of the client would probably have a far simpler option.

The legitimate app already needs to read its own data.

If WhatsApp can show you a conversation from six months ago, some part of the client has access to that information in a usable form.

So:

Figura 9

Encryption "at rest" is very useful against other programs, against certain kinds of physical access, or against directly copying the files.

But it does not protect the data against the very program that legitimately needs to decrypt it.

And in WhatsApp's case, the ordinary backup key doesn't even belong to the phone alone: as I describe in the first article, WhatsApp keeps it on its servers and hands it to any phone that verifies the number. To the app, yes. To the user, no.

And it wouldn't even need to send everything

A hypothetical targeted attack would not need to transfer 30 GB of photos, videos and audio either.

Text is very cheap.

In the abstract, one could select:

• the most recent messages;
• one specific conversation;
• text only;
• messages from a given date onwards;
• data about a particular correspondent;
• certain metadata.

This matters because a well-scoped hypothetical endpoint attack could generate very little traffic relative to the ordinary traffic of a messaging app.

WhatsApp Web multiplies the endpoints

The situation is even more interesting now that WhatsApp has a genuine multi-device architecture.

WhatsApp Web is no longer simply a screen permanently dependent on the main phone.

In the multi-device architecture, each linked device has its own identity key and maintains independent E2EE sessions. When a device is linked, the main phone sends it an encrypted portion of the recent history, and from then on the device keeps its own local database.

So:

Figura 10

This is very convenient.

But from a threat-model point of view it means we no longer necessarily have a single endpoint.

We have several devices with:

• their own keys or cryptographic state;
• local data;
• credentials;
• the ability to receive and decrypt messages.

That is why WhatsApp lets you list linked devices and remove sessions.

The general lesson is:

E2EE greatly reduces the trust required in the server, but every authorised device becomes a new place where the content exists in the clear.

"But WhatsApp says it can't give the messages even to the police"

And indeed WhatsApp publicly takes that position.

But it does have a door reserved for the authorities. Literally: WhatsApp's Law Enforcement Online Request System is a portal that only law enforcement officers can log into, to request data as part of an official investigation or an emergency. Meta has an equivalent one for Facebook and Instagram.

There is a certain irony in it: there is a dedicated counter for requesting information from a company that says it doesn't have the information. It is not a contradiction, because what it hands over is account data and metadata, not the conversations. But it neatly illustrates that "we don't have your messages" does not mean "we have nothing".

They explain how it works themselves:

• WhatsApp's law enforcement page: within an official criminal investigation, WhatsApp preserves an account's data for 90 days while the formal legal request arrives.
• Meta's guidelines distinguish three types of request: preservation (90 days), emergency (imminent harm to a child, or risk of death or serious injury, through the same portal), and records requests, which require the corresponding legal process.

And the volume is not anecdotal. In November 2024, in Shabana v. Govt of NCT of Delhi, the Delhi High Court recorded what Meta itself told it. Its request system (LEORS) received more than a hundred thousand data requests in a single year (2023), and emergency ones are answered within minutes: 18 or 30, in cases of missing children. WhatsApp also receives "a substantial number" of ordinary and emergency requests. It has even handed over information about terrorist activity 12 minutes after receiving the request. What they hand over, according to the court, is basic subscriber information: name, email, phone and registration date.

In Europe, Eurojust and Europol's 2024 SIRIUS report counts WhatsApp, alongside Meta, among the providers with their own portal for law enforcement requests.

There is nothing extraordinary about this: large technology companies routinely have procedures for responding to legal requests.

According to WhatsApp's public model, what they can provide depends on the data they actually hold.

The interesting question for this article is a different one.

We can distinguish:

A) "WhatsApp states that its servers cannot
   decrypt E2EE conversations."

B) "We can independently verify that no client
   controlled by WhatsApp could obtain the plaintext."

A does not automatically imply B.

Should we believe it?

Here it is important not to confuse scepticism with accusation.

I have no evidence that WhatsApp distributes special versions designed to let an intelligence agency read conversations.

It would therefore be irresponsible to claim that it does.

But it is not reasonable either to turn:

"We have no proof that it does"

into:

"It is technically proven that it could not."

These are three different epistemological degrees:

Figura 11

Good security architecture tries to move as far as possible from trust towards verifiable guarantees.

Not because any given company is necessarily malicious.

But because a secure system tries to minimise the things we have to believe on trust alone.

This is where "secure" and "verifiable" part ways

WhatsApp can be extraordinarily secure against many adversaries.

For example:

• someone eavesdropping on a Wi-Fi network;
• a telecommunications operator;
• an attacker capturing traffic;
• a particular breach of server infrastructure;
• certain internal administrators.

The problem in this article is much more specific:

What guarantee do we have against the very provider that controls our endpoint?

And here the situation is different.

We can summarise it:

Signal: public code and reproducible builds

Signal offers a good example of a more verifiable model.

Its Android client has public code and supports reproducible builds.

The official instructions explain how to:

1. obtain exactly the code corresponding to a release;
2. reproduce the build environment;
3. compile it;
4. extract the APKs installed on the device;
5. compare them.

The stated goal is precisely to verify that the version downloaded from Google Play corresponds to the published source code.

That is an enormous difference.

Not every Signal user needs to be a programmer.

The mere fact that any independent researcher can check it already makes it much harder to distribute en masse a binary that does not correspond to the public sources.

That said, even this has an important limit.

If your threat model includes an extraordinarily selective attack aimed only at you, the strongest thing would be to verify your own installed APK.

The scale would be:

Figura 12

Each step removes part of the blind trust.

Delta Chat: yet another way of splitting trust

Delta Chat is free software.

On Android there is also an interesting case when it is installed from F-Droid: the F-Droid listing states that each version is built and signed by F-Droid itself and that it is guaranteed to correspond to the published source package.

This introduces a separation:

Figura 13

It does not eliminate all trust.

You also have to trust F-Droid, its infrastructure, Android, and so on.

But at least it avoids the simplest model of:

"The same company writes the code, builds an opaque binary and hands me exactly what it wants."

Telegram: an especially interesting comparison

Telegram needs an important distinction.

Its cloud chats are not E2EE. According to Telegram's FAQ, they use client-server encryption and are stored encrypted in Telegram's cloud so that they are available on every device.

Secret chats, by contrast, do use end-to-end encryption.

So Telegram is not "more private" than WhatsApp by default.

But it is interesting for the question at hand because its clients are open source and Telegram publishes instructions for verifying that the App Store and Google Play versions correspond to the published code.

In addition, TDLib makes it possible to build your own clients, and it also supports secret chats.

That enables a model like:

Figura 14

Telegram could change the protocol.

It could end up rejecting your client.

It could stop serving you.

But if you control the executable you are running, the server cannot simply rewrite it remotely to make it do something else.

That is an important difference.

E2EE is also very convenient for WhatsApp

There is another aspect that is rarely discussed.

The usual narrative presents E2EE as if it were a concession the company makes purely for the user's benefit.

But an architecture in which the provider does not normally keep a readable copy of every conversation is also extraordinarily beneficial for the provider.

As we have seen, WhatsApp says delivered messages are removed from its servers and pending ones are kept temporarily in encrypted form.

That has very favourable business consequences:

Figura 15

This does not prove that WhatsApp adopted E2EE for those reasons.

We cannot attribute that intention to it.

But the objective advantages do exist.

"We don't have that information" is a very comfortable position

Suppose a publisher discovers that certain users are sending each other pirated books over WhatsApp.

Or that an authority wants to know the content of an old conversation.

If WhatsApp really does not keep that content and the normal architecture prevents the server from decrypting it, it can reply:

"We don't have that information."

That is good news for privacy.

But it is also a very convenient situation for the provider.

It does not need to:

• systematically decide what is legal inside every private conversation;
• maintain systems that inspect every file;
• retain content for years;
• answer every request by handing over data it no longer holds;
• safeguard an extraordinarily compromising central database.

I would not use the word "deniability" here, because it has specific technical meanings in cryptography and could cause confusion.

I would rather speak of non-custody of content.

The very feature that says:

"WhatsApp cannot see it"

also says:

"WhatsApp does not have to safeguard it."

And, as I found out the hard way, it also allows them to say: "we can't help you restore your chats."

But WhatsApp is not blind

We shouldn't go to the other extreme either.

The fact that a conversation's content is E2EE does not mean WhatsApp has no information related to the use of the service.

Its privacy policy describes, among other things:

• account information;
• device and connection information;
• logs and diagnostics;
• information needed to operate the service.

It also says it retains information related to transmission, such as the number, date and time of a message or the duration of a call, for as long as necessary to transmit the communication, operate the service or comply with legal obligations.

So:

Figura 16

"E2EE" does not mean "WhatsApp knows nothing about me".

It means a specific property about the content.

The provider can hand over the data it actually holds. What it should not be able to hand over, according to the published architecture, is the plaintext of an E2EE conversation it does not keep.

The question in this article, however, remains:

Is that inability a property we can independently verify at the endpoint, or a property that also depends on trusting the client WhatsApp gives us?

And there we are back to the beginning.

"They don't do it" is not the same as "they can't do it"

This is probably the most important distinction in the whole article.

We can have three situations:

1. The provider says it doesn't do it

That is a claim.

2. We have no evidence that it does

That is an observation about what we know.

3. The system is built so that we ourselves can verify it cannot do it silently

That is a much stronger technical guarantee.

Figura 17

Free software is not magically secure.

Compiling it yourself is not magically secure either.

But each layer of verifiability reduces the number of claims we have to accept just because.

Even compiling it yourself doesn't eliminate all trust

We could keep going down indefinitely.

If I compile the app myself, I still trust:

• the sources;
• the compiler;
• the dependencies;
• the operating system;
• the kernel;
• the firmware;
• the hardware.

Figura 18

Zero trust does not exist.

The useful question is:

How much trust can I replace with verification?

And in that respect not all systems are equivalent.

So is WhatsApp insecure?

That question is badly framed.

We have to ask:

Insecure against whom?

WhatsApp with E2EE can be very secure against someone capturing network traffic.

It can be very secure against a curious telecommunications operator.

It can protect extraordinarily well against a particular server breach.

But if your threat model includes:

"I don't want to have to trust the service provider itself"

then controlling the client becomes fundamental.

And E2EE, on its own, is no longer enough.

So why do I still use Telegram for low-sensitivity things?

Precisely because security does not exist in a vacuum.

It depends on what you are trying to protect.

Telegram lets me:

• keep my whole history synchronised;
• use many devices easily;
• recover conversations immediately;
• store an enormous amount of data in the cloud;
• access it regardless of the specific device.

Telegram's cloud chats are not E2EE, and Telegram says so openly: it keeps them in its cloud so they are accessible from any device.

But for talking about:

• grammar;
• Esperanto;
• classes;
• a hobby;
• a meeting;
• an ordinary social activity;

I can perfectly well conclude that those properties are more valuable to me than eliminating a risk which, for that particular information, I consider not very relevant.

That does not mean Telegram is more secure.

It means applying a proportionate threat model.

For a highly sensitive conversation, I would choose different guarantees.

For arguing about whether the accusative in Esperanto belongs after a particular construction, probably not.

What should a system with very strong guarantees require?

If we genuinely wanted to minimise trust in the provider, we would look for at least:

1. a public, auditable cryptographic protocol;
2. the complete client code made public;
3. reproducible builds;
4. the ability to compare our binary with the sources;
5. the ability to compile the client ourselves;
6. the ability to control when we update;
7. the possibility of using alternative implementations;
8. transparency mechanisms against selective treatment;
9. metadata minimisation;
10. an operating system and a build chain that are also reasonably verifiable.

Not every popular system meets all of that.

But there is a qualitative difference between:

"The vendor assures me it can't do it."

and:

"The way the system is built lets me independently check that it can't do it in the way we are considering."

The right question: whose endpoints are they?

When WhatsApp's familiar padlock appears, the usual question is:

"Is the conversation encrypted?"

Yes.

It is an important question.

But right after it we should ask another:

"Whose endpoints are they?"

Because the correct picture is not:

me  <============= E2EE =============>  you

but:

Figura 19

E2EE magnificently protects the stretch between B and C.

But it does not certify B or C.

And if B and C are programs the provider itself can develop, distribute and modify, trust in that provider has not disappeared.

It has merely been relocated.

Conclusion

WhatsApp's end-to-end encryption is neither false nor useless.

On the contrary: it is a hugely important security measure.

The problem is turning a specific property:

"our servers do not need to be able to decrypt the messages"

into an absolute claim:

"we could never obtain the messages".

That would require trusting the behaviour of the endpoints as well.

And the endpoints are software.

Software someone writes.

Software someone compiles.

Software someone distributes.

Software someone updates.

Software that, in the end, has the plaintext in front of it.

That is why, faced with any app that boasts about E2EE, I would no longer settle for asking:

"Is it end-to-end encrypted?"

I would also ask:

"Can I read the endpoints' code?"

"Can I prove the installed binary corresponds to that code?"

"Can I compile it myself?"

"Can I decide when I change version?"

"Can I keep using that version without the provider forcing me to replace it?"

"Can the server selectively modify my endpoint's behaviour?"

And above all:

"Is the endpoint really mine, or is it still under the provider's control?"

The E2EE padlock tells us that the journey between the endpoints is protected.

It does not tell us, on its own, whom we have to trust once we arrive at the endpoints.