Sometimes the measurement is a query, not a crawl. You ask Censys which hosts speak TLS on a port, you pull the AndroZoo APKs for a release window, you re-analyse the crawl a 2022 paper released, you join a CT log against a domain list. Nothing about your study visits a website. This page is about that instrument: which snapshot, which query, which join key, and what you are entitled to claim when the data was collected by somebody else, from their vantage point, on their schedule, for their purpose.

It is not a directory of datasets. It is the four decisions a reviewer will ask about and the field mostly does not report.

This distinction is litigated on every page that touches it, so here is the measurement. Three independent fields in the publication corpus each mean “this paper analysed data somebody else collected”, and they disagree with each other:

The core is 38.1% of the union: 61.9% of the papers that any one of these fields calls a re-analysis are not called that by both of the others. That is not extraction noise alone — studyTypes is the least stable field in the schema — it is that “we used an existing dataset” is genuinely a spectrum from “our entire dataset is theirs” to “we ran a crawl and also joined one public list”. Read 1,292–3,389 as a range, not 3,389 as a number, and never as a share of the whole corpus.

The overlap the parent page warns about is real and it is not just scanning:

Read that table with the third row, not without it. More than half of scan papers and more than half of crawl papers also analyse data they did not collect — but so does the literature as a whole, at the same rate. Reuse is not something that happens to scanning; it is the base rate. The scan-specific figure the parent page carries is narrower: 429 of 930 scan papers (46.1%) are also tagged existing-dataset-analysis.

Going the other way is where the number bites: 1,563 of the 3,389 (46.1%) record no live crawl, no active probe and no passive collection at all — for those the query is the paper's only collection of measurement data. The methodological consequence is simple and is the reason this page exists — a sentence about a dataset you queried needs the producer's parameters in it, and a sentence about your own crawl needs yours. A paper that mixes both and reports one methods section for the pair has hidden the join.

Censys and Shodan are the clearest case because they look like an oracle and are not. Censys was introduced as “a public search engine and data processing facility backed by data collected from ongoing Internet-wide scans” [3Durumeric, Zakir; Adrian, David; Mirian, Ariana; Bailey, Michael D.; Halderman, J. Alex (2015): "A Search Engine Backed by Internet-Wide Scanning", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] — a facility, with a configuration.

Four properties of the producer become properties of your result, and none of them is under your control:

• The port set. Wu et al. instrumented 28 honeypots for a year and traced 1,407 scanner IPs: “20% of Shodan and ZoomEye's traffic targets 29 ports, whereas Censys scans 49 ports, and FOFA targets seven ports” [2Wu, Mengying; Hong, Geng; Chen, Jinsong; Liu, Qi; Tang, Shujun; Li, Youhao; Liu, Baojun; Duan, Haixin; Yang, Min (2025): "Revealing the Black Box of Device Search Engine: Scanning Assets, Strategies, and Ethical Consideration", in: Proceedings of the Network and Distributed System Security Symposium. (Link)]. Against Izhikevich et al.'s finding that protocol deployment is diffuse [izhikevich2021_identifying], a fixed port set is a systematic, one-directional undercount of exactly the insecure tail.
• The vantage point. The same study traced every Censys scanner address it found to the United States, on enterprise ISPs. The others sit elsewhere and on different kinds of network: 67% of ZoomEye's and 72% of FOFA's addresses are in China, FOFA on cloud ISPs and ZoomEye on consumer ISPs, while Shodan mixes enterprise and cloud — 24.69% of Shodan's addresses are in the Netherlands and 19.17% of FOFA's in Finland [2Wu, Mengying; Hong, Geng; Chen, Jinsong; Liu, Qi; Tang, Shujun; Li, Youhao; Liu, Baojun; Duan, Haixin; Yang, Min (2025): "Revealing the Black Box of Device Search Engine: Scanning Assets, Strategies, and Ethical Consideration", in: Proceedings of the Network and Distributed System Security Symposium. (Link)]. A dataset collected from one country inherits every geographic blocking and geo-differentiation effect on Crawling location — you simply cannot see them, because you have one vantage point and no control.
• The cadence. “Not scanned all ports once a day” means the record you read has an age, and the age varies by port. If your claim is temporal, you are reading a smear, not a snapshot.
• The labels. A CVE tag, a device type, a “known software” label is a classifier the producer runs, and it has a precision. In a ground-truth experiment with 43 deployed Docker instances, Huang et al. measured Shodan at 85.71% precision and 75.00% recall and ONYPHE at 80.00% precision for the CVEs each tracks [huang2025_trust]. Their conclusion is directed at us: “the widespread use of banner-based vulnerability detection in academic work is problematic”.

