How to Record an Error Code Without Exposing Private Data
Preserve the exact code, message, language, timestamp, playback phase, app and operating-system versions, device class, and abstract scope. Before sharing, remove account names, email, tokens, cookies, full source URLs, addresses, network names, device identifiers, notifications, location, unrelated viewing history, and unnecessary copyrighted imagery.
In short: Preserve the exact code, message, language, timestamp, playback phase, app and operating-system versions, device class, and abstract scope. Before sharing, remove account names, email, tokens, cookies, full source URLs, addresses, network names, device identifiers, notifications, location, unrelated viewing history, and unnecessary copyrighted imagery.
An error screenshot can reveal more than the error. Build a minimal evidence record first, then choose the safest format.
Start with a written transcription
Copy capitalization, punctuation, spacing, code, and button labels. Add local time and zone, title timecode, startup or midplay phase, and whether the message recurred. A transcription often provides enough evidence without an image.
Do not replace the original language with a translation; add translation separately.
Identify essential context
Support may need app version, operating system, device class, authorised source category, title version, track, and network type. Use abstract values such as “TV on Wi-Fi” instead of full hardware IDs and network names.
Read the playback error before trying a fix to capture phase and scope.
Inventory screenshot risks
Check status bar, notifications, profile avatar, email, account ID, title history, search text, clock, precise location, network name, source URL, QR code, and reflected room details. Crop to the dialog and cover remaining fields with irreversible redaction.
Do not rely on a translucent blur that may be reversible or leave metadata unexamined.
Original evidence: redaction map
| Field | Keep? | Safe representation | Risk if exposed |
|---|---|---|---|
| Exact code/message | Yes | Verbatim | Low unless code embeds ID |
| Time/phase/version | Usually | Coarse time if public | Activity pattern |
| Account/token/cookie | No | “Authenticated” | Account takeover/privacy |
| Source URL/address | No | “Authorised source A” | Access and topology |
| Network/device ID | No | “Wi-Fi/device A” | Tracking/topology |
| Title imagery/history | Minimum | Text context | Copyright/privacy |
| Logs | Requested slice | Redacted trusted upload | Broad data exposure |
Inspect whether the error code itself contains a request, session, or account identifier.
Redact logs before sharing
Logs may include headers, cookies, tokens, addresses, file paths, source endpoints, device names, and account identifiers. Do not use broad find-and-replace without reviewing context; make a copy, redact it, then search for known sensitive patterns.
The support-evidence guide recommends a minimal time window and trusted channel.
Choose the audience
Public forum: use the smallest abstract record. Official support: follow its secure upload instructions and privacy policy. Device or provider support: send only evidence relevant to that boundary. Never send credentials even if someone requests them in chat.
Verify the support domain and account before uploading.
Apply retention limits
Delete temporary screenshots, exported logs, and unredacted copies when the support purpose ends, subject to legitimate record needs. Restrict access and use encryption where appropriate. RFC 6973 and the NIST Privacy Framework emphasize systematic privacy risk management.
Document who received the file and when.
Keep the original and redacted copies clearly separated while the case is active. Open the final attachment once in a clean viewer before upload, confirm that overlays are permanent, and verify that the filename itself contains no account, title-history, device, or location detail.
Preserve diagnostic usefulness
Redaction should not remove exact code, message, phase, version, scope, recurrence, or recovery. The error taxonomy can use those fields without private data.
If support needs a removed field, ask why, use a trusted channel, and disclose the minimum value.
Norva-specific handling
Use current official Norva support channels and Norva's privacy information. Norva organises compatible authorised sources; do not attach credentials or third-party source tokens to a Norva error report unless an official secure process explicitly requires a narrowly scoped diagnostic.
Frequently asked questions
Is an error code always safe to post publicly?
No. Some codes or request strings can embed identifiers. Inspect the entire value and official guidance.
Is blurring a screenshot sufficient?
Not always. Crop first, use irreversible redaction, remove metadata, export a copy, and inspect the final file.
Should full logs be retained after resolution?
Usually not. Follow the stated retention purpose and delete unnecessary sensitive copies securely.