Public Log Bundles Are a Symptom, Not Merely Bad Judgment

Nothing especially alarming appears in the three public support threads below. That is precisely what makes them alarming.

Customers encounter routine product failures. Support asks for diagnostic output. The customer pastes it into the public conversation. Everyone proceeds as though this is simply how technical support works.

Most of the time, the result is harmless. The problem is that the same habit, repeated often enough, eventually will not be.

Three ordinary support exchanges

In a Portworx community thread, a customer was trying to resolve a license-renewal failure. A staff member asked the customer to paste the alerts generated by Portworx. As troubleshooting continued, the customer posted command output from inside a container, including network and endpoint details. Support then asked for Portworx diagnostics, generated as a tarball.

In a MinIO GitHub issue, a customer troubleshooting an mc mirror failure pasted JSON log output and a complete mc admin info --json result into the public issue.

In a Neo4j community thread, a customer could not restore an offline backup. When asked whether debug.log contained anything that might explain the problem, the customer pasted long excerpts from debug.log and neo4j.log, along with a Google Drive link to the complete files. The public excerpts included server and database identifiers, listening interfaces and ports, filesystem paths, and ownership information.

These are not presented as breaches. I found no evidence of material harm, and the people involved appear to have been acting in good faith to solve legitimate technical problems. The vendors are also not unusual. Similar exchanges can be found across public product forums and issue trackers.

That is the point.

Individually benign, cumulatively risky

It is tempting to review each excerpt, decide that it contains nothing terribly sensitive, and conclude that no real problem exists.

That evaluates the artifact. It does not evaluate the practice.

A diagnostic-handling practice should not be judged by the least sensitive bundle it happened to expose. It should be judged by what it predictably permits when repeated across thousands of incidents by tired people under pressure.

Logs are not carefully authored reports. They are accumulated residue from an application, its dependencies, the operating system, deployment tooling, integrations, and sometimes the customer's own configuration. Depending on the product, they may contain:

• Usernames, email addresses, account or sensitive identifiers
• Hostnames, internal addresses, ports, network topology, and system configurations
• Filesystem paths and service-account names
• Software versions and enabled components
• Query text, request bodies, object names, or portions of customer records
• Authentication headers, access tokens, connection strings, or other secrets emitted in error

The customer seeking help may not know what every subsystem writes. The support engineer requesting the bundle may not know either. Even a vendor-supplied collection tool can sweep up output from components owned by someone else.

“Review and redact it before posting” sounds responsible, but it is a weak control. It makes the person least able to interpret the diagnostic material responsible for finding every dangerous value inside it—usually while that person is distracted by a broken production system.

This is how a culture forms

I have run IT and a support organization in an environment where privacy obligations, including HIPAA requirements, were part of daily operations. Public diagnostic disclosure by one of my support engineers would not have been treated as a harmless shortcut. It would have been a serious policy violation. If a customer began posting sensitive diagnostic material, support would have been expected to stop the exchange, explain the appropriate practice, and move it to an approved channel.

That may sound severe when the particular log excerpt contains nothing damaging. But operational culture is built from what an organization permits during ordinary work, not from what its policy manual says should happen during an extraordinary breach.

If engineers routinely ask for output in public threads, customers learn to paste output into public threads. If nobody interrupts the practice, it becomes normal. Eventually someone posts the wrong bundle.

The failure is then blamed on an inattentive customer or an insufficiently cautious engineer. Both were trying to get business done. Both may have made a mistake. But the system placed them on a path where uncontrolled copying was the natural next step.

A private upload portal is better...but incomplete

Moving the same tarball into a private support portal reduces public exposure. It does not eliminate the underlying problem.

The vendor has still acquired another copy of potentially sensitive customer data. That creates questions the support ticket itself cannot answer:

• Who inside the vendor can retrieve it?
• How long will it be retained?
• Is it replicated into backups or test systems?
• Can access be revoked after the immediate problem is resolved?
• Can the customer see who examined it and why?
• What happens when the bundle crosses national, contractual, or regulatory boundaries?

A private repository of diagnostic bundles can also become a concentrated target. It is safer than a search-indexed forum, but “not public” is not the same as “well governed.”

Design support around access, not extraction

The safer model begins with a different question.

Instead of asking, “How can the customer send us everything we might need?” ask, “How can the customer let us reach only what we need, only for as long as we need it?”

That suggests a remote-support workflow with explicit properties:

• The customer knowingly authorizes access to a specific environment or diagnostic capability.
• The grant is narrowly scoped rather than equivalent to opening the network.
• Access expires, and the customer can revoke it immediately.
• Every connection and material action is attributable and auditable.
• Diagnostic evidence remains where it was produced whenever possible.
• Support can begin without publishing an endpoint, exchanging a VPN configuration, or teaching the customer to export a mystery archive.

There will still be legitimate reasons to capture and transfer evidence. But extraction should be a deliberate exception with visible custody, not the default mechanism for remote diagnosis.

This is not principally a plea for customers to be more careful. Carefulness does not scale as a security architecture. People follow the path their tools and support processes make available. This is especially true when something important is down.

The question is not why a customer pasted the bundle.

The question is why exporting and publishing a copy was the shortest path between a broken product and someone capable of fixing it.