Summary

  • RFC 9841 extends Brotli with shared dictionaries, large-window operation and framing; the compressor and decompressor must use exactly the same dictionary.
  • A dictionary is not harmless reference data: altering it can alter decompressed content, while observable compressed sizes can disclose information in either direction between dictionary and payload.
  • The durable operating unit is therefore payload plus exact dictionary identity, provenance, scope, freshness, decoder compatibility and an explicit decision about whether secrets may be compressed at all.

The payload passed its checksum. The decoder was healthy. The output was still wrong.

The missing variable was a file that the performance team had treated as a reusable optimisation: the shared dictionary. One edge location had yesterday's bytes, another had today's, and both called the artifact by the same friendly name. The compressed object alone could not settle which plaintext was intended. Its meaning depended on an external input whose release history had not travelled with it.

That hypothetical is the control problem exposed by RFC 9841, the September 2025 Informational specification for the Shared Brotli Compressed Data Format. The plain-text edition and XML source describe a format that adds shared dictionaries, large windows and framing to Brotli. Publication proves that the mechanism has a public specification. It does not prove deployment, interoperability, safe configuration or any claimed saving in a live service.

A dependency that participates in meaning

Ordinary compression already relies on an algorithm and compatible decoder. A shared dictionary adds content outside the compressed payload. RFC 9841 allows dictionary material to supply LZ77 history bytes, replace Brotli's built-in static word list, replace transformations, or select context-dependent combinations. The compressor and decompressor must use exactly the same dictionary.

That requirement changes the artifact boundary. A stored blob labelled only with br or a decoder version is incomplete evidence. Reproduction requires the exact dictionary bytes, the applicable profile and framing state, and a decoder that implements them. A human-readable dictionary name is not enough; mutable paths and “latest” aliases are especially weak. The original Brotli format supplies the base grammar, while the Zstandard specification provides a useful comparison showing that dictionary dependence is a broader compression-governance issue, not a quirk of one implementation.

The minimal receipt binds the compressed payload hash to a cryptographic hash of the dictionary, its creation source, owner, approved scope, activation time, retirement or rollback version, and decoder compatibility. If a dictionary can be assembled from several resources, that construction belongs in the receipt too. A file that can change decoded meaning must go through release control with the same seriousness as executable configuration.

RFC 9841 includes a 256-bit HighwayHash-based identifier for known dictionary sets. Its security text is explicit about the limit: the identifier is not collision-secure in an adversarial environment. Identification inside a trusted set is not the same claim as hostile-input integrity. Operators need a cryptographic digest wherever untrusted substitution or supply-chain evidence matters; SHA-256 remains the obvious interoperable receipt component.

The dictionary crossed into the confidentiality model

Compression leakage is not new. RFC 7457 records attacks including CRIME, and the CVE-2012-4929 record preserves one public incident reference. The general mechanism is that an attacker influences some input, observes compressed length, and learns whether guesses align with secret material. Research on compression side channels explores the broader class.

RFC 9841 matters because it says the shared dictionary is one of the data sources in that model. Information about compressed data may be revealed by the dictionary; information about the dictionary may be revealed by compressed data. That bidirectionality defeats a tempting mental shortcut in which the dictionary is public scaffolding and only the request or response body deserves secrecy review.

Consider a dictionary built from recent customer traffic, authenticated pages or internal templates. Even if distributed as an opaque optimisation artifact, it can encode phrases whose presence is commercially or personally sensitive. Conversely, a public dictionary can make attacker-controlled probes more effective against a private value compressed in the same context. A policy that asks only “is the payload secret?” has already missed half of the boundary.

The strongest mitigation remains the least glamorous: do not compress private data in an attacker-observable context. Same-origin restrictions, avoiding cross-domain dictionaries, preventing attacker control, changing dictionaries slowly and isolating contexts can reduce exposure. They are conditions to test, not certificates of safety. The decision must classify every data source—the payload, dictionary and attacker-influenced prefix—before a benchmark turns byte savings into an approval.

HTTP adds authority, freshness and tracking edges

The companion RFC 9842, recorded separately by the RFC Editor, defines HTTP dictionary negotiation and the dcb and dcz content codings. It is not the main subject of this report, but it reveals what deployment has to carry around RFC 9841.

An Available-Dictionary value uses a SHA-256 digest. A candidate dictionary must satisfy origin and response-readability rules and must be fresh, or explicitly usable while stale. A response has to be dropped when the required mitigations fail. These rules sit within the semantics and caching environment described by HTTP Semantics, HTTP Caching and stale-response controls. Cookies provide a familiar comparison for state scope in RFC 6265.

The companion specification also warns that a dictionary hash can act as a tracking token and calls for storage partitioning comparable to or stronger than cookie partitioning. That is a separate future commission: browser negotiation, cache partitioning and tracking deserve their own thesis. Here, the narrower lesson is that dictionary identity cannot be reduced to a filename. It carries origin, readability, freshness and privacy state.

The relevant registries are public: IANA maintains the HTTP content-coding registry and HTTP field-name registry. Structured Field Values illustrates the wider discipline of making HTTP metadata parseable and explicit. Registry presence, however, is coordination evidence—not proof that a particular client, CDN or origin implements the negotiation safely.

Build a receipt before a benchmark

A serious rollout can be tested with a small adversarial matrix. Substitute a dictionary with the same friendly name but different bytes. Present a stale version. Supply the right hash from the wrong origin. Change decoder versions. Inject chosen phrases next to a secret and measure output-length variance. Exceed decompression limits. Remove the dictionary and observe whether the system fails closed, silently falls back or serves corrupted output.

Every result should identify payload hash, dictionary digest, algorithm/profile, framing mode, decoder build, origin and cache scope. The metric is not merely compression ratio. It includes deterministic reconstruction, failure mode, maximum memory, latency, leakage observations and rollback behaviour. The benchmark is invalid if it cannot say exactly which dictionary produced each number.

This is a minimum-specification argument. The shared standard should define the irreducible identifiers and safety constraints; local operators retain the decision about traffic classes, secret handling, deployment cadence and acceptable performance. Running code supplies the receipts. Neither a vendor slide nor a successful decode on one workstation can substitute for cross-boundary evidence.

What this report does not prove

No browser, server, CDN, library or production configuration was tested. No compression ratio, CPU cost, memory consumption, attack success or leakage rate was measured. The article does not infer adoption from publication status. It does not claim that every shared dictionary contains secrets or that every dictionary-assisted response leaks them.

The defensible conclusion is structural. Once a decoder needs exact external bytes to recover content, those bytes are part of the artifact. Once size observations can couple them to private data, they are part of the secret boundary. The byte saving may be real. So is the new dependency—and the receipt must record both.

Sources