An extractor's job is to walk a document and return strings. Invisibility is a property of how a viewer is told to draw those strings, not of the strings themselves. A PDF can carry a rendering mode telling viewers not to display text, or set the fill colour to the page background [2]. Neither changes what a parser hands back. Word is blunter: hidden is an attribute on the run, sitting right next to the text, independent of colour or size [3]. PowerPoint notes live in their own part of the package, and most extraction tools read them by default [4]. Spreadsheets hide whole rows, columns and sheets, and a cell comment shows only on hover [5]. Nothing here is broken. What is missing is a policy, because the pipeline has no reason to tell deliberate concealment from ordinary content unless something checks [8].
That policy is expensive precisely because concealment is normal. Hidden helper columns, private presenter notes and draft text somebody hid instead of deleting are everyday artefacts [7]. So a detector keyed on hidden content will fire on a large number of legitimate files, and the write-up as published carries no false-positive rate and no evaluation corpus [3]. There is no benchmark table to argue with. The transferable question is about your corpus: if your PDFs come from vendors and your spreadsheets from other teams' exports, quarantine volume is the adoption cost, and it lands on whoever owns the knowledge base. That the library returns quarantine as an action distinct from block suggests the author expects exactly that [17].
The engineering choices underneath are sound. No LLM dependency, no network calls, deterministic rules, argued as a considered tradeoff for reproducibility and a light footprint in someone else's pipeline [18]. Deterministic means diffable in CI, which is what you want from a gate. The two halves age differently, though. Structural hidden-content detection keys on a document property an attacker cannot avoid while staying invisible. Pattern matching for language characteristic of an instruction aimed at an AI system [14] is a blocklist, and blocklists lose to rephrasing. Reporting both as separate findings when they co-occur [16] is the honest way to score that.
Now the aside worth having. The post claims an adapter for each of six supported formats, then lists seven [1]. Count it yourself. The interesting part is which two have no documented hiding mechanism: plain text and Markdown [2]. Markdown is what OKF stores, as files agents read directly with no processing layer in between [11], and that directness is the format's stated design goal [12]. So the guard only helps where a source document is converted into the bundle [13]. Any file that reaches the bundle by another route never meets sanitize().
The library also makes no claim about the accuracy of content it passes [19]. Read that as the scope statement it is. It turns an invisible-text problem into a visible-text problem, and visible text still needs provenance for entirely separate reasons.
