FAQ

🛠️ Server and Open Source

Does Olvid use a server?

Olvid relies on a server to allow efficient asynchronous transmission of messages. Concretely, this allows a message to be “put on hold” until the recipient has a connection. The message is then immediately sent to them and deleted from our server. Most of the time, the message is deleted almost immediately after being uploaded.

Does this architecture present a security risk?

It is important to note that Olvid encrypts all communications from end to end. Messages, in particular, are encrypted on the sender’s phone, and can only be decrypted on the recipient’s phone. They remain fully encrypted while in transit from one phone to the other. Olvid encrypts everything that transits through the server, data and metadata, with the exception of the recipient’s public key (which is the bare minimum to allow efficient “routing” of the messages to the right recipient). Note that the sender’s public key does not appear in the message sent, however, their IP address is visible to the server (as with any service on the internet using TCP/IP). Olvid will work fine behind a VPN or via Tor if you want to hide it.

The cryptographic protocols implemented by Olvid have been designed in a very strong security model. In particular, privacy guarantees must be maintained even in the situation where Olvid’s server is controlled by an adversary. To put it simply: when you communicate with Olvid, you don’t have to trust the server relaying your messages. Even in the situation where it would be malicious, Olvid’s security is still guaranteed.

Peer-to-peer vs. centralized distribution server

Some instant messengers have chosen to decentralize the distribution of messages. This decentralization does not provide security comparable to state-of-the-art encryption, and therefore must always be accompanied by end-to-end encryption. On the other hand, decentralization of the distribution can guarantee a certain resilience to failures or denials of service. But this is usually accompanied by a degraded user experience (increased latency to receive messages, limited bandwidth).

Olvid in multi-servers

Today, Olvid uses a single server to relay messages. However, the current architecture has already been designed to support multiple servers (much like email). Although it is not peer-to-peer, eventually each user group could have its own server.

We also regularly reassess the possibilities towards a multicloud architecture.

Is the server code open source?

The entire client code is open-source. This code, once compiled, makes it possible to produce iOS and Android clients which are able to communicate with our production server (the exact same one used by the client applications downloaded from the App Store or Google Play), and thus enter into contact and chat with all other Olvid users.

For the moment, however, we have chosen not to publish the source code of the server through which the messages transit. Here are the four main reasons why we made this choice:

Olvid’s security model protects you from its server

For the reasons given above, the Olvid server plays no role in the security of communications. This sets Olvid apart from the vast majority of other end-to-end encrypted messaging systems, which typically rely on a “trusted third party” to make it easy for users to start communicating with each other. This third party can take several forms, the most classic being a blockchain or a centralized directory allowing the operator of the solution to associate a user’s personal data (phone number, email address, etc.) with their digital identity. This trusted third party is used to bootstrap any interaction between two users, and its role is to guarantee the integrity of the exchange of their digital identities. If that third party is malicious or corrupted, the security of the entire architecture is compromised.

Any messaging service that has chosen to centralize security within a single directory that it controls should therefore publish its code.

Olvid’s case is different: we have chosen to never impose a single trusted third party on our users, considering that this would represent too great a risk in terms of security. In addition, this allows Olvid to operate without having to request / know any personal data about its users.

Making the code open source would have no beneficial security impact. What protects Olvid users are the cryptographic protocols implemented, fully published (and therefore auditable) in the source codes of the iOS and Android client applications.

The current source code is also largely AWS configuration

Olvid’s message distribution server is currently hosted by AWS. We use a fully serverless architecture which has notably enabled us to guarantee an excellent quality of service until today. This architecture allows our technical teams to free up time to develop client applications (where Olvid’s intelligence lies) rather than spending time on server administration (a particularly complex and time-consuming subject).

While this architecture is perfectly suited for a general public messaging system that can serve several hundred thousand users (or more), it is clearly not very convenient for deploying a “personal” server that aims to serve only a few hundreds. The source code of the current server would therefore not be very useful for those who wish to deploy their own server.

Olvid’s server is constantly evolving

Olvid regularly offers new features. It is therefore important to allow users who have updated the application to benefit from it as soon as possible, without preventing them from communicating with their contacts who have not yet updated. The server plays an important role in this mechanism by being able to manage older versions of the application as well. Note: the current Olvid server can still be used with the very first public versions of Olvid (released in summer 2019).

In practice, when new features are developed in Olvid, the server is updated before these updates are rolled-out on the stores. Otherwise, the application may no longer be functional. The server API is therefore constantly evolving. As long as it is not stabilized, we cannot encourage our users to manage their own server since they may lose the use of Olvid with each app update. Worse, all their contacts could be impacted, giving the impression that it is the application that is not working.

The risk of denial of service

As we explained, Olvid’s message distribution server plays no role in security. However, it is central to quality of service. It is therefore important to protect it as much as possible against denial of service, or other attacks on availability.

Opening the server code thus presents a significant risk, as it would give malicious people all the tools they need to best target their attacks against these servers.

Will it ever be open source?

Yes, when the APIs are stabilized and we are ready. But for all the reasons explained above, it will probably not be the AWS version that we will open, but rather a “standalone” version (for example a Docker), easy to deploy and more suitable for a “small” number of users (a few hundreds).

Towards a multicloud architecture

We regularly reassess the possibilities so that we can offer a multi-cloud infrastructure and server offering. Wherever possible, our aim is to give priority to solutions that have been awarded the SecNumCloud label (or a European qualification of at least equivalent level).