The PDF Is Not the Whole Publication

ArXiv source archives—not just the rendered PDFs—are the subject of this series. The immediate question is simple: what can remain public when a paper looks clean in its PDF? Separating the build output from the submitted package gives us a practical judgment: a successful compilation says that the paper renders; it does not say that the surrounding archive is private, minimal, or free of secrets.

That distinction matters because an arXiv preprint is more than a file someone reads in a browser. A preprint is an early version of research shared before formal publication, often so that others can inspect, discuss, reuse, or build on it quickly. ArXiv’s model supports that openness by making source materials available for a large share of LaTeX-based submissions. The source can help with accessibility and long-term reuse, but it also carries the residue of how the paper was made.

The result is a mismatch between two ordinary intuitions. Authors often think of comments, intermediate files, and image properties as private working material. Readers often think of the PDF as the work that was published. The repository may hold both assumptions at once: a polished reading view and a much richer public package. Understanding that gap is the foundation for deciding what should be released, what should be checked, and what must be treated as exposed if it was uploaded accidentally.

A preprint is more than its reading view

A LaTeX submission has a build relationship. One or more source files define the document; the compiler follows the inputs it needs, reads images or bibliographic material, and produces a PDF. That PDF is the visible result of the relationship. It is not a complete inventory of everything the compiler was given.

The archive can retain files that were never needed for the build. An old draft, a debugging log, a backup, a data extract, or a copy of a project’s history may sit beside the files that produced the final pages. Because those materials do not change the pages, an author can inspect the PDF repeatedly and never notice that they are public. A reviewer who sees only the PDF has the same blind spot.

The distinction is not absolute in the other direction. Some material outside the rendered pages may be intentionally distributed as supplementary data or ancillary content. “Not used to make the PDF” therefore does not automatically mean “should be deleted.” It means that the material deserves a separate release decision. A build system can tell us what it used; it cannot, by itself, decide what the author intended to publish.

A useful thought experiment is to ask what a stranger could learn without reconstructing the paper at all. They might compare the archive with the PDF and find a draft paragraph that was abandoned, a note addressed to a collaborator, or a data file that was useful during analysis but never meant to accompany the result. None of these items has to be maliciously planted or technically sophisticated. They persist because the submission process treats the package as material to build from, while the author may still be treating it as a private workspace. The security boundary fails at that handoff between uses.

There is also a time dimension. ArXiv creates a versioned record, and the supplied studies describe older source material as remaining accessible in the analyzed workflow even after a later revision or withdrawal. A corrected PDF can therefore coexist with an older archive that still contains the original mistake. Replacing the visible document may improve the current reading view without closing the earlier disclosure.

This is why the subject is specifically the arXiv source archive, not “document security” in the abstract. The archive has an owner—the submitting author or team—an operating process—the build and submission pipeline—and a public lifecycle that can preserve more state than the final pages reveal. The question is not whether openness is good. It is whether the public boundary has been understood before the package crosses it.

The build creates three public surfaces

The Hidden Secrets study gives this problem a useful structure by separating three dimensions of information that can sit outside the PDF’s normal reading path.

The first is the file surface. A file is “dangling” when it is present in the submission but is not required to compile the paper. This surface is where workflow residue becomes especially easy to overlook. Logs and backups may preserve earlier values. Configuration or data files may contain connection details or personal information. A complete version-control history can reveal not only the current text but how it changed. Even a bibliography that is unnecessary for compilation can contain private notes or traces of collaboration.

The second is the metadata surface. Files can carry information in properties rather than in their visible content: modification times, software and device identifiers, usernames, email addresses, or image location data. A photograph inserted into a paper may look harmless on the page while retaining coordinates in its EXIF metadata. A cluster of timestamps can also expose something about an author’s working pattern. These clues may not open an account, but they can support profiling or correlation when combined with names, affiliations, and other public facts.

The third is the content and text surface. Some information lives inside a source file that the build does use, but does not influence the output. LaTeX comments are the obvious example, yet the mechanism is broader: text can be outside the document region, placed in a disabled conditional branch, or hidden in an argument that a command discards. Such content is invisible in the PDF while remaining ordinary text in the archive.

These surfaces can overlap, but they are not substitutes for one another. Deleting unused files does not remove a comment in a required source file. Removing comments does not erase a camera’s location metadata. Stripping metadata does not notice a private document sitting in the archive. A release check that examines only one surface can produce a clean result for that surface while leaving the other two untouched.

The distinction also changes who the audience is. The PDF is designed for a human reader following the argument; the source archive is legible to anyone willing to search, extract, or compare its contents. That second audience does not need to be an advanced attacker. A curious reviewer, a data miner, or an automated scanner can find repeated patterns much faster than an author can remember every temporary artifact in a project directory. Public availability turns ordinary residue into searchable evidence, even when no one was invited to read it.

flowchart LR S["Author submission"] --> B["Build process"] B --> P["Compiled PDF"] P --> R["Normal reading view"] S --> A["Public source archive"] A --> U["Unreferenced files"] A --> T["Comments or disabled content"] A --> M["Embedded metadata"] U --> X["Archive-visible information"] T --> X M --> X R --> V["What the PDF reveals"] A --> W["What the archive can reveal"]

The important boundary is therefore not between “the paper” and “everything else.” It is between information that affects the rendered reading view and information that is merely carried along by the public package. Both are published when the archive is exposed, even though only one is visible during ordinary reading.

The stakes are not all the same

Calling something hidden does not tell us how serious it is. The supplied studies describe a spectrum. At the low end, an unused template may create unnecessary storage or reveal a likely submission history. A timestamp or software identifier may disclose authoring context. Those details can still matter, especially when several clues can be correlated, but they are not equivalent to an active credential.

At a higher level, source material can expose private correspondence, reviewer comments, unfinished tasks, or disagreements among coauthors. These disclosures may damage trust or reputation without giving anyone technical access to a system. They also change the meaning of the published work: a comment about a limitation or an argument that was abandoned can reveal how the final claim was negotiated, even though it is absent from the final prose.

The most urgent cases are access-enabling or identifying material. The studies report examples involving passwords, API and cloud tokens, private keys, editable documents, survey data containing personal information, and location metadata. A private link may be more than a reference: depending on its permissions, it can act as a credential. A string that looks like a secret may instead be a test value, so context and validation matter; but an apparently small disclosure can become consequential when it is valid, combined with a target, or linked to an identifiable person.

That is also why the word “public” is not enough to settle the privacy question. A name or email address may be deliberately included in a paper. The same field in a commented-out draft, a leftover data file, or an image’s hidden properties can signal that it was not intended for public communication. Sensitivity depends on what was disclosed, where it was placed, who can reach it, and how it can be combined with other information.

The scale of the problem makes individual vigilance necessary but not sufficient. Hidden Secrets reports that 88% of source submissions had at least one form of “interesting” hidden information under its broad, uniqueness-filtered definition. That is not a claim that 88% contained confirmed secrets; it is evidence that non-rendered material is common enough to be a systems problem. A separate study finds a narrower set of explicitly sensitive disclosures in a sampled corpus. The difference between those measurements is important, and the next step is to understand what each number actually counts.

For now, the practical rule is modest: treat the source archive as part of the publication, not as a private implementation detail behind the PDF. Ask what the build needs, what the package retains, what metadata travels with it, and what text never reaches the page. A clean reading view is a necessary achievement. It becomes a trustworthy publication only when the wider archive has received the same attention.

References