Data privacy is a key proposition of our platform as we do not and will not sell or market your data. It is our job to protect your data and to keep it safe anytime. The privacy rights of our clients and the security of their personal data are our highest priorities.
Therefore this post expands on the major areas of security, encryption and GDPR-compliance.
Point-to-point Encryption/Data in Transit
Our real time chat communication platform encryption satisfies Articles 6 and 32 of the GDPR by providing both encryption for data in transit and data at rest. SSL/TLS endpoints for all APIs and data streaming services are included for all plans and services.
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS encryption is used by most secure websites today and accepted as a standard for point-to-point security over public networks.
End to End Message Security via AES-256 Encryption
Advanced Encryption Standard (AES) is a specification for the encryption of electronic data. AES has been adopted by many governments around the world and is now used worldwide in many high-security applications. 2003 the U.S. Government announced that AES can be used to protect classified information.
We´re using 256-bit encryption, enabling users to encrypt on one device (e.g. an iPhone) and decrypt on another (Desktop PC, Android etc.). The cipher key is stored in the tchop apps in a highly secured, safe way. As a consequence, no service provider (also not service provider of chat infrastructure) has the ability to decrypt any customer data.
Since messages encrypted with AES are not readable as they route through servers, they are also not readable by us.
Technically our chat messages have two parts: the body and the envelope. Data placed in the message body will be both TLS and AES encrypted, but data placed in the envelope will be encrypted with TLS (point-to-point) encryption. This approach optionally allows our developers to place actionable data in the message envelope, while placing the bulk of the message content into the message body.
Log Access and Audit Options
GDPR Articles 33 and 34 define reporting requirements for a data breach. Therefore our logs provide full visibility on all API calls made to the network. In addition to the network logs, the SDKs we´re using also generate logs that can be used for audit or troubleshooting purposes. Please get in touch if you want to have more detailed information or ways to access such logs.
Additionally we provide a flexible option to route messages to your own servers so that your IT department has the option to leverage their own infrastructure for audit purposes. This is especially important in case you want to store full history of all chat communication as we delete chat history on our servers after 30 days at the moment.
Our time-to-live for persisted messages is set to 30 days per default as mentioned. Basically there are also options to store full history of chat messages if that is requested. In such cases we can provide special routines to delete any persisted messages to stay compliant with Article 17 of the EU GDPR – Right to erasure.
Data Privacy, Storage, Portability
GDPR restricts cross-border data transfers from the EU to the US or to other Non-EU countries for good reasons. Therefore we persist all our data only in E.U. hosted data centers.
We´re technically also able to supports use cases that do not need (or want) access to historical messages at all. Therefore we can implement a “transient-only” mode with RAM-only message routing that prevents any data from being stored throughout the global network pipeline. Please get in touch if you´re interested in that option.
For data portability, as provided in GDPR Articles 13, 14, 15 and 20, we also can provide access to your stored chat data, in a standard JSON format.
Secure Access Manager
We control access to the chat platform via token-based authorization (so called Access Manager) allowing granular read and write access control at the user/device, channel, an key level.
No pub/sub operations can be done without first explicitly providing an authorization token (auth token). If an invalid token is provided, the requesting client will receive a 403 Forbidden Error.
PubNub recognizes any entity with the secret_key for the given API key set as a security authority; a recognized security authority is able to grant or revoke permissions on any token, as well as configure TTLs (time to live) for tokens to expire. A client should never be in possession of the secret_key.
Behaviour of App
It´s also important to understand that our apps require and handle a mininum amount of data. User can upload and share videos or photos, but before that they are asked if the app can have access to the corresponding apps. Our apps don´t require access to other data or any other apps.
This is especially important as many users use their private devices for business purpose in the moment they are using our apps. So we try to keep data strictly separated and only access what is really needed (which is as said the above mentioned case of content sharing).
Other than WhatsApp we also don´t need your telephone number nor do we try to get access to all contacts on your phone. We don´t track or store any meta data connected to the chat like location (which is apart from the question of end-to-end encryption one of the critical issues in most consumer chat apps).