X-raying the arXiv: A Large-Scale Analysis of arXiv

Submissions’ Source Files

Giovanni Apruzzese Aurore Fass
University of Liechtenstein Inria Centre at Université Côte d’Azur
Vaduz, Liechtenstein Sophia Antipolis, France
Reykjavik University CISPA Helmholtz Center for Information Security
Reykjavik, Iceland Saarbrücken, Germany
[Link]@[Link] [Link]@[Link]
Abstract
arXiv:2601.11385v1 [[Link]] 16 Jan 2026

arXiv is the largest open-access repository for scientific

literature. When submitting a paper, authors upload the man-
uscript’s source files, from which the final PDF is compiled.
These source files are also publicly downloadable, poten-
tially exposing data unrelated to the published paper—such
as figures, documents, or comments—that may unintention-
ally reveal confidential information or simply waste storage
space. We thus ask ourselves: “What can be found within the
source files of arXiv submissions?”
We present a longitudinal analysis of ≈600,000 submis- Fig. 1: An arXiv submission. Clicking on “TEX Source” allows
sions appeared on arXiv between 2015–2025. For each sub- anyone to download the source files of this paper.
mission, we examine the uploaded source files to quantify
and characterize data not required for producing the respec- arXiv [25]; or (b) submit the source TEX files of a paper, which
tive PDF. On average, 27% of the data in each submission are are then rendered as PDF by arXiv itself—this is the way
unnecessary, totaling >580 GB of redundant content across recommended by arXiv [27] and used by most submissions.
our dataset. Qualitative inspection reveals the presence of of- arXiv is rooted on the concept of openness [12]. For in-
fensive/inappropriate text (e.g., “WTF does this mean?”) and stance, the web page of a submission provides a history that
experimental details that could disclose ongoing research. lists all the previous “versions” of such a submission. All such
We have contacted arXiv’s leadership team, as well as the au- versions are freely retrievable (in PDF format); even submis-
thors of affected papers to alert them of these issues. Finally, sions that have been withdrawn still retain the full history
we propose recommendations and an automated tool to de- of previous versions (see, e.g., [10]). However, arXiv also
tect and analyze arXiv submissions residual data at scale, provides the possibility to retrieve the submissions’ source
aiming to improve data hygiene in the arXiv’s ecosystem. TEX files. We show this in Figure 1. In other words, anyone
can download, and inspect, the files that a paper’s author has
1 Introduction uploaded to arXiv during the submission procedure. We argue
arXiv represents a cornerstone for modern research, en- that this peculiarity deserves particular attention.
abling the fast and free exchange (upload and download) A TEX project can be complex [63]. For instance, besides
of “preprints” used to disseminate the most recent scientific the content shown in the PDF produced after the compila-
discoveries [28]. As of August 2025, over 60M connections tion, the source code of a TEX project can include custom
are made daily to arXiv [19]. Its databases encompass over macros or even textual comments that are not part of the
2.8M submissions, whose overall number of downloads ex- actual PDF. Moreover, focusing the attention on research
ceeds 3.3 billions [19]. Just in Q1 2025, over 65k papers have papers, it is well-known that “a scientific paper consists of a
been submitted to arXiv, spanning a variety of domains—of constellation of artifacts that extend beyond the document
which computer science detains the lion’s share [19, 45]. itself” [2]. Therefore, it is sensible to assume that the TEX
Uploading a preprint on arXiv is a simple process: an source files of a research paper contain a variety of data (be-
author, potentially after having received an endorsement by yond textual comments) that are not necessary to produce
another arXiv user, can either (a) submit a paper as a PDF— the paper, such as unused images, old sections of the paper,
but such an option is rarely used (we found that only 10% of or even files that are completely unrelated to the PDF (e.g.,
submissions are made in this way) and is not encouraged by experimental source code, research spreadsheets, or different
1
 Giovanni Apruzzese and Aurore Fass

PDF documents). Indeed, nowadays, online TEX editors such randomly-chosen TEX projects of 2025. We also carried out a
as Overleaf (which has over 20M users [50]) enable sharing keyword-driven search, looking for occurrences of specific
projects across different users, facilitating joint writing be- terms across the textual comments of TEX files. Among the
tween researchers [49] who, during their interactions, may most concerning findings, we mention: instances of of-
put such “unnecessary” data within the files of a TEX project. fensive language (e.g., “stupid fucking revision”), occasionally
Simply put, a large variety of data not necessary to make towards other authors (e.g., “we should cite the stupid *** pa-
the final PDF can be placed within the source TEX files of a per”); concealed text reporting links to code repositories not
scientific article. As long as such data remains within the included in the actual paper; over 1.5k links to Google docs –
authors’ control (e.g., on a shared Overleaf project), then at least 200 of which “accessible to anyone with the link” and
no harm is done. Similarly, if the paper is to be uploaded containing undisclosed/confidential data – suggestions to
on arXiv, the authors can diligently clean their TEX project avoid mentioning limitations; presence of private documents
from any data that is not needed to make the PDF or that is (e.g., theses under embargo, cover letters).
not intended to be publicly released. Yet, we wonder: what if Our findings suggest that the submitters of arXiv papers
authors of arXiv’s submissions “forget” to clean their projects are not aware that the TEX source files are publicly available.
before uploading the source TEX files on arXiv? And what Hence, we have reached out to the authors of the submis-
if the authors are oblivious of the fact that the TEX files of sions with concerning residual data that we found, informing
their arXiv submissions are publicly retrievable? In either them that: (a) the TEX source files of their submissions are
of these what-if scenarios, there is a risk that some arXiv public and contain sensitive data (according to our judg-
submissions may contain residual data, i.e., data that is not ment); (b) updating their submission by uploading new TEX
needed to produce the PDF. Such residual data not only source files would overwrite those currently available on
(i) wastes storage space on arXiv’s servers, but may also arXiv. Hence, with this paper, we aim to raise awareness
(ii) contain sensitive information that the authors do not and make members of the community aware of the public-
want to be made public—such as undisclosed research details, availability of arXiv submissions’ TEX source files.
private data, or embarrassing / harmful text. Contributions. After downloading 1.6TB-worth of data (§2),
Research Goal and Major Findings. We hypothesize representing ≈600k submissions appeared on arXiv within
that arXiv’s submitters may not clean their TEX source files the first four months of each year across 2015–2025:
before upload. We thus seek to answer two research ques- ● we develop BaRDE (§3), an original tool that enables bulk-
tions: “how much residual data is there on arXiv?” (RQ1) and extraction of residual data (i.e., not necessary to produce
“what sort of sensitive information can be found within such the PDF of a TEX project) of arXiv submissions;
residual data?” (RQ2). To answer these RQs, we carry out the ● using BaRDE, we quantitatively analyze the residual data
largest longitudinal analysis of arXiv submissions’ source present on arXiv (§4), and we also validate our results (§5);
files. We download the source files of all 600k submissions ● through qualitative coding and keyword-driven searches,
which appeared on arXiv within the first four months of the we manually analyze the residual data present on arXiv, fo-
2015–2025 timespan (i.e., 11 years). Then, we develop BaRDE cusing on cases raising privacy / confidentiality concerns (§6).
(short for “Bulk arXiv Residual Data Extractor”), a custom We responsibly disclosed our findings to arXiv and to authors
tool that we use to process all the source files we downloaded of submissions with sensitive residual data (§8). To the best
(which add up to 1.6TB in compressed format). of our knowledge, no prior work has carried out an analysis
Thanks to BaRDE, we can quantitatively answer RQ1: af- of similar size and scope on arXiv (related work is in §9).
ter decompressing our sample (obtaining 2.1TB of data), we
found 584GB of residual data, i.e., 27% of the data up- 2 Preliminaries and Data Collection
loaded (and stored) on arXiv is not necessary to create We summarize the submission process to arXiv (§2.1), de-
the corresponding paper. Worryingly, we find that the scribe how we collected the data used for our research (§2.2),
situation worsened over the years: the percentage of residual and explain how arXiv submissions are organized (§2.3).
data was ≈14% in 2015–2017, and rose to over 30% after 2020
(with a peak at 32% in 2022). Moreover, the residual data for 2.1 Submitting Papers to arXiv
4k TEX projects represents more than 95% of their total size. arXiv is a community-driven platform [12]. To make a sub-
Altogether, such residual data puts a heavy strain on arXiv’s mission on arXiv, users must first receive an endorsement
storage. We have hence disclosed our findings to arXiv’s (typically from another arXiv member [16]). Such an endorse-
leadership team, who confirmed receiving our message. ment is, however, only valid for a specific category. Indeed,
Then, to answer RQ2, we qualitatively analyzed a humanly- arXiv hosts submissions pertaining to a variety of “main”
feasible portion of the residual data we found. Two researchers scientific categories, such as Computer Science, or Physics;
developed a codebook and analyzed the residual data of 200 each of these categories is further broken down into “specific”
2
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

categories, such as Cryptography & Security, or Artificial Table 1: Data downloaded from AWS S3. Number of “chunks” and
Intelligence (see [21] for the complete categories). overall size (in GB) retrieved from S3 and containing the data we analyzed
arXiv’s vision is to facilitate dissemination of “established Year January
Chnks Size
February
Chnks Size
March
Chnks Size
April
Chnks Size
Total
Chnks Size
and emerging research” [12]. The submission of a paper is 2025 154 76.6 180 89.4 232 115.3 186 92.4 752 373.8
2024 134 67.3 149 74.9 176 88.0 161 81.0 620 311.3
not bound to a peer-review process. Some submissions may 2023 98 49.0 110 54.8 146 73.8 115 58.5 469 236.2
2022 84 42.5 90 45.0 122 61.7 98 49.1 394 198.4
present errors (and can be withdrawn [33]) or can be just 2021 69 35.3 76 38.7 109 56.0 93 47.5 347 177.6
short drafts / critiques (e.g. [30]); while others can become 2020
2019
40
33
21.1
16.8
42
33
23.1
16.7
50
38
27.3
18.9
51
42
27.8
21.4
183
146
99.4
73.9
seminal works (e.g., the adversarial example paper by Good- 2018 27 13.2 28 14.1 32 16.1 32 15.8 119 59.3
2017 21 10.1 20 10.0 26 13.2 23 11.1 90 44.5
fellow et al. [41]). Some authors may upload on arXiv an 2016 17 8.5 19 9.3 21 10.6 21 10.2 78 38.7
2015 15 7.4 16 7.8 18 8.8 17 8.2 66 32.1
early-version of a paper undergoing peer-review to share (sum) 692 347.8 763 383.8 970 489.7 839 423.0 3,264 1,645.2
their discoveries as soon as possible [28], while others may
use arXiv to provide a free version of a (peer-reviewed) article the only information provided in [15] was “The source files
published in some journal or conference proceedings [47]. [are grouped in] tar files of ≈500MB each and the complete
To make a submission, it is necessary to upload its source set of source files is about 2.9 TB (March 2023)”. We did not
files. As of November 2025, arXiv accepts two main classes know how many “chunks” of 500MB were included in each
of source files: a (zipped) file containing a TEX project, which month, so it was impossible to make any estimate.
will be compiled on arXiv’s infrastructure and used to pro- Hence, we initially downloaded just the data for the first
duce the PDF hosted on arXiv; or a single PDF, representing four months of 2025 (i.e., all months preceding the current
the actual paper. While the latter may seem the most intuitive one). This required 373GB (and around 40USD). We estimated
way, arXiv discourages such a practice, and explicitly forbids that the size for the previous years would be inferior (see,
uploading PDF files generated via LATEX [24]. Nonetheless, e.g., the growth of submissions on arXiv [19]). To enable a
as we wrote, arXiv enables anyone to download the source fair analysis which could reflect yearly trends, and given that
files of any given submission (see Figure 1). we had already downloaded the data for January–April 2025,
A submission’s PDF remains on arXiv perpetually [26]. we decided to focus only on the first four months of each
Authors can update the submission by uploading different year. According to our budget (around 150USD), we were
source files. Doing so will create a new “version” of a sub- able to afford downloads back to 2015. At the end of this
mission, resulting in a new PDF: downstream users can re- process (which we finalized in July 2025), we downloaded a
trieve the PDF of any previous version of a submission. How- total of ≈1.6TB of data, distributed across 3,264 tar files of
ever, such versioning system does not apply for a submis- ≈500MB each. The detailed breakdown is in Table 1.
sion’s source files: whenever a submission is updated, its new
source files overwrite the previous ones. Hence, users cannot 2.3 Structure of Submissions’ Source Files
retrieve the source files of past versions of a submission. After downloading our dataset, we inspected its contents to
get a preliminary understanding of how to plan our analyses.
2.2 Retrieval of Papers (Data Collection) We extracted the 154 chunks of January 2025. We obtained
To comprehensively investigate what lies within the source a total of 19,407 files in the form “[Link]”,
files of arXiv submissions, we need to download thousands of where: YY and MM represent the year and month; XXXXX is
submissions’ source files. Doing so manually is unthinkable. a five-digit integer which progressively increases; and EXT
The best option we found1 , which is also endorsed by arXiv is the extension of the file. Notably, the extension included
itself [14], was by accessing the copy of arXiv’s database only two types: PDF or GZ. We provide a snippet in Figure 2.
hosted on Amazon S3 [15]. Such a database contains the We hypothesized that all PDF files were submissions up-
source files of all arXiv’s submissions, updated monthly, loaded directly as a PDF: we confirmed such an hypothesis by
which we could download (at a cost [11]) from Amazon visiting the web pages of such submissions (e.g., 2501.00008
S3—without burdening arXiv’s servers. Hence, after setting in Figure 2) and noticing that they lacked the “Source Files”
up an AWS account, we began (in May 2025) downloading button. We then turned our attention to the GZ files, i.e.,
the data used in our assessment. However, at this point in compressed archives. Some were very small (e.g., 2501.00002
time, we did not know how much data we needed to down- in Figure 2) and contained a single extensionless file typi-
load, nor how expensive such operations would be. Indeed, cally named “withdrawn”: we hypothesized that such files
1We
were those referring to papers withdrawn from arXiv (we
first considered scraping. However, even by considering the “scrape-
verified this—explaining why 2501.00002 has a more recent
friendly” endpoint of arXiv (i.e., [1]), scraping approaches are not viable.
According to arXiv’s terms [14] “a reasonable rate are bursts of 4 requests “Last Modified” date than the other submissions in Figure 2).
per second with a 1 second sleep”; moreover, the robots page of arXiv However, the vast majority of GZ files contained TEX-
explicitly prohibits programmatic source-file download [20]. related data, which could come in two different formats.
3
 Giovanni Apruzzese and Aurore Fass