Coverage is not a property you can assume, and it is cheap to check. Sethuraman et al. compared the ANT/ISI IPv4 census with Censys for July 2021: 118M addresses in both, but 268M unique to the ANT census and 92M unique to Censys — the two agree on only about a quarter of the addresses either sees [sethuraman2022_ipv4]. VanderSloot et al. did the equivalent for certificates and found that aggregated CT logs and Censys snapshots “encompass over 99% of all certificates found by any of these techniques” while still missing 1.5% [6VanderSloot, Benjamin; Amann, Johanna; Bernhard, Matthew; Durumeric, Zakir; Bailey, Michael D.; Halderman, J. Alex (2016): "Towards a Complete View of the Certificate Ecosystem", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] — the lesson there is not the 99% but that they had to compare four perspectives to know it.

A dataset is not a thing, it is a sequence of things. “We used Censys” identifies a company, not data. What identifies data is producer + product + snapshot date (or version) + the query.

Of the 2,534 papers whose provenance is an existing dataset, this is what they state — with papers that ran a live crawl as the comparison:

1,097 of the 2,534 (43.3%) give neither a first nor a last date for data they did not collect. This is the reverse of the archive result on Archives, where papers date their data better than live-crawl papers because the date is the point. Here the date belongs to somebody else, so it goes unrecorded — and it is the one thing a reader cannot recover.

It matters because reused data is old. Taking the venue year minus the last date of the data, for the papers that give a parsable year:

17.8% of dateable reuse papers describe a world at least three years older than their venue year, against 2.7% of live-crawl papers. Much of that is legitimate — a longitudinal or historical study should have old data. The problem is that you cannot tell which is which for the 43.3% that give no dates at all, and a three-year-old snapshot presented in the present tense is a different paper from one that says so.

Three from the corpus, all Censys, all checkable — and one counter-example:

• “We use the Censys snapshot of this dataset that was collected on April 24th, 2018, which contains 489,580,002 certificates” — producer, product, exact date, size.¹⁾
• IMC 2016's Towards Better Internet Citizenship gives both the volume and the count — 4.1 TB derived from 28 full IPv4 scans obtained from censys.io — and, for its accuracy simulation, the window and the cadence: monthly snapshots from 09/2015 to 03/2016, seven of them. Range and count, so a reader knows what one data point is.²⁾
• “We queried Censys on February 13, 2017.” — the query date, which is what you actually control.³⁾

And the counter-example, from the same corpus and the same service: “We analyzed TLS handshakes using the data provided at censys.io.”⁴⁾ That sentence cannot be reproduced, compared or dated. It is not an outlier: 43.3% of the 2,534 existing-dataset papers have no first or last date recorded for their data at all.

The second irreproducible half. A snapshot plus a query is a dataset; a snapshot alone is a shelf.

1. Publish the query text, not a description of it. A Censys or Shodan search string, a BigQuery SELECT, a CT log filter, a jq expression over a JSONL dump — these are short, and they are the method. Put them in the artifact, not only in prose.
2. Say which fields you read and which you ignored. “Hosts with TLS” is ambiguous across a producer's schema versions; a fully qualified field path — Censys's legacy 443.https.tls.version, or its v3 equivalent — is not. Name the schema generation as well as the field, because the two do not use the same names.
3. Say what you deduplicated on and at what level. Host, IP, (IP, port), service, certificate, eTLD+1, package name — these give different Ns from the same query, and the difference is often larger than the effect you are reporting.
4. Say what you excluded. Cloud ranges, CDNs, parked domains, non-2XX responses, apps below a download threshold. Exclusions move headline percentages more than most modelling choices.
5. Pin the version of the producer's schema or API. Censys's current interface is the Platform API v3 at https://api.platform.censys.io/v3/, and the older Search API is being retired;⁵⁾ code written against the old Search API in a 2019 paper does not run today.

