H3.14.4PII redaction in error reportsdesignresearch

User content in reports has to be redacted

Aliases: redaction · PII · telemetry privacy

What it is

An error payload easily takes field values, filenames, message bodies, and addresses with it, because those often sit on the line that broke. User content must be redacted: do not collect raw text by default; where shape is needed, use a class or a hash. A fixer can still replay the task and cannot read a secret. Without this layer, automatic reporting turns from a recovery tool into a silent leak of content. This entry is about content in the payload. It is not about whether to send, or whether the path is complete.

Why it happens

Exception objects, URLs, log interpolation, and “dump the current form state” are all raw-text doors. Raw text almost never adds repair value: “this was an email field, length exceeded” is enough, not the address. Once raw text enters the log stack, access control, retention, and subprocessors all see a copy that should not have left the device. Redaction has to happen before leaving the device: classify (email / phone / free text), truncate, irreversible-hash identifiers. Deleting later in the warehouse does not recall copies already synced elsewhere. If people cannot see that their content is in the report, they cannot decide to opt out of diagnostics either.

Studying it

Report a failure that contains typical fields, then audit the payload. Compare no redaction, field-level classification, and a ban on free text.

Independent variables: whether raw text is stripped on the client, whether URL query strings are kept, whether attachments upload. Dependent variables: rate of still being able to reproduce, count of identifiable personal data in the payload, whether a reviewer can read content.

Do not run “collect first, see if there is PII” on real traffic. Use fixture data.

Where it stops holding

When the user explicitly attaches a screenshot or log and sees what will be sent, richer material may go—that is informed consent, not default reporting. Crash dumps often contain raw text; default them off, or only inside an opt-in diagnostic pack. Audit logs that regulation keeps longer stay separate from error reports; “audit” is not an excuse for unredacted reporting. Internal employee tools still redact; internal is not no privacy.

Applying it

  • Default report allowlist: surface IDs, action types, error codes, version, classified field types. Field values, message bodies, file contents, precise coordinates stay off the list.
  • Before send, the client scans URLs, exception messages, and custom context for email, phone, and ID patterns and strips them.
  • Settings explain in one human sentence what is reported, and offer a look at the latest redacted sample.
  • Verify by walking a failure with fake personal data in real formats, then opening the outbound payload. If that fake string is readable, redaction did not happen before leaving the device.

Related

  • Within the group: H3.14.1 Client errors must report themselves · H3.14.2 Reports need the path, not only the stack · H3.14.3 A spike in reports is itself an alarm
  • Adjacent: H3.03 Tone of error copy · H4.04 Revocable permissions · H1.08 Draft autosave
  • Search terms: PII redaction · error telemetry privacy · diagnostic opt-out

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H3.14.4