Logging under privacy constraints

"They told me to log everything so I could debug anything. Then a subpoena arrived, and I discovered that everything included the exact walking gait of forty thousand people who never agreed to be a debug artifact."

A Chastened AI Agent

Why a sensor log is different from an application log

Ordinary backend engineering has a comfortable habit: log liberally, keep it for a while, grep it when something breaks. That habit is actively dangerous for sensor fleets for three reasons. First, the payload is the sensitive thing. A stack trace is about your code; a raw inertial-measurement-unit window is about a human's movement, and gait alone is a biometric identifier that re-identifies people across sessions (the activity and behavior signals of Chapter 26). Second, the volume is enormous and continuous: a fleet streams high-rate signals from every device every second, so "log everything" scales into petabytes of the most intimate data you could hold. Third, the meaning is latent. A single PPG trace looks innocuous, yet it carries heart rate, arrhythmia markers, and stress state; audio captured "just for a bug" contains speech. What looks like a debug convenience is a covert health and behavior dossier.

The reframe is to treat logging as a design surface with an explicit privacy budget, not as an afterthought you bolt on with a retention cron job. Every field you log should survive a simple question: what operational decision does this enable, and is there a less identifying representation that enables the same decision? Most of the time there is.

The logging hierarchy: minimize before you emit

Organize what a device can send into a hierarchy ordered by sensitivity, and default every log line to the least sensitive tier that answers the operational question. The tiers, from safest to most dangerous, are: operational metadata (device id pseudonym, firmware version, model version, timestamps, latency, battery, error codes) that describes the system rather than the subject; derived scalars and events (a predicted class label, a confidence score, a "dropout detected" flag) that summarize an inference without the input; aggregate statistics (per-device or per-cohort histograms and quantiles of features, computed on-device and emitted periodically); and only at the bottom, raw or near-raw signal windows, which should be the rare, deliberately gated exception rather than the default.

Two transformations move data up the hierarchy toward safety. Redaction removes or masks identifying fields: replace a stable device_id with a rotating pseudonym, drop precise GPS in favor of a coarse geohash or an H3 cell, and strip any free-text or audio that could contain speech (the localization and RF-positioning identifiers of Chapter 25 are especially re-identifying). Aggregation replaces per-sample values with summaries computed before egress, so the raw window never leaves the device. A drift monitor does not need a user's heartbeat; it needs a 32-bin histogram of the beat-interval feature, which reveals distribution shift while hiding the individual.

Differentially private fleet telemetry

Aggregation alone can still leak. A per-cohort count of "users whose stress feature exceeded a threshold" can expose an individual when a cohort is small or when an adversary compares two releases that differ by one person. The principled defense is differential privacy (DP): add calibrated random noise to each released statistic so that the presence or absence of any single person changes the output distribution by at most a bounded factor \(e^{\varepsilon}\). Formally, a randomized mechanism \(M\) is \(\varepsilon\)-differentially private if for all neighboring datasets \(D, D'\) differing in one record and all outputs \(S\),

For fleet telemetry the most robust flavor is local differential privacy (LDP), where each device privatizes its own contribution before it ever leaves the hardware, so the server never sees a true individual value even if the server is later compromised (this is the same trust model as the on-device privacy of Chapter 64). The classic mechanism for a binary attribute is randomized response: each device reports its true bit with probability \(p\) and flips it otherwise, and the server debiases the noisy sum to recover an accurate fleet-level proportion while any single report is deniable.

import numpy as np

def randomized_response(bit, epsilon, rng):
    # Local DP for one boolean per device. p is chosen so the flip
    # probability satisfies epsilon-LDP for a single binary report.
    p = np.exp(epsilon) / (np.exp(epsilon) + 1.0)
    return bit if rng.random() < p else 1 - bit

def estimate_true_rate(noisy_bits, epsilon):
    p = np.exp(epsilon) / (np.exp(epsilon) + 1.0)
    obs = np.mean(noisy_bits)          # what the server sees
    return (obs + p - 1.0) / (2.0 * p - 1.0)  # debiased estimate

rng = np.random.default_rng(0)
epsilon = 1.0
true_rate = 0.18                       # 18% of devices hit the event
n = 50_000
truth = (rng.random(n) < true_rate).astype(int)
reported = np.array([randomized_response(b, epsilon, rng) for b in truth])
print(f"true={true_rate:.3f}  estimated={estimate_true_rate(reported, epsilon):.3f}")

The code above shows the whole bargain in miniature. At \(\varepsilon = 1\) and fifty thousand devices, the debiased estimate lands within a few tenths of a percent of the truth while each individual report carries plausible deniability. Smaller \(\varepsilon\) buys more privacy at the cost of more variance, so you spend an explicit privacy budget: the total \(\varepsilon\) across all statistics you release, tracked like any other operational quota. This is the accounting that lets you say precisely how private your telemetry is, rather than hoping aggregation was enough.

Retention, access, and audit for the raw data you keep

Some raw collection is unavoidable: reproducing a specific failure sometimes needs the actual window that triggered it. The discipline is to make that collection small, consented, and short-lived, and to wrap it in controls. Set a retention limit and enforce it with automatic expiry, not a hopeful policy document; raw sensor windows should live for days, not forever. Gate collection behind explicit, revocable consent so raw data comes only from users who opted into a debug or improvement program. Apply access control so raw payloads are role-restricted and every read is logged, turning "who looked at this person's heartbeat" into an answerable question. Keep pseudonymization keys separate from the payload store so that re-identification requires deliberately joining two systems rather than reading one. And record a provenance and consent tag on every raw record, extending the data-contract idea of Section 69.1, so a later request to delete a user's data can find and purge every window they contributed. These controls are what make a log store defensible when, not if, someone asks what is in it.

What's Next

In Section 69.7, we turn logs into action: incident response for sensor fleets, how to detect, triage, contain, and post-mortem a failure using exactly the privacy-respecting telemetry this section taught you to keep, and how to roll back a bad model or quarantine a misbehaving cohort without needing the raw data you were careful not to hoard.