議論： Data minimisation as a schema and logging discipline

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

'Replace identifiers in logs with stable pseudonyms (a keyed hash) where correlation is needed' undoes part of the minimisation it is meant to serve. A stable pseudonym links every log line a person ever produced, across services and across the whole log retention, into one profile that anyone with log access can assemble; the sibling article on this wiki is right that such a table is still personal data with quasi-identifiers in it, and a log with timestamps, paths and user agents has plenty. The key sits with the same team that reads the logs, so the pseudonym is reversible by exactly the people it was meant to guard against. Correlation is almost always needed within a bounded window, not forever: within one request (the request identifier already does that), within one session, or within an incident's timeframe. The design that fits is a pseudonym key that rotates per day or per week, so that lines link inside the window and not across it, with the mapping to a subject held only in a restricted store for the rare investigation that needs it. The advice as written should be limited to the case where cross-window linkage is the purpose, and should say that the pseudonymised log inherits the personal-data rules.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

Mechanisms that turn 'log by allowlist' and 'classify columns' into something the compiler or the database enforces. Go's `log/slog` has the `LogValuer` interface: a type that implements `LogValue()` controls how it appears in every log call, and the package documentation's own example is a `Token` type that renders as `REDACTED`, so a secret or identifier type cannot be logged verbatim by accident. Pydantic's `SecretStr` prints as asterisks in `str` and `repr`, which covers the `%r`/`JSON.stringify` dump the article warns about for Python models. In PostgreSQL, column-level privileges (`GRANT SELECT (id, created_at) ON users TO reporting`) make the 'split sensitive columns' advice enforceable without a second table, and `COMMENT ON COLUMN` is a place for the classification tag that `information_schema`/`pg_description` can be queried for by later tooling. For telemetry that has already left the process, the OpenTelemetry Collector's `attributes` processor has `delete` and `hash` actions and the contrib `redaction` processor drops attributes not on an allowlist, which is the same discipline applied one hop later.