Session replay privacy risks and safer alternatives

Session replay tools promise to end vague bug reports: instead of asking what happened, you watch it happen. The appeal is real. So is the cost, and the cost is usually discovered later than the benefit.

The core problem is proportionality. Debugging needs a small number of facts about a single failed interaction. Continuous recording collects everything about every interaction, including data that has nothing to do with any defect and that you now hold, store, and are responsible for.

What does continuous recording actually capture?

A replay tool reconstructs the visitor's screen. To do that it must capture the page content, the input events, and the changes over time. That means it can capture, by default or by accident:

• Text typed into forms, including fields that were never submitted.
• Personal data rendered on the page — names, addresses, order history, medical or financial detail.
• Content belonging to other people, when a staff user views a customer record.
• Values that appear briefly, such as a one-time code or a card field before masking applies.

Most tools offer masking. Masking is a suppression list, which means it is only as good as your memory of every sensitive field on every page, including the ones added last week. A missed field is a silent failure: nothing breaks, the data is simply collected.

There is also scope creep. A tool installed for debugging is easy to repurpose for watching behaviour generally, and the recordings are usually retained far longer than any bug investigation needs.

What obligations does the recording create?

Recorded sessions are personal data. That brings real responsibilities regardless of intent.

You must be able to say what you collect and why, keep it only as long as necessary, protect it, and honour deletion requests. Recordings are hard to search selectively, so "delete this person's data" becomes an awkward operation. Access control matters too: a replay archive is a rich target, and a breach exposes sessions you never needed.

Consent is the sharpest issue. Visitors generally do not expect their session to be recorded. Disclosure in a privacy policy is not the same as a visitor understanding, at the moment they type, that their input is being captured.

What do you actually need to debug?

This is the question worth asking before installing anything. In practice, most investigations need a small, specific set of facts:

• Which page the action happened on.
• Which action the visitor took.
• What appeared instead of the expected result, including exact error text.
• Whether a request failed, and with which method, path, status, and duration.
• Whether the browser logged an error.
• Which build the visitor was running.

Notice that none of these require the content of what the visitor typed. Whether a field was filled in is structural. What it contained is personal. Defects live overwhelmingly in the structure — a missing field, an unexpected empty value, a request that returned 500 — not in the specific characters someone entered.

How does metadata-only evidence work?

Metadata-only means recording facts about data rather than the data. For a cookie, a form field, or a local-storage entry, that is three things: the name, whether it is present, and its approximate size.

That is enough to answer real questions. Was the session cookie present when the request failed? Did the time-zone field exist but sit empty? Did a stored value grow unexpectedly large? Each of these can be checked against the source without holding a single value belonging to a visitor.

The privacy properties follow directly. A password cannot leak from a record that never held it. A support engineer reviewing evidence sees structure, not someone's private message. A breach of the evidence store exposes field names, not customer data.

The limitation is honest: metadata will not tell you that a visitor typed an unusual character that broke a parser. You may still need a reproduction attempt for that. In exchange, you are not permanently accumulating everyone's input in case one of them one day matters.

Which safeguards should any evidence collection have?

Whatever tooling you choose, a few properties separate careful collection from indiscriminate collection:

• Bounded by event. Evidence attaches to a report the visitor deliberately submitted, not to every session.
• Fixed shape. The set of collectable fields is defined in advance, so a configuration change cannot start capturing values.
• Redaction at source. Token-like and email-like text is removed before storage, not after.
• Explicit consent for anything visual. A screenshot is a picture of whatever was on screen — see why screenshots need consent.
• Short retention. Evidence outliving the investigation is pure liability.
• No values, ever. Not "masked by default", but structurally incapable of holding a value.

The last one is the meaningful difference. A tool that can capture values and is configured not to depends on that configuration staying correct forever. A tool that cannot capture values has no such failure mode.

How IssueProbe handles it

IssueProbe collects evidence only when a visitor chooses to send a report, never continuously. Cookies, form fields, and local-storage entries are metadata only — a name, a presence state, and a size, with no value in any case. The schema rejects value-like and undocumented fields, and a website owner can disable a category but cannot configure a value field into it.

Console evidence is limited to errors and warnings, bounded, with token-like and email-like text redacted. Network evidence records the method, a path without query values, the status, the duration, and the time — never headers, bodies, credentials, query values, or fragments. A screenshot is captured only after a visible visitor action, previewed, explicitly approved, and removable before sending.

Read the exact widget privacy rules for the full field list, and what browser evidence helps investigate a problem for how each category is used in practice.