Skip to content

Batching and Delayed Release

Release-timing policy — instantiates Side-Channel Leakage Containment

Holds outputs and emits them on a fixed schedule in constant-size batches, so the timing and volume of a release can't be traced back to the event that triggered it.

Even when what a system emits is within policy, when it emits and how much can betray the protected event. Batching and Delayed Release collects outputs over a fixed window and emits them together on a data-independent clock, padding each batch to a constant size with cover fills, so an observer watching release timing or volume cannot correlate a release with the event that produced it. Its defining move is that the release schedule is set by the clock, never by the data: an output is never emitted "as soon as it's ready," because readiness is exactly the signal being hidden. This is the temporal counterpart to Constant Response Envelope — where that equalizes the form of a single response, this equalizes the timing and volume pattern across many releases.

Example

A securities regulator must publish large-holding disclosures once they clear review. If each filing were posted the instant review finished, the posting time would pinpoint when a specific position changed — a timing leak, even though the filing's content is public by design. The regulator instead holds all cleared filings and publishes them in a single fixed daily window (e.g., 17:00), padding the batch to a constant slot count with placeholder entries. An outside analyst watching the feed sees the same-sized batch drop at the same time every day; neither the moment of publication nor the batch size reveals which filing landed, or how many real ones did. The protected fact — when a particular holding moved — no longer rides out on the release timing.

How it works

  • Clock, not readiness. Releases fire on a fixed schedule decoupled from event arrival; an output ready early waits for the next window.
  • Hold-and-flush queue. Outputs accumulate in a buffer and are flushed together, so individual arrival times are absorbed into the batch.
  • Constant batch size. Batches are padded with cover fills to a fixed count, so volume carries no information about how many real events occurred.
  • Data-independent boundaries. Window length and cadence are chosen without reference to the protected data, so batch boundaries can't be read as event signals.

Tuning parameters

  • Window length — longer windows decorrelate timing more strongly but add latency; the core privacy/latency dial.
  • Cadence regularity — a strictly fixed clock hides event-time best; adding jitter resists an observer who aligns to the schedule, at some timing-precision cost.
  • Cover-fill ratio — how many decoy slots keep batch size constant; more hides the true count but spends bandwidth.
  • Flush trigger — time-based (fire on the clock) versus size-based (fire when full); time-based is safe for timing, size-based re-introduces a rate signal.
  • Batching scope — global versus per-recipient batches; finer scope is more usable but leaks more structure.

When it helps, and when it misleads

Its strength is closing timing, ordering, and volume channels that content review never touches — the leak that survives even a perfectly redacted payload. Its cost is latency, which rules it out where outputs must be real-time. The classic misuse is a data-dependent flush — releasing "once N real events accumulate" — which quietly re-opens the channel, because the batch-boundary timing now encodes the arrival rate. The discipline that guards against this is to keep the schedule provably independent of the protected data and to measure residual timing correlation rather than assume it is gone.[1]

How it implements the components

Batching fills the temporal-release components — the dials that govern when and how much leaves, not what:

  • release_delay_or_batching_window — the hold-and-flush window and its fixed schedule are this mechanism's core artifact.
  • decoy_or_cover_traffic_policy — the constant-size padding: cover fills that keep batch volume uninformative.

It does not equalize the content or shape of any single response — that is Constant Response Envelope's output_equalization_policy — nor does it enumerate which channels leak, which is the Side-Channel Inventory Workshop's map.

Notes

The window trades latency for containment, so batching belongs to feeds and disclosures that tolerate delay, not interactive request/response paths — there, equalize each response's timing with Constant Response Envelope instead. Batching also hides when and how much, not whether ever: an observer integrating volume over long horizons still sees aggregate throughput, which is why the cover-fill policy matters.

References

[1] Traffic analysis — inferring information from the timing, volume, and pattern of messages rather than their contents. Fixed-schedule batching and constant-volume cover (decoy) traffic are its standard countermeasures, because both sever the correlation between an event and its observable emission. ↩