We take security very seriously here at Countly, since our main focus is privacy of your data, and we know and understand how important the responsibility of safeguarding this data is to our customers. There are several measures we have undertaken for Countly, and you'll find a list of questions here to make your instance more secure.
We have worked with many companies to date and we have an extensive knowledge in this domain, especially when it comes to General Data Protection Regulation (GDPR), HIPAA and COPPA, collaborating with several parties and conforming to their standards and regulatory laws. This has enabled us to make Countly the platform of choice when it comes to data privacy and security. Below you can read some of the unique features of Countly and how it helps secure sensitive information.
- Self-hosting options: Countly can be installed on-premise (i.e. either in your own data center or with a trusted hosting partner), allowing for a greater depth and breadth of security and control. Self-hosting means that no third party (not even Countly) ever has access to your data unless you permit it.
- Secure transmission: Data collected from devices are sent over a secure channel, and cannot be tampered — this eliminates intruders and potential man-in-the-middle attacks.
- Right to be forgotten rule: If a EU citizen asks for his data to be removed, it can be done in Countly so his data is completely wiped out. Countly also has a “blocking rule” plugin which blocks data from reaching Countly database using several criteria like username, email, IP address, deviceID etc.
- Do not track: GDPR also stipulates that individuals have a right to ‘block’ or suppress processing of personal data. If an individual decides not to be tracked, Countly has a function to support this. If it is invoked, then we do not track that user at all.
- Data-at-rest encryption: When data is stored, we can use data-at-rest encryption, further enhancing the security of personal data, making it impossible for a rogue employee to reach this data.
- Extensive system audit logs: There are more than 30 different system logs collected, and this helps system administrator know what is happening inside the server. In case of an emergency or an audit, logs can be viewed, allowing organization insight into what has happened and the cause of issue.
- Login security: We have several methods to keep logins secure — Countly can require strong passwords, only permit logins via HTTPS, and ban users when there is a brute force attack.
- Access levels: Countly dashboard users can only view what what has been enabled for them. Administrators have the ability to disable a menu item or a view (e.g User Profiles) for specific users. This way, only necessary and required data is shown.
- No IP address storage: Countly doesn’t store any IP address, but rather converts IP to user’s city and then discarding the IP. For customers where this is an issue, Countly has the ability to completely remove city and country information.
- Data portability: Our database schema is completely open, allowing any Countly client to transfer data from Countly to another service easily.
You may enable password expiration under
Management → Configuration → Security → Password expiration. You can set it to 0 (no password expiration), or to a number like 20, where password expires after 20 days and must be changed.
Yes, this is configurable under
Management → Configuration → Security → Allowed Login attempts and default value is 3, after which account will be locked for amount of time configurable under
Management → Configurations → Security → Incorrect Login block time increment. On consecutive failed logins account will be blocked with increased time, so if configured value is 5 minutes, then after 5 minutes expire, if a user fails to login 3 more times, it will be locked for 10 minutes, then 15 minutes, etc.
Countly can be configured so that a user may not be able to use his one of previous passwords. In order to enable this, go to Management → Configurations → Security → Password rotation and define number of previous passwords user should not be able to reuse.
See this documentation for adding a username and password to MongoDB.
This documentation can be used to configure Countly to accept HTTPS connections.
In order to use Let's Encrypt certificates, please follow this guideline.
Countly can be configured to use a salt (from
Management → Applications and inside the SDK) to add checksum to SDK requests in order to prevent parameter tampering. For more information about parameter tampering, see this documentation.
Default hardware, software and telemetry data collected
- Application Key (App_Key of the application)
- Generated device ID
- Session duration (Gives duration of a session)
- Country code & city (Gives country and city, from IP address. IP address is discarded)
- Operating system (Platform of the device, e.g Android)
- Operating system version (Platform version, e.g 7.0)
- Device resolution (e.g 1344x768)
- Carrier (e.g Verizon)
- Application version (Version of the application)
- Density (e.g XXHDPI or @2X)
- Locale (device language, e.g Polish)
- Store (Store that this app is downloaded from, e.g Google Play)
- Crash dump (Whole crash dump of the error)
- Current and total RAM (RAM sizes at the time crash occurred)
- Current and total disk space (Disk sizes at the time crash occurred)
- Online or not (Whether device had an active connection when crash happened)
- Muted or not (Sound - Whether the device was muted or not when crash happened)
- App is in background or not (Whether app was in background or not when crash happened)
- Name of crash (Name of crash)
- Fatal or non-fatal (Whether crash caused app to exit or not)
- Running time of app (how long the app was running at the time of crash, in seconds)
- Any custom key/value provided by developer (Any value that can help identify cause of crash)
- Which screens user has visited
- Campaign name (Name of the campaign this user has been attributed / converged)
- Campaign ID (ID of the campaign)