Your Folder Names Should Stay Out of Support Logs

Suppose your collection lives in a folder named after a family member. A scan fails, and you send a diagnostic excerpt to support. You want help with the scan. You probably did not intend to include your Mac account name, the person's name, and the arrangement of your home directory in the same message.

A folder path can carry all of that. Even a fairly ordinary path such as /Users/alex/Music/Family Recordings says more than “a folder source failed.” A work collection could reveal an employer or project. The music files can stay on your Mac while their names travel in an error report.

This is why logging deserves its own privacy review. A network request and a support log are different surfaces. Care with one does not automatically protect the other.

What support actually needs

A useful diagnostic records the operation, the failure, and enough context to connect related events. Was the app reading an older cache format? Did a folder source fail repeatedly? Did the next attempt concern the same source?

The full path is often unnecessary for those questions. Private Press gives a collection source a diagnostic token consisting of its kind and a short digest of its identifier. For a folder, the kind is folder. The digest supplies a stable handle for connecting messages about that source.

That lets someone reading the log follow repeated events without seeing the raw path in the source-identifier field. The app still needs the real identifier internally to distinguish collections. Choosing a smaller representation for diagnostics does not change where your files live or how the app finds them.

There is a subtle trap here: calling something an “ID” does not make it safe to publish. Private Press's raw folder-source identifier includes the folder path. A developer reviewing a log statement has to inspect what went into the identifier, rather than assuming that its type or variable name means it contains a random number.

Public is a deliberate choice

Apple's unified logging system supports privacy annotations on values included in a message. Strings and objects are redacted by default; marking a value public makes its contents visible. Apple describes both behaviors in Explore logging in Swift.

That is a useful default, but an application can override it. If a path-bearing identifier is marked public, the operating system is following the application's instruction when it displays the path. The problem has to be fixed at the logging call.

One cache-recovery notice uses the short source token instead of the raw path. It explains that the old cache format will be discarded and the collection rescanned. Someone investigating the scan can understand the decision without needing the folder’s name.

This approach also keeps the log useful when multiple folder collections are involved. A message that only says “folder” cannot help distinguish two sources. A stable token supplies that missing connection, within the limitations of a short digest.

Read the log the app really produced

Source code shows what the app intends to log. Private Press also tests a real example: it creates a folder source with recognizable personal text in its path, triggers the cache warning, then reads the operating system’s log. The test checks that the warning and short token appear and the username and raw path do not. Requiring the warning to appear prevents an empty log from passing the check.

That regression check covers this warning only. It does not certify every log or support file, but it checks that this diagnostic remains useful without directly printing the folder identifier.

A short hash does not make you anonymous

The token uses the first four bytes of an unsalted SHA-256 digest, rendered as eight hexadecimal characters. It is a correlation handle. It is not encryption, and it is not a confidentiality boundary.

Someone who suspects a particular folder identifier can hash that candidate and compare the result. Folder names often have predictable pieces. A cryptographic hash does not turn a small set of likely paths into an unguessable secret. Truncation also means different identifiers can produce the same token, so it should not become proof of unique source identity outside its diagnostic role.

The benefit is narrower and useful: an ordinary reader does not receive the path directly in that field. Describing the token as anonymous or irreversible would promise protection that this implementation does not provide.

When reporting a problem, start with the app version, the action you took, and the error you saw. If a diagnostic excerpt is requested, review the excerpt before sharing it. Screenshots, copied filenames, and logs from other components can carry their own personal details. A source-token safeguard does not remove those for you.

You should be able to get help with your collection without casually publishing its folder names. Keeping the operation understandable, preserving a limited correlation handle, and testing the actual emitted notice are practical steps toward that standard.