Anil Kumar Singh, trading as BugCapture ("we", "us"), operates the BugCapture service. Effective 20 July 2026. Contact: qatoolshub@gmail.com.
This policy covers two very different kinds of data, and the difference matters:
- Your account data — who you are, what you pay, how you use BugCapture. We decide how this is handled.
- Bug report contents — what BugCapture captures from the web pages you test. You decide what is collected and why; we only store and process it on your instruction.
1. Account data
Collected when you sign up and use the product.
| What | Why | Where it comes from |
|---|---|---|
| Email address | Sign-in, workspace invitations, service notices | You |
| First and last name | Shown to your teammates on reports | You, or your Google account name |
| Account creation time | Support, abuse investigation | Firebase Authentication |
| Workspace name, membership, role | Deciding who can see which reports | You |
| Report count | Enforcing the free-plan limit | Counted automatically |
| Integration credentials (Jira / GitHub / ClickUp tokens) | Filing issues on your behalf | You |
Integration tokens are stored where no browser can read them — a private Firestore location denied to all client access, written only by our server. Once saved, a token is never sent back to your browser. You can replace or disconnect it at any time.
We do not sell any of this, use it for advertising, or use your bug report contents to train machine-learning models.
2. Bug report contents
When you capture a bug, BugCapture collects the following from the page you are testing.
Always collected:
- A screenshot of the page or the region you selected
- Page URL, title, browser, operating system, screen and viewport size, language, timezone
- Browser console output, including errors
- Network activity — request lines, status codes, headers and timings
- A trail of your actions leading up to the capture: clicks, form submissions, navigations. The values you type are never recorded — only which field was interacted with, and what kind of event it was
Collected unless a workspace admin turns it off:
- A snapshot of the page's HTML, up to 200 KB. Before it is stored we remove everything typed into form fields, the contents of inline scripts, and any email addresses, tokens or card-like numbers in the markup
Collected only if a workspace admin turns it on (both are off by default):
- Browser storage:
localStorage,sessionStorageand non-HttpOnly cookies - Network request and response bodies, up to 50 KB each
Never collected: HttpOnly cookies (a browser extension cannot read them), passwords you type, or the contents of form fields.
This may include other people's personal data
If you capture a bug on a production site, the page can contain a real end user's information — their name in the interface, their data in an API response, their session in browser storage.
You control that risk:
- Storage, cookies and network bodies are off by default. Turning them on is a deliberate decision by a workspace admin.
- The HTML snapshot can be switched off by a workspace admin, and what it does collect is redacted before it is stored.
- Blocked sites. A workspace admin can list domains where capture is refused entirely — no screenshot is taken and nothing is collected.
- Automatic redaction. Before anything is stored we attempt to remove email addresses, authentication tokens, long hexadecimal strings and card-like numbers, and to mask values under keys whose names suggest a secret.
Be aware of the limits of that redaction. It is pattern-matching. It reliably catches things with a recognisable shape, and it will not catch a person's name, a postal address, a phone number, or an identifier that looks like ordinary text — including such text visible on the page and therefore in the HTML snapshot. If that is your risk, turn the snapshot off.
If you are testing against production data, treat a bug report as containing personal data and use the controls above.
Your role and ours
For bug report contents you are the controller — you decide what to capture and why. We are the processor: we store and process it to provide the service, on your instruction, and for nothing else.
3. Where your data is stored
On Google Cloud Platform / Firebase, in the asia-south1 region (Mumbai, India). Screenshots and report files are held in Firebase Cloud Storage; account and report metadata in Firestore.
If your users are in another country, their data is processed in India.
4. Who else touches it
Listed in full in SUBPROCESSORS.md. In short:
- Google (Firebase) — hosting, database, file storage, authentication
- Jira, GitHub, ClickUp — only when you connect them, and only the reports you choose to file. Sent using credentials you supply, at your instruction
Nobody else receives your data.
5. Staff access
We can access your data when needed to run the service — investigating a fault you have reported, or a suspected abuse of the platform.
An internal admin view lists workspaces, the email addresses of their members, and how many reports each has captured. It is restricted to the operator of the service.
6. Sharing a report outside your workspace
A share link is a secret token that expires after 30 days and can be revoked at any time. Only the token's hash is stored, so our database does not contain working links. A shared report exposes a fixed list of fields — never the reporter's identity or your integration settings.
One honest limitation: screenshots and report files carry their own long-lived access URLs. If someone copied one of those URLs while a report was shared, revoking the share does not invalidate it. We are working on this. Until then, treat a share link as permanently disclosing that report's screenshots.
7. How long we keep it
Until you delete it. There is no automatic expiry today.
- Deleting a report removes its database record and its files
- Archiving does not delete — an archived report stays until you delete it
- Deleting your account removes your profile, integration credentials and workspace membership
If you need a report gone, delete it. To have an entire account and its data removed, email qatoolshub@gmail.com and we will action it within 30 days.
8. Your rights
You can request access to, correction of, export of, or deletion of your personal data by emailing qatoolshub@gmail.com. We will respond within 30 days.
If you are an end user whose data appeared in a bug report captured by one of our customers, contact that customer — they decided to capture it and control it. Tell us and we will help identify and reach them.
9. Cookies
The dashboard stores a sign-in session and small preferences (theme, last workspace) in your browser. No advertising or third-party tracking cookies.
10. Security
Encryption in transit and at rest. Access to a report requires membership of the workspace that owns it, enforced on the server. Integration tokens are stored where no browser can read them.
We are a small operation and do not hold a formal security certification. What we do is described above and we would rather be accurate than impressive.
11. Children
Not intended for anyone under 16. We do not knowingly collect their data.
12. Changes
Material changes will be announced by email to workspace admins at least 14 days before taking effect.
13. Contact
qatoolshub@gmail.com — privacy questions, deletion and access requests. Anil Kumar Singh, trading as BugCapture.