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.

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.


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, sessionStorage and 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.


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.


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.


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.


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.


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.


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.


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.


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.


The dashboard stores a sign-in session and small preferences (theme, last
workspace) in your browser. No advertising or third-party tracking cookies.


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.


Not intended for anyone under 16. We do not knowingly collect their data.


Material changes will be announced by email to workspace admins at least 14 days
before taking effect.


qatoolshub@gmail.com — privacy questions, deletion and access requests.
Anil Kumar Singh, trading as BugCapture.