Redaction: completeness review

The project's own review (not an external audit) of Office.Redact / OfficeFile.Redact. The question: after a match or region is redacted, can the removed text be recovered from the output file by any means? The method was to list every place a string can live from the format specifications, compare the list with docs/redaction.md, attack the feature with hostile inputs (generated by tests/OneDocument.Redaction.Tests/Attacks.cs), and test the verifier on the survivors it should report.

The attacks are read back by an independent reader (Attacker.cs) that knows nothing about the redaction code: zip entries, gzip and zlib streams anywhere in a binary, compound-file streams through their sector chains, macro source after decompression, XML text with character references, _xHHHH_ escapes, percent-escapes to any depth, text joined across elements, base64 tokens, case, accents and invisible characters.

Verdict

Pass, with the matching contract stated and the open items below listed in the feature's own documentation.

After the fixes in this review there is no tested input from which a matched string can be read back and which the report calls verified, except the four where the plan's literal does not match the text at all (invisible characters, another Unicode normalisation form, a no-break space, a typographic apostrophe: matching is exact, see Open items). Every other survivor is either removed or makes Verified false and appears in Survivors or Gaps. Copies of a region's text are reported as redaction.region-copy gaps and do not change Verified, which speaks for matches.

Before the review the feature failed this standard in ten ways. Each is a regression test now:

Two further defects in region redaction:

One regression was found by running LibreOffice over the outputs: the first version of the zip header cleaning zero-filled extra fields, which left a truncated field that LibreOffice refused to open. The cleaner now only rewrites the Info-ZIP name and comment fields and leaves others alone.

Where a string can live: the independent list

Sources: ECMA-376 Parts 1–4, [MS-DOCX], [MS-XLSX], [MS-PPTX], [MS-ODRAWXML], [MS-OFFMACRO2], [MS-OVBA], [MS-OFFCRYPTO]. Status per location:

• T covered and tested (a row in Attacks.cs or the torture packages);
• U covered by the generic text/attribute pass over every XML part but without its own test;
• D gap, documented in docs/redaction.md;
• N gap that was not documented; fixed or documented by this review.

Every XML part of the package and of each package embedded in it goes through the same two passes (paragraph-like units across runs; every other text node, attribute value, comment and processing instruction), so a location in an XML part is U unless it needs a rule of its own.

Package level

WordprocessingML

SpreadsheetML

PresentationML

Attacks and results

Survived means the independent reader recovered the secret from the output and the report did not say so. Reported means it is recoverable but Verified is false and the report names it. Removed means nothing is recoverable.

The verifier

It must not say verified when something recoverable survives. Its false negatives, all now closed unless listed under Open items:

1. Zip headers (comments, extra fields): not read. Now every header region is searched.
2. Compound-file streams across non-adjacent sectors: not read. Now mapped through the chains.
3. Compressed data inside binary parts and streams (zlib at any offset, gzip, macro source, packages in streams): not read. Now decoded, bounded to 2,000 candidate starts per entry and to the part size limit; inside pictures only literal matches count.
4. _xHHHH_ escapes and base64 values: not decoded. Now decoded.
5. Percent-encoding beyond one level. Now four.
6. Text parts that are not XML (RTF, HTML, quoted-printable): searched as bytes only. Now decoded.
7. A hit ignored because it is a substring of some mark. Now only inside a mark at that place.

What it still cannot see, so Verified can be true with the secret recoverable: pixels, text in formats nobody here decodes (PDF streams inside objects are inflated only at zlib starts it finds, and their fonts may encode text through glyph ids), encrypted payloads, and the matching variants under Open items.

Open items

1. Matching is exact on characters. The four skipped tests in AttackTests are this. Options: (a) keep, document, tell callers to list variants or use a pattern (current); (b) add an additive RedactionOptions.Relaxed that folds no-break and thin spaces to a space, typographic quotes and dashes to ASCII, and ignores soft hyphens and zero-width characters, with an index map so spans map back to the original text; (c) also normalise Unicode forms, which needs normalisation tables of our own because the library runs with invariant globalization. Recommendation: (b) for 1.0 or 1.1, since a no-break space inside a name and an autocorrected apostrophe are common in Word documents; (c) later.
2. Copies of a region's text are reported, not removed. Option: remove text copies of at least N characters automatically (as a match), with an option to turn it off. Risk: removes innocent repeats. Recommendation: keep reporting, add RedactionPlan.RemoveRegionCopies (additive) when a caller asks.
3. Part names and relationship identifiers are not rewritten. Option: rename parts to /path/REDACTEDA.ext and rewrite every relationship target, content-type override and Flat OPC name that points to them. Recommendation: do it when a real document shows a secret in a part name (media and attachment file names are the realistic case).
4. Compressed macro source, packages inside object streams, included RTF and mail archives are verified, not rewritten. A rewrite of macro source needs a recompressor that fits the old stream length. Recommendation: document that redaction of a macro-enabled file needs the project removed (docs/vba.md), and consider making Redact accept a "remove macros" option.
5. Signed documents: any redaction invalidates the signatures, and the signature parts carry the signer's certificate (a name). The base64 rule now overwrites a match inside a certificate, which only makes the corrupt signature obvious. Recommendation: drop signature parts and report redaction.signatures-removed, since a redacted file cannot keep a valid signature.
6. Office checks (the output of each new rewrite opens without a repair prompt): the base64 rewrite of custom XML, the _x re-escape of a shared string, the dropped PNG chunk, the blanked zip comments and the removed slide links. Committed unanswered in testdata/redaction/ORACLE-REQUEST.md.

Information-only corpus run

Not a gate. Documents from public corpora (never committed), redacted with a pattern and re-verified:

• Census of 1,850 Office Open XML files (documents, workbooks and presentations from web crawls and bug trackers). Parts beyond text and pictures: embedded fonts (202), macro projects (76) and one signature, ActiveX controls (44), EMF/WMF pictures (165), video and audio, SVG, one included HTML page, one included Word file, one PDF. Extension namespaces in use go up to Word 2024 (sdtformatlock, word16du, sdtdatahash) and include the three generations of chart extensions (chartex), ink, 3D models and the Excel revision streams. The extension namespaces are all covered by the generic text and attribute passes; the embedded fonts led to the big-endian fix (finding 10).
• Documents, \bthe\b ignoring case: 297 readable files, all redacted and verified (6,499 and 8,910 replacements); 3 truncated downloads gave format.unrecognised. 25 files have a redaction.opaque-part gap (embedded objects, fonts, pictures).
• Presentations, same pattern: 100 of 100 verified.
• Workbooks, pattern \b[A-Z][a-z]{5,}\b: 198 redacted, 140 verified. The 58 unverified are workbooks with macro projects (the project's module and class names are readable once the source is decompressed: reported, as designed), printer settings that hold deflated text, and the TargetMode="External" attribute of relationship files, which a pattern like this matches as structure (see Known gaps in docs/redaction.md: patterns should be as specific as the secret).
• Two more truncated workbooks gave format.unrecognised. Time per file: 54 to 180 ms on average, 7.7 s at most.