Only 42.9% of the 2,029 papers that drew their population from a pre-existing dataset name a version for it — indistinguishable from the 43.0% corpus-wide rate for any population list, and below the 57.1% of papers that took an exhaustive population and the 49.3% that took a top-n. Versioning is not harder here; it is just nobody's job.

Almost every reuse study is a join: this scan corpus against that domain list, this APK set against those store listings, these certificates against that ranking. The join key is where the study silently changes population, and the corpus cannot measure it for you — so this section is practice, not a figure.

• Name the key and its cardinality. IP, (IP, port), domain, eTLD+1, registered domain, host, certificate SHA-256, APK SHA-256, package name, ASN. A one-to-many join inflates your N; the inflated N is the one that ends up in the abstract.
• Both sides must be normalised the same way. Trailing dots, IDN vs punycode, www. stripping, case, port defaults, IPv6 zero-compression. Two spellings of the same key are a silent left-anti-join.
• The join is a filter. Report the size of both inputs and the size of the result. “We joined A with B” without three numbers hides an arbitrary sample.
• A domain is not a site and an IP is not a host. Turning either into an organisation or a category is its own instrument with its own error rate: IP classification for addresses, Website classification for domains. Do not treat a lookup as a fact.
• Time is a join dimension. Joining a 2024 scan to a 2021 domain list produces a population that existed at neither moment. If the two sides have different dates, say so and say which one your claim is about.
• Do not join on a label produced by the same vendor on both sides. Correlation between two of a producer's own derived fields tells you about their pipeline, not about the world.

The commonest existing dataset in this literature is not a service, it is somebody's released crawl or scan. It is also the one with no documentation team behind it, and the corpus shows two reasons to treat it carefully: 9 of the 60 residue strings hand-audited in the next section name a prior paper's dataset by citation rather than by name — the reader has to chase a reference to find out what the data even is — and only 57.7% of the 3,389 reuse papers release an artifact of their own (against 61.1% of the crawled population), so the chain usually stops with you.

Before you build on one, establish five things, and put the answers in your methods section:

1. Does the deposit still resolve, and is it the version the paper used? A GitHub repository moves; a DOI does not. If the artifact is a repository, record the commit, not the URL.
2. Is it their whole population or their filtered one? Papers routinely release the analysed subset rather than the collected set. Your denominator is then their exclusion rules, which are in their prose and not in their tarball.
3. What are the collection dates of the data, as opposed to the paper's publication year? They are usually only in the paper. Carry them forward — this is the field that section Which snapshot is about, and it is lost at exactly this hand-off.
4. Are the field semantics written down anywhere but the paper? A column called third_party encodes somebody's definition of third party. If you do not reproduce their definition, you are measuring a different thing under their column name.
5. Are you allowed to redistribute it? Many corpora are licensed for the recipient only, which decides whether your own artifact can include the join or only the code that performs it.

And the thing a re-analysis cannot recover: re-running their measurement is not the same as re-analysing their file. Demir et al. ran a web measurement over 4.5 million pages with 24 different setups and conclude that “slight differences in the experimental setup directly affect the overall results” [7Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)]. A released dataset is one setup's output. You inherit it whole — its browser, its vantage point, its interaction depth — and no amount of re-analysis reveals how much of your result is that setup. If your claim depends on that, you need your own collection. Longitudinal is the page for doing it twice on purpose.

Of the 3,389 reuse papers, 2,919 (86.1%) name at least one source. Those names are free text, so they are folded into families before counting and counted by paper; the fold rules and the full residue are on existing_datasets.

Four further scopes exist in the fold and are counted but not tabulated here, because they are not what this page is about: adjacent reused data — social and UGC dumps (216 papers), blockchains (99), code hosts and package registries (92), leaked-credential corpora (39), scholarly indexes (33), the Enron email corpus (27), official statistics (25), privacy-policy corpora (14) and underground-forum corpora (10); benchmarks — ML datasets (307) and software or fuzzing suites (60); explicit industry or partner data (55); and authors' own or unnamed sources (79). All of them, with their raw-spelling counts, are in the report output on existing_datasets.

