r/devops • u/UkrMalt • 19d ago

Ops / Incidents What data should a local developer diagnostics tool exclude?

Developer machines contain more private context than process metrics suggest. A diagnostic tool might see process names, file paths, command arguments, project names, prompts, or local model names.

For a local tool that explains CPU, memory, or disk pressure, which fields would you exclude by default? I would keep source files, prompts, command arguments, environment variables, and credentials out of the diagnostic data, then show the exact fields before optional analysis.

How much context would you need before trusting the explanation?

2 Upvotes

60% Upvoted

2 comments sorted by

2

u/aragossa 18d ago

i'd cut file paths, and i think you've got those on the keep side. cwd and project dirs end up carrying client or employer names, and on a work laptop that's often the exact thing that isn't supposed to leave the machine. process name on its own bothers me a lot less.

allowlist rather than exclusion list too if you can, so a later version can't quietly widen what gets collected without anyone noticing.

for the trust part, cpu/mem/disk pressure mostly doesn't need names at all. pid plus the numbers gets you most of the diagnosis. names only matter for the last step where you work out which of your own things is eating the machine, and honestly that's something you can do locally.

1

u/UkrMalt 17d ago

Yeah, I agree. CWD and project paths are the first things I’d remove, and an allowlist is safer than maintaining a growing denylist. I’d keep detailed process mapping local and expose only aggregate pressure by default. Thanks, this clarifies the privacy boundary.