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.
We also publish a second, free extension — Mobile View — which collects nothing at all. It is covered immediately below, and the rest of this policy does not apply to it.
Mobile View by BugCapture — a separate extension that collects nothing
Mobile View is a free browser extension from the same developer. It draws device-sized frames on top of the page you are already on, so you can see how a site behaves at mobile, tablet and desktop widths. It is not BugCapture, and no other section of this policy describes it.
It collects nothing, because it cannot. Mobile View makes no network request of any kind. There is no server, no account, no analytics and no telemetry — nothing you do in it reaches us, because there is nowhere for it to go.
It stores one thing, and only in your own browser: your interface preferences — the device sizes you chose, any custom sizes, favourites, the layout, zoom level, theme, interface language, whether the drawn browser bars are shown, which side the panel sits on and the toolbar setting. That never leaves your device, and clearing the extension's storage removes it.
It does not store or transmit the addresses of pages you visit, page content, screenshots, console output, network activity, form values, keystrokes or clicks. The Sync feature passes a scroll, click or keystroke into the preview frames as it happens and keeps no record of it — nothing is buffered and nothing is recorded.
Keep open after reload, if you turn it on for a site, is a permission held by your browser rather than by us. Your browser drops it every time it starts, so no access to any site is kept from one session to the next.
The two products do not share data. Nothing in Mobile View sends anything to a BugCapture workspace. If that ever changes, this section and the extension's store listing will be updated before the feature ships.
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
- If you record a video, the clip you recorded. On Firefox this is the whole browser window — including the tab strip, address bar and bookmarks bar — because Firefox does not let an extension capture a single tab. Chrome and Edge capture only the tab, or only the area you dragged. Check what is on screen before recording in Firefox.
- 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.
Voice input (dictation)
The New report dialog, and the browser extension's manual report, offer a microphone button on the Title and Description fields. It is optional, off until you press it, and typing always works instead.
Your voice is sent over the internet, and we never receive it. Dictation uses the speech recognition built into your browser. When you use it, your browser sends the recording to an online speech service run by the company that makes the browser — in Chrome, that is Google. This happens between you and your browser's maker, under their privacy policy, not ours. BugCapture is not part of that exchange and has no access to it.
What reaches us is only the text that appears in the field, and only if you then create the report — exactly as if you had typed it. Specifically:
- No audio is recorded, stored or uploaded by BugCapture, at any point
- No transcript is stored separately from the report you create
- Nothing is sent while you are still speaking; you can edit or delete the text before creating the report, or close the dialog and nothing is kept
- Stopping the microphone, closing the dialog or pressing Esc ends the recognition immediately
If you would rather no audio left your machine at all, do not use the microphone — every field can be typed.
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 India. Account and report metadata are held in Firestore and screenshots and report files in Firebase Cloud Storage, both in the asia-south2 region (Delhi, India). The server functions that process them run in asia-south1 (Mumbai, India).
Screen recordings are stored separately, on Cloudflare R2, with automatic region placement — Cloudflare selects the location. Recordings are the only data held there.
If your users are in another country, their report data is processed in India, with the exception of recordings as described above.
4. Who else touches it
Listed in full in SUBPROCESSORS.md. In short:
- Google (Firebase) — hosting, database, file storage, authentication
- Cloudflare (R2) — storage and delivery of screen recordings
- Razorpay — payments, if you buy a Team plan. Your card details are entered on Razorpay's own checkout and never reach our servers
- The integrations you connect — Jira, GitHub, ClickUp, Jira Service Management, GitLab, Linear, Notion, Trello, Asana, Azure Boards, Bitrix24, Sentry, Slack, Microsoft Teams, or your own webhook endpoint. Only the reports you choose to file, sent using credentials you supply, at your instruction
Nobody else receives your data.
The one thing that is not on this list, because it never passes through us, is dictation audio: if you use the microphone button, your browser sends that recording straight to its maker's own speech service. See Voice input in section 2.
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
The bug report: until you delete it. Title, description, environment, severity, priority, console messages, network summary and timestamps stay for as long as the workspace exists.
Screenshots and screen recordings expire, because they are almost all of the storage we pay for:
| Plan | Screenshots, full-page shots, report.json and recordings |
|---|---|
| Free | 30 days from when the report was filed |
| Team, subscription active | Kept — nothing expires while you are subscribed |
| Team, subscription ended | 1 year from the day the subscription ended, then all of it |
When they expire we delete the files and the report reads "Screenshot expired". Nothing else about the report is removed.
Three things worth being plain about:
- Which window applies is decided when the expiry runs, not when you filed. Upgrade and your existing reports immediately stop expiring.
- If your subscription ends, nothing is deleted for a year. The year runs from the day the subscription ended, not from the date of each report — so an accidental lapse costs you nothing, and you have a full year to resubscribe or export. Resubscribe at any point inside it and everything is kept again. When the year is up, the assets for that workspace are removed together. We warn in the product for 30 days before that happens.
- Copies you sent elsewhere are not ours to delete, and they do not expire. When you file a report to Jira, GitHub, Linear, ClickUp, Notion, Trello, Asana, Azure Boards, Sentry or Slack, the screenshot and details are uploaded into that tool and become that tool's data. Expiry here removes our copy only. The one in your tracker stays for as long as your own retention rules keep it — in practice, usually forever. If you need it gone, you have to delete it there.
Deleting a report deletes its files immediately, on any plan.
- 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.