Privacy and data

Exactly what BugLoop collects, why, how long it stays, and what that means for GDPR and cookie banners.

What is collected

When a visitor submits the form, and only then, BugLoop stores:

  • What they wrote: type, severity, summary, description, and any custom fields — plus a design aspect or steps to reproduce where your project asks for them
  • A screenshot of the page, only if they pressed the button and confirmed the preview
  • Their email address — only if they chose to give it
  • The page URL and page title they submitted from
  • The browser user agent string and the viewport size
  • Whether the description was typed, dictated, or both — a one-word label, never any audio
  • A salted hash of their IP address, used solely for rate limiting

What is never collected

There is no passive collection phase. The widget does not observe clicks, scrolling, mouse movement, keystrokes outside its own form, form fields elsewhere on your page, or page-to-page navigation.

The widget sets no cookies and writes nothing to localStorage or sessionStorage on your visitors' browsers.

A screenshot is the only thing that can leave the browser before send, and only on a deliberate press: the reporter asks for it, sees exactly what it contains, and can throw it away. Nothing is captured in the background, and no image exists at all unless the button is pressed.

Screenshots and what is masked

Before the image is rendered, the widget bullets every input and textarea on the page and hides everything carrying data-bugloop-mask. That happens on the page itself, so there is no unmasked version of the image anywhere.

Masking is not a setting and cannot be turned off. A tool that ships to other people's sites must not be able to exfiltrate a half-typed password because a visitor pressed a button. What you do have to do is mark the regions only you know are sensitive — Screenshots covers the two attributes and the one gap, shadow roots on your own page, that the automatic pass does not reach.

Images live in a private bucket, are read only through time-limited signed URLs, and are deleted when the report or the project is deleted.

The footnote on "no third-party requests"

BugLoop initiates no third-party request of its own. Two features cause the browser to make one, and both require a deliberate press. The first is dictation: the microphone button uses the browser's own speech API, and in Chrome that API streams the audio to Google for transcription.

So dictation is off unless you turn it on for a project, the widget shows the reporter a one-line notice the first time the button is pressed, and it is written down here. BugLoop never receives or stores the audio — only the text the browser hands back, and a label recording that dictation was used.

The second is the screenshot. Drawing your page into an image means re-reading the assets it is already displaying — its images, its stylesheets, its webfonts — and where those are hosted elsewhere, that is a request to another host. It is the same request your page already made to show you the asset, and BugLoop forces it to carry no cookies and no referrer, so nothing about the visitor is disclosed that the asset host did not already have. But it is a request, and it is not one BugLoop can suppress without shipping screenshots with the images missing.

If you would rather your privacy policy say "no third-party requests" with no footnote attached, leave both dictation and screenshots off for that project. With both off, nothing in the widget contacts anyone but BugLoop.

Cookie banners

Because BugLoop sets no cookies and stores nothing on the device, the widget itself does not require cookie consent under the ePrivacy Directive. Personal data is only processed when a visitor voluntarily submits it, with the purpose stated in the form.

Screenshots do not change that: an image is produced on a press and stored on our side, never on the visitor's device. Dictation does not store anything on the device either, but it does involve a third party, which is a disclosure question rather than a storage one.

This is a description of how the product behaves, not legal advice. Confirm your own obligations with your counsel.

Data subject requests

Feedback records are deletable from the dashboard by an organization admin, and deleting a project deletes every report under it. If you need a report removed on behalf of a visitor, deleting the record removes the email address, the IP hash, and any screenshot along with it.

Issues already filed in your GitHub or Jira are yours to manage — BugLoop cannot reach into your tracker after the fact.