Three Hidden Surfaces Inside a Source Archive
ArXiv source archives expose three different security surfaces, and each one crosses the boundary from a working project to a public record in a different way. This chapter focuses on the mechanism: which files the build actually needs, what metadata travels with them, and how source text can remain public without affecting a single pixel of the PDF. That map lets us judge both the value and the limits of a source-archive audit.
The file surface follows the build graph
A LaTeX build is a dependency relationship. The main document refers to other inputs, the compiler follows those references, and the resulting set of reads determines what is needed for that particular output. A file that the submission contains but the build never reads is commonly called a dangling file. It may be harmless, useful as supplementary material, or dangerously revealing. The word describes its relationship to the build, not the author’s intention.
That distinction is more important than it first appears. An author can remove a paragraph from the visible paper but leave the earlier draft in the same archive. They can generate a fresh figure while retaining an older export with embedded data. They can copy a project directory for submission and forget that a log or backup came along. Because none of those leftovers is needed to produce the final PDF, the document can compile perfectly while the archive preserves a much longer history of the work.
The Hidden Secrets study found 12.0 million dangling files across the arXiv source corpus it examined. The file types ranged from ordinary text and images to scripts, research data, and executable material. The long tail matters more than the common template: it contains artifacts whose meaning comes from the authoring workflow rather than from the paper’s layout. The researchers found 74 submissions containing complete Git repositories, including their editing histories. They also found hidden filesystem remnants in 40 submissions and configuration files capable of carrying API keys or database connection strings in 2,774 submissions.
Those figures do not mean that every such file was a working credential or an accidental upload. Some submissions deliberately include additional data. The study notes that paths suggesting supplementary or additional data can indicate intentional distribution, while names suggesting old or backup material point in the opposite direction. A file-level detector can identify a mismatch between archive membership and build use; it cannot infer the author’s release decision from that mismatch alone.
This is where a build graph becomes more useful than a visual inspection. Instead of asking whether a file looks familiar, an audit asks whether the build actually imported it. LaTeXpOsEd describes reconstructing a dependency graph for each submission, excluding referenced assets, and retaining files that were never imported for a second inspection. The candidate set was then narrowed to file classes likely to contain sensitive information, such as structured data, plain text, source code, logs, backups, and database artifacts. The point is not that a particular extension is always unsafe. The point is to focus human attention where the PDF provides no evidence that the material was intended for public release.
This relationship also clarifies who owns the decision at the interface. The compiler owns the question “what did this run read?” The author or release team owns the different question “what do we mean to make public?” Those questions can diverge when a build depends on an environment, a package, or a conditional path that is not exercised in the audit. A recorder or dependency graph describes observed behavior under a particular compilation; it does not certify that every possible build path has been tested. That limitation is still useful. It is a precise way to identify the material that needs an intentional release decision instead of relying on memory or filename conventions.
The file surface therefore has two failure modes. If the audit removes only what it fails to recognize, sensitive residue remains. If it removes everything outside the observed dependency set, legitimate ancillary material or a needed alternate input may disappear. The correct control is not a universal deletion rule. It is an explicit handoff from automated observation to human ownership, followed by a new build and comparison after the decision.
Build evidence also has a boundary. “Not read during compilation” is a strong statement about one build, but not necessarily about the whole publication. A data file may be intentionally provided for reuse even if the paper does not import it. A README may communicate submission instructions. A repository’s ancillary-file convention may explicitly preserve material that is not part of the PDF. Blind deletion can therefore damage reproducibility or discard legitimate supplements. The safer decision is two-stage: use the build graph to find what needs a separate review, then decide whether each item is intentional, necessary, or removable.
The reverse failure is equally important. If an author cleans only the files that are obviously unused, they may leave sensitive material inside files that the build does read. The bibliography illustrates the boundary. A compiled bibliography file can be sufficient for the build, while a source bibliography may still contain unreferenced entries, note fields, or keys that expose collaboration history. Removing every source bibliography would not be a safe universal rule; assuming that every required input is harmless is no safer.
The file surface can also carry more history than the author expects. A version-control directory or a generated backup can preserve earlier names, abandoned arguments, or intermediate results. A log can record an endpoint or a diagnostic message that never appears in the manuscript. A structured data file can contain rows that were excluded from the published analysis. In each case, the archive has become a record of process rather than merely a container for the final result.
That process record is often more revealing precisely because it was not prepared for readers. The final paper has been edited for explanation. A debug artifact has been written for a tool, a collaborator, or the author’s future self. It may therefore contain direct language, default settings, temporary identifiers, or assumptions that would have been removed from public prose. The archive’s security problem begins when the submission system preserves that private context without requiring a separate decision about it.
The diagram captures a subtle but decisive property: the archive can contain several kinds of information that are not represented in the PDF, even though the PDF came from the same submission. File-level review is therefore not an optional cleanup after the “real” publication. It is a review of a different output surface.
Metadata and source text carry different kinds of history
Metadata is information attached to a file rather than written as part of its visible content. It can come from the archive process, the software that created an asset, or the device that captured it. A source review that reads only text can miss all three.
The Hidden Secrets researchers found modification timestamps in 90% of submissions. In 72% of submissions, at least one timestamp fell within an hour of the recorded submission time, and 35% fell within five minutes. Those patterns can reveal when the final packaging happened. Creation dates can describe a much longer authoring process: after excluding commonly reused templates, 83% of submissions indicated creation dates more than 180 days before submission. Timestamps are not automatically private, and they do not prove who worked at a particular moment. They are side-channel evidence that can become meaningful when correlated with other records.
Embedded metadata adds a different route to the same kind of inference. The study found metadata in 62% of non-dangling files and 61% of dangling files that it analyzed with metadata-extraction tools. Images and PDFs were especially likely to carry it. Source-only fields included usernames, software information, email addresses, and hardware details. GPS data appeared in 7,326 submissions; in a small manual sample of coordinate clusters, most included both research buildings and residential areas. That sample cannot establish a general rate of personal identification, but it demonstrates why location fields deserve more than a cosmetic cleanup.
LaTeXpOsEd reports a separate finding of nearly 1,200 images with sensitive metadata in its 100,000-paper sample. The number is not interchangeable with the full-corpus count: the studies use different populations and filters. Their agreement is more basic and more useful. A figure can look innocuous in the PDF while retaining device, software, timestamp, or location information in the file that generated it. A metadata check is therefore a distinct control, not a more thorough way of reading the page.
The third surface is source text that is present but irrelevant to rendering. LaTeX comments are familiar because a percent sign can make a line disappear from the output. But the Hidden Secrets study identifies several ways for irrelevant text to survive in a source archive: ordinary comments and comment environments, material outside the document region, branches of a conditional that the build does not take, and arguments discarded by custom command definitions. In each case, the content is still available to someone reading the source even though it does not enter the PDF.
This is why “delete every line beginning with a comment marker” is not a complete model. A percent sign can be meaningful inside a special environment. An escaped character can look like a comment delimiter without acting like one. A disabled branch can contain a full alternative argument. A command definition can receive text that is never used. A cleaner that does not understand enough of the source structure can leave sensitive material behind or remove text that was needed for the document to compile correctly.
The scale of ordinary comments makes the problem easy to underestimate. Hidden Secrets reports 644 million comment occurrences before its filtering process and says comments appeared in 95% of the considered submissions. After removing repeated material likely inherited from templates, the study still had 114 million “interesting” comments spanning 75% of the considered submissions. Most comments are not secrets. They can be formatting aids, mathematical markup, bibliography notes, or harmless fragments. The important point is that the same storage mechanism also carries conversations, todo items, review responses, and alternative text.
The studies use context to separate likely candidates from noise. Pattern matching can locate URLs, email addresses, IP addresses, banking identifiers, and recognizable secret formats at high volume. Hidden Secrets applied entropy filters and known pattern lists, then manually validated selected findings. It reports examples involving API tokens, private keys, and passwords, as well as links to cloud storage and collaborative documents. LaTeXpOsEd’s benchmark, however, shows why a pattern hit is not a verdict: TruffleHog found only four true credentials in its synthetic test while producing many false positives. A token-shaped string may be a placeholder, an example, or a live value; the surrounding text and its access context matter.
This is also true for lower-severity material. A URL may identify a public paper, a private folder, or an editable document. An email address may be intentionally printed in an author block or accidentally retained in a comment. A timestamp may be a template artifact or a clue about the person who prepared the archive. The same field changes significance when it appears in a different surface and is combined with other identifiers. The useful question is not simply “is this string sensitive?” but “what does its location and context make possible?”
The three surfaces should consequently be inspected as separate interfaces of one system. The file interface asks what the package retains beyond the build graph. The metadata interface asks what files reveal about their origin and handling. The content interface asks what source text exists outside the rendered argument. A strong audit can connect findings across those interfaces, but it should not assume that one clean result implies the others are clean.
Once the archive is understood this way, the headline numbers from large-scale studies become easier to read. A count of dangling files, a rate of metadata-bearing submissions, and a count of sensitive comments describe different objects and different mechanisms. They are not competing descriptions of one hidden folder. They are measurements of separate surfaces that happen to cross the same publication boundary.