Skip to main content

Collect

TECHNIQUE
📖11 min read
BagIt: Transferring Content for Digital Preservation (Library of Congress, 2009)
Why this old video is here

A 17 (!) year old video. I just had to include it: it is so beautifully retro that it would be a crime (no pun intended) not to show it.

Introduction​

This is Stage 1 of the Research Gate. Define set the baseline; this stage is the first practical step. It puts the sources your reconstruction will be based on into your hands and on the record.

The stage has two jobs. Document every source, whatever its mode of arrival: one evidence log entry each, in chain-of-custody form. Capture the sources that can disappear: a sealed capture, fixed in time, that a third party can verify without trusting your word.

CRITICAL: Nothing you capture is evidence yet. What you do to a source in the first hour determines whether it can be considered evidence later.

The evidence log

One record for every source: what it is, where it came from, when you got it. The chain of custody starts with the first entry.

Seal the volatile

Some sources disappear. Capture now, hash it, pin it in time with an independent timestamp, and record who did it.

Stand on a standard

RFC 3161, BagIt, ISO/IEC 27037, SWGDE: the anchors and containers that let anyone else verify what you captured.

What this page is, and is not​

This page is not a guide to finding data. Finding data is OSINT work, and there are many other resources that do that job well. This page starts one step later: you have data, now what do you do with it? Document it. Check it. Protect it. That is the purpose of this page.

Define set the baseline: why you capture what you capture. Collect is the first practical step: getting the data your reconstruction will be based on into your hands and on the record.

How you get the data​

Projects get their data in three ways:

  • Collect it yourself. You seek the source: an archive request, a download, a field capture.
  • Receive it. Someone hands it to you: a client's files, a tip, a court submission, a forwarded video.
  • A hybrid. Both, in the same project.

The mode does not change what this stage requires. A received file gets the same documentation and the same checks as one you collected, and usually more of them, because you did not watch it come into existence.

The mode is also not fixed at the brief. Data received on day one does not end the collection: you do not have all the data you will need at the beginning, and new sources can matter even deep into the project. Collection is ongoing, not a one-time step.

From a project I worked on

I got a brief, and I was given some data with it. It turned out there was more data out there that I could use, so I collected it myself, on top of what I had been handed, even while I was already in the reconstruction phase: more information on a car, another angle on a building. The evidence log does not distinguish between the two. Every source gets the same record, whatever its mode of arrival.

The stage itself​

This is Stage 1 of the Research Gate. Collection is where you acquire sources and document them. It is read-only characterization, not transformation. The dividing rule: if you are recording or deciding about a source, it belongs here; if you are modifying it, that belongs to process.

Enter the stage with a working assumption: nothing is trustworthy yet, and nothing you capture is evidence yet. What you do to a source in the first hour determines whether it can be considered evidence. Keep one chronological record of every source, the evidence log: what the Berkeley Protocol[1] and evidence practice generally call chain of custody, where each source came from, how it was obtained, and that it hasn't been altered.

Preserve & Store is the second half of this one: the moment data arrives, you document it (this page) and protect it (preserve-store).

The original-file gate​

The first practical question for any source: can you find the original file? Copies of images and videos are easy to make, and every copy loses metadata. Reverse-image search compares the pixels of your copy against indexed copies on the web; archive snapshots preserve the page that carried the source. If you cannot trace a copy back to an original, note that in the evidence log: it lowers what the source can support.

Capturing a Source​

Your source may be a link, not a file: a video on a platform, a post, a page, a photo on a service. A brief can say "this video is your source" and hand you a URL. The first act is to make it something you have.

This page does not teach you how to download it. It tells you what to do so that what you captured can be considered evidence. That is a preliminary question, separate from the question of whether the data is authentic: verify examines it later and issues the verdict. Here you only make sure it can be put forward.

Some sources are gone by the time you leave: a deleted post, a corrected article, a closed chat. For these, and for any link you capture, the capture itself must be able to stand up later.

A sealed capture is the captured data plus the records that bind it to its origin and its moment: what exactly was captured, where it came from, when, and by whom, fixed at the moment of capture, so that a third party can verify it later without trusting your word.

When you put a captured image forward as evidence, three objections usually surface:

  1. The date. A computer clock can be set by hand. A screenshot carries no certain date of its own.
  2. The integrity. Anyone can edit that image in minutes. Who can say that a line was not deleted from that chat?
  3. The origin. A crop hides the address, the profile, the page. Where exactly does this come from?

Whatever the source, the handling is the same. Eight steps:

Capture now· at discovery

At the moment of discovery, not later. If it can disappear, it may be gone by the time you think about it.

Hash before anything else· before you touch it

SHA-256 of the captured file before you process it, rename it, or move it: the hash of what arrived, not of what you did to it.

Pin it in time· RFC 3161 / OpenTimestamps

A timestamp from an independent authority (RFC 3161[2] or OpenTimestamps[3]), not the local clock.

Name the operator· who, what, when

Who captured it, with which tool, when. Write it on the artifact itself, not only in your notes.

Log everything, never delete· append-only

The evidence log is append-only. A correction adds a row; it does not rewrite the old one.

