Open source client

A messaging app that claims end-to-end encryption and strong cryptographic properties must make it possible to verify those claims, rather than simply asking to be believed. This verifiability rests on two elements: clear cryptographic documentation, which precisely describes the protocols used, and open client code, which makes it possible to confirm that the application really implements what the documentation describes.

What about the code of the relay server (or of the directory, when there is one)?

Publishing the server’s code is not necessary for the security of exchanges. If that security is truly end-to-end, the server plays no greater role than a network router sitting between your device and your correspondent’s: there is no need to know the software running inside a router to verify the confidentiality and authenticity of an exchange passing through it. Besides, it is extremely difficult to verify that the code running on a server you have no access to matches exactly the code published by the vendor. That said, publishing code is still welcome, and some solutions, such as Signal, Matrix and Olvid, have made that choice.

Reproducible builds

Most users of a messaging app download the official application from a “store” on their smartphone (such as Apple’s App Store or Google Play). Few users compile an application’s open source code themselves. Consequently, the “open source” nature of a messaging client is not, on its own, enough to guarantee that the application installed on the phone was actually compiled from that code.

In some cases, the developer of the solution can take the necessary steps so that every stage of compilation (which turns the source code into a usable application) is deterministic. When that is the case, a third party can go through exactly the same compilation steps and obtain the same “binary” (the same application), bit for bit. Anyone can then verify that the binary downloaded from the app store is identical to the one they obtained themselves by reproducing the build process. From there, one can conclude that the downloaded application does correspond to the published code.

The special case of iOS

This verification is feasible on Android (see the documentation from Signal^archived, Threema^archived or Olvid^archived on the subject), but on iOS it runs into an obstacle that is not specific to any given messaging app. Apple encrypts every application submitted to the App Store using its FairPlay technology. The downloaded binary is therefore encrypted, and only becomes comparable to a local rebuild once decrypted, which means extracting it at runtime from a jailbroken device. As a result, almost all messaging apps give up on reproducible builds on iOS; to our knowledge, only Telegram offers a verification procedure, which it describes as experimental and which requires a jailbroken phone^archived. We consider here that a solution offers reproducible builds as soon as it does so on Android^archived.

Applying this criterion

✅Good if the client’s source code (the application that handles the keys) is published under an open source license (AGPL, GPL, MIT, Apache, etc.), guaranteeing anyone the right to examine it, compile it and share their analyses. Merely making the code available “read-only” (source available) is not enough: it grants no lasting rights, and in particular withholds the right to recompile the application, on which the reproducible-build verification described above depends.