How to ensure your Instant Messaging solution offers users privacy and security

Concerns around privacy and security have become a big talking point this year. There have been a number of major Instant Messaging providers who have been criticised for the way that their apps collect, store and share the information of their users. In amongst the mountains of data collected most apps will receive information about users interests, behavioural patterns and location. Users’ privacy concerns have caused an unexpected and unwanted complication for many companies using enterprise versions of these chat applications.

Customers prioritise security

Firstly, if customers are turning away from the specific chat provider a business has chosen to adopt, it can create a barrier between the company and their customers. Secondly, for businesses in regulated industries such as FinTech or Healthcare, a chat provider’s ability to change their privacy and security terms and conditions is an unacceptable risk. The best way for a business to be sure that their enterprise instant messaging solution is secure and meets the privacy demands of its users is to have control of the privacy and security setting of the chat application. With most out-the-box solutions, control over privacy and security is rigid and dictated by the chat provided.

Privacy by default, customisable by design

MongooseIM is built with maximum user privacy levels as the default, which means anyone using a standard implementation of MongosseIM has an extremely private, secure chat server that has been approved by some of the most stringent regulatory boards. On top of that, you control your chat application giving you the ability to format the settings to suit your company’s needs and your users. Below are a list of privacy considerations built into MongooseIM.

Minimise and limit

The minimise and limit principle regards the amount of personal data gathered by a service. The general principle here is to take only the bare minimum required for a service to run instead of saving unnecessary data just in case. If more data is taken out, the unnecessary part should be deleted. Luckily, MongooseIM is using only the bare minimum of personal data provided by the users and relies on the users themselves to provide more if they wish to – e.g. by filling out the roster information. Moreover, since it is implementing XMPP and is open source, everybody has an insight as to how the data is processed.

Hide and protect

The hide and protect principle refers to the fact that user data should not be made public and should be hidden from plain view disallowing third parties to identify users through personal data or its interrelation. We have tackled that by handling the creation of JIDs and having recommendations regarding log collection and archiving. What is this all about? See, JIDs are the central and focal point of MongooseIM operation as they are user unique identifiers in the system. As long as the JID does not contain any personally identifiable information like a name or a telephone number, the JID is far more than pseudo-anonymous and cannot be linked to the individual it represents. This is why one should refrain from putting personally identifiable information in JIDs. For that reason, our release includes a mechanism that allows automatic user creation with random JIDs that you can invoke by typing ‘register’ in the console. Specific JIDs are created by intentionally invoking a different command (register_identified).
Still, it is possible that MongooseIM logs contain personally identifiable information such as IP addresses that could correlate to JIDs. Even though the JID is anonymous, an IP address next to a JID might lead to the person behind it through correlation. That is why we recommend that installations with privacy in mind have their log level set to at least ‘warning’ level in order to avoid breaches of privacy while still maintaining log usability.

Separate and aggregate

The separate principle boils down to partitioning user data into chunks rather than keeping them in a monolithic DB. Each chunk should contain only the necessary private data for its own functioning. Such a separation creates issues when trying to identify a person through correlation as the data is scattered and isolated – hence the popularity of microservices. Since MongooseIM is an XMPP server written in Erlang, it is naturally partitioned into modules that have their own storage backends. In this way, private data is separated by default in MongooseIM and can be also handled individually – e.g. by deleting all the private data relating to one function.
The aggregation principle refers to the fact that all data should be processed in an aggregated manner and not in one focused on detailed personal cases. For instance, behavioural patterns should be representative of a concrete, not identifiable cohort rather than of a certain Rick Sanchez or Morty Smith. All the usage data being processed by MongooseIM is devoid of any personally identifiable traits and instead tracks metrics relevant to the health of the server. The same can be said for WombatOAM if you pair it with MongooseIM. Therefore, aggregation is supported by default.

Privacy by default

It is assumed that the user should be offered the highest degree of privacy by default. This is highly dependant on your own implementation of the service running on top of MongooseIM. However, if you follow our recommendations laid out in this post, you can be sure you implement it well on the backend side, as we do not differentiate between the levels of privacy being offered.

The Right of Access

As users privacy concerns go, so too does the likelihood that a user will request to see the data that your chat application has stored on them. With MongooseIM we have put a lot of effort in order to make the retrieval as painless as possible for system administrators that oversee the day to day operations. That is why we have developed a mechanism you can start by executing the retrieve_personal_data command in order to collect all the personal and derivative data belonging to a user behind a specific JID. The command will execute for all the modules no matter if they are enabled or disabled. Then, all the relevant data is extracted per module and is returned to the user in the form of an archive.
In order to facilitate the data collection, we have changed the schemas for all of our MAM backends. This has been done to allow a swift data extraction since up till now it was very inefficient and resource hungry to run such a query. Of course, we have prepared migration strategies for the affected backends.

The right to be forgotten

The right to be forgotten is another one that goes alongside the right of access. Each user has the right to remove their footprint from the service. Since we know retrieval from all the modules listed above is problematic, removal is even worse.
We have implemented a mechanism that removes the user account leaving behind only the JID. You can run it by executing the “unregister” command. All of the private data not shared with other users is deleted from the system. In contrast, all of the private data that is shared with other users – e.g. group chats messages or PubSub flat nodes – is left intact as the content is not only owned by one party. Logs are not a part of this action. If the log levels are set at least to ‘warning’, there is no personal data that can be tied to the JIDs in the first place so there is no need for removal.

Long-term peace of mind

The recent privacy concerns of major messaging provider has created an unwanted hurdle for many businesses, but one that can be easily overcome. They do however serve as a good example of one of the broader problems with choosing an out-the-box, software-as-a-service provider for your chat solutions. Most third party products are offered as one-size-fits all, meaning any changes made by the owner will impact your account, this creates an uncontrolled liability for your business. MongooseIM offers an easily manageable alternative to software-as-a-service providers. With us, you’ll be able to utilise an extremely robust, battle-tested messaging server, that has been used by many of the world’s most used chat applications. In doing so, you’ll have a solution that is scalable, reliable but customisable and owned by your business.

Want to learn MongooseIM?

Visit our training to page to find out how you can empower your team to utilise our awesome, open source instant messaging server for the needs of your organisation.