Data protection¶
Hosting (Cloud edition)¶
The Drovio website, blog and Cloud services are hosted on Amazon AWS in Oregon (USA). Customer data is stored on AWS RDS (Oregon, USA). Multiple instances run to form a cluster, ensuring redundancy and load balancing, preventing outages. Alarms are in place to detect any administrative access (on Production and Development environments) and any increase in traffic, allowing us to deploy more instances automatically.
The third parties involved in the service, where they process data and under which safeguards, are listed in Compliance & data processing.
Encryption¶
Data in transit¶
Strong encryption protocols are used for any data transferred between Drovio clients and Drovio servers, including TLS 1.2 or 1.3 and SHA-2 signatures for authentication and account management on Drovio Cloud.
Screen sharing, calls (audio and video), messaging, file transfers and any other data shared between users go through P2P connections, using:
- DTLS-SRTP (UDP version of TLS on top of Secure Real-Time Protocol, with AES-128 encryption) for audio / video;
- DTLS-SCTP (Stream Control Transmission Protocol) for data (mouse and keyboard inputs, text chat, shared files…).
Data at rest¶
Data at rest is stored on PostgreSQL databases. Drovio Cloud uses AWS RDS to securely store customer data using AES-256 encryption on database instances, backups and read replicas.
Password storage¶
Passwords are never stored, only their argon2id hash: the memory-hard function recommended by OWASP against offline cracking, computed with a random salt for each account and with parameters aligned on the OWASP recommendations. The parameters are stored alongside each hash, so the cost can be raised over time as hardware improves.
This applies to local accounts only. Signing in through SSO (SAML), or with Slack, GitHub or Google, stores no password at all.
What we store (Cloud edition)¶
We store only the minimum customer data needed to deliver the service.
Service¶
- Email address
- Password, hashed with argon2id and a per-account random salt (see Password storage), or an access token when signing in with Slack, GitHub or Google. With SSO (SAML) no credential is stored on our end: authentication is delegated to your identity provider
- Display name
Invoices¶
For payments made through the Cloud edition, we also store additional information for invoicing purposes:
- First name
- Last name
- Address
- Company name (optional)
- VAT number (optional)
No card data
We don't store any customer credit card information in our databases. We rely on a PCI-compliant payment provider, Stripe, for payment processing.
Statistics¶
To continuously improve the user experience and be able to assist you when you encounter an issue, we collect some information about the usage of our service, including but not limited to:
- Connection events, with app version, OS name and version
- Session started/ended events
- New contacts
- Invites to join a session (email, direct link or contact list)
- User joined/quit (with their already-stored email identity when using the integrated client)
- Connection types (direct, NAT'd or relayed)
These events describe how the service is used, never what happens inside a session: no screen content, keystroke, audio, message or transferred file is collected, and none of it is technically available to us.
Data retention¶
Customer data is removed upon request. Backups are automatically destroyed within 15 days.
Statistics¶
The usage statistics described above are handled by a daily process in Drovio Server, driven by the timestamp carried by each event. Two things trigger it:
- an event becomes older than one year
- the user it relates to is deleted, in which case their events are processed without waiting for the one-year mark
What happens next is decided per event type. An event that still has value for aggregate reporting is anonymized: the identity it carried is replaced, so the event keeps feeding dashboards and BI without pointing at anyone. Every other event is wiped.
On the Enterprise edition you decide how it behaves, with the
anonymize settings:
whether the process runs at all, at what time of day, and how many users it handles
per execution. Accounts themselves can be removed automatically after a period of
inactivity, 90 days by default, with
users.remove_inactive.
Logs¶
On the Cloud edition, every log group is stored in AWS CloudWatch with a one-year retention, after which the logs are deleted automatically.