Module pii 

Person pseudonymization (enterprise#39, GDPR/DSGVO).

usage_events.person is normally an e-mail address — personal data under GDPR. With [gateway_server].pseudonymize_persons = true the gateway replaces it at the identity choke-point (attach_gateway_tags) with a stable keyed hash: p:<16 hex>. One choke-point means budget ledgers, usage rows, dashboards, metrics and logs all see only the pseudonym.

Properties:

• Stable per install: keyed BLAKE3 with a per-install salt (<data_dir>/gateway_pii_salt, created on first use, 0600). The same person always maps to the same pseudonym, so per-person budgets and rollups keep working.
• Not reversible without the salt file; the salt never leaves the host.
• Re-identifiable on purpose by the operator (GDPR Art. 15/17 requires acting on “the data of person X”): pseudonymize("x@acme.com") recomputes the key, which is exactly what the gateway gdpr CLI does.

Normalization: e-mail-ish inputs are trimmed + lowercased before hashing so A@Acme.com and a@acme.com land on one pseudonym.

Constants

PSEUDONYM_PREFIX

Pseudonym prefix — makes pseudonymized rows self-describing in exports, dashboards and GDPR tooling.

Functions

effective_person

Applies the configured person policy: pseudonym when enabled, identity otherwise. The single entry point for the auth guard.

enabled

True when the deployment opted into pseudonymization.

person_match_keys

All storage keys a GDPR request for person must match: the raw value (pre-pseudonymization rows, or pseudonymization off) and the pseudonym.

pseudonymize

The stable pseudonym for a person: p: + first 16 hex chars of BLAKE3_keyed(salt, normalized_person). Already-pseudonymized inputs pass through unchanged (idempotent — safe on re-tagged requests).