Reference
For lawyers, data-protection officers, courts, and journalists — not engineers. Every entry: a plain explanation, a courtroom analogy, and why it matters for evidence.
Every day, MachineWitness visits a large, fixed list of European websites and records what they tell machines: whether a site reserves its content against AI training (robots.txt, ai.txt, TDM headers), which AI crawlers declare which identities, and what AI providers' terms of service say. Each recording is sealed cryptographically the same day, anchored outside our control, and (as the architecture is completed) confirmed by a second independent witness. Years later, the archive answers exactly one question: "What did X serve to machines on date Y?" We record. We do not interpret, accuse, or judge.
A single recording of a single web resource at a single point in time: the exact bytes the server delivered, plus when, to whom, and how.
Analogy: one page in a notary's daybook.
Disputes are always about a specific date — not "what does the file say", but "what did it say on 14 August 2027".
A fingerprint of digital content: a short fixed-length code computed from the exact bytes. Change one character and the fingerprint changes completely; it is practically impossible to craft a different document with the same one.
Analogy: a fingerprint that identifies one specific document version, not just the document.
Every snapshot's fingerprint is what gets sealed and anchored; comparing fingerprints later proves the content is unaltered.
Every payload is filed under its own fingerprint — the fingerprint is the filing number. Identical content, even across days or sites, is stored once and referenced many times.
Analogy: an evidence locker where the label on the box is the fingerprint of what is inside — nothing can be swapped in without the label ceasing to match.
Retrieval by fingerprint makes tampering self-evident.
With every snapshot we seal the circumstances of delivery: the full HTTP response headers, the site's TLS certificate chain, the observing server's IP address, and the timestamp — all hashed into the same sealed record as the content.
Analogy: chain-of-custody notes stapled to the evidence bag — who collected it, where, when, from whom.
It ties content to source: not merely "this file existed", but "this server delivered this file".
A method of sealing thousands of records with a single master fingerprint. Each snapshot's fingerprint is combined pairwise, level by level, until one root remains that depends on every record beneath it. That daily root is what we anchor and publish.
Analogy: a bound, numbered evidence volume with one wax seal on the cover — the seal vouches for every page at once.
We follow the construction style of RFC 6962, the standard behind the public logs browsers use to audit TLS certificates. One short code per day commits us, irreversibly, to everything we recorded that day.
A short mathematical receipt showing that one specific snapshot is contained in a given daily root. Anyone can check it, without trusting us and without access to the rest of the archive.
Analogy: proving one page belongs to the sealed volume by matching its position against the cover seal — without reopening every other page.
This is what makes a single evidence extract independently verifiable.
Publishing each daily root outside our own control, the same day: into the Bitcoin blockchain via OpenTimestamps, and to an independent RFC 3161 time-stamping authority.
Analogy: depositing a sealed copy with a notary the day it was written.
A hash in our own database proves nothing — we could recompute it. An anchor in systems we cannot rewrite proves the seal existed no later than that day.
A second recording system, on different infrastructure with a different operator key, observes the same targets independently. Both daily roots are compared and published.
Analogy: two witnesses who took their own notes and are cross-examined separately — matching testimony is qualitatively stronger than one witness repeating himself.
This addresses the strongest objection against any single archive operator: "you could have fabricated your own records."
Each day our public root log is additionally captured by systems we do not control (the Internet Archive's Wayback Machine; a public git repository with provider timestamps).
Analogy: the newspaper archive that happens to have printed the notice — nobody claims the newspaper conspired.
When a justified erasure request under the GDPR concerns archived content, we delete the plaintext payload and leave a marked "tombstone" in its place. The fingerprint, the seals, and all proofs remain intact and verifiable.
Analogy: a redacted page in the evidence volume — the page is blacked out, but the binding, page number, and cover seal prove the volume was never rebound.
It reconciles two duties that seem to conflict: the right to erasure and the integrity of evidence.
The technical ways a website tells machines "do not use my content". Under Art. 4 of the EU DSM Directive, a rights-holder's reservation against text-and-data-mining must be machine-readable to be effective; the Hamburg Higher Regional Court confirmed in December 2025 that natural-language terms alone are insufficient. These files change silently and leave no trace — recording them daily is the core of this archive.
The deliverable: for a given resource and date range, a package containing the raw payload (or its tombstone), the sealed provenance, the fingerprints, the inclusion proof, the daily root, and the external anchor receipts — with step-by-step verification instructions any technical expert can follow independently.
Stating limits precisely is part of being a credible witness:
We are the flight recorder, not the investigator.