why-fieldwitness.md: Plain-language narrative for non-technical audience (journalists, grant reviewers). Opens with local government scenario, explains the evidence gap, positions FieldWitness against existing tools, includes three usage scenarios and technical appendix. packaging-strategy.md: Four-tier packaging plan ordered by feasibility for a solo developer. Hosted demo first (8-12h effort), standalone binary second, mobile app with grant funding, browser extension last. Includes onboarding flow, pricing model, and strict sequencing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
13 KiB
Why FieldWitness Exists
Audience: Non-technical first (journalists, editors, grant reviewers, advocates), with a technical appendix for developers and security reviewers.
The problem
A journalist covering local government photographs a leaked budget document showing irregularities in public spending. She publishes the story. Six months later, the city's attorney writes a letter: "That photograph is fabricated. There is no evidence it existed before your article."
The journalist has the photo on her laptop. The file has a date stamp, but anyone with basic computer skills can change a file's date. She has it in iCloud, but Apple's timestamps prove when the file was uploaded, not when it was taken, and certainly not that it hasn't been altered since. She emailed it to her editor -- but that only proves she sent something to her editor, and both parties are considered interested. The metadata inside the photo could establish when and where it was taken, but metadata is trivially editable and routinely stripped by every messaging app and social media platform.
She has no proof. Not because she fabricated anything, but because none of the tools she uses were designed to prove she didn't.
This is not a war-zone problem. It is an every-newsroom problem. It happens at school board meetings, city council sessions, county commissioner hearings, and state legislature corridors. It happens every time a public official decides the easiest defense is to attack the evidence rather than address the substance.
Why existing tools fail
Cloud storage (iCloud, Google Drive, Dropbox). These services record when a file was uploaded and synced. They do not prove a file's contents haven't changed. The timestamps belong to the cloud provider, not the journalist, and can be subpoenaed, disputed, or simply unavailable if the journalist changes services.
Email. Emailing yourself a file creates a record that something was sent at a certain time, but email headers are not cryptographically signed in a way courts consistently accept. And you're trusting Google, Microsoft, or whoever runs your mail server to testify on your behalf.
Signal, WhatsApp, encrypted messaging. These tools protect the privacy of your communications. They do not create verifiable records of what was communicated. Signal's disappearing messages are the opposite of evidence preservation. These tools solve a different and equally important problem.
The Wayback Machine. Useful for web pages, useless for photographs, documents, and files that were never published online.
ProofMode (Guardian Project). The closest existing tool to what FieldWitness does. ProofMode is Android-only, designed for individual use, and does not handle multi-reporter workflows or cross-organization chain of custody. It is a good tool solving a narrower problem.
C2PA (Content Authenticity Initiative). An emerging industry standard backed by Adobe, Microsoft, and the BBC. Primarily designed for camera manufacturers and publishing platforms -- not for field journalists working offline. FieldWitness is building a bridge to C2PA so that attestations can be exported in the industry-standard format (see the technical appendix).
None of these tools answer the question a lawyer actually asks: "Can you prove, to a standard a court would accept, that this file existed in exactly this form at the time you claim, and that it has not been altered since?"
What FieldWitness does
When you attest a file with FieldWitness, it creates a cryptographic fingerprint that proves the file existed in this exact state at this exact time, signed with your identity. That proof is chained to every other attestation you have ever made, so tampering with one means tampering with all of them. The proof can be independently verified by anyone using the free verification tool -- no FieldWitness account or installation needed.
The key properties:
- Tamper-evident. If a single byte of the file changes, the fingerprint breaks and verification fails.
- Time-anchored. Each attestation is chained to all previous attestations in sequence. External timestamps (from independent timestamping authorities) can anchor the chain to a provable point in time.
- Identity-bound. Each attestation is signed with the journalist's cryptographic identity. The signature proves who attested the file without exposing their device, location, or personal information.
- Independently verifiable. FieldWitness produces self-contained evidence packages -- ZIP files with the original file, the attestation record, and a standalone verification script. A court, a lawyer, or a colleague can verify the evidence with nothing but Python installed. No FieldWitness account. No internet connection. No trust in any third party.
- Works offline. Every core function works without internet access. FieldWitness was built for environments where connectivity is unreliable, monitored, or dangerous.
Three scenarios
1. Solo journalist protecting their evidence
Maria covers local government for a Substack newsletter. She attests every photo, document, and recording she collects. Her attestation chain grows over time, creating a continuous, tamper-evident record of her work. When a source's leaked memo is challenged, she exports an evidence package and hands it to her lawyer. The lawyer runs the verification script and confirms: this file was attested on this date, signed by Maria's identity, and its fingerprint is intact.
Maria does not need to understand cryptography. She opens FieldWitness in her browser, uploads a file, and clicks "Attest." The hard part is already done.
2. Newsroom with multiple reporters
A regional newspaper has five reporters covering a corruption investigation. Each reporter attests their own evidence. The newsroom runs an organizational FieldWitness server that collects and indexes all attestations. When the newspaper needs to produce evidence for a legal proceeding, it can export a complete, verifiable chain of custody showing which reporter attested which file, when, and that nothing has been altered.
The reporters work independently. The organizational server provides backup, coordination, and the ability to share verified evidence between reporters without breaking the chain of custody.
3. Cross-organization coalition
Three NGOs are documenting the same environmental disaster in different regions. Each organization runs its own FieldWitness server. Through federation -- a system where servers synchronize attestation records with each other -- they can verify each other's evidence without any central authority. When Organization A attests a water sample photograph and Organization B independently attests satellite imagery of the same site, both attestations can be presented together with a provable timeline and independent verification.
Federation works over the internet when available, or via physical USB transfer when it is not. The system was designed for exactly this kind of decentralized, trust-nothing collaboration.
What FieldWitness does NOT do
FieldWitness does not protect your communications. Use Signal, Wire, or another end-to-end encrypted messenger for that. FieldWitness protects evidence, not conversations.
FieldWitness does not anonymize your internet activity. Use Tor or a VPN for that. FieldWitness can operate entirely offline, but it does not hide your network traffic when it is online.
FieldWitness does not replace a lawyer. It produces evidence that is cryptographically verifiable, but whether a court accepts that evidence depends on jurisdiction, the judge, and the legal arguments made. FieldWitness gives your lawyer better evidence to work with.
FieldWitness does not require internet access. It was built for environments where internet access is unavailable, unreliable, or actively dangerous. Every core function -- attestation, verification, evidence export -- works on an air-gapped laptop.
FieldWitness does not store your files in the cloud. All data stays on your device (or your organization's server). Nothing is sent anywhere unless you explicitly choose to federate with a partner organization.
The deeper technical story
This section is for developers, security reviewers, and grant evaluators who want to understand the cryptographic foundations. If you are a journalist evaluating FieldWitness, you can safely skip this -- everything above is the complete picture of what the tool does for you.
Cryptographic primitives
- Ed25519 digital signatures bind each attestation to a specific identity. Ed25519 is the same signature scheme used by Signal, SSH, and WireGuard.
- SHA-256 cryptographic hashes fingerprint file contents. Any modification, no matter how small, produces a completely different hash.
- Perceptual hashes (pHash, dHash) for images enable verification even after an image has been re-compressed, resized, or screenshotted -- common when evidence passes through messaging apps.
Append-only hash chain
Every attestation is recorded in an append-only hash chain -- a structure where each record includes the hash of the previous record. This means altering any record in the chain would break the hash linkage of every subsequent record. The chain is encoded in CBOR (a compact binary format) and can be independently verified without FieldWitness.
Merkle tree verification
The chain supports Merkle tree consistency and inclusion proofs. These allow a third party to verify that a specific attestation is part of the chain without needing to download the entire chain -- important for large-scale deployments with thousands of attestations.
External timestamp anchoring
FieldWitness supports RFC 3161 timestamping, the same standard used by Adobe, DigiCert, and other certificate authorities. A single external timestamp for the chain head implicitly timestamps every preceding record, because the chain is append-only.
C2PA bridge
FieldWitness is building export capability to the C2PA (Coalition for Content Provenance and Authenticity) standard. This means FieldWitness attestations can be embedded in images in the format that Adobe, Microsoft, and the BBC use for content provenance -- enabling interoperability with the broader industry ecosystem.
Gossip federation
For cross-organization deployment, FieldWitness servers synchronize attestation records using a gossip protocol. Servers periodically compare their chain state using Merkle roots. When they detect divergence, they exchange only the missing records. This design requires no central coordinator, works over intermittent connections, and supports offline synchronization via USB transfer.
Field security features
For high-risk deployments, FieldWitness includes a killswitch (emergency data destruction), a dead man's switch (automated purge if check-in is missed), tamper detection, USB device whitelisting, and GPS geofencing. These features exist because some users work in environments where being caught with evidence is more dangerous than losing it.
For the full threat model and security architecture, see docs/security/threat-model.md.
Current status and what is needed
FieldWitness is a working prototype. The core attestation system, hash chain, federation protocol, and field security features are implemented and tested. It runs as a Python command-line tool and a web application.
What works today:
- File attestation with Ed25519 signatures and SHA-256/perceptual hashing
- Append-only hash chain with Merkle verification
- Self-contained evidence packages with standalone verification
- Cross-organization federation (gossip sync and offline USB transfer)
- Emergency data destruction (killswitch and dead man's switch)
- Cold archive export for long-term evidence preservation
- Web UI for all core operations
What is needed:
- Security audit. The code has not been independently audited. For a tool that journalists may rely on in adversarial conditions, an audit is a prerequisite for responsible deployment. An application to the Open Technology Fund's Red Team Lab (which commissions free audits through firms like Cure53 and Trail of Bits) is planned.
- Packaging for non-developers. FieldWitness currently requires Python and pip to install. This excludes the vast majority of the target audience. A hosted demo instance, standalone desktop applications, and eventually a mobile app are needed to reach working journalists. See the packaging strategy for the roadmap.
- C2PA export. Bridging to the industry standard for content provenance is in progress. See the C2PA integration plan.
- Field testing. The tool needs to be used by real journalists in real workflows to identify usability problems, missing features, and incorrect assumptions.
- Institutional review. Organizations like the Freedom of the Press Foundation, the Electronic Frontier Foundation, and the Committee to Protect Journalists have the expertise and credibility to evaluate whether FieldWitness meets the security bar for their constituents.
FieldWitness is open source (GPL-3.0) and welcomes collaboration -- from code contributions and security review to feedback on whether this tool solves a problem you actually have. The most valuable contribution right now is honest criticism from people who work in journalism, human rights documentation, or digital security.
Source code: github.com/alee/fieldwitness