security

Why support bundles keep failing the password-manager sniff test (by design)

Any export flow that ships full Documents, AppData or Desktop paths to a stranger is one autocomplete away from catastrophe. The sane bounds around support data.

ProofTune Project··4 min read
Security & trust illustration Security & trust

The incident shape everybody knows

“Found it! Attached is AppData\Local\…\Login Data so you can see the error.” Thirty seconds of helpfulness, years of consequences. Support-bundle flows that accept arbitrary files are to blame as much as threadbare judgment.

What isn't allowed to be in scope

  • Browser profile directories wholesale (cookie stores nor login databases).
  • SSH/GPG/keyring material, DPAPI blobs, token caches.
  • Anything named like an export — .kdbx, wallet files, config.yml with tokens, .env trees.

The exporter pattern that survives contact: fixed field list (known-innocent by construction), no path parameters, preview-first screen-render before save, and explicit in-bundle documentation of what was deliberately excluded so the receiver can't “just add” it later.

Sharing discspline: even a clean bundle, once sent, is outside your control. Send the minimum. The bundle spec at the Evidence section is a working reference of how floor-level data answers 90% of support asks.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.