Why screenshots in bug reports need consent

A screenshot is the most useful single piece of evidence in a bug report and the most dangerous. It shows the exact visible state — the error text, the selected control, the layout as it actually rendered — which often answers in one glance what several paragraphs cannot.

It also captures everything else that happened to be on screen. That is not an edge case; it is what a screenshot is.

What ends up in a screenshot that nobody intended?

The reporter is focused on the broken thing. The image contains the entire viewport.

Commonly captured without intent:

• Other people's data. A staff user reporting a bug on a customer record captures that customer's details.
• The reporter's own private data. Their address, order history, or account balance sitting in the same page.
• Adjacent context. A visible browser tab title, a bookmark bar, a notification, an open email in another pane.
• Transient sensitive values. A partially entered card number, a one-time code, a token in a visible address bar.

Automatic capture makes this worse. If an image is taken at the moment of failure without the reporter seeing it, nobody has evaluated what it contains. The reporter cannot object to something they never saw, and the recipient inherits data they did not ask for and cannot easily justify holding.

Why is consent the right control?

Because the reporter is the only person positioned to make the judgement.

They know whether the record on screen belongs to someone else. They know whether the number in the corner is sensitive. No masking rule can encode that, because sensitivity depends on context the software cannot see.

Consent only works if it is informed, which requires three things in sequence:

1. A visible action. The reporter deliberately starts the capture. Nothing is taken in the background.
2. A preview. They see the exact image that would be sent, at a size where they can actually read it.
3. A real choice. They can approve it or remove it, and the report still sends without it.

Remove any one and consent becomes decorative. A preview too small to read is not review. A capture that cannot be removed is not a choice. A screenshot attached automatically with a checkbox to opt out is not a deliberate action.

Does this cost you evidence?

Slightly, and the trade is worth making.

Some reporters will decline. Some will remove an image after seeing what it contained — which is the safeguard working exactly as intended, not a loss. What you receive is a smaller set of images that people knowingly agreed to share, which is a much better position to be in than a large archive of images nobody reviewed.

You also lose very little diagnostically. Most of what a screenshot proves — that an error appeared, which page, which control — is also available from the page path, the visible error text, failed request metadata, and console errors. The screenshot is confirmation and detail; it is rarely the only route to the answer.

What should you do with the ones you receive?

Consent at capture is not the whole story. An approved screenshot is still an image of someone's screen, and it should be handled accordingly:

• Restrict access. Only people who need it for the investigation.
• Keep it out of public reach. Not on a public URL, not in a shared bucket with a guessable path.
• Retain it briefly. An image outliving its investigation is liability with no benefit.
• Never paste it into a reply. Especially not to a different person than the one who sent it.

If a screenshot turns out to contain data that should not have been shared, delete it and note that you did. The reporter approved sharing it with you for a purpose; that approval does not extend to keeping it indefinitely.

What about redacting automatically?

Automatic redaction — blurring anything that looks like a card number, an email, or a name — sounds appealing and is unreliable in both directions.

It misses things, because sensitivity is contextual: a normal-looking string can be a private identifier in your domain. It also over-blurs, sometimes obscuring the very error message that made the screenshot worth sending.

Automatic redaction is a reasonable second layer. It is not a substitute for a human looking at the image before it leaves their machine.

How IssueProbe handles screenshots

IssueProbe captures a screenshot only after a visible visitor action. It uses browser screen-capture permission when available and a visible file input otherwise, so nothing is ever taken silently.

The visitor sees a preview, approves inclusion explicitly, and can remove the image before sending. The evidence review step also shows the configured privacy link, so the visitor can read what is collected before deciding. After a report is sent, the next report starts with a blank form, no prior consent, and no carried-over screenshot.

A submitted screenshot must match its declared PNG, JPEG, or WebP signature and size limits. It is stored outside the public web root and reaches an authorized surface only through an exact report relation. Retention follows the plan — seven days on Free, thirty days on Pro — and expired image bytes are removed from storage before the matching record.

The widget is available in English, Portuguese, and Spanish, and consent is requested in the visitor's language rather than in yours.

Read the exact widget privacy rules, and see session replay privacy risks for why deliberate, bounded evidence beats continuous recording.