Skip to content

Error Message Normalization

Failure-normalization rule — instantiates Side-Channel Leakage Containment

Collapses every failure into one indistinguishable generic error — same message, code, and timing — while logging the true reason internally, so a rejection never reveals why.

A rejection can leak as loudly as an answer: "wrong password" versus "no such user" quietly confirms which accounts exist. Error Message Normalization maps every distinct internal failure reason onto a single external error — identical message, status code, and response time — while recording the true reason in an internal, access-controlled log. Its defining move is external uniformity with internal fidelity: the observer outside sees one indistinguishable failure no matter what actually went wrong, but the system keeps the real reason for authorized review and probe detection. Where Constant Response Envelope fixes the whole response including the success path, this specializes the failure branch, where the reason for rejection is the thing that leaks.

Example

A payments gateway can decline a charge for many reasons — invalid number, insufficient funds, a fraud hold, a velocity limit. If the API returned each distinct reason, or even answered faster for "invalid number" than for "fraud check," an observer could probe an account and map its state, which is a protected fact. Under normalization, every decline returns one generic "transaction declined," the same response code, padded to the same timing band; the specific reason is written to an internal log the issuer can review and that flags repeated failed-probe patterns. Legitimate failures still get handled — the truth is retained inside — but the outside sees a single, uninformative "no."

How it works

  • Enumerate the failure modes. List the distinct internal reasons a request can fail.
  • Define one external error. Choose a single canonical message, status, and timing band that all failures collapse to.
  • Equalize timing, not just text. Pad declines to a constant delay so fast-fail vs. slow-fail can't separate the reasons.
  • Branch the truth internally. Write the real reason to an access-controlled log that also surfaces repeated-probe patterns for review.

Tuning parameters

  • Collapse granularity — one universal error vs. a few coarse buckets; coarser leaks less but degrades legitimate diagnostics.
  • Timing equalization — whether declines are padded to a constant delay; without it, timing re-opens the channel the text closed.
  • Internal-log fidelity — how much true detail is retained internally, and how tightly that log is access-controlled.
  • Actionable carve-outs — which few responses must stay specific for legitimate users (e.g., "try again later") versus being collapsed.

When it helps, and when it misleads

Its strength is closing the reason-probing and enumeration channels that a detailed error opens, without going dark internally — support and fraud teams still see the truth. Its cost is degraded feedback for honest users and harder debugging. The classic misuse is normalizing the text while leaving timing distinguishable — a quick "invalid card" and a slow "fraud review" still separate the cases — so the timing must be equalized too. The discipline is to equalize every observable dimension of the failure and to treat the internal log as protected state in its own right, since it now holds the very reasons the outside was denied.[1]

How it implements the components

  • output_equalization_policy — for the failure branch: one canonical error form (message, code, timing) that every rejection is forced into.
  • probe_detection_and_review_log — the internal record of true failure reasons, which doubles as the signal for repeated-probe patterns worth review.

It normalizes failures only; equalizing the whole success-path envelope is Constant Response Envelope's broader output_equalization_policy, and acting on the probe log by capping query rate and composition is Query Rate and Composition Limit's.

Notes

The internal log is a new protected surface: it holds exactly the reasons the external error hides, so if it leaks — through a debug endpoint, verbose telemetry, or an over-broad access grant — the normalization is undone. Guard the log as tightly as the fact it protects.

References

[1] An oracle — any response that lets an observer distinguish internal states by probing, such as different errors for "wrong password" and "no such user." Collapsing all outcomes to one indistinguishable response removes the oracle. ↩