Insert one sentence at the beginning of a document and every later byte moves to a new fixed position. If a backup system divides files into blocks of exactly 4 KiB, that small insertion can shift all following block boundaries. Large portions of unchanged content may now look different. Content-defined chunking takes another approach: it slides a window across the bytes, calculates a rolling fingerprint, and declares a boundary when the fingerprint matches a rule. Because the rule depends on nearby content rather than an absolute offset, matching regions can recover their old boundaries after a local edit.
Rabin fingerprints provide a mathematically elegant way to build that rolling value. They represent a byte string as a polynomial and reduce it modulo another polynomial, often over the two-element field. The fingerprint can be updated when a byte leaves the window and another enters, without recomputing the whole window. This article develops the algebraic idea, the boundary probability, the difference between chunking and identity verification, and the practical limits. It shows why mathematics is important in storage, backups, synchronisation and network systems without promising that one hash eliminates every collision or performance problem.
Choose Your Reading Route
- Student: start with the fixed-block failure, the toy rolling hash and the coin-flip boundary model.
- Parent: focus on the backup story, misconceptions and project guidance.
- Educator: use the window experiment to connect modular arithmetic with probability.
- Computing learner: continue through polynomial fingerprints, rolling updates and chunk constraints.
- Systems explorer: study collision handling, recipes, deduplication scope and adversarial limits.
Three Different Jobs That Are Often Confused
The first job is finding boundaries. A rolling fingerprint examines each window and applies a predicate such as “the lowest 13 bits are zero.” Positions satisfying the predicate become candidate cut points, subject to minimum and maximum chunk sizes. The second job is identifying a chunk. After cutting, a system computes a strong digest over the entire chunk and looks for an existing object with the same identifier. The third job is verifying equality, which may involve a collision-resistant digest, length and sometimes byte-for-byte comparison depending on the threat and integrity model.
One number should not automatically perform all three jobs. A rolling fingerprint is attractive for boundary detection because it updates cheaply and has a useful distribution. It is usually not the only integrity check. Deduplication systems separate the fast local boundary signal from the stronger whole-chunk identity mechanism.
This distinction prevents a common misconception: “Rabin fingerprinting deduplicates the data.” More precisely, it can help choose stable content-defined chunks. A separate index and verification process decides whether a chunk is already stored and safe to reuse.
Why Fixed-Size Blocks Lose Synchronisation
Write a file as a sequence of symbols and cut every eight symbols. Suppose the original is
`ABCDEFGH | IJKLMNOP | QRSTUVWX | YZ…`
Insert one symbol at the front:
`XABCDEFG | HIJKLMNO | PQRSTUVW | XYZ…`
The underlying text after the insertion is almost unchanged, yet every fixed block has different membership. Hashing each block will find few matches. Deleting or inserting one byte causes the same phase shift until another edit happens to restore alignment.
Content-defined chunking lets boundaries follow local patterns. A boundary that depended on bytes around the old position may reappear once the sliding window moves past the insertion. Only chunks near the edit are replaced; later chunks can align with earlier stored objects again. This is called edit locality in an informal sense, although exact guarantees depend on the chunking scheme.
Fixed-size blocking still has advantages: simple addressing, predictable sizes and fast arithmetic. The right comparison depends on the edit pattern and workload. Append-only files may work well with fixed blocks; frequently inserted documents or virtual-machine images can benefit from content-defined boundaries.
A Toy Rolling Hash Before Polynomial Algebra
Consider a window of three decimal digits and modulus 11. Interpret digits (a,b,c) as the polynomial-like number (a10^2+b10+c), then take the remainder modulo 11. For window 314, the fingerprint is (314\bmod11=6). Slide to 141. We could recompute (141\bmod11), but a rolling update removes the contribution of 3, shifts the remaining number, and adds 1:
(((314-3\cdot10^2)\cdot10+1)\bmod11=141\bmod11=9.)
Precomputing (10^2\bmod11) makes removal cheap. The idea generalises to a base (B), window length (w) and modulus (M): subtract the outgoing symbol multiplied by (B^{w-1}), multiply by (B), add the incoming symbol, and reduce modulo (M).
This toy hash is not the Rabin polynomial fingerprint used in many chunkers, but it exposes the rolling structure. The next window reuses almost all the old window, so the arithmetic reuses almost all the old result.
Strings as Polynomials
Let a window contain symbols (a_0,a_1,\ldots,a_{w-1}). Represent it by
(A(t)=a_0t^{w-1}+a_1t^{w-2}+\cdots+a_{w-2}t+a_{w-1}.)
A Rabin fingerprint is a remainder (A(t)\bmod P(t)), where (P(t)) is a chosen polynomial. In the common binary setting, coefficients lie in (GF(2)): they are 0 or 1, addition is XOR, and subtraction is also XOR because (1+1=0). Multiplication by (t) corresponds to a bit shift followed by reduction when the degree reaches that of (P(t)).
The fingerprint has bounded degree, so it fits in a fixed number of bits. Different long strings can share the same remainder; that is a collision. The value is a compact fingerprint, not a lossless encoding. The mathematics of random polynomials provides useful collision properties under stated choices, which is why Michael Rabin’s 1981 technical report was titled *Fingerprinting by Random Polynomials*. Its publication details are recorded in the Google Books catalogue entry.
Rolling a Polynomial Fingerprint
Suppose the current window polynomial is
(A(t)=a_0t^{w-1}+a_1t^{w-2}+\cdots+a_{w-1}.)
The next window drops (a_0), shifts the remaining symbols left by one polynomial position and appends (b):
(A'(t)=(A(t)-a_0t^{w-1})t+b.)
Over (GF(2)), subtraction becomes XOR. Because modular reduction is compatible with addition and multiplication, we can perform each operation on the remainder. Precompute the reduced contribution of every possible outgoing byte at the highest window position. Then update with table lookups, shifts, XORs and a reduction table rather than rereading all (w) bytes.
The exact tables and bit orientation vary among implementations. Some process the high bit first; others use reflected representations. Two programs can both claim “Rabin fingerprint” and produce different numeric values while preserving similar mathematical properties. Interoperable storage formats must define the polynomial, window length, byte order and update convention precisely.
Boundary Rules as Probability
Assume the low (k) bits of rolling fingerprints behave approximately like uniformly distributed random bits. A boundary rule such as
( ext{fingerprint}\ &\ (2^k-1)=0)
matches with probability about (1/2^k) at each eligible position. The expected gap between matches is therefore about (2^k) bytes. Choosing (k=13) suggests an average of roughly (8192) bytes under the idealised model.
This does not mean every chunk has exactly 8192 bytes. If independent positions matched with probability (p=2^{-k}), the gap would resemble a geometric distribution: short and long chunks both occur. Real rolling values overlap because neighbouring windows share bytes, so independence is approximate. Minimum and maximum limits reshape the distribution further.
The expected-size calculation is still useful. It links a bit mask to a storage parameter. Increasing (k) by one roughly doubles the mean natural gap. Mathematics turns a low-level bit condition into an understandable operational knob.
Minimum, Target and Maximum Chunk Sizes
Unrestricted anchor selection can produce tiny chunks, increasing metadata and index overhead, or unusually large chunks, reducing deduplication granularity and buffering predictability. Practical systems therefore use a minimum (L_{\min}), a target around (L_{\text{avg}}), and a maximum (L_{\max}).
Before the minimum, ignore matching fingerprints. Between minimum and maximum, accept the first position satisfying the boundary predicate. At the maximum, force a cut even if no natural anchor appears. Some algorithms change masks before and after the target to shape the size distribution.
These limits create trade-offs. A larger minimum reduces tiny chunks but makes small edits replace more surrounding bytes. A smaller average yields finer deduplication but more chunk records, hashes and lookups. A forced maximum bounds memory and latency but can introduce a boundary tied to distance rather than content. Parameter selection should use representative files and measured costs.
A Worked Boundary Example
Use a deliberately tiny 4-bit fingerprint model so the process can be seen. Suppose a boundary occurs when the low two bits are `00`, giving an idealised probability of (1/4), with minimum length 3 and maximum length 8. Imagine eligible fingerprint values after successive bytes are:
- position 1: `1011`
- position 2: `0100`
- position 3: `1110`
- position 4: `1000`
- position 5: `0011`
- position 6: `1100`
The match at position 2 is ignored because the minimum has not been reached. Position 3 is eligible but does not match. Position 4 ends in `00`, so the chunk closes at length 4. The next chunk begins and the length counter resets, while the rolling window may continue across the stream depending on the specified algorithm.
If no eligible fingerprint matched by length 8, the maximum would force a boundary. This example separates three conditions: fingerprint match, eligibility by current chunk length, and forced termination. Debugging becomes much easier when each is logged separately.
Why Boundaries Recover After an Insertion
Consider identical long content in two files, except that one has a short insertion. Windows overlapping the insertion contain different bytes, so their fingerprints and boundary decisions may differ. Once the sliding window lies entirely beyond the inserted region, it sees the same local byte sequences as the original, just at shifted offsets. It therefore produces the same fingerprints in the same content-relative positions.
Natural boundaries can then reappear, allowing later chunks to match. The disturbance length depends on the window and boundary rules, plus where maximum cuts occur. This is the central locality advantage over fixed offsets.
Recovery is not instantaneous or absolute. An edit can remove an anchor, create a new one, or interact with minimum and maximum limits. Repetitive or adversarial data may yield unusual gaps. A proper evaluation measures changed chunks under realistic insertions, deletions and replacements rather than showing one favourable illustration.
Fingerprints, Digests and Collisions
A (q)-bit fingerprint has at most (2^q) values. By the pigeonhole principle, more than (2^q) possible windows must collide. Even before that, the birthday effect makes some collision likely among about (2^{q/2}) random values. Boundary detection can tolerate collisions differently from identity verification: if two windows share a boundary-triggering fingerprint, they merely create anchors; if two distinct chunks are treated as identical, data integrity can be harmed.
Therefore systems commonly compute a stronger digest over each completed chunk. Depending on requirements, they may also store length, compare bytes on suspected matches, or use cryptographic authentication. The threat model matters. Accidental corruption, malicious input and trusted local deduplication are different problems.
No hash is “unique” in the mathematical sense when its output is shorter than arbitrary input. Good engineering manages collision probability and verification rather than denying it.
Chunk Recipes and Reconstruction
After chunking, a file can be represented as an ordered recipe of chunk identifiers and lengths. If a chunk already exists in the store, the system reuses it; otherwise it stores or transmits the new bytes. Reconstruction concatenates the referenced chunks in recipe order.
The recipe must be protected. Missing, reordered or incorrectly referenced chunks change the file even if every chunk object is individually intact. Metadata versioning, transactional updates and end-to-end file verification are essential. Garbage collection must not delete chunks still referenced by any live recipe.
This is where a mathematical idea meets systems discipline. Fingerprints discover boundaries, but durability depends on indexes, reference tracking, crash recovery and integrity checks.
Application 1: Low-Bandwidth File Systems
The Low-Bandwidth Network File System, LBFS, used content-based techniques to exploit similarities between files and reduce network transfer. The original paper by Athicha Muthitacharoen, Benjie Chen and David Mazières is available as a Stanford-hosted copy of the 2001 paper.
The motivating idea is simple: a client and server may already hold much of the same content even when files differ in offsets or names. Content-defined chunks make reusable regions discoverable. Sending identifiers for known chunks can save bandwidth; only new chunks need transfer.
Network latency, index lookup cost and protocol security still matter. Deduplication savings depend on similarity across the working set. Compressed or encrypted files may have little repeated plaintext structure at the byte level.
Application 2: Backup and Archival Systems
Incremental backups benefit when local edits replace only a few chunks. Content-defined chunking can identify unchanged regions across versions, users or machines, depending on the deduplication scope. Storing one copy of repeated chunks can reduce capacity and transfer.
Global deduplication introduces privacy concerns. If users can test whether a chunk already exists, the system may leak information about other users’ data. Encryption complicates deduplication because secure randomised encryption intentionally makes equal plaintext look different. Convergent approaches have security trade-offs and should not be improvised.
For education, keep the focus on the mechanism. A classroom backup prototype should use non-sensitive sample files, local storage and explicit verification. Do not treat deduplication as a reason to collect personal documents.
Application 3: Storage Redundancy Studies
Researchers have compared whole-file hashing, fixed-size blocking and content-defined chunking across datasets. The USENIX paper Alternatives for Detecting Redundancy in Storage Systems Data is a primary source that explicitly evaluates Rabin-fingerprint chunking alongside alternatives.
Such studies show why evaluation must include workload. Whole-file hashes are cheap and effective for exact duplicate files. Fixed blocks have predictable overhead. Content-defined chunks can recover similarity after shifted edits but cost more CPU and metadata. Compression can reduce remaining redundancy and alter the comparison.
Do not quote one deduplication ratio as a universal property of an algorithm. File types, versions, chunk parameters, dataset size and whether compression is applied all influence results.
Application 4: Synchronisation and Transfer
When two endpoints hold related byte streams, content-defined chunks can produce tokens for matching regions. A sender transmits a recipe and missing chunks rather than the full file. This resembles “find common substrings,” but boundaries reduce the number of candidates from every possible substring to a manageable set.
The receiver must authenticate data and handle version races. If a file changes during chunking, the recipe may combine inconsistent states unless the system snapshots or validates it. Network protocols also need protection against malicious identifiers, decompression bombs and resource exhaustion.
Mathematics finds reusable structure; protocol design decides whether reuse is safe.
Rolling Hash Versus Cryptographic Hash
Rolling hashes are designed for efficient window updates. Cryptographic hashes are designed for properties such as preimage and collision resistance under adversarial conditions. A cryptographic hash generally cannot remove the oldest byte and add a new one in constant time. A simple rolling hash generally should not be trusted as a tamper-proof identifier.
Some systems use a rolling fingerprint for anchors and a cryptographic digest for chunks. Others use modern fast non-cryptographic hashes in trusted settings, paired with byte comparison or other safeguards. The labels “fast” and “secure” are incomplete without a threat model and failure consequence.
This comparison is a useful mathematics lesson: two functions can both map data to fixed-size numbers while optimising entirely different properties.
Adversarial and Pathological Inputs
The ideal boundary probability assumes fingerprints behave suitably on the input distribution. Carefully constructed data may produce too many or too few anchors for a particular polynomial and mask. Long runs of zeros, repeating patterns or adversarial sequences can stress implementations. Minimum and maximum chunk sizes bound some damage but do not remove all performance concerns.
An attacker might try to force many tiny chunks, expensive lookups or hash-table collisions. Systems exposed to untrusted data need resource limits, robust indexing and tested algorithms. Never rely on an informal “random-looking” claim as a security proof.
Recent research explores chunkers with different speed and worst-case guarantees. For example, the official USENIX page for FastCDC documents a later approach designed to improve content-defined chunking performance. Its reported results apply to the studied implementations and datasets, not every deployment.
Performance Accounting
Chunking reads every byte, maintains a window and evaluates boundary logic. After each cut, the system hashes the chunk, looks up its identifier and may update metadata. Smaller chunks increase lookup and recipe overhead. Larger chunks reduce overhead but miss fine-grained duplication.
CPU cost may be worthwhile when network or storage is scarce. It may be wasteful when data are unique, already compressed, encrypted or short-lived. Benchmark throughput, deduplication ratio, memory, metadata size and restore speed together. Optimising only the storage ratio can make restores slow or indexes enormous.
A useful experiment reports bytes processed per second and unique bytes stored, then plots the trade-off across average chunk sizes. The “best” setting depends on how those costs are valued.
Choosing Parameters Without Overfitting One Dataset
Chunker parameters can look excellent on one collection and disappoint on another. Source code, photos, database images and compressed archives have different repetition and edit patterns. A responsible evaluation separates parameter tuning from final testing. Choose candidate window, minimum, average and maximum sizes on a development collection, then freeze them before testing on independent files or later versions.
Compare at least three baselines: whole-file hashing, fixed-size blocks and content-defined chunks. Report unique stored bytes, chunk count, index memory, chunking throughput and reconstruction throughput. For versioned data, measure how many chunks change after realistic edits. An average alone may hide a few files that create enormous metadata or almost no natural anchors.
Sensitivity plots are more informative than a single winning configuration. Vary one parameter at a time around the chosen setting. If a tiny change reverses the conclusion, the recommendation is fragile. If several nearby settings behave similarly, operational convenience and compatibility may decide. Mathematics guides a robust region of choices rather than producing a mystical perfect number.
Restoration Is the Final Correctness Test
Deduplication is successful only when every stored version can be reconstructed exactly. A test pipeline should chunk the input, store unique chunk bytes, save an ordered recipe, rebuild the file in a clean directory and compare a strong whole-file digest—or the bytes themselves—with the original. Repeat after simulated interruption, missing-chunk detection and index rebuilding.
This end-to-end check catches errors that local tests miss. A rolling update can be correct while the last short chunk is forgotten. Every chunk digest can be correct while a recipe records the wrong order. Reference counts can look plausible while garbage collection removes a still-needed object. Correct mathematics in one component does not guarantee correct composition.
For long-term archives, periodically audit stored objects and recipes. Keep format versions and algorithm identifiers with metadata so future software knows how boundaries and identifiers were produced. If a digest algorithm is retired, migration needs a verified plan rather than silent reinterpretation. Durability is a time-dependent promise.
Privacy and Shared Deduplication
Deduplicating across users can reveal more than storage engineers intend. If an uploader learns that a candidate chunk already exists, that fact may confirm another user possesses particular content. Timing, quota changes or “already uploaded” responses can become side channels. The risk is strongest when an attacker can predict the target bytes.
Possible mitigations include scoping deduplication within one trust boundary, hiding existence responses, rate limiting probes, encrypting with managed keys and avoiding cross-user reuse for sensitive data. Each changes savings, complexity or threat assumptions. There is no purely algebraic fix because the leak arises from system behaviour around equality.
Students should learn the principle without experimenting on real accounts or documents. Use synthetic files and a local store. A technique that recognises identical content should immediately prompt the question: who is allowed to learn that the content is identical?
Did You Know? Average Size Comes from a Bit Pattern
A target average of about 8 KiB can emerge from a rule as small as “accept when 13 selected fingerprint bits are zero.” Under a uniform model, that pattern occurs once in (2^{13}=8192) positions on average. The chunks are variable, but the expectation is controlled by a simple probability.
This is a striking bridge between binary arithmetic and system behaviour. A mask in code is not arbitrary punctuation; it expresses a geometric waiting-time model. Students can simulate coin flips or random integers to see the same distribution before touching file bytes.
Common Misconceptions
- “Rabin fingerprints encrypt data.” They do not provide confidentiality.
- “A fingerprint uniquely identifies every window.” Fixed-size outputs necessarily collide.
- “The rolling fingerprint should be the final chunk ID.” Boundary selection and strong identity verification are different jobs.
- “The target size is the exact size.” The natural boundary rule produces a distribution, shaped by minimum and maximum limits.
- “Content-defined chunking always saves space.” Savings depend on repeated content and must exceed CPU, index and metadata costs.
- “An insertion changes only one chunk.” It usually disturbs a local region, but exact propagation depends on anchors and limits.
- “Equal chunk digests prove equal files.” File recipes, order and metadata also matter, and collision policy must be explicit.
A Student Learning Progression
Start with fixed-size blocks on short strings. Insert one symbol and count matching blocks. Then choose content anchors using an easy rule such as “cut after a vowel” or “cut when a three-digit rolling remainder has a chosen value.” Observe how boundaries recover after an edit.
Next, implement the base-(B) toy rolling hash with a prime modulus. Verify that rolling updates equal full recomputation for every window. Measure collision frequency with a deliberately small modulus. This builds modular arithmetic intuition.
Then study polynomial arithmetic over (GF(2)) with tiny bit strings. XOR polynomials, shift, reduce by a small irreducible polynomial and compare fingerprints. Only after those foundations should learners use a production chunking library or larger files.
Finally, evaluate a complete pipeline: boundary fingerprint, chunk digest, index, recipe and restore verification. Keep these stages visible in separate columns or logs.
Practical Projects
Project 1: Fixed Versus Content Anchors
Take a public-domain paragraph. Divide it into 16-character blocks, then insert a word near the start and count unchanged blocks. Repeat using a simple content rule. Discuss where alignment recovers and why the simple rule may create uneven chunks.
Project 2: Rolling Update Proof by Test
Implement a toy rolling hash. For every window in a file, calculate the value twice: once from scratch and once with the rolling formula. Assert equality. Deliberately alter the outgoing-power term to see how a small algebra error spreads.
Project 3: Boundary Distribution
Generate random bytes or use several non-sensitive public files. Apply masks with (k=4,6,8), record natural gap lengths, and compare sample means with (2^k). Add minimum and maximum sizes and explain how the histogram changes.
Project 4: Safe Deduplication Prototype
Chunk two versions of a sample file, compute a strong digest for each completed chunk using a standard library, store unique chunks locally and build recipes. Reconstruct both files and verify their complete digests. Never use confidential data for the exercise.
Guidance for Parents
The intuitive entry point is a card game. Put a long sentence on cards, group every eight cards, then insert one at the front. The fixed groups shift. Next invent a boundary rule based on card content. The student can see why local landmarks travel with the content.
Ask them to separate three questions: Where do we cut? Have we seen this chunk? Does reconstruction exactly match? If those answers stay distinct, the system idea is becoming clear.
Do not worry if polynomial arithmetic over (GF(2)) comes later. Modular rolling hashes can build the core reasoning first. The goal is transferable understanding, not premature jargon.
Guidance for Educators
This topic works after modular arithmetic, polynomial representation or binary XOR, but can be introduced conceptually earlier. Require learners to verify rolling updates against recomputation. That single invariant catches many implementation errors and reinforces algebra.
Include collision demonstrations with small outputs so students stop using the word “unique” carelessly. Then explain why larger fingerprints and stronger digests make risk manageable without making collisions mathematically impossible.
Assessment should include trade-offs. Ask students to predict how chunk size affects metadata, deduplication granularity and CPU. Have them test insertions, deletions and replacements, not only exact copies.
Connections to Other Mathematics
Rabin fingerprints connect polynomial rings, modular reduction, probability and algorithms. The boundary gap resembles a geometric waiting time. Chunk collisions invoke the pigeonhole principle and birthday reasoning. Parameter selection becomes optimisation across storage, compute and network costs.
There is also a useful link to string search. Rolling hashes can compare many substrings efficiently, while verification handles collisions. Deduplication extends the idea from “does this pattern occur?” to “which variable-sized regions can be reused?”
Our MinHash article uses randomised fingerprints for set similarity, not byte-window boundaries. The shared word “fingerprint” should not hide the different mathematical guarantees.
Frequently Asked Questions
Is a Rabin fingerprint the same as Rabin–Karp string search?
They share polynomial rolling-hash ideas. Rabin–Karp uses hashes to locate possible pattern matches; content-defined chunking uses rolling values to choose boundaries. Exact formulations and moduli can differ.
Why use a sliding window?
The window makes a boundary depend on recent local content. After an edit leaves the window, matching content can reproduce matching fingerprints and anchors.
What window size is best?
There is no universal value. It affects locality, computation and sensitivity. Use established implementations and evaluate representative workloads rather than inventing production parameters casually.
Does a larger fingerprint make chunks larger?
Not by itself. Average boundary spacing is controlled mainly by the number of bits tested in the boundary predicate. Fingerprint width also affects collision properties and implementation.
Can compressed files be deduplicated effectively?
Often less effectively at the byte level because small plaintext changes can alter much of the compressed stream. Results depend on format, compressor and versioning.
Can encrypted files be content-defined chunked?
They can be chunked as bytes, but secure randomised encryption tends to destroy visible equality. Schemes that preserve deduplication can introduce serious privacy trade-offs.
Does deduplication replace backups?
No. It is a storage optimisation. Backups still need independent copies or failure domains, retention policy, integrity checks, access control and tested restoration.
Useful Next Reading
- Identify the foundational work through the catalogue record for Rabin’s 1981 technical report.
- Read the LBFS paper for a primary system design using content-based techniques on low-bandwidth networks.
- Review the USENIX study Alternatives for Detecting Redundancy in Storage Systems Data for an empirical comparison of chunking strategies.
- See the official USENIX page for FastCDC as a later performance-oriented design.
- Compare byte-stream fingerprints with MinHash and Jaccard similarity.
Final Perspective
Rolling Rabin fingerprints turn a local byte window into a compact algebraic remainder that can be updated efficiently. A simple bit predicate converts those values into variable chunk boundaries with a controllable expected spacing. After an insertion or deletion, local content can rediscover familiar anchors, allowing unchanged chunks to be recognised again.
The complete lesson is larger than the trick. Fingerprints collide, target size is an expectation, parameters shape overhead, and safe deduplication requires strong chunk identity, protected recipes and verified reconstruction. Mathematics makes all of those statements precise. It lets us design a system that notices repeated content while remaining honest about probability, loss and trust—and that is exactly the kind of practical clarity the question “Why Mathematics?” is asking for.
Careful restoration proves that the clever shortcut never displaced the original obligation: every saved byte must remain recoverable.