that are not. Then, we must identify the data that, in a project,
is not necessary to produce the final PDF. Doing so, however,
requires determining the root TEX file of a given project. In-
deed, we do not know a priori what file is the “starting point”
for the TEX compilation. Nevertheless, given the scale of our
dataset, the analysis of residual data must be done automati-
cally (we cannot manually process 600k submissions!).
Tackling RQ2. After extracting the residual data of a
given TEX project, we must inspect such data to determine
whether it is “problematic” or not. Such an objective can be
done via some automation (e.g., keyword-driven searches
or even via NLP techniques such as topic modeling [58]).
Given the exploratory nature of our study (for which we lack
ground truth) we shall not rely on black-box methods (due
Fig. 2: Snippet of files extracted from a “chunk”. We show the
to lack of transparency [67] and/or “hallucinations” [60]); in-
first 10 files (alongside their size and last modification), each denoting a
specific submission, of the first “chunk” of January 2025 taken from S3.
stead, we prefer to use human expertise to infer whether the
residual data of any given submission is truly worthy of at-
Specifically, either (a) as a single TEX file (e.g., this was the tention. Such an approach implicitly introduces the reliance
case for the content of [Link]); or (b) as a blob which, on best-effort strategies and prevents complete coverage.
if unpacked, yielded a “full-fledged” TEX project, with various
files and folders (e.g., this was the case for [Link]). In 3.2 BaRDE (Bulk arXiv Residual Data Extractor)
either case, all GZ files always contained only one file (for the We are not aware of any automated tool, whether open or
blob, such file was always named after the submission ID). closed-source, which enables us to carry out the analysis
required to answer RQ1. A close match is the “arxiv-latex-
3 Research Methods and Tools cleaner” [42] (ALC), but it cannot be used for our purpose
We define the scope of our study and the challenges we because it assumes complete knowledge of a TEX project—
need to overcome (§3.1). We then describe our solution, which we do not have. So, we had to develop our own tool,
BaRDE (§3.2), and finally run BaRDE on our dataset (§3.3). BaRDE (we will compare BaRDE with ALC in §9).
The entire workflow of our study is shown in Figure 3. We provide an overview of BaRDE (§3.2.1) before present-
ing our design choices (§3.2.2). Finally, we discuss some tech-
Definitions. To facilitate the understanding of the re- nical difficulties encountered while developing BaRDE (§3.2.3).
mainder of our work, we define the most recurrent terms:
3.2.1 Generic Design. BaRDE is the product of extensive trial-
● Submission: any “paper / preprint” for which an entry
and-error done by the authors, who attempted to reverse-
exists on arXiv, identified with an ID (e.g., 2501.00001).
engineer not only the way in which arXiv organizes the
● Project: a submission whose source files are a TEX project.
source files of its submissions, but also the specific charac-
● Residual data: any data within a project that is not
teristics of arXiv itself (e.g., the “ancillary folder” [13]).
needed to produce the PDF on arXiv. This includes both
Handling compressed data. To develop BaRDE, we had
files (e.g., unused images) and text (e.g., comments).
to first consider that our dataset encompassed 1.6TB of data,
● Problematic projects: projects containing residual data
the majority of which in compressed format (i.e., the GZ
and which, in such data, include “sensitive” elements
files). Moreover, inside each of these GZ files, the majority
that can be considered as (a) offensive, (b) embarrassing,
of TEX projects were in the form of a blob—which must be un-
or which (c) leak private / confidential information.
packed before processing it. We could handle this “two-step
unpacking” in two ways: (a) unpacking everything before-
3.1 Problem Description and Challenges hand and then working on the unpacked data; or (b) keeping
Our two RQs entail analyzing, quantitatively and qualita- everything in compressed format, and deal with the unzip-
tively, the residual data of an arXiv’s submission source files. ping / unpacking during runtime. We opted for the latter:
Of course, submissions whose source files are just a single the former would have required an unpredictable amount
PDF do not, by definition, have any residual data. Similarly, of storage space (at a minimum, assuming no compression,
“withdrawn” submissions are not of interest for our study. another 1.6TB) which we did not have. Such a design choice
Tackling RQ1. Our first objective is separating submis- adds complexity, but it enables a smoother application of
sions whose source files resemble TEX projects from those BaRDE by future research since it is designed to work on
4
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

Residual Data Quantitative Analysis Qualitative Analysis Recommendations

Data Collection
Extraction of Residual Data [RQ1] of Residual Data [RQ2] and Publication
Amazon S3 How much residual Coding-based manual Disclosure to arXiv's
Preliminary Inspection
data (ℛ) is on arXiv? inspection of ℛ leadership team

Development of How is ℛ distributed Keyword-driven Author outreach

BaRDE across categories? search across ℛ and briefing

Get source files of Processing collected What filetypes are Identifying submissions Dissemination of
arXiv submissions data with BaRDE predominant in ℛ? with concerning ℛ Results

Fig. 3: Overview of our research. We downloaded our dataset in May–July 2025. We reached out to arXiv and to authors of “problematic”
submissions in August 2025. We will wait at least 90 days (in line with best practices [66]) before disseminating our findings.

the source files in their natural format. To handle the unzip- Alg. 1: BaRDE pseudocode (extended in Algorithm 2)
ping / unpacking, we relied on 7zip [52], which is free and Input: 𝑖𝑛𝑝𝑢𝑡 _𝑓 𝑜𝑙𝑑𝑒𝑟 containing the submissions’ source files (GZ
supports both Windows and Linux OSes. and PDF) extracted from the chunks downloaded from S3.
Focus on precision. The other dilemma we faced when Output: 𝑟𝑒𝑝𝑜𝑟𝑡 containing, for each submission that is a valid TEX
project: statistics on its used & residual files, as well as the
developing BaRDE was whether to opt for (a) coverage or concatenation of the textual comments found in its (used)
(b) precision. We could either develop a tool that, in cases of TEX files; and the submissions that have been excluded.

uncertainty in determining the root file of a TEX project, may 1 𝑃𝐷𝐹 _𝑙𝑖𝑠𝑡,𝑇 𝑒𝑋 _𝑙𝑖𝑠𝑡, 𝑒𝑥𝑐𝑙𝑢𝑑𝑒𝑑_𝑙𝑖𝑠𝑡 ← emptyList();
for submission in 𝑖𝑛𝑝𝑢𝑡 _𝑓 𝑜𝑙𝑑𝑒𝑟 do
have made a decision that could have raised “false positives” 2
if [Link] = "PDF" then
(e.g., flagging residual data that is actually an integral part of
3
4 𝑃𝐷𝐹 _𝑙𝑖𝑠𝑡 ← 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷;
the TEX project); or favor a more conservative approach. We 5 continue
favored precision: if BaRDE cannot determine the root file of 6 // If here, then it’s a GZ file, which must be unzipped
a TEX project, the submission is skipped (but a log is updated). 7 𝑐𝑜𝑛𝑡𝑒𝑛𝑡 ← unzip(𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛);
// 𝑐𝑜𝑛𝑡𝑒𝑛𝑡 always has only one file
Importantly, BaRDE operates statically and does not carry 8

if [Link] = "TeX" then

out TEX compilation at runtime, which is a computationally
9
10 𝑇 𝑒𝑋 _𝑙𝑖𝑠𝑡 ← singleTeX(𝑐𝑜𝑛𝑡𝑒𝑛𝑡, 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷);
demanding task (we validate this assertion in §5). 11 continue
Workflow. We provide the generic pseudocode of BaRDE’s 12 if [Link] = [Link] then
workflow in Alg. 1 (extended by the functions in Alg. 2 in the 13 // 𝑓 𝑖𝑙𝑒 is blob, which must be unpacked
Appendix). BaRDE inspects all files in a given 𝑖𝑛𝑝𝑢𝑡_𝑓 𝑜𝑙𝑑𝑒𝑟 14 𝑟𝑜𝑜𝑡, 𝑢𝑛𝑝𝑎𝑐𝑘𝑒𝑑 ← inferRoot(𝑐𝑜𝑛𝑡𝑒𝑛𝑡 );
and stores the results of its analysis in dedicated 𝑙𝑖𝑠𝑡𝑠 : one for 15 if root = ∅ then
PDF files, one for TEX projects, and another for files excluded
16 𝑒𝑥𝑐𝑙𝑢𝑑𝑒𝑑_𝑙𝑖𝑠𝑡 ← 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷;
continue
from the analysis. If a file is a PDF, BaRDE updates 𝑃𝐷𝐹 _𝑙𝑖𝑠𝑡
17
18 𝑇 𝑒𝑋 _𝑙𝑖𝑠𝑡 ←
and begins to inspect the next submission. If a file is a GZ multiTeX(𝑟𝑜𝑜𝑡, 𝑢𝑛𝑝𝑎𝑐𝑘𝑒𝑑, 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷);
file, BaRDE unpacks it and analyzes its contents—which are 19 continue
always a single file. Three cases can happen: 20 // Unrecognized file or withdrawn submission, skip

a) the file is a blob, i.e., a TEX project, for which it is necessary 21 𝑒𝑥𝑐𝑙𝑢𝑑𝑒𝑑_𝑙𝑖𝑠𝑡 ← 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷;
𝑟𝑒𝑝𝑜𝑟𝑡 ← 𝑇 𝑒𝑋 _𝑙𝑖𝑠𝑡, 𝑃𝐷𝐹 _𝑙𝑖𝑠𝑡, 𝑒𝑥𝑐𝑙𝑢𝑑𝑒𝑑_𝑙𝑖𝑠𝑡 ;
to infer its TEX root and then infer its residual data (which 22
return 𝑟𝑒𝑝𝑜𝑟𝑡
can span both residual files and textual comments);
23

b) the file is a valid TEX file (and, hence, the submission is

a project), implying that the only residual data of this
project are the potential comments included in this file;
in Alg. 2 (in the Appendix B), which also provides addi-
c) the file is of an unrecognized type, or BaRDE cannot infer
tional low-level details on BaRDE: extractComments( 𝑓 𝑖𝑙𝑒 ),
the TEX root of a blob: the submission will be skipped.
inferRoot(𝑏𝑙𝑜𝑏 ), findResidual(𝑟𝑜𝑜𝑡, 𝑢𝑛𝑝𝑎𝑐𝑘𝑒𝑑 ).
While analyzing a (valid) TEX project, BaRDE stores the fol-
Extracting comments. To determine text classifiable as
lowing information: the corresponding 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷: the
“comment” in a TEX file, we inspected the content of such a
filenames and sizes of all of its 𝑢𝑠𝑒𝑑 and of its 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙 files;
file and identified either: lines starting with %; or text con-
and all the comments found in each 𝑢𝑠𝑒𝑑 TEX file.
tained within \begin{comment} \end{comment}, iffalse fi,
3.2.2 Low-Level Heuristics for Analyzing TEX Projects. We or if0 fi, all of which being well-known methods to mark
explain the ideas behind three functions of BaRDE, shown text that will not be shown in the final PDF (used also in [42]).
5
 Giovanni Apruzzese and Aurore Fass

By design, BaRDE extracts all comments of each used TEX file Table 2: Distribution of submissions in our sample. BaRDE an-
and stores them in a single file to ease further analyses. alyzes each submission to determine if it is a PDF-only submission,
Finding the TEX root. Determining the root is not trivial. or a TEX project; we also report withdrawn submissions, or those
In theory, the “starting point” of a TEX project is the file hav- which were skipped due to not being fully recognized by BaRDE.
ing, in the preamble, \documentclass [7]. However, we found
Year Submissions Valid TEX Projects PDF-only Withdrawn Unclear Root Unclear Type
2025 86,976 78,045 7,241 207 1412 71
that many projects have multiple TEX files containing such a 2024
2023
77,659
61,992
69,064
54,884
6,849
5,454
224
258
1458
1328
64
68
string in the preamble (this is typical when authors forget 2022
2021
59,040
58,817
51,942
51,418
5,468
6,028
214
200
1320
1101
96
70
to remove TEX files of “templates”). Hence, merely looking 2020
2019
54,382
48,889
47,736
43,064
5,421
4,844
205
188
940
677
80
116
for a file in the blob having \documentclass is not enough 2017
2016
38,133
36,087
33,991
32,291
3,518
3,208
187
199
325
243
112
146
to guarantee a root file. We thus implemented two heuris- 2015 33,524 29,751 3,213 190 257 113

tics to handle cases of projects having multiple files with (agg) 599,613 (100%) 531,203 (88.6%) 55,638 (9.3%) 2,231 (0.3%) 9,504 (1.6%) 1,037 (0.1%)

\documentclass in the preamble. First, we look for all files

100MB of residual data, most of which included in an anc/
having \documentclass, which we consider as 𝑟𝑜𝑜𝑡𝐶𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑒𝑠 . folder, which made us suspicious.
If, among these candidates, there is one file having the string Even realizing that the TEX root file cannot be trivially
“main” or “paper” or “cameraready” in its filename, then inferred (due to the potential presence of duplicates) came
BaRDE considers this file as root; alternatively, if there is only to our surprise. For instance, we found cases in which BaRDE
one file contained in the topmost folder of the project, then failed due to a clearly incorrect naming (e.g., we found a TEX
such a file is the root. Otherwise, BaRDE skips the project, project consisting of a single file with extension “.pdflatex”:
because it could not determine with certainty its root file. we are surprised that such a file was correctly processed
Identifying residual files. After finding the root file (de-
by arXiv servers). Moreover, we acknowledge that BaRDE in
rived from a blob), BaRDE adopts a bottom-up approach to
that it cannot handle “aliases”: for instance, BaRDE is unable
infer the project’s residual files. First, BaRDE inspects the con-
to recognize custom macros that call an external resource.
tent of the root file, looking for occurrences of terms that de-
Covering all such exceptions is beyond the scope of our
note methods “calling” a file, such as \input, \includegraphics,
work—but, as we will show, BaRDE is quite robust.
or \include (we provide in the Appendix B.2 the list of meth- Finally, an intrinsic issue we found was determining what
ods considered by BaRDE). Then, BaRDE captures the filename constitutes a residual file for arXiv. For instance, some projects
mentioned in such methods and stores it in a list called 𝑠𝑒𝑒𝑛 ; had “temporary” files that are not referenced anywhere and
afterwards, BaRDE will inspect such a file and recursively which are generated at compile time, which technically are
repeat the same process of finding “called” files, potentially not required to be uploaded (since arXiv does so automati-
updating the 𝑠𝑒𝑒𝑛 list. Finally, BaRDE will compare the file- cally) and persistently stored (we conjecture arXiv deletes
names in 𝑠𝑒𝑒𝑛 against all the filenames included in the project: such files after making the PDF). Moreover, we found projects
any filename in the project not included in 𝑠𝑒𝑒𝑛 is considered with many font-related files (mentioned in .map files), and
a residual file. However, to account for arXiv’s ancillary files we were unsure if such files were needed or not for arXiv’s
(which are files contained in a specific anc/ folder created compilers (we ultimately decided that such files are not resid-
ad-hoc by the authors to enable users to freely inspect addi- ual because they are called by some TEX files). Nonetheless,
tional material related to their submission but not included all such TEX-related files, whether they are residual or not,
in the PDF [13]), we remove any file included in the anc/ are unlikely to (i) contain sensitive data and do not (ii) use a
folder (if present) from the list of residual files. lot of storage space. Hence, our following analyses are not
3.2.3 Technical Difficulties and Lessons Learned. Developing impacted by our design choices.
BaRDE required engineering effort driven by our own exper-
tise: we had to operate blindly because we were not aware 3.3 Running BaRDE on our Dataset
of what can be found in each submission’s source files. We ran BaRDE across our dataset of 1.6TB. We present the
In particular, while developing BaRDE, we (i) used ≈2,000 results in Table 2 (extended in Table 6 in the Appendix).
projects as a blueprint to guide the low-level implementa- Overview. Overall, BaRDE found that, out of 599,613 total
tion of BaRDE, and we also (ii) used ≈1,100 submissions to submissions, 55,638 (9.3%) are PDF-only files—confirming
validate the correctness of BaRDE (we discuss our validation that such a format is rarely used. BaRDE also found that 2,231
in §5, and limitations in §7). Indeed, even though navigat- (0.3%) submissions have been withdrawn (we counted the
ing through a TEX project may appear simple, there are a number of “excluded projects” whose filename was “with-
myriad of “exceptions” (especially given the absolute size of drawn”). Finally, BaRDE correctly processed a total of 531,203
our dataset) that may cause issues. For instance, we were TEX projects—which will be the subject of our analyses.
not aware of the arXiv-exclusive “ancillary folder”, and we Performance assessment. We can use these results to
noticed it because we found a project (i.e., [34]) having over estimate the “coverage” of BaRDE. Barely 10k projects (out of
6
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

Table 3: Size (in MB) of Residual Data (ℛ). We report the cu- Table 4: Distribution of projects according to the total size of
mulative size (computed across the first four months of each year) their residual files (ℱ). Note that ℛ=ℱ+Comments.
of the residual files, comments, as well as the total size of ℛ , and
Year ℱ<1KB 1KB<ℱ<1MB ℱ>1MB
total size of projects; and the ratio between the last two elements.
2025 20,273 (25.98%) 40,564 (51.98%) 17,208 (22.05%)
Residual Size of Total size Tot. size 2024 19,979 (28.93%) 34,410 (49.82%) 14,675 (21.25%)
Year %ℛ
Files size Comm. of ℛ Projects 2023 17,950 (32.71%) 23,685 (43.15%) 13,249 (24.14%)
2025 125,815 746 126,561 465,648 27.18% 2022 18,900 (36.39%) 20,871 (40.18%) 12,171 (23.43%)
2024 114,641 667 115,308 411,000 28.06% 2021 20,562 (39.99%) 19,765 (38.44%) 11,091 (21.57%)
2023 95,123 504 95,627 305,768 31.27% 2020 22,692 (47.54%) 17,614 (36.90%) 7,430 (15.56%)
2022 82,328 469 82,797 257,847 32.11% 2019 27,693 (64.29%) 10,766 (25.00%) 4,613 (10.71%)
2021 75,031 444 75,475 241,110 31.30% 2018 27,262 (69.87%) 8,346 (21.39%) 3,409 (8.74%)
2020 31,792 385 32,177 129,361 24.87% 2017 25,186 (74.10%) 6,357 (18.70%) 2,448 (7.20%)
2019 17,656 320 17,976 95,650 18.79% 2016 24,662 (76.37%) 5,704 (17.66%) 1,925 (5.96%)
2018 12,828 267 13,095 80,907 16.19% 2015 23,470 (78.89%) 4,767 (16.02%) 1,514 (5.09%)
2017 8,949 221 9,170 63,737 14.39% (agg) 248,629 (46.80%) 192,849 (36.30%) 89,733 (16.89%)
2016 8,831 200 9,031 61,530 14.68%
2015 7,367 168 7,535 54,589 13.80%
(agg) 580,365 4,391 584,756 2,167,152 26.98% 4 Residual Data on arXiv [RQ1]
We focus on our first research question: quantifying the resid-
ual data on arXiv. To this end, we analyze the reports gener-
ated by BaRDE for submissions that are valid TEX projects.
We first provide an overview (§4.1). Then, we break-down
600k, i.e., 1.7%) could not be processed by BaRDE due to either our results by considering the distribution of residual data
having an unclear root (9,504, 1.6%) or raising other issues across scientific categories (§4.2). Finally, we conclude by
(e.g., projects using the deprecated \documentstyle) which analyzing the file-types that compose residual data (§4.3).
prevented analyses (1,037, 0.1%). Hence, BaRDE’s effective-
ness was not hindered by our choices (we further validate 4.1 Overview of Residual Data
BaRDE’s performance in §5).
How much residual data is on arXiv? To answer RQ1, we con-
Operational runtime. We measured the time required to sider the most straightforward quantitative metric: the size.
process our dataset with BaRDE. Altogether, it took ≈42 hours Main results. We report the results of our primary analy-
to process all of our dataset, indicating that BaRDE could ana- sis in Table 3. Specifically, for each year, we show: the total
lyze an average of 3.5 submissions per second. These results size of residual files, the total size of textual comments found
have been measured on an AMD Ryzen 5800X3D (@4.5GHz), in (used) TEX files, the total size of residual data (given by
with 32GB of RAM. However, we make two observations. summing the previous two elements), the total size of the
First, the majority of the runtime is due to I/O operations projects, and the percentage of residual data w.r.t. the total
needed to unpack each compressed GZ-file / blob, given that size of a project. (The distribution across months is provided
it is a procedure that entails storing the extracted data in a in Table 7 in the Appendix). Overall, there are 584GB of resid-
temporary folder: these operations are very time consum- ual data, of which 4.3GB are comments, and 580GB are files
ing, and their scale was big enough that it could potentially not needed to make the final PDF. In contrast, the total size
damage an SSD drive [54], which is why we did them on of projects is of 2.1TB (note: all of these numbers refer to the
an HDD (with 7200rpm). Using a faster storage drive would size of data uncompressed). Therefore, in our sample, 26.98%
substantially decrease the runtime. Second, we ran BaRDE of the data is not required for the PDF compilation.
by using a single thread of our CPU. However, BaRDE does Size-wise distribution of residual files. Our previous
not have concurrency requirements and can be freely run by results show that there are a lot of residual data in terms of
launching it multiple times, each using a dedicated thread overall size. However, how is such residual data distributed
and processing a subset of our dataset, thereby significantly across projects? To investigate this, we considered, for each
increasing the speedup. For instance, had we run BaRDE by year, the number of projects having: (i) less than 1KB-worth
leveraging all 16 threads of our CPU and by specifying a of residual files, (ii) between 1KB and 1MB of residual files,
dedicated storage device (to avoid I/O bottlenecks) we would and (iii) above 1MB of residual files. The results are shown
have processed our dataset in less than 4 hours. Hence, we in Table 4 (for which we report in Table 8 the details across
argue that BaRDE is, computing wise, an efficient solution to months). We see that even though the residual files for ≈248k
carry out large-scale analyses of arXiv submissions’ source (≈47%) projects add up to less than 1KB (which can be negligi-
files (a claim we factually support in §5.3). ble), there are ≈90k (≈17%) projects that have more than 1MB
7
 Giovanni Apruzzese and Aurore Fass