Store it safely· master and working copy

The vault and the working copies: preserve-store.

Leave a verifier behind· their own machine

A reviewer must be able to re-hash and compare on their own machine, without your tools. The capture tools below and BagIt bundles ship an offline verifier for exactly this.

Keep the record factual· no interpretation

Only what you observed. No interpretation in the evidence record; interpretation is what analyze is for.

A sealed capture answers the three objections. It records:

  • The content: the exact page, post, or chat at the moment of capture.
  • The origin: the full URL, plus the platform domain and TLS certificate, which tie the content to that site at that moment.
  • The date: a timestamp from an independent time-stamping authority (RFC 3161[2]), not the local clock.
  • The fingerprints: a battery of hashes (SHA-256 at minimum; the full battery of MD5, SHA-1, SHA-256, SHA-512 survives a challenge to any single algorithm).
  • The custody: who captured it, with which tool, when, written in the evidence log.

Tools that do the recording for you​

What you get from a capture tool is the record: every step above leaves one.

  • Forensic Capture (UserSearch): free browser extension (Chrome, Edge, Firefox). Captures the whole page: a stitched full-page image, a DOM snapshot, an MHTML archive, the raw HTTP response, optionally a screen recording. Hashes each artifact locally, combines the hashes into one master fingerprint, signs them, and anchors them to RFC 3161 and the Bitcoin blockchain; only the anonymous hashes leave the device. The custody timeline is append-only and carries your operator identity. Exports PDF or BagIt bundles with an offline verifier. A free UserSearch account (email only) is required to create captures[4].
  • Witness: open-source Chrome extension, same core: SHA-256, RFC 3161 timestamps from independent authorities, tamper-evident hash chain, all local, no vendor lock-in[5].
  • ProofSnap: proprietary capture, open-source verifier. RSA-4096 signatures, OpenTimestamps Bitcoin anchoring, and (enterprise) eIDAS qualified timestamps; forensic mode keeps the full network archive[6].
  • Auto Archiver (Bellingcat): open-source Python tool for batch archiving. Give it a list of URLs (command line, CSV, Google Sheets) and it archives web pages, social media posts, images, and videos, appending a status record of what it archived, when, and how to a CSV or the original sheet. Self-hostable; Bellingcat also runs a shared instance. Bellingcat launched it in 2022; it has since preserved over 150,000 pieces of online evidence[14][15].

The tool you choose matters less than what it leaves behind: artifacts, hashes, independent timestamps, a custody record, and a record someone else can check.

The standards behind this practice​

The field has spent decades writing the rules down, and the standards overlap: they agree on a baseline (record where the data came from, never alter the original, fix it in time, verify it by fingerprint) and they differ in the details. Knowing what each one covers tells you which standard to abide by when.

StandardWhat it isWhat it covers here
RFC 3161[2]A trusted time-stamping authority signs a file's fingerprint with its own timeThird-party dates for volatile captures. In the EU, a qualified RFC 3161 timestamp carries a legal presumption of exact date under eIDAS[12]; the protocol profile is defined in ETSI EN 319 422[13]
ISO/IEC 27037:2012[7]International guidelines for the handling of digital evidenceThe four verbs of the whole pipeline: identify, collect, acquire, preserve
SWGDE 18-F-002 v2.0 (2025)[8]Working-group best practice for collecting items that contain digital evidence (computers, storage media)The care rules: collect without altering, and document how
BagIt, RFC 8493[9]A standard package for digital evidence with a built-in manifestThe handover archive: data, manifest, and metadata in one verifiable folder
CASE[10] / UCO[11]Community ontologies (machine-readable vocabularies) for describing digital investigationsHow to describe evidence and custody steps so other analysts and tools can read them

They point at different moments of the same pipeline: RFC 3161 fixes when, ISO/IEC 27037 orders the phases, SWGDE sets the care rules for devices and media, BagIt makes the handover verifiable, and CASE/UCO make the description machine-readable. When two standards give different advice, follow the one closest to your actual artifact: for a web capture, RFC 3161 plus BagIt; for a disk image, SWGDE plus ISO/IEC 27037.

Mark sealed sources in the evidence log: sealed (hash + third-party timestamp) versus noted only. A volatile source that is only noted is weak: if it disappears, you cannot show what it said, and the claim it supported stands on nothing.

Summary​

This stage turns "here is some data" into a documented starting point: every source on the record, and every volatile source captured so it can stand up later.

Key takeaways:

  • One log, every source. Every source gets one evidence log entry (what it is, where it came from, when you got it), whether collected, received, or hybrid. The log is append-only.
  • Ask the gate question. Can you find the original file? If you cannot trace a copy back to an original, record it: it lowers what the source can support.
  • Seal the volatile. Capture now, hash before you touch anything, pin it in time with an independent timestamp, name the operator, and leave a verifier someone else can run.
  • Stand on a standard. RFC 3161 fixes the date, BagIt packages the handover, ISO/IEC 27037 orders the phases. When two standards disagree, follow the one closest to your actual artifact.

The stage ends where Preserve & Store begins: the moment data arrives, you document it here and protect it there.

Resources​