Three things in that table are worth more than the ranking itself.

Nothing is big. The largest family is named by 3.2% of reuse papers. That table is the complete Internet/web/security scope of the fold — nothing is truncated off the bottom — and it accounts for only 853 of 3,389 papers (25.2%); 367 (10.8%) name an ML or software benchmark suite instead, which is what a broad security corpus looks like. There is no shared substrate here comparable to Tranco for website selection or EasyList for tracker labelling.

Censys is named by 51 papers and Shodan by 9, which is a fact about publication, not about quality — Shodan is a commercial product with an academic tier, Censys began as a research project and runs a research-access programme. Do not read the ratio as an endorsement.

The tail is one-off and mostly not reusable. Across the 2,919 papers that name something, there are 5,103 distinct raw strings, 4,782 of which appear exactly once, and only 59 appear in five or more papers. After folding, 3,192 strings (62.6%) match no family at all, and 3,162 of those are named by a single paper. A hand-audit of a 60-string random sample of that residue (full classification on the provenance page) came out:

Split those last two carefully, because they are not the same problem. 10 of 60 (17%) name data a reader cannot obtain at all — commercial telemetry, a partner's logs, an anonymised industry feed. A further 9 (15%) are identifiable only by chasing a citation: they may be perfectly downloadable once you find them, but the paper's own text does not say what the data is. Data reuse in this literature is not the same thing as shared public infrastructure. Plan for that: when you build on a dataset, check that a reader can still obtain the exact thing you used, and if they cannot, deposit what you can.

That obligation is not being met either. 1,954 of the 3,389 reuse papers (57.7%) release an artifact link of their own, against 61.1% of the crawled population and 56.7% of the corpus. Re-analysis is not passing more data on than crawling does.

Checked on 2026-08-28 by fetching each primary source. A 2018–2022 methods section is not a working recipe; several of these routes have closed or changed hands.

What is in this table and what is not. It lists sources from the table above whose access route has changed since roughly 2020, plus Pushshift — which is out of this page's scope as a data source but is the clearest example of a whole method going away. A source is absent because its access route is unchanged, not because it is unimportant: VirusTotal (51 papers) and the vulnerability databases (76) are absent for that reason, and label quality for the first is Website classification. This is not a directory.

A methods paragraph a reader can act on, in this order. The first four are the ones the corpus says are usually missing.

1. Producer, product and snapshot. Not “Censys” but “the Censys Universal Internet Dataset snapshot of 2026-03-14”. Not “AndroZoo” but “the AndroZoo index as of 2026-03, apps with dex_date in 2024”.
2. The query, verbatim, in the artifact. Search string, SQL, filter expression, API call with parameters.
3. The producer's parameters that bound your claim — port set, vantage point, scan cadence, list source, inclusion rule — as far as the producer documents them, and a sentence saying which ones you could not establish.
4. Dates: collection and query. When the producer collected it, and when you pulled it. They are different, and only the second is under your control.
5. The join: key, normalisation, size of each input, size of the result.
6. Deduplication and exclusion rules, with the N before and after each.
7. A validation slice. Something you checked against a second source or against your own collection, with the agreement rate. One number, and it is the difference between “we used Censys” and a defensible claim.
8. Where your derived data lives, so the next paper joins to yours rather than re-deriving it. See the OSF warning above and Artifacts.

For an archive rather than a scan corpus, start from Hantke et al. [9Hantke, Florian; Calzavara, Stefano; Wilhelm, Moritz; Rabitti, Alvise; Stock, Ben (2023): "You Call This Archaeology? Evaluating Web Archives for Reproducible Web Security Measurements", in: Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pp. 3168–3182. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] and Singh et al. [10Singh, Sachin Kumar; Mahmud, Faisal; Ricci, Robert; Siby, Sandra (2026): "The Empire Strikes Back (at Your Privacy): An Archaeology of Tracking on Government Websites", Proceedings on Privacy Enhancing Technologies 2026(2):108-126. (DOI)] on Archives — the anachronism trap described there (today's classifier over yesterday's data) applies to every dataset on this page, not only to archives.