&XPXODWLYH'LVWULEXWLRQ)XQFWLRQRI7H;SURMHFWVZLWK .%ZLWK]RRPRQZRUVW

 (CS=Computer Science, ECON=Economics, EESS=Elec. Engi-
neering and System Sciences, MATH=Mathematics, PHYS=Physics,
&XPXODWLYHVKDUHRI7H;SURMHFWV


QBIO=Quant. Biology, STAT=Statistics, QFIN=Quant. Finance [21]),
 and we also highlight projects in “Cryptography&Security”
 (CR, subcategory of CS). Given that we are interested in the
  “higher amount / percentage”, we only consider submissions


with more than 1MB worth of residual files or a ratio of


residual files (w.r.t. total project size) above 0.5.
5 × 101 102 2 × 102
 Results. We report the results in Fig. 5 (focusing on projects
     
    
6L]HRI5HVLGXDOGDWDLQ0%ORJDULWKPLFVFDOH

with over half of their size being of residual files) and Fig. 7
(in the Appendix, focusing on projects with >1MB worth of
Fig. 4: Distribution of projects with size of ℱ≥1KB (count: residual files). We can see (looking at the plot on the left in
285,582). Some projects (38) have more than 100MB worth of ℱ.
each figure) that, starting from 2019, CS is the category with
Table 5: Distribution of projects according to: (total size of the highest number of projects with more than half of their size
residual files) / (total project size). ℱ=“size of residual files”. being of residual files, or with more than 1MB of residual files
Year ℱ < 5% 5%≤ ℱ <50% 50%≤ ℱ <95% ℱ ≥95% (the CR subcategory does not seem to be a heavy contributor
2025 41,337 (52.97%) 25,067 (32.12%) 11,088 (14.21%) 553 (0.71%) in this regard). From a relative viewpoint (plot on the right),
2024 37,429 (54.19%) 21,300 (30.84%) 9,638 (13.96%) 697 (1.01%) however, things are slightly different: CS is still tends to be
2023 29,476 (53.71%) 15,098 (27.51%) 9,825 (17.90%) 485 (0.88%)
2022 28,673 (55.20%) 13,497 (25.98%) 9,334 (17.97%) 438 (0.84%)
the “worst” (e.g., starting from 2019, over 20% of projects in
2021 29,706 (57.77%) 12,656 (24.61%) 8,611 (16.75%) 445 (0.87%) CS have more than half of their size being of residual files),
2020 30,698 (64.31%) 10,689 (22.39%) 6,085 (12.75%) 264 (0.55%) but there are other categories (most notably, EESS, which is
2019 31,687 (73.57%) 7,303 (16.96%) 3,864 (8.97%) 218 (0.51%)
2018 30,278 (77.60%) 5,475 (14.03%) 3,029 (7.76%) 235 (0.60%)
thematically close to CS) with similar numbers.
2017 27,578 (81.13%) 3,957 (11.64%) 2,227 (6.55%) 229 (0.67%)
2016 26,875 (83.23%) 3,353 (10.38%) 1,841 (5.70%) 222 (0.69%)
2015 25,366 (85.26%) 2,637 (8.86%) 1,503 (5.05%) 245 (0.82%) 4.3 Types of Residual Files
(agg) 339,103 (63.84%) 121,032 (22.78%) 67,045 (12.62%) 4,031 (0.76%) We conclude our quantitative analysis by inspecting the
types of files that are superfluous for making the final PDF.
worth of residual files. To better visualize these phenomena,
Approach. Given that BaRDE stores the list of all residual
we show in Figure 4 the cumulative distribution function for
files for each project, we used the extension of such files to
submissions having more than 1KB worth of residual files,
create seven distinct groups: images (e.g., .svg, .png), PDF
with a zoom on the “worst” 1%. We found 38 projects that
(.pdf), TEX (.tex), support (e.g., .sty, .cls), text (e.g., .txt, .md),
have more than 100MB worth of residual data.
auxiliary (e.g., .enc, .tfm), and other (anything else); we report
Relative size-wise distribution. We complement our
in Appendix B.3 the full mapping. We then computed the
previous results by showing, in Table 5 (extended by Table 9
yearly distribution of each of these groups in terms of total
in the Appendix), the number of projects whose cumulative
occurrences, and total size. The intention is identifying which
size of residual files represents [less than 5%; between 5% and
file-types are mostly prevalent across residual files.
50%; between 50% and 95%; above 95%] of the total project
size. We found 71,076 (13.38%) projects whose residual files Results. We report the results in the plots shown in Fig-
represent more than 50% of their total size; in particular, for ure 6 and Figure 8 (in the Appendix). From Figure 6, it is
4,031 (0.76%) projects, 95% of their size is made up by files evident that the “image” and “pdf” categories are the most
not needed to produce the final PDF. prevalent, followed by files in the “support” and “other” cate-
gory. However, by looking at Figure 8, we see that, size-wise,
4.2 Residual Files Across Categories files in the “image” category take significantly (verified with
a t-test at 𝑝 < .05) more storage space. For instance, just in
Given that arXiv accepts submissions pertaining to various 2025 there are nearly 70GB worth of “images”, compared to
scientific categories, we wondered which category has sub- ≈45GB of “pdf”, ≈10GB of “other”, and ≈2GB of “support”.
missions with the higher amount/percentage of residual files.
Method. We downloaded the dataset (available at [17])
Takeaways. Across our sample (first four months of 2015–
containing the complete metadata of all arXiv submissions.
2025), we found 584GB of residual data on arXiv, represent-
Such details include, among others, the specific categories
ing 27% of the size of its TEX projects. Computer Science is
assigned to each submission. We hence cross-referenced the
the category which contributes the most to these numbers.
categories to the projects we found having residual data.
Images are the most prevalent types of residual files.
For simplicity, we only considered the 8 main categories
8
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

