Security and Privacy

A lot of Bug Capture's users come from highly security-sensitive industries (e.g. banking, accounting, insurance and even public sector), which is why the topic of data handling is extremely important to us.

In this page you can find a summary of the principles and practices carried out by our team to safeguard the privacy, security, and reliability of our service, in easy to understand language.

Security

Thanks to software development experience in both startups and large companies, we are aware that bug reports can contain sensitive information. That's why we place highest value on keeping customer data secure. Below you can find information on how exactly we do that. If you have more questions, we are happy to answer them.

Product Features Benefitting Security

• We offer password-less login and OAuth 2.0 login methods only. This eliminates the risk of leaked passwords, because we do not store them.
• Local first: Bug reports never leave your browser until you decide to upload and share them with your teammates.
• You can choose to share recordings privately between team members and configure role-based access control on a workspaces level.
• Even for public links (when you want people outside your workspace to access the recording), we randomize all IDs and asset names with high entropy, so that even public session URLs can not be guessed and accessed by outsiders with whom the recording was not shared.

Measures We Take To Operate The Service Safely

• Hosting: Our services are hosted in Google Cloud Platform data centers, and configured securely. All data centers are located in the European Union and certified for information storage security (ISO 27001) and IT service management (ISO 20000).
• Encryption: All of our services provide secure and encrypted Secure Sockets Layer (SSL) connections, so that data is encrypted in transit between our users' computers and the servers. Likewise, communication between our services and third parties is always encrypted. User data on the servers is encrypted at rest at the storage level using the 256-bit Advanced Encryption Standard (AES256), as recommended by the National Institute of Standards and Technology (NIST). Each encryption key is itself encrypted with a regularly rotated set of master keys.
• Payment processing: Paddle, our payments processing vendor, is based in the UK and compliant with the Payment Card Industry Data Security Standard (PCI-DSS) and Payment Services Directive (PSD2).
• User authentication: We use Auth0 to authenticate our users. Auth0 is a leading provider for authentication and authorization services and ISO 27001/27018 certificated, among others.

Safeguarding Our Application Code

• Automated dependency scanning: We limit our usage of third party code where possible. We continuously scan our code for known security flaws using dependency scanning. You can verify the list of third party packages we use here: https://app.birdeatsbug.com/credits
• Content security policy and security related headers: Our applications use strict CSP headers, which ensure that only code commissioned by us is executed on clients. We also set restrictive HTTP headers so that our applications, for example, can't be embedded by bad actors.

How Our Team Protects Our Service

Any information system can be hacked given enough time and resources. However, many security issues arise from accidental human mistakes. That's why it's all the more important that our team makes it a habit to follow best practices:

• Training and operational security: All employees receive security training during onboarding and at least once per year afterwards. Our exhaustive policies include – amongst other things – the encryption of all computers, and the usage of password managers for all business accounts. Business accounts are automatically scanned for breaches. We also ensure the usage of multi factor authentication (MFA) for tools we use to build Bug Capture. We use a VPN to mitigate risks caused by potentially insecure networks.
• Limited access: We follow the need-to-know principle / the principle of least privilege. This means that we limit access to customer data to the smallest group of staff possible. Only two team members can access the production database, which is required to provide the service and ensure high uptime. We do not give employees access to more data than is required for them to fulfill their role.
• Environment segregation: All product development and testing occurs on environments with separate databases and user pools. This ensures that product development doesn't impact customer data.
• Confidentiality: Employees are bound by additional contractual confidentiality clauses.

Reliability And Data Integrity

You can verify our uptime and service status at all times on https://status.birdeatsbug.com/, in which you can find any past and current incidents.

We run daily backups so that even in the worst case we can't lose more than 24h worth of data. In the unlikely event of a data breach or loss, affected users and the competent supervising authorities will be timely notified.

Privacy

We adhere to the strict European General Data Protection Regulation (GDPR) and regularly audit that our product continues to follow the latest legislation. That means that we design our product following a "privacy first" approach and do not collect unnecessary data. Furthermore, you – as the owner of the data – can ask us to share a copy of your data with you, or permanently delete it. You'll receive a timely response by a human being.

Please consult our privacy policy on https://birdeatsbug.com/privacy-policy to see detailed policies and a list of third party data processors we use to provide our service.

Comparison With Similar Tools

There are various services on the market which allow you to record technical logs and actions performed by end users on web applications.

We believe that the approach of "always-on" recording live user interaction has several important privacy downsides:

• Users don't generally know that they are being recorded. Even though they can find out by checking the Terms of Service or Privacy Policy, most people don't read those and remain unaware.
• It is easy to forget to exclude certain fields (i.e. passwords, credit card details, etc.) from being recorded, which means that critical private information can be seen by people who shouldn't have access to it.

These downsides were some of the reasons we decided to build Bug Capture and create mechanisms to prevent them from happening in our product:

• Bug Capture is not for tracking the end users of a product. It is designed to be used on pre-production environments, where 80% of the bugs are discovered, yet no live customer data is stored.
• Bug Capture doesn't upload anything before you explicitly choose to do so and it allows you to review the data before uploading it.

Technical Data Bug Capture Collects

In order to help your team spend less time on reporting and fixing bugs, Bug Capture collects technical data generated while you interact with your product. This data includes general information like your browser version, operating system, time of recording, console logs, URLs that you visit during the recording, network logs, etc.

When does Bug Capture Collect This Data?

Bug Capture only collects this data from the domains to which you give it explicit access. The idea is that you only enable Bug Capture on the URLs of the product you are working on.

Also no data is uploaded to our servers, until you explicitly press the upload button.

Closing Remarks

If you have further questions about privacy and security, contact us and we will do our best to answer them.