Figures are from scripts/report_existing_datasets.mjs over the 5,859-paper extraction of CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026. Every claim is a claim about those seven venues. 2025–2026 venue-years are provisional — CCS and IMC 2026 have not been held, and IEEE S&P and WWW 2026 are under-selected by construction.

Flat. Re-analysis is not a trend, it is a constant of this literature — which is an argument for treating it as a first-class design with its own reporting standard, rather than as the thing you say when you did not crawl.

Share of that venue's own output:

• Populations. Every table names its own denominator. “All 5,859 papers” is used only where the field applies to every paper. The reuse population (3,389) is the union of three fields and the core (1,292) is their intersection; both are given because the difference between them is a finding, not a rounding error.
• studyTypes is the least stable field in the schema — 57% run-to-run on a 100-paper sample, measured on the previous corpus and not re-measured on this one. It is one of the three fields in the union, so the union inherits that instability, and the core does too since it requires all three. Read both as ranking-grade. Of the three, only temporal.mode has a measured stability figure (69% on that same sample); population.samplingMethod is an enum but was not in the stability comparison, so nothing is claimed about it.
• Sentinels are never answers. not-stated and none-mentioned are counted as silence, and silence is reported as itself.
• Counts are of papers, never tuples. A paper naming Censys four times is one paper.
• Free-text dataset names were folded into families before counting, by an all-matches rule so that one string naming four sources counts for all four. The fold and its 3,192-string residue are published in full on existing_datasets, along with the hand-audit of the residue sample.
• Quotes were spot-checked. 40 evidence quotes behind the dataset-family and old-data figures were matched against paper.cols.txt; all 40 located (24 exact after whitespace collapse, 14 via an 8-word run, 2 via a 5-word run).
• Data age is approximate. It is the venue year minus a 4-digit year parsed from spanEnd, so it is granular to a year and inherits the venue-year convention. 28 existing-dataset papers had a spanEnd with no parsable year and 1 had a year after its venue year; both are excluded and reported rather than absorbed.
• Every query, the report script and its unedited output are on existing_datasets; corpus-level caveats are on Corpus.

• Automated measurements — the router: crawl, scan, app analysis, and why re-analysis is none of them.
• Archives — the archive as a recording, and the anachronism trap that applies to every dataset here.
• TLS certificates — CT and scan data when the question is the web PKI.
• Website selection / Sampling — ranking lists as an existing artefact you query.
• IP classification / Website classification — turning a join key into a claim.
• Mobile and app measurement — AndroZoo and the store corpora.
• Longitudinal — pinning a dataset version so wave two is comparable to wave one.
• Artifacts — depositing the derived data so the next paper joins to yours.
• Corpus — venue scope, funnel, provisional years.
• existing_datasets — every query, the report script, the folds and the residue.

[2]

Wu, Mengying; Hong, Geng; Chen, Jinsong; Liu, Qi; Tang, Shujun; Li, Youhao; Liu, Baojun; Duan, Haixin; Yang, Min (2025): "Revealing the Black Box of Device Search Engine: Scanning Assets, Strategies, and Ethical Consideration", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[3]

Durumeric, Zakir; Adrian, David; Mirian, Ariana; Bailey, Michael D.; Halderman, J. Alex (2015): "A Search Engine Backed by Internet-Wide Scanning", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[6]

VanderSloot, Benjamin; Amann, Johanna; Bernhard, Matthew; Durumeric, Zakir; Bailey, Michael D.; Halderman, J. Alex (2016): "Towards a Complete View of the Certificate Ecosystem", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[7]

Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)

[8]

Durumeric, Zakir; Adrian, David; Stephens, Phillip; Wustrow, Eric; Halderman, J. Alex (2024): "Ten Years of ZMap", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[9]

Hantke, Florian; Calzavara, Stefano; Wilhelm, Moritz; Rabitti, Alvise; Stock, Ben (2023): "You Call This Archaeology? Evaluating Web Archives for Reproducible Web Security Measurements", in: Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pp. 3168–3182. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[10]

Singh, Sachin Kumar; Mahmud, Faisal; Ricci, Robert; Siby, Sandra (2026): "The Empire Strikes Back (at Your Privacy): An Archaeology of Tracking on Government Websites", Proceedings on Privacy Enhancing Technologies 2026(2):108-126. (DOI)