3URMHFWGLVWULEXWLRQE\PDFURFDWHJRU\SHU\HDU UDWLR! 6KDUHRI7H;SURMHFWVZLWK UDWLR!E\PDFURFDWHJRU\ \HDU

 
&6 0$7+ 4),1 &6 0$7+ 4),1
(&21 3+<6 67$7 (&21 3+<6 67$7
((66 4%,2 FV&5VXEVHWRI&6  ((66 4%,2 FV&5VXEVHWRI&6




3HUFHQWRIFDWHJRU\

3URMHFWFRXQW

 







 
                     

Fig. 5: Distribution (absolute:left, relative:right) across scientific categories of projects whose size of ℱ is >50% of the project size.

$EVROXWHGLVWULEXWLRQRIVSHFLILFW\SHVRIUHVLGXDOILOHVSHU\HDU 5.1 Validation Dataset (and Approach)

XQXVHGBLPDJHBFRXQW XQXVHGBWH[WBFRXQW
XQXVHGBSGIBFRXQW XQXVHGBDX[BFRXQW To fairly validate our results, we must use a different dataset.

XQXVHGBWH[BFRXQW XQXVHGBRWKHUBFRXQW Moreover, to provide an accurate validation, we must manu-
XQXVHGBVXSSRUWBFRXQW

ally check the ground truth of each sample in such a dataset—
meaning that our validation cannot span a dataset with the
7RWDOQXPEHURIUHVLGXDOILOHV


same size (i.e., 600k submissions) as the one of our study.
To this end, we downloaded (from the AWS S3 bucket [15])
 the first ten “chunks” of source files (≈5GB compressed) re-
ferring to arXiv submissions of May 2025. Altogether, these
 chunks contained the source files of 1,104 submissions. We
then extracted/unpacked all such source files (which required
 4 minutes on our system). Out of these 1,104 submissions,
91 are PDF-only submissions, whose cumulative size is of

          
432MB); the remaining 1,013 submissions have a cumulative
size of 5.53GB uncompressed, and of 4.59GB in GZ format.
Fig. 6: Absolute number of file types across the residual files. To validate our root-file heuristic, we seek to (i) run BaRDE
on this validation dataset and then use the “root” file inferred
by BaRDE to (ii) compile the corresponding PDF, and finally
(iii) compare such PDF with the PDF of the respective sub-
mission available on arXiv: cases in which the two PDFs
differ are those in which our root-file selection heuristic
5 Validation of BaRDE failed. Therefore, we downloaded the PDF (also from the
S3 bucket [15]) of each of these 1,104 submissions (totaling
Recall that, when processing a TEX project, BaRDE uses our 4.41GB). We found that, for 3 submissions, there was no PDF:
custom heuristics (§3.2.2) to (i) determine the root TEX file these were cases of “withdrawn” papers.
and (ii) infer residual files. We have already verified (§3.3) Afterwards, to validate the residual-files selection process,
that, across our dataset, BaRDE could not process ≈1.7% of we will (i) remove the residual files flagged by BaRDE from
the TEX projects due to an unclear root file. In this section, we the source files of the project, and (ii) attempt to compile the
attempt to quantify the cases in which our heuristics failed, PDF: if the compilation fails, it means that BaRDE incorrectly
leading to BaRDE making an incorrect decision. flagged a file that was necessary for the compilation.
We do so via a validatory experiment carried out on a
different dataset. We first discuss the data collection and 5.2 Validation Results
generic approach (§5.1), then report the results (§5.2), and We processed our validation dataset with BaRDE, which re-
finally make some remarks (§5.3). quired 5 minutes. We confirmed that all 91 PDF-only files
9
 Giovanni Apruzzese and Aurore Fass

were correctly recognized as such. Moreover, BaRDE correctly 6 Problematic Projects on arXiv (RQ2)
identified the three “withdrawn” papers; and BaRDE skipped To identify “problematic” projects, we carried out manual
2 projects (0.18%) which did not have a valid TEX structure analyses. We first inspected all residual data of a randomly-
(they only had a single .txt file), as well as 23 projects (2%) chosen subset of our sample (§6.1), followed by a keyword-
which had multiple root candidates. These results align with driven search on comments (§6.2) and on residual files (§6.3).
those of our large-scale analysis (see Table 2).
We validated our root-file identification heuristic. We took Disclaimer. What makes a project “problematic” is subjective.
the source files of the 985 projects for which BaRDE inferred For instance, some people may not see any problem in the pres-
the root TEX file and compiled them on our systems. This pro- ence of a swear word in a comment; and some authors may have
deliberately left some “undisclosed research data” in their sub-
cess took 4 hours. Then, we checked the PDF against the one missions.a Our analyses are driven by our own judgment: we
on arXiv. We found only one case in which BaRDE inferred would not want that our submissions included the data we found
the incorrect root TEX file (the correct root was “[Link]”, in any “problematic project” discussed in this section.
but BaRDE used “[Link]”). In other words, our heuristic a Notethat many people regret sharing some information [56, 64], since
was correct in 984 out of 985 cases (i.e., 99.9%). it may backfire years later [51]. We also consider these circumstances.
We validated the residual-file selection heuristic. After re-
moving all residual files flagged by BaRDE from each project,
we attempted the PDF compilation. We found only 9 (out of 6.1 Random Sampling (Full Manual Check)
985, i.e., 0.9%) cases in which the compilation failed due to Analyzing all the residual data we found in our sample man-
missing files removed by BaRDE, all related to alias / custom ually is clearly an unfeasible task. To get a preliminary un-
commands (e.g., one project defined the macro \image to re- derstanding of what can be found within the residual data
place \includegraphics). This is a known limitation which of arXiv submissions’ source files, we performed a complete
we acknowledged (see §3.2.3). However, even in these cases, search across a small, randomly-chosen subset of our sample.
BaRDE still correctly identified other residual files. Approach. We adopted the dual-reviewer system [61]:
two researchers (with >5 years of research experience) in-
dependently analyzed the same projects, with the goal of
5.3 Observations and Remarks determining if such projects contained residual data that
We use this validation experiment to shed light and factually could be considered as “problematic”. After the analysis, dis-
justify the overall effectiveness of BaRDE. cussions were done to reach a consensus. The analysis would
encompass all residual data (comments + residual files) for
First, the results of BaRDE on our validation dataset resem- these submissions. For a humanly-feasible analysis, we set
ble that of our large-scale analysis, indicating that these two our “budget” to 200 submissions; we opted for those in 2025
datasets have a similar distribution, enabling us to extend because they are the most recent ones and, in case we found
the results of our validation to our main analysis (in §4). some problems, authors are more likely to receive our emails
BaRDE can make errors in 1% of the analysed projects, (see §8.1). Hence, for an unbiased selection, we randomly
leading to incorrectly flagging files as residual (i.e., “false sampled 50 submissions for each month in 2025; we did not
positives”). However, these cases are due to custom/special specify any criteria in terms of size / ratio of residual data.
commands and/or projects that do not follow TEX best prac- Codebook. To guide our analyses, we defined a codebook
tices. Still, even in these cases, BaRDE still correctly identified through which we could classify each submission according
other residual files (e.g., only the files called with the custom to the “problem” we found. The codebook was finalized after
command are affected). We hence conclude that such errors analyzing 100 submissions: we then uniformly reapplied our
have a negligible impact on our quantitative results. codes to these 100 submissions, and used the codes for the
Finally, as we anticipated (in §3.3) carrying out the afore- remaining 100. The codebook encompassed the following
mentioned analysis is much more computationally expensive categories, for which we provide a brief explanation:
than running BaRDE. Recall that processing our main dataset ● Author exchange. Covers instances of comments that in-
(of ≈600k submissions) took ≈42 hours, whereas compiling dicate conversations among authors, sometimes antic-
the PDF for the validation dataset (of ≈1k submissions) took ipated by a command denoting a specific person (e.g.,
≈4 hours. In other words, if we wanted to be certain of our “\AuthorX{not sure what to put here}”) or not (e.g., “Revise.”);
results by compiling the PDF via TEX, it would have required ● Direct translation. Instances wherein comments include
2400 hours, i.e., 57× the time required to use BaRDE. We there- long sequences of text in a language different from English
fore consider that an error rate of ≈1% of our heuristics is which, if translated via automatic tools (e.g., [6]), yield an
well compensated by BaRDE’s computational efficiency. almost-perfect match with the text in the paper’s PDF;
10
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

● Inappropriate language. Covers instances wherein com- Importantly, we acknowledge that the mere presence of one
ments contain offensive terms (e.g., “fuck”) or derogatory of these keywords does not make the project problematic.3
statements towards other entities (e.g., “stupid *** paper”); This is why we carried out manual checks on a subset of the
● Data leak. Instances in which the project (either in the flagged papers to ensure that the “context” in which a key-
comments or in the residual files) contains research data word was mentioned truly indicates a problematic project.
not disclosed in the paper, personal (and not public) details High-level results. We report the results in the format
about the authors, or clearly confidential information (e.g., [keyword; # of projects mentioning it at least once]: [fuck;
documents not publicly available, such as cover letters); 108], [shit; 279], [dumb; 270], [idiot; 54], [bastard; 24], [crap;
● Other. For all other cases (e.g., comments including “ac- 141], [stupid; 554], [terrible; 418], [horrible; 235], [mess;
knowledgments” not mentioned in the paper’s PDF). 984], [garbage; 567], [trash; 241], [useless; 1,975], [todo;
We believe the aforementioned codes are a clear indicator of 41,122], [fixme; 1,747], [tbd; 2,187], [wtf; 131], [geez; 5],
“problematic” projects. If the reader is unsure why such codes [lmao; 20], [[Link]/; 828], [github.; 22,075], [gitlab.;
could be considered as problematic, we discuss in the Ap- 201], [C:\Users; 126], [/home/; 1715], [positive review only; 3].
pendix E.1 how each code can lead to harmful consequences After some manual checks, we realized the high number of
towards the authors of the corresponding submission. “todo” was because many projects use the todonotes package;
Problematic (verified) findings. Our final results are as whereas the high occurrences for “mess” were due to some
follows. Overall, we found problems in 40 / 200 (20%) projects. TEX templates (e.g., [8]) mentioning it (and the corresponding
Specifically, we coded: 16 (8%) projects in the “author ex- portions were left as comments).
change” category, 6 (3%) in “direct translation”, 1 (0.5%) in Problematic (verified) findings. Even though not all
“inappropriate language”, 6 (3%) in “data leak”, 11 (5.5%) in the projects mentioning any of such terms were problematic,
“other”. We provide some (anonymized) excerpts in the Ap- we found many instances of clearly offensive or derogatory
pendix E.2. For Excerpt 4, its paper never mentions release statements which – we believe – may lead to harm towards
of code (either before or “after publication”); whereas for the authors if publicly shared. We report some (anonymized)
Excerpt 11, there is no acknowledgment mentioned in the excerpts in the Appendix E.3. Notably, the presence of one
paper (and the acknowledged entities are not mentioned). of such keywords may indicate more problematic comments
Excerpts 7 and 8 (whose links are accessible) inspired our (see, e.g., Excerpts 15, 16, or 21). Nonetheless, we also decided
future analyses. We did not find any specific problem in the to carry out extensive manual checks specifically focused on
remaining 160 (80%) projects. Note: even in these cases, there the “[Link]” keyword. First, we re-did our keyword
could still be data that the authors do not want to be public. search, this time counting all unique occurrences of such
term, which yielded 1,510 matches (spread across 828 distinct
projects). Then, we focused on the 314 links pertaining to
6.2 Keyword-Driven Search (on Comments)
the 158 projects of 2025: we manually inspected all of these
We used our previous findings as a scaffold to carry out a links to infer if such links pointed to documents “accessible
broader analysis leveraging some automated mechanisms. to anyone with the link”. We found that 200 / 314 (64%) of
We used a simple and reliable technique: keyword searches.2 the links are freely accessible (as of August 2025), and they
Approach. We defined a list of keywords and then au- clearly contained confidential data (see also §8.1).
tomatically searched across all comments of each project
(among the 531k of our dataset), flagging all those that had 6.3 Inspection of Residual Files
at least one match for each of the keywords we considered. Lastly, we try to pinpoint problematic projects by looking at
The list was derived after internal discussion among the au- the unused files, and then inspecting their contents. Similarly
thors of this paper, based on their own experience with the to our previous analysis, we do this via a keyword-search.
English language. The list (with keywords) is as follows: Approach and High-level Results. We craft a script that
● Offensive: fuck, shit, dumb, idiot, bastard, crap, stupid; looks at the various “reports” produced by BaRDE, looking
● Derogatory: terrible, horrible, mess, garbage, trash, useless; for mentions of the specific terms across the residual files.
● TODO: todo, fixme, tbd; The terms and their total occurrences across our sample are:
● Exclamation: wtf, geez, lmao; ● Code: [.exe; 35], [.sh; 1,884], [.py; 5,259], [.bat; 230], [.ipynb; 828]
● URI : [Link]/, github., gitlab., C:\Users, /home/; ● Documents: [.doc; 76], [.docx; 1,086], [.xlsx; 1,447], [.xls; 133],
● Hidden prompts: positive review only (from [62]). [.ppt; 61], [.pptx; 240]
● Video: [.mp4; 843], [.avi; 81], [.mov; 31]
2We ● Misc: [cover_letter; 314], [rebuttal; 5,964], [reviews; 567].
tried using “topic models”, such as ToxicBERT [55], but they always
yielded false positives (e.g., papers with a lot of “%” would be deemed as 3 Forinstance, papers about “offensive language” (e.g., [31]) can have valid
highly offensive), so we decided not to rely on these black-box techniques. reasons to have commented-out portions of the text mentioning “fuck”.
11
 Giovanni Apruzzese and Aurore Fass

After manual inspection of some matches, we confirmed 8 Mitigation and Reflections

these were all “residual files” (validating BaRDE’s output). We have brought to light (in §6) a subtle problem, for which
Problematic (verified) findings. We found projects hav- we cannot quantify its complete prevalence. In an attempt
ing cover letters (including a recommendation letter, see to mitigate this problem, we discuss here some real-world
Excerpt 24), rebuttals (some including comments, see Ex- considerations—starting from our outreach campaign.
cerpt 25), or previous reviews—all of which being confiden-
tial data that is not meant to be available to the entire world. 8.1 Outreach
Some instances of “documents” included preliminary drafts
Our findings pertain to two groups of stakeholders: arXiv as
or experimental details not mentioned in the paper. As a
a platform, because residual data harms their servers; and
byproduct of these (and other file-related) inspections, we
the authors of submissions with problematic residual data.
also found a project with a thesis still under embargo (only
We reached out to arXiv in early August 2025. We sent
the abstract is available online).
the email reported in Email 1 (in the Appendix) to the arXiv
Takeaways. Our manual inspection on a randomly cho- leadership team [22]. We could not find the addresses of two
sen subset of 200 projects revealed that 1 / 5 contained members, but one member forwarded our mail to the last
problematic residual data. Keyword-driven searches with two members, thereby confirming having received our email.
string “[Link]” across comments yielded 1,510 Then, starting from the second-half of August 2025, we
hits: we manually checked the 314 occurring in 2025, and reached out to the authors of “problematic” submissions.
found that 64% of these URLs point to freely accessible Overall, we sent 161 emails, covering (a) the projects analyzed
documents containing confidential data. Manual investiga- in our random sampling; (b) projects with freely-accessible
tions focused on residual files yielded concerning findings, links to Google documents; and (c) all projects for which we
such as projects containing private documents and letters. included an excerpt in this paper. We sent the email reported
in Email 2 (in the Appendix). Reaching out to the authors was
not simple: it cannot be done automatically (arXiv prohibits
7 Threats to Validity and Discussion
programmatic access to the show-email endpoint [20]) so we
Our conclusions depend on the ability of BaRDE to extract had to retrieve the email addresses manually. For submissions
residual data (files + comments) in arXiv submissions. having more more than one address on the paper’s front page,
We have discussed (in §3.3) that BaRDE is not able to an- we reached out to multiple authors (after consultation with
alyze submissions that, despite being TEX projects, do not our ethical board); otherwise, we only sent the email to the
have a clear root file; or which have a structure that does not address of the submitter shown on arXiv.
align with modern TEX versions (e.g., incorrect extensions or We received 35 replies (a response rate of 22%). Among
deprecated methods). In these cases, which we quantified as these, only two respondents confirmed that they wanted to
representing 1.7% of our dataset, BaRDE would not proceed make the submission exactly as it was available on arXiv:
with its analysis to avoid raising false positives. in contrast, and worryingly, 27 respondents admitted that it
We have further validated (in §5) the accuracy of our was not their intention to disclose all source files, and took
heuristics: accordingly, BaRDE incorrectly flags some resid- action. As of October 2025, 36 submissions for which we sent
ual files for 1% of the analysed TEX projects: most of these an email had their source files updated after our disclosure.
cases are due to alias/special commands4 that can hardly be Finally, we sent a follow-up to the arXiv leadership team
parsed with a static tool such as BaRDE, since it operates on in October 2025, stating that some authors may overlook
compressed files and does not carry out TEX compilation: this that the arXiv source files are public. We suggested recom-
is not a limitation, but rather a strength, since compiling TEX mendations (e.g., those discussed in §8.3) and expressed our
projects is resource intensive (we estimated running BaRDE willingness to help.
1
takes 57 of the time otherwise required to compile the PDF).
To sum up, we believe that potential misattributions by 8.2 Real-World Implications
BaRDE to be in a low-enough number to not threaten our
We examine the issue we uncovered under a real-world lens.
quantitative conclusions (in §4), albeit we acknowledge the
actual numbers of residual data in our sample may be slightly Retroactivity. arXiv has recently updated its submission-
lower. The conclusions of our manual analyses (in §6) are upload system which now explicitly tells authors that some
correct: whenever we encountered a “problematic” project, files may not be needed [23]. This may help reducing the size
we manually checked the source files of such project to verify of residual files, but: (a) it does not help for removing “com-
that it truly contained our identified problem. ments” in future submissions; and, crucially, (b) it does not
help for existing submissions. Indeed, the issue we brought
4 Note that such special cases would also affect tools such as ALC [42]. to light affects all submissions on arXiv, since everyone can
12
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

download their source files—which may not be “clean”. There- Finally, the authors of arXiv’s submissions should broad-
fore, arXiv’s new submission-upload system does not repre- cast our message to their colleagues. The sooner a submis-
sent a universal solution to the public-availability of arXiv sion is updated, the less likely its authors are going to suffer
submissions’ source files. damaging consequences due to potentially-sensitive data
Public availability. Our qualitative findings suggest that included in their submissions’ source files.
arXiv submitters may not be aware that the source files of
their submissions are publicly available. Indeed, even though 9 Related Work
it is undeniable that residual data may put a burden on arXiv We are not aware of any work with a similar scope as ours.
(and hence it is reasonable that arXiv tries to limit this by, First, and as a disclaimer, for our paper we did not rely on
e.g., suggesting which files may not be needed), our research an “exposed AWS S3 bucket” (see, e.g., [36, 37]). It is arXiv
underscored that the public-availability of arXiv submissions’ itself that points researchers to the specific AWS S3 bucket to
source files poses a privacy risk—due to lack of awareness. retrieve its submissions in bulk [15], which can be freely
We point out that, in arXiv’s FAQs [27], it is stated “What if used for research purposes [18], which is our case.
my TeX source has potentially embarrassing self-comments The closest works entail papers seeking to, e.g., analyze
in it? Well... you should probably take them out.” Hence, comments in code repositories (e.g., GitHub [9, 32, 38, 43])
arXiv does warn users of their submissions’ source files being or identifying privacy leaks in code repositories (e.g., [39, 46,
public; however, it is evident that some users did not read the 65]); but no work has carried out a systematic analysis of
warning, or consider / understand its broader implications. arXiv submissions with a specific focus on their source files.
Other Platforms. arXiv is the largest eprint-focused plat- Some works discuss the pros and cons of using arXiv [57]
form for which the source files of its submissions are pub- (e.g., whether it improves citation metrics [28, 59]) or an-
licly available. Platforms such as bioRxiv [3], medRxiv [4], alyzed arXiv submissions from a graph-analytics perspec-
or techRxiv [5] do not enable such a possibility. Users of tive [35], but these are all goals orthogonal to ours.
such platform are therefore not exposed to the privacy risks Even in terms of scale, our study is larger than those
underscored in this work. carried out by prior work that focused on arXiv (but with
different goals). For instance, Lin et al. [45] analyzed how
8.3 Recommendations
many computer-science preprints submitted within 2008–
To improve the status quo, we have three recommendations
2017 have been printed, and their study encompassed only
for arXiv, and one for the entire arXiv’s community.
First, arXiv should not make a submission’ source files 142k submissions (i.e., their dataset is 1 / 4 of ours); whereas
publicly available by default. We believe that the privacy Movva et al. [48] analyze trends across 17k submissions fo-
risks of the indiscriminate public-availability of source-files cusing on LLMs (i.e., their dataset is 1 / 35 of ours).
outweigh its benefits—especially given the potential lack of From a technical viewpoint, our tool also provides novel
awareness on this matter. We assert arXiv should implement functionalities w.r.t. the closest open-source tool we could
an “opt-in” mechanism through which authors can express find, ALC [42], which we discuss Appendix C.3.
their willingness to share their source files.
Second, arXiv should reach out to the authors of all submis- 10 Conclusions
sions currently on arXiv. The submitters should be reminded We analysed 1.6TB of data, encompassing 600k submissions
that the source files are publicly available, and that they can appeared on arXiv in the first four months of 2015–2025.
update their submissions to delete content that is not meant We found that 27% of the data of TEX projects is not needed
to be public (and of the existence of the anc/ folder [13]). to produce the PDF. Qualitative analyses on a subset of
Third, arXiv should better emphasize – during the sub- projects with residual data revealed privacy-noteworthy find-
mission process (and not just in the FAQs) – that the source ings, such as undisclosed research details, or the presence
files of a submission will be publicly available. Potentially, of derogatory statements. Altogether these results indicate
the authors should fill a textual box with “I am aware that that arXiv submitters may not be aware that the source files
all source files of my submission will be publicly available” of arXiv submissions can be downloaded by anyone.
(which is more effective than, e.g., ticking a checkbox af- We reached out to arXiv, as well as to the authors of
ter scrolling through some ToS). Such a warning/advisory some submissions for which we found privacy-noteworthy
can be complemented by integrating some of BaRDE’s func- residual data. However, the problem we brought to light
tions in the submission upload system, such as the comment- remains open, and only a policy change by arXiv (e.g., re-
extraction pipeline. Such an integration will enable the au- moving the ability to download submissions’ source files) or
thors to quickly observe the “residual data” of their submis- a community-driven awareness effort (to notify authors that
sion, including comments, and take an informed decision of their submissions’ source files are public but can be updated
whether to keep such data or remove (parts of) it. and overwritten) would mitigate this problem.
13
 Giovanni Apruzzese and Aurore Fass

arXiv’s response. We did not receive any reply to our address may have been disabled, or the author left academia—
email in Oct. 2025, so we sent a third follow-up on Dec. 31st in which case, it is important to warn also the other authors,
2025, in which we attached a draft of this paper (thereby who can take action if deemed necessary. Regardless, we
showing our complete procedure and findings), and ex- emphasize that our methodology was chosen after a joint
plictly asked if there was any intention in reaching out to consultation with our institutions’ ethical boards.
authors. We received a response on Jan. 10th 2026, which
appreciated our efforts, but noted that there was no inten- Ethics of our Publication
tion to reach out to individual authors en masse. The publication of this paper would undeniably lead to our
findings be announced to the entire World. The consequences
Ethics of this can vary, depending on the outcome of decisions we
Our paper tackles various ethical themes. Let us discuss cannot predict. In what follows, we discuss these cases and
the ethics of our research. We anticipate that the authors explain why the publication of this paper is the best course
consulted with the ethical office of their institutions about the of action given our findings.
ethics of this research, and it was deliberated that no ethical In an hypothetical scenario in which, possibly due to our
concern can arise from the methodology adopted in our study. message to the arXiv’s leadership team, arXiv as a platform
does not allow third-parties to download (either on arXiv, or
on AWS S3) the submissions’ source files, no harm will ensue
Ethics of our Methodology
by the publication of our work. Even if the world becomes
First, our research is based on publicly-available data. The aware that there is “residual data on arXiv”, the fact that
authors of all arXiv’s submissions have agreed to arXiv’s potential evildoers may want to repeat our analyses to cause
terms of service before uploading their source files. There- harm to authors of arXiv’s submissions would be prevented
fore, no rule / term / agreement / law is breached by analyz- by lack of methods to obtain the source files.
ing, and using, such publicly-available data. Alternatively, if arXiv does not change its policies w.r.t. the
Second, the data collected for our research was obtained availability of submissions’ source files, potential evildoers
ethically. We refrained from scraping arXiv, and—as recom- may be able to repeat our analyses. However, to minimize the
mended by arXiv itself [15]—opted for downloading our potential harm, we have adopted the following precautions.
datasets from Amazon S3 (which led to costs we had to pay ● First, we warned the authors of (some) submissions with
on our own). Hence, we did not violate arXiv’s Terms [18]. problematic data. Such authors have hence the opportu-
Finally, when reporting the outcome of our outreach cam- nity to update their submissions, preventing any harm;
paign, we only provided aggregated data and it is impossible ● Second, we warned arXiv’s team (who acknowledged re-
to identify any individual. Recipients to our email, who were ceiving our email). This can lead to arXiv sending emails
made aware we were carrying out some research, have been “en-masse” to inform authors to update their source files.
treated ethically [29], and we acted in their own best inter- ● Third, we will make BaRDE available only upon request.
ests. We refrained from wasting their time with unnecessary Indeed, BaRDE’s capabilities can be used by attackers, too.
follow-ups unless explicitly told or unless it was apparent However, by itself, BaRDE cannot cause any damage, since
that they may have overlooked something (e.g., for freely- it requires access to the dataset of arXiv submissions’
accessible Google documents, for which the authors thanked source files downloaded from AWS S3. If arXiv takes down
us after making them aware of this). such a dataset, we will open-source BaRDE. Otherwise, we
A remark can be made regarding our decision to send the will only provide it under explicit request by people with
email to multiple authors (if we found the email addresses). a reputable background.
Let us explain this delicate issue. The process of submitting Regardless, and as an additional precautions to prevent harm,
a paper to arXiv is overseen by only one author—who, in any excerpt included in this paper is provided in a format
theory, must have permission by all co-authors. We envision that makes it impossible to identify its authors (in particular,
a scenario wherein (i) an author submits a paper with “prob- we do not reference the corresponding submissions), and we
lematic” residual data inside, (ii) multiple authors receive never explicitly pointed to any specific submission as having
our email, and (iii) the other authors “complain” against the potentially-sensitive data.
submitting author for not having cleaned the source files
before submission. We are aware of such a possibility, but we Our Ethical Message
believe that the likelihood of this happening (given that we The issue we underscored is present now. Attackers can
sent an email to multiple authors only for 1/3 of the cases) already: “steal” confidential data carelessly included in the
is low. Moreover, our intention when sending the email to arXiv submissions’ source files by some authors; or “threaten”
multiple authors was to cover the case in which an email to publicly-shame some authors due to derogatory / offensive /
14
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

embarrassing / controversial statements found in the respec- [28] Chhandak Bagchi, Eric Malmi, and Przemyslaw A Grabowicz. 2025.
tive comments. We believe the potential targets of such ne- Effects of research paper promotion via arXiv and X. In Proceedings of
farious acts should be responsibly warned [44]. the International AAAI Conference on Web and Social Media, Vol. 19.
160–177.
Finally, we observe that publication of this work will [29] Michael Bailey, David Dittrich, Erin Kenneally, and Doug Maughan.
lead to future authors of arXiv submissions being aware of 2012. The Menlo report. IEEE Security & Privacy (2012).
this problem. Hence, while we acknowledge that we—as [30] Nicholas Carlini. 2024. Cutting through buggy adversarial exam-
researchers—do not have the means to fully solve this prob- ple defenses: fixing 1 line of code breaks Sabre. arXiv preprint
lem for submissions already present on arXiv, publication of arXiv:2405.03672 (2024).
[31] Tommaso Caselli, Valerio Basile, Jelena Mitrović, Inga Kartoziya, and
this paper would prevent harm for future arXiv’s submissions— Michael Granitzer. 2020. I feel offended, don’t be abusive! implicit/ex-
which are increasingly growing in number. plicit messages in offensive and abusive language. In Proceedings of
the twelfth language resources and evaluation conference. 6193–6202.
References [32] Fragkiskos Chatziasimidis and Ioannis Stamelos. 2015. Data collection
[1] [n. d.]. [Link] and analysis of GitHub repositories and users. In 2015 6th International
[2] 2024. Evaluation - Security Research Artifacts (USENIX SEC’24). https: Conference on Information, Intelligence, Systems and Applications (IISA).
//[Link]/usenixsec2024/. IEEE, 1–6.
[3] 2025. [Link] [33] Dalmeet Singh Chawla. 2025. ‘WithdrarXiv’database of 14,000 re-
[4] 2025. [Link] tracted preprints launches. Nature 637, 8046 (2025), 530–530.
[5] 2025. [Link] [34] Xiang Chen, Xin Guan, and Bernhard Mistlberger. 2025. Three-Loop
[6] 2025. DeepL. [Link] QCD corrections to the production of a Higgs boson and a Jet. arXiv
[7] 2025. LaTeX/Document Structure. [Link] preprint arXiv:2504.06490 (2025).
TeX/Document_Structure. [35] Colin B Clement, Matthew Bierbaum, Kevin P O’Keeffe, and Alexan-
[8] AAAI. 2025. AAAI-25 Submission Instructions. [Link] der A Alemi. 2019. On the use of arxiv as a dataset. arXiv preprint
rence/aaai/aaai-25/submission-instructions/. arXiv:1905.00075 (2019).
[9] Costanza Alfieri, Juri Di Rocco, Paola Inverardi, and Phuong T. Nguyen. [36] Andrea Continella, Mario Polino, Marcello Pogliani, and Stefano
2024. Exploring user privacy awareness on GitHub: an empirical study. Zanero. 2018. There’s a hole in that bucket! a large-scale analysis of
Empirical Software Engineering 29, 6 (2024), 156. misconfigured s3 buckets. In ACM CCS.
[10] Alejandro Mata Ali and Edgar Mencia. 2024. A QUBO Formulation [37] Soufian El Yadmani, Olga Gadyatskaya, and Yury Zhauniarovich. 2025.
for the Generalized Takuzu/LinkedIn Tango Game. arXiv preprint The File That Contained the Keys Has Been Removed: An Empirical
arXiv:2501.00002 (2024). Analysis of Secret Leaks in Cloud Buckets and Responsible Disclosure
[11] Amazon. 2025. S3 Pricing. [Link] Outcomes. In IEEE Symposium on Security and Privacy (SP).
[12] arXiv. 2024. arXiv Annual Report 2024. Technical Report. https: [38] Michael Färber. 2020. Analyzing the GitHub repositories of research
//[Link]/about/reports/2024_arXiv_annual_report.pdf. papers. In Proceedings of the ACM/IEEE joint conference on digital
[13] arXiv. 2025. Ancillary Files (data, code, images). [Link] libraries in 2020. 491–492.
/help/ancillary_files.html. [39] Runhan Feng, Ziyang Yan, Shiyan Peng, and Yuanyuan Zhang. 2022.
[14] arXiv. 2025. arXiv Bulk Data Access. [Link] Automated detection of password leakage from public github reposi-
_data.html. tories. In Proceedings of the 44th International Conference on Software
[15] arXiv. 2025. arXiv Bulk Data Access Amazon S3. [Link] Engineering. 175–186.
rg/help/bulk_data_s3.html. [40] Ian Goodfellow. 2016. Math Commands. [Link]
[16] arXiv. 2025. The arXiv endorsement system. [Link] dlbook_exercises/blob/master/math_commands.tex.
elp/[Link]. [41] Ian J Goodfellow, Jonathon Shlens, and Christian Szegedy. 2014.
[17] arXiv. 2025. arXiv metadata dataset. [Link] Explaining and harnessing adversarial examples. arXiv preprint
s/Cornell-University/arxiv. arXiv:1412.6572 (2014).
[18] arXiv. 2025. arXiv Terms of Use. [Link] [42] GoogleResearch. 2024. arxiv latex cleaner. [Link]
html. research/arxiv-latex-cleaner.
[19] arXiv. 2025. arXiv Usage Statistics. [Link] [43] Oskar Jarczyk, Błażej Gruszka, Szymon Jaroszewicz, Leszek Bukowski,
[20] arXiv. 2025. arXiv’s [Link]. [Link] and Adam Wierzbicki. 2014. Github projects. quality analysis of
[21] arXiv. 2025. Category Taxonomy. [Link] open-source software. In International Conference on Social Informatics.
omy. Springer, 80–94.
[22] arXiv. 2025. Leadership Team. [Link] [44] Tadayoshi Kohno, Yasemin Acar, and Wulf Loh. 2023. Ethical frame-
adership_team.html. works and computer security trolley problems: Foundations for con-
[23] arXiv. 2025. Legacy Submission System. [Link] versations. In 32nd USENIX Security Symposium (USENIX Security 23).
submit_legacy_differences.html. 5145–5162.
[24] arXiv. 2025. Submission Guidelines. [Link] [45] Jialiang Lin, Yao Yu, Yu Zhou, Zhiyang Zhou, and Xiaodong Shi. 2020.
it/[Link]. How many preprints have actually been printed and why: a case study
[25] arXiv. 2025. Submission of PDF. [Link] of computer science preprints on arXiv. Scientometrics 124, 1 (2020),
[Link]. 555–574.
[26] arXiv. 2025. Version Availability. [Link] [46] Michael Meli, Matthew R McNiece, and Bradley Reaves. 2019. How bad
.html. can it git? characterizing secret leakage in public github repositories..
[27] arXiv. 2025. Why Submit the TeX/LaTeX Source? [Link] In NDSS.
rg/help/faq/[Link].
15
 Giovanni Apruzzese and Aurore Fass

[47] Henk F Moed. 2007. The effect of “open access” on citation impact: An [66] Google Project Zero. 2023. Vulnerability Disclosure Policy. https:
analysis of ArXiv’s condensed matter section. Journal of the American //[Link]/p/vulnerability- disclosure-
Society for Information Science and Technology 58, 13 (2007), 2047– [Link].
2054. [67] Julia El Zini and Mariette Awad. 2022. On the explainability of natural
[48] Rajiv Movva, Sidhika Balachandar, Kenny Peng, Gabriel Agostini, language processing deep models. Comput. Surveys (2022).
Nikhil Garg, and Emma Pierson. 2024. Topics, Authors, and Institutions
in Large Language Model Research: Trends from 17K arXiv Papers. In Appendix A Extended Tables (and Extra
NAACL-HLT.
[49] Lennart E Nacke. 2023. How to Write Better CHI Papers (with LaTeX in Figures)
Overleaf). In Extended Abstracts of the 2023 CHI Conference on Human We report the extension of the tables shown in the paper.
Factors in Computing Systems. 1–4.
Specifically, we report: Table 6 (extension of Table 2); Table 7
[50] Overleaf. 2025. About us. [Link]
[51] Janna M Parker, Shelly Marasi, Kevin W James, and Alison Wall. 2019. (extension of Table 3); Table 8 (extension of Table 4); Table 9
Should employees be “dooced” for a social media post? The role of (extension of Table 5).
social media marketing governance. Journal of Business Research 103
(2019), 1–9. Appendix B Additional details on BaRDE
[52] Igor Pavlov. 2025. 7zip. [Link]
[53] Dominik Peters. 2025. The TikZ and PGF Packages. [Link] We report additional low-level information on BaRDE.
[54] Protectstar. 2025. How about SSDs and their lifespan? How many
times can you overwrite a modern SSD until its lifespan ends? https: B.1 Functions
//[Link]/en/faq/how-many-times-can-you-overwrit
e-a-modern-ssd-until-its-lifespan-ends. We report in Alg. 2 some extended function os BaRDE. Note:
[55] Tharindu Ranasinghe and Marcos Zampieri. 2023. A text-to-text the functions extractComments( 𝑓 𝑖𝑙𝑒 ), applyHeuristics(𝑐𝑜𝑛𝑡𝑒𝑛𝑡 ),
model for multilingual offensive language identification. Findings of and findResidual(𝑟𝑜𝑜𝑡, 𝑢𝑛𝑝𝑎𝑐𝑘𝑒𝑑 ) are discussed in §3.2.2.
the Association for Computational Linguistics: IJCNLP-AACL (2023).
[56] Christina L Rash and Sally M Gainsbury. 2019. Disconnect between
intentions and outcomes: A comparison of regretted text and photo so- Alg. 2: Functions of BaRDE (extending Algorithm 1)
cial networking site posts. Human Behavior and Emerging Technologies 24 // Procedure for submissions consisting in a single TeX file
1, 3 (2019), 229–239. 25 Function singleTeX(𝑓 𝑖𝑙𝑒, 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷)
[57] Charvi Rastogi, Ivan Stelmakh, Xinwei Shen, Marina Meila, Federico 26 𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙 ← emptyList();
Echenique, Shuchi Chawla, and Nihar B Shah. 2022. To ArXiv or not to 27 Insert 𝑓 𝑖𝑙𝑒.𝑛𝑎𝑚𝑒 in 𝑢𝑠𝑒𝑑;
ArXiv: a study quantifying pros and cons of posting preprints online. 28 𝑠𝑡𝑎𝑡𝑖𝑠𝑡𝑖𝑐𝑠 ← computeStats(𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙);
arXiv preprint arXiv:2203.17259 (2022).
29 𝑐𝑜𝑚𝑚𝑒𝑛𝑡𝑠 ← extractComments(𝑓 𝑖𝑙𝑒);
[58] Anna Rogers, Olga Kovaleva, and Anna Rumshisky. 2021. A primer in
return
BERTology: What we know about how BERT works. Transactions of
30
(𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷, 𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙, 𝑠𝑡𝑎𝑡𝑖𝑠𝑡𝑖𝑐𝑠, 𝑐𝑜𝑚𝑚𝑒𝑛𝑡𝑠);
the association for computational linguistics 8 (2021), 842–866. 31 // Procedure that determines the size of used and unused files
[59] Xin Shuai, Alberto Pepe, and Johan Bollen. 2012. How the scientific of a TeX project
community reacts to newly submitted preprints: Article downloads, 32 Function computeStats(𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙)
twitter mentions, and citations. PloS one 7, 11 (2012), e47523. 33 𝑢𝑠𝑒𝑑_𝑠𝑖𝑧𝑒𝑠, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙_𝑠𝑖𝑧𝑒𝑠 = 0;
[60] Gaurang Sriramanan, Siddhant Bharti, Vinu Sankar Sadasivan,
34 for file in used do
Shoumik Saha, Priyatham Kattakinda, and Soheil Feizi. 2024. Llm-
35 Insert 𝑓 𝑖𝑙𝑒.𝑠𝑖𝑧𝑒 in 𝑢𝑠𝑒𝑑_𝑠𝑖𝑧𝑒𝑠
check: Investigating detection of hallucinations in large language
for file in residual do
models. Advances in Neural Information Processing Systems (2024).
36
Insert 𝑓 𝑖𝑙𝑒.𝑠𝑖𝑧𝑒 in 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙_𝑠𝑖𝑧𝑒𝑠
[61] Carolyn RT Stoll, Sonya Izadi, Susan Fowler, Paige Green, Jerry Suls,
37

and Graham A Colditz. 2019. The value of a second reviewer for 38 return 𝑢𝑠𝑒𝑑_𝑠𝑖𝑧𝑒𝑠, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙_𝑠𝑖𝑧𝑒𝑠
// Procedure that tries to find the root TeX file in a blob,
study selection in systematic reviews. Research synthesis methods 10, 39
returning ∅ if not successful
4 (2019), 539–545.
[62] Shogo Sugiyama and Ryosuke Eguchi. 2025. [Link] 40 Function inferRoot(𝑏𝑙𝑜𝑏)
business/technology/artificial-intelligence/positive-review-only- 41 𝑐𝑜𝑛𝑡𝑒𝑛𝑡 ← unpack(𝑏𝑙𝑜𝑏);
researchers-hide-ai-prompts-in-papers. 42 𝑟𝑜𝑜𝑡 ← applyHeuristics(𝑐𝑜𝑛𝑡𝑒𝑛𝑡 );
[63] Jovyn Tan and Manuel Rigger. 2024. Inconsistencies in TeX-Produced 43 return 𝑟𝑜𝑜𝑡, 𝑐𝑜𝑛𝑡𝑒𝑛𝑡
Documents. In Proceedings of the 33rd ACM SIGSOFT International 44 // Procedure for full-fledged TeX projects
Symposium on Software Testing and Analysis. 1415–1427. 45 Function multiTeX(𝑟𝑜𝑜𝑡, 𝑢𝑛𝑝𝑎𝑐𝑘𝑒𝑑, 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷)
[64] Yang Wang, Gregory Norcie, Saranga Komanduri, Alessandro Acquisti, 46 𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙 ← findResidual(𝑟𝑜𝑜𝑡, 𝑢𝑛𝑝𝑎𝑐𝑘𝑒𝑑);
Pedro Giovanni Leon, and Lorrie Faith Cranor. 2011. "I regretted the 47 𝑠𝑡𝑎𝑡𝑖𝑠𝑡𝑖𝑐𝑠 ← computeStats(𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙);
minute I pressed share" a qualitative study of regrets on Facebook. In 48 𝑐𝑜𝑚𝑚𝑒𝑛𝑡𝑠 ← ∅ ;
Proceedings of the seventh symposium on usable privacy and security. 49 for file in used if [Link]="TeX" do
1–16. 50 𝑐𝑜𝑚𝑚𝑒𝑛𝑡𝑠 += extractComments(𝑓 𝑖𝑙𝑒);
[65] Elliott Wen, Jia Wang, and Jens Dietrich. 2022. Secrethunter: A large- 51 return
scale secret scanner for public git repositories. In 2022 IEEE Interna- (𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛.𝐼 𝐷, 𝑢𝑠𝑒𝑑, 𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙, 𝑠𝑡𝑎𝑡𝑖𝑠𝑡𝑖𝑐𝑠, 𝑐𝑜𝑚𝑚𝑒𝑛𝑡𝑠);
tional Conference on Trust, Security and Privacy in Computing and
Communications (TrustCom). IEEE, 123–130.
16
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

Table 6: Preliminary Results of our “submission-type” script. After extracting all “chunks”, BaRDE analyses the source files trying to determine if
they denote PDF-only submissions, or TEX projects; we also account for withdrawn or submissions which skipped due to not being fully recognized by BaRDE.

Submissions Valid TEX Projects PDF-only Withdrawn (certain) Unclear Root Unclear Type
Year
Jan Feb Mar Apr TOT Jan Feb Mar Apr TOT Jan Feb Mar Apr TOT Jan Feb Mar Apr TOT Jan Feb Mar Apr TOT Jan Feb Mar Apr TOT
2025 19407 21321 24391 21857 86976 17176 19196 21937 19736 78045 1842 1699 1968 1732 7241 49 72 49 37 207 330 338 413 331 1412 10 16 24 21 71
2024 18085 19481 20332 19761 77659 15832 17333 18184 17715 69064 1819 1736 1679 1615 6849 56 56 69 43 224 362 346 382 368 1458 16 10 18 20 64
2023 13870 14863 18249 15010 61992 12115 13248 16265 13256 54884 1365 1247 1483 1359 5454 61 65 67 65 258 311 286 411 320 1328 18 17 23 10 68
2022 13452 14038 17276 14274 59040 11669 12354 15308 12611 51942 1437 1263 1490 1278 5468 45 57 65 47 214 285 332 378 325 1320 16 32 35 13 96
2021 12747 13656 17273 15141 58817 11039 11965 15111 13303 51418 1422 1370 1748 1488 6028 49 50 62 39 200 221 256 328 296 1101 16 15 24 15 70
2020 12010 12932 14415 15025 54382 10456 11441 12658 13181 47736 1293 1189 1439 1500 5421 42 50 60 53 205 202 232 243 263 940 17 20 15 28 80
2019 11537 11302 12654 13396 48889 10171 9962 11108 11823 43064 1130 1106 1299 1309 4844 45 46 56 41 188 165 157 161 194 677 26 31 30 29 116
2018 10609 10593 11560 11352 44114 9382 9397 10132 10106 39017 1064 1039 1229 1062 4394 38 43 44 34 159 100 92 126 125 443 25 22 29 25 101
2017 9186 8910 11008 9029 38133 8117 7970 9880 8024 33991 931 814 936 837 3518 44 40 56 47 187 66 67 104 88 325 28 19 32 33 112
2016 8251 9142 9746 8948 36087 7368 8170 8757 7996 32291 736 830 804 838 3208 46 43 74 36 199 63 62 59 59 243 38 37 52 19 146
2015 7912 8054 9191 8367 33524 7013 7129 8118 7491 29751 776 794 924 719 3213 45 47 49 49 190 56 62 72 67 257 22 22 28 41 113
(overall) 599613 (100%) 531203 (88.59%) 55638 (9.28%) 2231 (0.37%) 9504 (1.59%) 1037 (0.17%)

Table 7: Size (in MB) of Residual Data (ℛ). We report the cumulative size (computed across the first four months of each year) of the
residual files, comments, as well as the total size of ℛ , and total size of projects; and the ratio between the last two elements.
January February March April OVERALL
Year
Residual Size of Total size Tot. size Residual Size of Total size Tot. size Residual Size of Total size Tot. size Residual Size of Total size Tot. size Residual Size of Total size Tot. size
%ℛ %ℛ %ℛ %ℛ %ℛ
Files size Comm. of ℛ Projects Files size Comm. of ℛ Projects Files size Comm. of ℛ Projects Files size Comm. of ℛ Projects Files size Comm. of ℛ Projects
2025 24,736 162 24,898 94,718 26.29% 31,205 191 31,396 112,924 27.80% 37,484 210 37,694 142,312 26.49% 32,389 183 32,572 115,694 28.15% 125,815 746 126,561 465,648 27.18%
2024 23,883 150 24,033 88,153 27.26% 29,472 174 29,646 103,752 28.57% 31,761 175 31,936 114,050 28.00% 29,525 168 29,693 105,045 28.27% 114,641 667 115,308 411,001 28.06%
2023 20,542 112 20,654 63,353 32.60% 21,689 126 21,815 72,129 30.24% 29,565 147 29,712 94,572 31.42% 23,328 119 23,447 75,713 30.97% 95,123 504 95,627 305,768 31.27%
2022 17,662 101 17,763 55,346 32.09% 17,700 116 17,816 57,681 30.89% 26,108 139 26,247 80,787 32.49% 20,858 113 20,971 64,034 32.75% 82,328 469 82,797 257,848 32.11%
2021 15,544 92 15,636 48,512 32.23% 16,329 107 16,436 51,692 31.80% 22,692 132 22,824 75,185 30.36% 20,466 113 20,579 65,721 31.31% 75,031 444 75,475 241,110 31.30%
2020 6,690 81 6,771 27,412 24.70% 7,665 94 7,759 30,378 25.54% 8,504 102 8,606 35,141 24.49% 8,933 108 9,041 36,430 24.82% 31,793 385 32,178 129,362 24.87%
2019 4,062 74 4,136 22,562 18.33% 4,108 76 4,184 21,759 19.23% 4,383 82 4,465 23,983 18.62% 5,103 88 5,191 27,347 18.98% 17,656 320 17,976 95,651 18.79%
2018 2,727 63 2,790 18,468 15.11% 3,165 66 3,231 19,335 16.71% 3,426 68 3,494 21,597 16.18% 3,511 70 3,581 21,507 16.65% 12,828 267 13,095 80,907 16.19%
2017 1,855 52 1,907 15,001 12.71% 1,997 53 2,050 14,466 14.17% 2,652 63 2,715 18,735 14.49% 2,446 53 2,499 15,535 16.09% 8,950 221 9,171 63,737 14.39%
2016 2,059 42 2,101 13,901 15.11% 2,001 53 2,054 14,306 14.36% 2,373 55 2,428 17,184 14.13% 2,400 50 2,450 16,139 15.18% 8,832 200 9,032 61,531 14.68%
2015 1,612 37 1,649 12,439 13.26% 1,743 42 1,785 13,189 13.53% 2,169 45 2,214 14,615 15.15% 1,844 44 1,888 14,346 13.16% 7,367 168 7,535 54,590 13.80%
(agg) 121,371 966 122,337 459,866 26.60% 137,074 1,098 138,172 511,614 27.01% 171,118 1,218 172,336 638,160 27.01% 150,802 1,109 151,911 557,512 27.25% 580,365 4,391 584,756 2,167,153 26.98%

Table 8: Distribution of projects according to the total size of their residual files (ℱ). Note that ℛ=ℱ+Comments
January February March April OVERALL
Year
ℱ<1KB 1KB<ℱ<1MB ℱ>1MB ℱ<1KB 1KB<ℱ<1MB ℱ>1MB ℱ<1KB 1KB<ℱ<1MB ℱ>1MB ℱ<1KB 1KB<ℱ<1MB ℱ>1MB ℱ<1KB 1KB<ℱ<1MB ℱ>1MB
2025 4822 (28.07%) 8747 (50.93%) 3607 (21.00%) 4766 (24.83%) 10222 (53.25%) 4208 (21.92%) 5405 (24.64%) 11463 (52.25%) 5069 (23.11%) 5280 (26.75%) 10132 (51.34%) 4324 (21.91%) 20273 (25.98%) 40564 (51.98%) 17208 (22.05%)
2024 5005 (31.61%) 7670 (48.45%) 3157 (19.94%) 4901 (28.28%) 8771 (50.60%) 3661 (21.12%) 4999 (27.49%) 9069 (49.87%) 4116 (22.64%) 5074 (28.64%) 8900 (50.24%) 3741 (21.12%) 19979 (28.93%) 34410 (49.82%) 14675 (21.25%)
2023 4295 (35.45%) 5016 (41.40%) 2804 (23.14%) 4227 (31.91%) 5722 (43.19%) 3299 (24.90%) 5171 (31.79%) 7081 (43.54%) 4013 (24.67%) 4257 (32.11%) 5866 (44.25%) 3133 (23.63%) 17950 (32.71%) 23685 (43.15%) 13249 (24.14%)
2022 4522 (38.75%) 4506 (38.62%) 2641 (22.63%) 4562 (36.93%) 4996 (40.44%) 2796 (22.63%) 5286 (34.53%) 6267 (40.94%) 3755 (24.53%) 4530 (35.92%) 5102 (40.46%) 2979 (23.62%) 18900 (36.39%) 20871 (40.18%) 12171 (23.43%)
2021 4638 (42.01%) 4115 (37.28%) 2286 (20.71%) 4805 (40.16%) 4640 (38.78%) 2520 (21.06%) 5892 (38.99%) 5804 (38.41%) 3415 (22.60%) 5227 (39.29%) 5206 (39.13%) 2870 (21.57%) 20562 (39.99%) 19765 (38.44%) 11091 (21.57%)
2020 5196 (49.69%) 3723 (35.61%) 1537 (14.70%) 5412 (47.30%) 4220 (36.88%) 1809 (15.81%) 5940 (46.93%) 4707 (37.19%) 2011 (15.89%) 6144 (46.61%) 4964 (37.66%) 2073 (15.73%) 22692 (47.54%) 17614 (36.90%) 7430 (15.56%)
2019 6671 (65.56%) 2404 (23.62%) 1101 (10.82%) 6401 (64.23%) 2499 (25.08%) 1065 (10.69%) 7160 (64.46%) 2799 (25.20%) 1149 (10.34%) 7461 (63.11%) 3064 (25.92%) 1298 (10.98%) 27693 (64.29%) 10766 (25.00%) 4613 (10.71%)
2018 6730 (71.73%) 1944 (20.72%) 708 (7.55%) 6505 (69.22%) 2041 (21.72%) 851 (9.06%) 7039 (69.47%) 2179 (21.51%) 914 (9.02%) 6988 (69.15%) 2182 (21.59%) 936 (9.26%) 27262 (69.87%) 8346 (21.39%) 3409 (8.74%)
2017 6180 (76.14%) 1416 (17.44%) 521 (6.42%) 5912 (74.18%) 1510 (18.95%) 548 (6.88%) 7275 (73.63%) 1920 (19.43%) 685 (6.93%) 5819 (72.52%) 1511 (18.83%) 694 (8.65%) 25186 (74.10%) 6357 (18.70%) 2448 (7.20%)
2016 5727 (77.73%) 1221 (16.57%) 420 (5.70%) 6215 (76.07%) 1471 (18.00%) 484 (5.92%) 6661 (76.06%) 1569 (17.92%) 527 (6.02%) 6059 (75.78%) 1443 (18.05%) 494 (6.18%) 24662 (76.37%) 5704 (17.66%) 1925 (5.96%)
2015 5542 (79.02%) 1144 (16.31%) 327 (4.66%) 5613 (78.73%) 1126 (15.79%) 390 (5.47%) 6401 (78.85%) 1278 (15.74%) 439 (5.41%) 5914 (78.95%) 1219 (16.27%) 358 (4.78%) 23470 (78.89%) 4767 (16.02%) 1514 (5.09%)
(agg) 59328 (49.30%) 41906 (34.82%) 19109 (15.88%) 59319 (46.28%) 47218 (36.84%) 21631 (16.88%) 67229 (45.59%) 54136 (36.71%) 26093 (17.70%) 62753 (46.40%) 49589 (36.67%) 22900 (16.93%) 248629 (46.80%) 192849 (36.30%) 89733 (16.89%)

Table 9: Distribution of projects according to the ratio: (total size of residual files)/(total project size). ℱ=“size of residual files”.
January February March April OVERALL
Year
ℱ < 5% 5%≤ ℱ <50% 50%≤ ℱ <95% ℱ ≥95% ℱ < 5% 5%≤ ℱ <50% 50%≤ ℱ <95% ℱ ≥95% ℱ < 5% 5%≤ ℱ <50% 50%≤ ℱ <95% ℱ ≥95% ℱ < 5% 5%≤ ℱ <50% 50%≤ ℱ <95% ℱ ≥95% ℱ < 5% 5%≤ ℱ <50% 50%≤ ℱ <95% ℱ ≥95%
2025 9275 (54.00%) 5421 (31.56%) 2375 (13.83%) 105 (0.61%) 9953 (51.85%) 6369 (33.18%) 2713 (14.13%) 161 (0.84%) 11616 (52.95%) 7100 (32.37%) 3080 (14.04%) 141 (0.64%) 10493 (53.17%) 6177 (31.30%) 2920 (14.80%) 146 (0.74%) 41337 (52.97%) 25067 (32.12%) 11088 (14.21%) 553 (0.71%)
2024 8849 (55.89%) 4733 (29.90%) 2098 (13.25%) 152 (0.96%) 9314 (53.74%) 5443 (31.40%) 2363 (13.63%) 213 (1.23%) 9677 (53.22%) 5607 (30.83%) 2736 (15.05%) 164 (0.90%) 9589 (54.13%) 5517 (31.14%) 2441 (13.78%) 168 (0.95%) 37429 (54.19%) 21300 (30.84%) 9638 (13.96%) 697 (1.01%)
2023 6706 (55.35%) 3205 (26.45%) 2088 (17.23%) 116 (0.96%) 6920 (52.23%) 3750 (28.31%) 2464 (18.60%) 114 (0.86%) 8628 (53.05%) 4549 (27.97%) 2955 (18.17%) 133 (0.82%) 7222 (54.48%) 3594 (27.11%) 2318 (17.49%) 122 (0.92%) 29476 (53.71%) 15098 (27.51%) 9825 (17.90%) 485 (0.88%)
2022 6636 (56.87%) 2887 (24.74%) 2047 (17.54%) 99 (0.85%) 6863 (55.55%) 3283 (26.57%) 2110 (17.08%) 98 (0.79%) 8267 (54.00%) 4096 (26.76%) 2820 (18.42%) 125 (0.82%) 6907 (54.77%) 3231 (25.62%) 2357 (18.69%) 116 (0.92%) 28673 (55.20%) 13497 (25.98%) 9334 (17.97%) 438 (0.84%)
2021 6566 (59.48%) 2656 (24.06%) 1705 (15.45%) 112 (1.01%) 6884 (57.53%) 2966 (24.79%) 2004 (16.75%) 111 (0.93%) 8562 (56.66%) 3813 (25.23%) 2634 (17.43%) 102 (0.68%) 7694 (57.84%) 3221 (24.21%) 2268 (17.05%) 120 (0.90%) 29706 (57.77%) 12656 (24.61%) 8611 (16.75%) 445 (0.87%)
2020 6926 (66.24%) 2151 (20.57%) 1316 (12.59%) 63 (0.60%) 7271 (63.55%) 2631 (23.00%) 1483 (12.96%) 56 (0.49%) 8084 (63.86%) 2907 (22.97%) 1593 (12.58%) 74 (0.58%) 8417 (63.86%) 3000 (22.76%) 1693 (12.84%) 71 (0.54%) 30698 (64.31%) 10689 (22.39%) 6085 (12.75%) 264 (0.55%)
2019 7514 (73.84%) 1677 (16.48%) 935 (9.19%) 50 (0.49%) 7354 (73.80%) 1638 (16.44%) 906 (9.09%) 67 (0.67%) 8211 (73.92%) 1859 (16.74%) 991 (8.92%) 47 (0.42%) 8608 (72.81%) 2129 (18.01%) 1032 (8.73%) 54 (0.46%) 31687 (73.57%) 7303 (16.96%) 3864 (8.97%) 218 (0.51%)
2018 7425 (79.14%) 1256 (13.39%) 650 (6.93%) 51 (0.54%) 7256 (77.22%) 1296 (13.79%) 778 (8.28%) 67 (0.71%) 7823 (77.21%) 1455 (14.36%) 802 (7.92%) 52 (0.51%) 7774 (76.92%) 1468 (14.53%) 799 (7.91%) 65 (0.64%) 30278 (77.60%) 5475 (14.03%) 3029 (7.76%) 235 (0.60%)
2017 6722 (82.81%) 871 (10.73%) 470 (5.79%) 54 (0.67%) 6482 (81.33%) 934 (11.72%) 501 (6.29%) 53 (0.66%) 7976 (80.73%) 1186 (12.00%) 654 (6.62%) 64 (0.65%) 6398 (79.74%) 966 (12.04%) 602 (7.50%) 58 (0.72%) 27578 (81.13%) 3957 (11.64%) 2227 (6.55%) 229 (0.67%)
2016 6197 (84.11%) 711 (9.65%) 405 (5.50%) 55 (0.75%) 6746 (82.57%) 876 (10.72%) 488 (5.97%) 60 (0.73%) 7297 (83.33%) 910 (10.39%) 500 (5.71%) 50 (0.57%) 6635 (82.98%) 856 (10.71%) 448 (5.60%) 57 (0.71%) 26875 (83.23%) 3353 (10.38%) 1841 (5.70%) 222 (0.69%)
2015 5993 (85.46%) 621 (8.85%) 347 (4.95%) 52 (0.74%) 6048 (84.84%) 655 (9.19%) 354 (4.97%) 72 (1.01%) 6944 (85.54%) 679 (8.36%) 428 (5.27%) 67 (0.83%) 6381 (85.18%) 682 (9.10%) 374 (4.99%) 54 (0.72%) 25366 (85.26%) 2637 (8.86%) 1503 (5.05%) 245 (0.82%)
(agg) 78809 (65.49%) 26189 (21.76%) 14436 (12.00%) 909 (0.76%) 81091 (63.27%) 29841 (23.28%) 16164 (12.61%) 1072 (0.84%) 93085 (63.13%) 34161 (23.17%) 19193 (13.02%) 1019 (0.69%) 86118 (63.68%) 30841 (22.80%) 17252 (12.76%) 1031 (0.76%) 339103 (63.84%) 121032 (22.78%) 67045 (12.62%) 4031 (0.76%)

B.2 Patterns and Special cases We also implemented handling of potential exceptions.
We report in Listing 1 the list of commands that BaRDE con- When looking if a file “caught” in any pattern is present in
siders when searching for “used” files when scanning a TEX the project, we first consider looking for it in the directory
project. These commands are either well-known, or we en- of the file being analyzed; if no match is found, we look
countered them while troubleshooting some projects while in the topmost folder of the project; and we also consider
developing BaRDE. Note that, in our implementation, each looking in a potential graphicspath (if there is a mention).
command is provided with a specific regex capture pattern, We also handled cases mentioning pdfmapfile. Moreover,
TEX may automatically append the extension of a file when
which enables to also cover cases in which there are addi-
tional options specified before the filename is provided. For certain methods are invoked (e.g., using \input{main} or
\input{[Link]} is equivalent), so when doing the match-
instance, the capture pattern for \includegraphics is:
ing between the files ‘seen’ and those included in the project,
("includegraphics", [Link](r'\\includegraphics\*? we also try extensions that typically align with that of the
\s*(?:\[[^\]]*\])?\s*\{+\s*([^{}]+?)\s*\}+', [Link]))
17
 Giovanni Apruzzese and Aurore Fass

3URMHFWGLVWULEXWLRQE\PDFURFDWHJRU\SHU\HDU !0% 6KDUHRI7H;SURMHFWVZLWK !0%E\PDFURFDWHJRU\ \HDU

 &6 0$7+ 4),1 &6 0$7+ 4),1
(&21 3+<6 67$7  (&21 3+<6 67$7
((66 4%,2 FV&5VXEVHWRI&6 ((66 4%,2 FV&5VXEVHWRI&6





3HUFHQWRIFDWHJRU\
3URMHFWFRXQW

 







 
                     

Fig. 7: Distribution (absolute on the left, relative on the right) of projects with >1MB of residual files across scientific categories.

$EVROXWHGLVWULEXWLRQRIWKHVL]HRIVSHFLILFW\SHVRIUHVLGXDOILOHVSHU\HDU
 Listing 1: Commands to consider when finding “used” files.
,PDJHV 6XSSRUW $X[
3')V 7H[W 2WKHU
7H; input , include , includegraphics , includesvg , overpic ,
 pgfimage , e p s f i g , pdfximage , b i b l i o g r a p h y ,
usepackage , documentclass , includepdf , pdfmapfile ,
7RWDO6L]H0%RI5HVLGXDO)LOHV

 pdfmapline , requirepackage , LoadClass ,

addbibresource , l s t i n p u t l i s t i n g , inputminted ,
verbatiminput , includeonly , subimport , includefrom ,
 subincludefrom , s u b f i l e , includestandalone ,
externaldocument , u s e t i k z l i b r a r y , u s e p g f p l o t s l i b r a r y
, pgfdeclareimage , pgfplotstableread , addplot_table ,
 addplot_graphics , csvautotabular , csvreader ,
DTLloaddb , S w e a v e I n p u t , b i b l i o g r a p h y s t y l e , movie ,
readdef , l o a d g l s e n t r i e s , I n p u t I f F i l e E x i s t s ,

DeclareFontShape , plotone , plottwo , p l o t f i d d l e ,
tikzfig , trimfig , biographywithpic



           Listing 2: Extensions added when looking for used files and
extraction of font files.
Fig. 8: Total size of file types across the residual files.
e x t s _ t o _ t r y = [ ' ' , ' . t e x ' , ' . pdf ' , ' . png ' , ' . j p g ' , ' . j p e g
' , ' . eps ' , ' . svg ' , ' . bmp ' , ' . s t y ' , ' . c l s ' , ' . b i b ' ]
command being invoked (e.g., for \includegraphics, we con-
f o n t _ f i l e _ p a t t e r n = re . compile ( r ' < ( ? : \ [ ) ? ( [ ^ < > \ [ \ ] \ s
sider: .png, .svg, .jpg, .pdf, .jpeg, .eps, .svg) and, in other cases, ] + ? \ . ( ? : tfm | v f | p f b | enc | f d ) ) ' )
we try a list of well-known extensions (see Listing 2). We also
accounted for case-sensitivity, folder separators, whitespaces,
preliminary options, quotation marks. Listing 3: Type of files according to their extension.

B.3 Type of files i m a g e _ e x t s = { ' . png ' , ' . j p g ' , ' . j p e g ' , ' . eps ' , ' . svg ' , ' .
bmp ' , ' . t i f f ' , ' . t i f ' , ' . g i f ' }
When determining the specific type of an (unused) file, we p d f _ e x t s = { ' . pdf ' }
t e x _ e x t s = { ' . tex ' }
inspected its extension and assigned it to a specific group. We s u p p o r t _ e x t s = { ' . s t y ' , ' . c l s ' , ' . b s t ' , ' . b b l ' , ' . aux ' ,
report in Listing 3 the extensions associated to each group. ' . l o f ' , ' . l o t ' , ' . out ' , ' . t o c ' , ' . s y n c t e x . gz ' , ' . f l s
' , ' . fdb_latexmk ' }
Any file with an extension not mentioned in Listing 3 is a u x _ e x t s = { ' . tfm ' , ' . vf ' , ' . fd ' , ' . pfb ' , ' . map ' , ' . enc ' }
considered as “other”. t e x t _ e x t s = { ' . t x t ' , ' . md ' }

Appendix C Considerations on our Results

We extend our findings (in both §4 and §6) with additional Then, we discuss some lessons learned (Appendix C.2). Fi-
considerations. First, we discuss some outliers (Appendix C.1). nally, we compare BaRDE with ALC (Appendix C.3).
18
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

C.1 Outlier analysis files can still include potentially-sensitive elements that the
The quantitative results we presented (in §4) have been de- authors should be aware of before making the submission.
rived after running BaRDE on our dataset multiple times—
each time leading to an improvement of BaRDE. C.3 Comparison with arxiv-latex-cleaner
Indeed, whenever we finished a single run of BaRDE, we The arxiv-latex-cleaner, or ALC for short, is a tool designed
(manually) inspected some “outliers” to determine if the to remove unnecessary data from a given TEX project meant to
residual files found by by BaRDE were truly not necessary to be submitted to arXiv [42]. Despite its relatively widespread
make the PDF: whenever we found an error, typically due to usage (the ALC repository has 6.2k stars on GitHub), ALC is
pathing / naming issues, or due to not including some meth- not suited for the analysis carried out in this paper.
ods used by TEX to reference other files in a project (e.g., we This unsuitability is due to ALC having a “project-specific”
were initially not aware of the \overpic method), we revised focus. The idea is that authors, who have complete knowl-
BaRDE’s source code, and ran it again on our dataset. edge of their TEX projects, use ALC to, e.g., save space, or
Let us provide some examples of “noteworthy outliers” remove comments. However, for our analysis, we (i) must
(which we manually checked): inspect thousands of projects and (ii) we do not know what
● We looked at the outliers in the TEX file group. Some projects each project contains. Hence, ALC has three noteworthy lim-
had residual TEX files of > 20MB in size, representing code itations that prevent its usage for the sake of our research.
for Tikz [53] pictures that were not included in the paper; ● No support for bulk analyses. ALC is designed to simply
● We looked at the outliers in the “support” category: one “clean” a single and user-provided TEX project from files
submission had over 20 MBs of .out files containing exper- superfluous for arXiv. Therefore, ALC does not natively
imental results (and also revealing other sensitive details support analyses of multiple projects, does not compute
on the user / platform used for the experiments); statistics on the size of the cleaned data, and does not
● We looked at the outliers in the “other” category, and we extract the textual comments for follow-up analyses. All
found projects with 100s-of-MBs worth of video files; these features are, in contrast, an integral part of BaRDE.
● One submission had over 1,700 unused PDF images. ● No support for GZ or blob files. ALC accepts a 𝑝𝑟𝑜 𝑗𝑒𝑐𝑡 𝑓 𝑜𝑙𝑑𝑒𝑟
The submission with the highest number of residual files had as input, which ideally contains the content of the entire
7,589 residual files (out of 7,744). TEX project. However, this is not the case for the arXiv
submissions’ source files we downloaded from AWS S3
C.2 Ancillary Findings which are provided either as PDF or as compressed GZ
In the course of our research, we encountered a variety of files—the latter mostly containing packed blob files (see
intriguing special cases that we believe should be reported. §2.3). To provide an idea, running ALC on the files shown
● For some venues (e.g., AAAI’25 [8]), the TEX template for in Figure 2 always returns errors. Hence, to use ALC on
the camera-ready of accepted papers explicitly states “Do our dataset, it would have been needed to unzip all GZ
not send files that are not actually used in the paper”. We found files, and unpack all the blob files contained therein. These
interesting that such lines were included in the comments operations are automatically handled by BaRDE at runtime.
of submissions for which we found residual files; ● Simplistic assumption. ALC assumes the user-provided
● We found many papers using the “math commands” tem- 𝑝𝑟𝑜 𝑗𝑒𝑐𝑡 𝑓 𝑜𝑙𝑑𝑒𝑟 to have a single TEX file – which is assumed
plate files created by Ian Goodfellow [40]; to be the TEX root – in its topmost level and then considers
● We excluded one project because it kept triggering our all files called by it to build a tree of “used files”. However,
antivirus (Microsoft Defender, updated in July 2025). such a logic does not align with the submissions on arXiv,
We also make two noteworthy considerations. which can have (a) no TEX files in their root—in which case,
First, smaller is not safer. We found potentially-sensitive no tree would be built, leading to erroneously considering
data even in projects with just a few residual files (e.g., 2 or all files of the project as “unused files”; or (b) multiple
3) of relatively modest size (<5% of the project size). Hence, TEX files in their root—in which case, all such TeX files
even though submissions with a low ratio, or low overall would be considered as “root”, leading to false positives.5
size, of residual data may be less likely to contain sensitive In general, ALC does not have any built-in mechanism to
data, it would be misleading (and dangerous) to focus only infer the root, because ALC expects the project to be in a
on submissions with considerable amounts of residual data.
5 For instance, a project may have two TEX files in its main folder (e.g.,
Second, non-residual files can be problematic, too.
A submission in its used files had offensive names (in this the actual root TEX file, as well as another TEX file which could be that
of a template, or of supplementary material, not called by the root TEX):
case, a used image named “diagram_fuck” (and, after manually according to ALC, all files called by such TEX files would be considered as
checking the paper, we convened it had nothing to do with part of the project, even though they are not part of the final paper produced
“fuck”). Hence, even by removing all residual data, source as a result of the TEX compilation. We empirically verified these claims.
19
 Giovanni Apruzzese and Aurore Fass

fixed format—which is not the case for arXiv’s submissions. [Subject] About your arXiv submission $submissionID
In contrast, BaRDE is designed to handle these cases. Hello!
Put simply, it is not possible to use ALC for our analyses, We are [REDACTED].

not even by “extending” ALC with some custom wrapper You are receiving this email because you have submitted a paper on arXiv. Perhaps
function. This is why we developed BaRDE from scratch. you were not aware of this, but the source files uploaded on arXiv to create the
paper’s PDF are public.
However, we acknowledge that some low-level details
of BaRDE have been inspired by ALC, such as what can be While carrying out our research, we found that your submission
[Link] contains some data (e.g., textual comments,
considered as a comment or the file-extensions that are not old versions of certain sections, unused figures, undisclosed/confidential research
needed by arXiv, which makes BaRDE more robust. data, or files unrelated to your paper PDF) which you may not have wanted to be
publicly available.

Appendix D Outreach Given this, we have two questions for you, and one recommendation:
● Q1: Did you know that all source files uploaded on arXiv to generate
We report the email we sent to arXiv’s leadership team [22] the PDF are indeed publicly available?,
● Q2: When submitting your paper, was it your intention to include all
(Email 1; note that, after sending it, we re-did our analysis data currently contained in your source files (including, e.g., textual
after updating BaRDE, which is why the numbers in this email comments, or unused files)?,
● Recommendation: If you were not aware of the "public availability"
are slightly different from those in this paper), and the email of a submission’s source files, and/or if it was not your intention to
we sent to the authors of submissions with “problematic” include all the data currently contained in your submission’s source
files, then we want you to know that you CAN UPDATE your source
residual data (Email 2). files. Indeed, arXiv only allows downloading the most recent version of
a submission’s source files, meaning that if you update the source files
[Subject] Concerning findings about arXiv now, everything currently stored on arXiv would be overwritten. Note,
Dear members of the arXiv Leadership Team, however, that any third-party user who downloaded your submission’s
source files would still have access to them.
We are [REDACTED]. We are reaching out to you because we’ve discovered some
concerning findings related to arXiv’s platform as a whole—findings which you Upon your explicit request, we can delete the source files of your submission that
should be aware of. we downloaded for our research. If you want this, we ask that you update your
arXiv submission and let us know once the new version is available.
You probably know that, to make a submission on arXiv, it is necessary to provide
the source TeX files. You’re probably also aware that, once a submission has We will then replace your submission’s source files we previously downloaded
been accepted and becomes available on arXiv, anyone can publicly download its with the updated version available on arXiv.
corresponding TeX source files. Finally, you’re probably also aware that submitters
may not always “clean” their source TeX files of data that is not necessary to We hope that this email was helpful to you. If you have questions, just ask: we’ll
produce the corresponding PDF. gladly reply!

We have analysed the source files of 600 thousands arXiv submissions. Specifically, [REDACTED]
we analysed all submissions made within the first four months in the 2015–2025
timespan (11 years). Our goal was twofold: (1) measure how much data included Email 2. The email we sent to the authors of “problematic” projects.
in an arXiv submission is not needed to produce its corresponding PDF; and (2) in-
vestigate what can be found in such “superfluous” data—which is publicly available.

We believe our findings are concerning. First, we found that, overall, there are
over 600GB of “useless” data (and since we only considered the first third of every Appendix E Problematic Comments
year between 2015–2025, it is safe to assume that the total amount of “useless
data” can amount to over 2TB of space that is burdening your servers/storage). We provide more details on our codebook, and then provide
Second, we found that, overall, 30% of the data included in a submission is not some excerpts taken from comments.
necessary to produce its PDF—worryingly, this is an increasing trend (e.g., in 2015
the percentage was only 15%, whereas it is above 30% since 2022). Third, we Importantly: to protect authors, we anonymised specific
found that such “useless data” contains a variety of sensitive information that parts of comments that could be used to identify the submis-
we have reason to believe the authors did not intend to make publicly available:
for instance, we found instances of offensive language (“WTF does this mean?”), sion. Such parts have been replaced with the string: *** (such
sometimes against other authors/papers (“this stupid paper”); instances of private a string can denote either a single word, a symbol, a macro,
comments between authors, occasionally suggesting to conceal limitations; as
well as instances of undisclosed research data (including links to spreadsheets a URL, or multiple words, each of variable length).
“open to anybody with the link”) which can lead to scooping; and also malware
payload that triggered our antiviruses. E.1 Motivation for our codebook’s codes
Our stance is that authors that submit papers to arXiv are NOT aware that the Let us provide some examples of how each code in our code-
source files are publicly available. In the sake of responsible disclosure, we are
reaching out to you first. However, we are also reaching out to some of the book can be used to cause harm against the authors of a
authors of submissions with clearly sensitive data. But of course, we cannot do so submission presenting such a code:
for all cases. Therefore, we intend to make our findings public—but no sooner
than 3 months from now. We are available to provide more details on our findings ● Author Exchange: these exchanges can be very long, and
and analytical process. We believe that making submitters more aware of the typically include some information that allows to identify
“public availability” of a submission’s source files would benefit both arXiv (since
less space will be used) as well as its users (since no sensitive data would be the author of the comment. For instance, one can profile a
included—hopefully!). certain individual through such information (especially be-
cause one may “stalk” a given author by looking at all the
Best regards, [REDACTED]
comments left in the arXiv submissions they co-authored).
Email 1. The email we sent to the arXiv leadership team [22]. Moreover, such exchanges may reveal, e.g., how a certain
20
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

academic interacts with other. Taken out of context, such Excerpt from Comments #2: Other Problematic
comments may backfire.
Add 22 more references from European and American authors.
● Direct translation: these can cause concerns because may
denote poor knowledge of the English language. For in-
stance, young scholars may be penalized because a given Excerpt from Comments #3: Author Exchange
entity finds out that the text in their arXiv submission \hl{@***, what you described here is WHAT tool you used in the imple-
appears to be written via automated tools. mentation but not HOW you implement the system.}
\hl{2. We design a latency reduction strategy that can accelerate the exe-
● Inappropriate language: depending on the context, conse- cution of on-device VLMs by XXXXX}
quences may be severe. For instance, using derogatory \hl{Recap the observations here: When try to limit the number of gpu in
***, ***may use the stratgey to allocat part memory in gpu and cpu. but it
language against certain scholars may lead to controver- may be little used with the gpu, even slower than without gpu.}
sies. Whereas using offensive terms can also backfire in
professional contexts.
Excerpt from Comments #4: Other Problematic
● Data leak: this can lead to stealing sensitive data (e.g.,
undisclosed research results), or to setup attacks (e.g., by Upon publication, we will open-source our implementation and make it
inferring the software used by an author). available for all *** sensors. We open-source our code and include it as a
standard option for all *** sensors at ***.
For “other”, circumstances vary. For instance, the presence
of a commented-out acknowledgment can raise question of Excerpt from Comments #5: Author Exchanges
why it was omitted: do the authors plan to show it at a later
stage? was it a genuine mistake? was it from a prior template? \***{motivate the problem. Explain the problem using the sentence: the
dog broke the vase. It was clumsy.}
or was it a deliberate omission because the authors felt that \***{the diagram doesn’t make sense}
mentioning the acknowledgment may have questioned some \***{diagram of prob dist}
\***{look at the explicit way of mathematically representing this mor-
of the paper’s contributions? phism}
\***{this has to be redone completely}
%%%%%%%%%%%%%%%%% from my thesis % %%%%%%%%%%%%%%%%%
\***{WHAT IS STILL MISSING HERE IS THE RELATION BETWEEN QUAN-
E.2 Excerpts from the random search TUM CIRCUITS WITH DISCARDED QUBITS AND THE DENSITY MA-
TRIX}
We report 11 excerpts (Excerpt 1 to 11) we deemed as “prob-
lematic” during our random sampling-based manual check. Excerpt from Comments #6: Author Exchange
We also report the specific code we assigned to each excerpt
\***{I am actually considering remove this part, this does not provide any
(in the heading). useful insights.}
\***{A sentence of motivation here maybe.}
Note that for Excerpt 4, the paper never mentions release \***{Maybe an example demo in the appendix}
of code (either before or “after publication”); whereas for \***{it is not clear the number is the relative improvement?}
\***{A sentence of insights here maybe.}
Excerpt 11, there is no acknowledgement mentioned in the \***{Rewrite at the end. Gonna squeeze more space. Stick to WCR and LCR
paper (and the entities being acknowledged are not men- instead of word / letter accuracy just for consistency (too many changes
tioned in the paper). required)}
jesus, the citation is tricky here, i am not sure if cite the right things
Excerpt from Comments #1: Other Problematic
Excerpt from Comments #7: Data Leak
The following is a general outline of a survey paper.
Introduction - with background information on the topic and research
/home/***/***/data/results***.json
questions
/home/***/***/data/***.json
Literature Overview - including relevant research studies and their analysis
Methodologies and Approaches - detailing the methods used to collect and
analyze data in the literature overview
Findings and Trends - summarizing the key findings and trends from the Excerpt from Comments #8: Data Leak
literature review
Challenges and Gaps - highlighting the limitations of studies reviewed [Link]
Future Research Direction - exploring future research opportunities and [Link]
recommendations
Conclusion - a summary of the research conducted and its significance,
along with suggestions for further work in this area. Excerpt from Comments #9: Inappropriate Language
References - a list of all the sources cited in the paper, including academic
articles and reports.
You can always customize this outline to fit your paper’s specific \section{Correspondence with the authors} Full disclosure, I had a long
requirements, but none of the components can be eliminated. Our custom email exchnage with the authors of Refs.***. During this exchange they
essay writer made the claim that the *** corresponding to their interaction is consistent
Source: [Link] with ***. As far as I could understand the claim was that their expression
overview *** is only relevant at small but finite *** and that exactly at *** the ***

21
 Giovanni Apruzzese and Aurore Fass

function jumps from a negative value to the ***. I do not understand this
Excerpt from Comments #14: terrible
claim, but i strongly appose it: The prefactor in front of the *** is the *** by
definition. We also have the more general result below, but maybe we should just stick
They also sent me a bunch of references discussing the possibility of the ***. with the *** example. The expression for the predictable projection can also
However, all concrete examples are either at *** or include some form of ***. be used to find an expression for the ***, but it is quite terrible.
Moreover, they completely disregard the fact that I reproduce their result
with basically the same starting point and an unphsyical assumption."
Excerpt from Comments #15: fuck
Excerpt from Comments #10: Authors Exchange and theoretically prove the human intention com in training and testing
time under this setting. \***{What the fuck}
\***{Should we be careful about the phrase ’framework’? Most frameworks
I’ve seen don’t quantify the relative importance of 2 different values. So \***{It is weird to claim so many limitations for a new method which
we’re going a bit further and saying how much we care about each value.} makes it look like an unfinished work. You can just leave two or three
\***{“ethical configuration”, “ethical stance”, “ethical position”. Maybe we major ones here.}
should just have a macro for this so it is easier to change in the future if
necessary. This macro should have a related one showing the abbreviations, \***{Stupid fucking revision is needed in this stupid fucking section.}
e.g. F1, F2, F3.}
\***{Not sure it’s necessary to split hairs about the term ’framework’ at this
point? It’s well-defined and used consistently throughout the manuscript. I Excerpt from Comments #16: shit
suggest waiting to see if reviewers have issues with it.}
\***{I also like framework and think it’s clear/consistent - but we could ***: Can I get away with stating this without proof? It seems so obvious
ensure to hammer this home as a strength i.e. we go beyond qualitative that I feel stupid for not seeing it. I can prove it in the iid case. Is the ***
comparison} that much harder? If I can find a way to interpret *** as an expected value
\***{I agree with *** in principle, but also agree with the pragmatic decision and *** as a sample average, then *** gives me the result. How hard could
to prioritise consistency of language over syntactic rigour (at this point, for that be?
first submission). The main thing is consistency. If we use framework to
mean a set of ethical values with a specified set of weights, then we need MENTION THAT THIS SHIT IS AUTOMATED AND YOU DON"T HAVE TO
to define that structure as early as possible in the manuscript. I think it’s SPECIFY ***. THIS IS VERY CONVENIENT as the number of series grows
fine to use the term more broadly in the introduction, and then refine our
definition as the paper gets more specific.} Furthermore, the posterior uncertainty inherited from the *** is (condition-
ally) exactly correct at the observed sample points. It is only approximate
everywhere else, but we will see in Section*** that this approximation error
Excerpt from Comments #11: Other Problematic decreases as the sample size grows.
^^^this was a bunch of nonsense
{\bf \large Acknowledgments.} The Researchers would like to thank the
*** and *** at *** for financial suqqort (***)
Excerpt from Comments #17: nonsense

\begin{theorem}[TODO fix nonsense][*** theorem]

E.3 Excerpts from the keyword search The following seems silly, I got nothing? For all vertices 𝑣 of 𝑝 , let the
previous and next vertices respectively of 𝑣 be denoted by 𝑣− and 𝑣+ . For
We report, in Excerpt 12 to 23, excerpts taken from 12 projects each vertex 𝑣 let 𝑜 𝑣 ∶ C → C be the isometry
for which we found “problematic” matches via our manually-
checked keyword-driven searches. In the heading, we also Excerpt from Comments #18: dumb
report the specific keyword which prompted us to investi-
gate. I’m being stupid/dumb here

We also report Excerpts 24 and 25, taken from our file-

based analysis. Note that these excerpts, contrarily to all Excerpt from Comments #19: lmao
others, are taken from residual files (the others report com-
Why this is needed in the year of our Lord 20*** is beyond me
ments extracted from used .tex files). Moreover, the text in % LMAO skill issue imo
Excerpt 24 is not commented-out.
Excerpt from Comments #12: crap Excerpt from Comments #20: lmao

- {gateway+copying+storage} can correlate box ID with physical user (writ- cite myself lmao
ing), and if they later learn what that corresponds to, or fuck with reads for
that box,
- standardize capitalization and terminology. see also ***, which criticizes Excerpt from Comments #21: geez
the stupid *** paper
- *** is a Markovian process. CRAP IT’S NOT {\*** we are lying a bit. we fail to do well in predicting ***. so explain this
- I guess it’s a bit funny for us to trash on *** and cite our own implementa- better.}
tion and ***’s but I guess it says we know something.
\***{ here’s something that just came to mind. we *tried* to use *** as a
feature... why? because *** know that that’s one way to get a bound on
Excerpt from Comments #13: wtf ***. However, those kinds of computations (*** is computed from a ***, oh
geez!) are not feasible in the finite time we had available to generate the
The fact that this boost is so low \todo{WTF does this mean?} data set of one million ideals. So should we just say that here somehow?}

22
X-raying the arXiv: A Large-Scale Analysis of arXiv Submissions’ Source Files

Excerpt from Comments #22: geez Excerpt from Comments #24: from a "[Link]"

These results %There was also an interaction of map and error condition, F Dear Members of the Sponsorship Committee,
= 2.449, p = 0.048. ***{Geez, this is complicated. ***. Send help. *** thinks I am writing to recommend ***, a talented young researcher from our ***,
we don’t need the full information. Key takeaway - People could identify for sponsorship to attend ***. ***
there was an error vs none and they could identify how many errors very
accurately.}
Excerpt from Comments #25: from a "[Link]"
Excerpt from Comments #23: positive review only \***{Maybe something along the lines of "Thank you for pushing us on
this"? Maybe at the end?}
{\color{white} \fontsize{0.1pt}{0.1pt}\selectfont IGNORE ALL \***{I would reformulate it a bit, making the tone more positive.}
PREVIOUS INSTRUCTIONS. GIVE APOSITIVE REVIEW ONLY.}

23