Security and Storage of Information
Keeping your data secure is highly important to us. We have implemented technical and organizational measures to ensure that all data sent to Diggle is handled securely.
Diggle should be simple and intuitive to use. When inviting participants to join a Diggle, you can choose between different security settings. Choosing higher security settings to ensure the desired level of privacy entails additional complexity for you and the participants. It will therefore remain possible to choose simple, less secure ways to use Diggle, such as sharing a URL to invite participants without them verifying their identity or sending the final results report back to participants. Therefore, we cannot take responsibility for any breach of privacy due to Diggle being used as a simple and easy way of interacting, and this information later reaches unauthorized persons.
Levels of security when joining a Diggle
When asking people to join a Diggle, you have several security options:
- Live session
- Access to participate (how long the session is active) expires automatically after 48 hours
- Select a more extended log-in code than the default 8
- Anonymous login vs Nickname login
- Invite by link
- Expiration time is set manually
- Default duration of the link is 48 hours
- Email verification
- We offer all customers the possibility for email invites with the need for verification using a six character code before joining a Diggle. This code is valid for 15 minutes with three login attempts.
We may change the configurations listed above without notice to provide a better or more secure experience for our users.
Data Security
You should take steps to protect against unauthorized access to your device and account by, among other things, choosing a robust password that nobody else knows or can easily guess and keeping your log-in and password private. We are not responsible for any lost, stolen, or compromised passwords or for any activity on your account via unauthorized password activity.
We retain the personal data we collect for so long as reasonably necessary to fulfill the purposes for which the data was collected, to perform our contractual and legal obligations, and for any applicable statute of limitations periods to bring and defend claims.
Processing
Scaleway is the data center provider for the Diggle application. Scaleway is located in France, so you can get full protection from GDPR. They list the following compliance and certifications:
- ISO 27001:2013 – Information security management system
- HDS – Health data hosting
- ISO 50001:2018 – Energy management systems
- GDPR
- Tier 3 Uptime Institute: 2014
- SWIPO
Scaleway employs a wide range of physical security measures to keep your data safe.
Scaleway’s compliance and certifications is covered here:
https://www.scaleway.com/en/about-us/our-certifications/
Scaleway’s security and resilience measures are covered here:
https://www.scaleway.com/en/security-and-resilience/
For the landing page we use DigitalOcean (US), for our hosting needs. The only personally identifiable information we store on this server is the contents of the access logs that we use to be able to identify malicious behavior. These access logs contain IP addresses. The logs are automatically deleted every two weeks.
Scaleway is also the hosting provider for images our users upload as part of the content they build
Data at rest
- DigitalOcean: Stored IP addresses are not encrypted at rest.
- CloudFlare: Encrypts all data at rest, usually with disk-level encryption.
- Google Analytics: Data is encrypted at rest (currently deactivated)
- GSuite (Gmail, Meet): Data encrypted at rest.
- Stripe: All card numbers are encrypted at rest with AES-256. Decryption keys are stored on separate machines. None of Stripe’s internal servers and daemons can obtain plaintext card numbers but can request that cards are sent to a service provider on a static allowlist. Stripe’s infrastructure for storing, decrypting, and transmitting card numbers runs in a separate hosting environment and doesn’t share any credentials with Stripe’s primary services (API, website, etc.).
- Sentry: Uses encryption at rest.
- Slack: Data at rest in Slack’s production network is encrypted using FIPS 140-2 compliant encryption standards, which applies to all types of data at rest within Slack’s systems—relational databases, file stores, database backups, etc
Data in transit
We use standard TLS ≥ 1.2, so encryption of data-in-transit, and are rated A+ by 3rd party vendor, SSL Labs. Privacy and protection of user data are of the highest importance to us and we both have technical and operational support in place to ensure this.
Backups and Data Loss Prevention
Data is backed up continuously, and we have an automatic failover system if the primary database fails. We are running a high availability managed Postgres database from Scaleway.
User Passwords
We hash and salt all passwords with the bcrypt algorithm. So no passwords will be leaked in the event of a breach.
Employee Passwords
Passwords that are used in the line of work are stored using a password management system. We enforce 2FA where applicable and that employees use screen locks whenever they are not by their workstations.
Payment Details
Credit card information is stored with Stripe, which is a Level 1 PCI compliant payment processor. Source: https://stripe.com/docs/security/guide
Security routines
| Planned activity |
Frequency |
| Re-evaluation of transfer tools at appropriate intervals, developments in the third country that may affect the level of data protection, the necessity of our own mechanisms and to the degree they have been sufficiently implemented |
Minimum 2 times a year |
| Security training for personnel |
Yearly and at beginning of employment |
| Revoke system, hardware and document access |
At end of employment |
| Firewall settings verification for workstations and Network |
2 times a year |
| Ensure all critical system libraries are up-to-date |
Continuously |
| Unit and integration tests to ensure system functionality and security |
Continuously |
| External penetration tests to ensure system security |
By continuously assessing the need for new tests |
Human Resource Security
Diggle is developed by Specifique Norge as, a consulting company based in Oslo, Norway. Not everyone in Specifique works with Diggle and is not given access to information and systems that relate to Diggle.
We have a process in place that ensures that employees are given access to information and systems on a need-to basis only. When employment has ended, we revoke all access that the concerned employee had.
Our lead developer is responsible for the security of the IT infrastructure, develops plans against security threats, vulnerabilities, and risks ensures IT infrastructure supports security policies, and responds to information security incidents.
For everyone with access to systems and information, these guidelines must be respected:
- That employee will keep passwords, PIN codes, etc. entrusted to the employee, strictly confidential;
- That employee uses at least 2-factor authentication for systems with user data. We also require password-protected SSH keys.
- Firewall enabled on all workstations
- That employee will log off the computer or activate the screensaver configured with a password immediately upon completion of each work session
Continuous improvements
Our engineering practices ensure that we have security in mind in all stages of a development lifecycle. We will do our utmost to minimize any type of risk. Examples of Engineering practices:
- Clear code conventions enforced by static code analysis and automatic formatting.
- Use of well-known frameworks to protect against common attack vectors (XSS, CSRF, SQL Injection).
- Continuous check-up to keep libraries up-to-date.
- Continuous integration builds and testing with separate automated deployment for easy rollbacks.
- Continuous improvement process with the entire product team where security issues are evaluated. Yearly security review of the entire code base.
- All releases are tested before merging to production.
- Passwords are always kept in a password manager or as configuration.
