Keep personal data out of logs, errors and anything a person is asked to send

[iderex]

The most common way personal data leaves a device is not a network call. It is a
log file that somebody is asked to attach to a bug report. A log holding a server
address, a username, a token and a list of what was watched is a disclosure with
a person's own hand on it.

What this produces

A rule for what may be logged at each level, with the personal fields named
explicitly rather than described. That list is also what #109 needs for the
recorded fixtures, so it is written once here and named there.

Identifiers shortened or replaced where they are needed for correlation and not
needed in full, so that a log stays useful for debugging without carrying the
data itself.

The same rule applied to the payload of every error kind in #4, since an error
that carries a full request is a log entry that travels further.

A diagnostics bundle a client can produce with the fields it excludes stated in
the bundle itself, so that whoever sends it can see what they are sending.

Done when

The rule is recorded. A test drives a full session at the most verbose level and
searches the output for every named personal field, failing on any hit. The
bundle names its own exclusions. Blocked on #4, #68 and #100.

[iderex]

The rule landed as docs/decisions/0071-what-may-leave-through-a-diagnostic-event.md, on cf9705d.

One thing this issue plans came out the other way round and it is worth stating first. The field list is not written here and named in #109; it is 0068's, which landed first and states it explicitly along with the question a contributor asks about a field neither document names. So this record names 0068 rather than copying it, and #109 reads 0068 directly. Copying it would put the same list in two documents that then disagree in the one situation where somebody is reading a document to find out.

Redaction is decided per field name, by the core, before the client's sink is called. Three treatments and no fourth. Excluded, which is the token and anything derived from it, a password, and whatever the secret store handed back. Reduced, which is a fixed-width prefix of a salted digest, covering the account identifier, server-supplied identifiers, the device identity, the server identity and its address. Carried whole, which is counts, durations, an error kind, a capability name, a status, a severity, an event identity, a boolean, none of which can differ between two people running the same build against the same server. A field nobody has classified is excluded, because the direction a default falls in on its own is the other one: an event is written by somebody who wants to see the value.

The salt is created when the core is created, held in memory, never written and never emitted. Within a run, two events about the same item carry the same correlator, so a report shows that one thing failed eleven times rather than that eleven things failed once, which is the whole of what the identifier was there for. Across runs and across devices it means nothing. The first of those is the point and the second is a real cost, paid by somebody chasing an intermittent fault across restarts.

The rule this issue asks for per level is answered differently from the way the question expects, and the record gives the reason rather than quietly not answering it. The redaction does not vary with severity. What varies at detail is how much is emitted, not how much is redacted, because detail is the level somebody turns on to answer a question and it is therefore the level running at the moment its output is about to be sent to a stranger. A per-level rule sounds careful and puts the decision in the hands of the person with the strongest reason to relax it.

The same rule applied to the payload of every error kind also comes out with a boundary the issue does not draw. An error returned to a caller in the same process keeps its address, because the caller is the client holding the address it handed the core a moment earlier, and redacting it removes nothing from anybody while making the payload useless for what it exists for. What is redacted is the copy that leaves through the sink: a failure event names the kind and carries reduced fields, never the payload whole. The boundary is the sink rather than the error type, which is 0101's placement, and it is why 0004's payloads stand. The two limits that hold in both directions were already 0004's: no payload holds a token, and answer-not-understood never carries the answer itself.

The bundle cannot be the core's, and that is the last thing the record settles. 0068 and 0100 both fix that an event is handed over and forgotten in the same call, with no ring buffer and nothing retained, so there is no store of past events to assemble. A client builds the bundle from what its own sink kept, and the core's half is the rule as data: for each field name it has ever emitted, which of the three treatments it applies, through a call that cannot wait. The statement is about what the core did rather than about what the client's sink did afterwards, and the record says so instead of implying a guarantee across a boundary the core cannot see.

Two of the three conditions here are untouched and the third is met in part. The rule is recorded. A test driving a full session at the most verbose level and searching the output for every named field is a statement about running code, and there is no language chosen, no build and no test command in this tree, with #21 open. The bundle naming its own exclusions is met only to the extent the core can supply the statement; the bundle itself is the client's and nothing in this repository will assemble one. This stays open on the test and on the bundle.