Context
Follow-up to audit tracking issue #196.
Support bundles mask known secrets, credentials, URLs and email addresses, but can still contain local paths, share names, hostnames and other infrastructure identifiers. The current presentation can be mistaken for full anonymization.
Target
Make the privacy boundary explicit and provide stronger deterministic pseudonymization for infrastructure identifiers while retaining diagnostic value.
Acceptance criteria
- The UI and generated bundle documentation state clearly that bundles are sanitized but not guaranteed anonymous.
- The bundle inventory identifies data categories that may remain, without listing user secrets.
- Optional stronger pseudonymization covers local user paths, SMB share names, hostnames, private addresses and comparable infrastructure identifiers.
- Related occurrences use stable placeholders within one bundle so diagnostics remain correlatable.
- Repository paths and log relationships remain understandable after pseudonymization.
- Passwords, tokens, private keys and authorization headers remain fully removed rather than pseudonymized.
- Tests cover representative paths, shares, hostnames, private addresses and already-sanitized values.
- Existing support bundle generation remains usable when stronger pseudonymization is disabled.
Refs #196
Context
Follow-up to audit tracking issue #196.
Support bundles mask known secrets, credentials, URLs and email addresses, but can still contain local paths, share names, hostnames and other infrastructure identifiers. The current presentation can be mistaken for full anonymization.
Target
Make the privacy boundary explicit and provide stronger deterministic pseudonymization for infrastructure identifiers while retaining diagnostic value.
Acceptance criteria
Refs #196