Consent

Check a consent receipt

Type a receipt id. Your own browser looks it up in a published snapshot of our consent chain and checks that the chain around it links up. Nothing you type is sent to us, and no account is needed.

Everyone in this market says their footage is rights-cleared. This is the page where you check ours instead of taking the sentence on trust — and where, today, the published chain is empty because no recording has been made against a commissioned brief.

Type a receipt id above, then choose Check it.

Nothing is published yet, and this is why

0

0 · None Receipts publishable under the two rules below. Nothing is hidden and nothing failed to load — there is genuinely nothing here yet.

That is a deliberate zero, not an empty page.

Two rules decide what may appear here. Both are enforced by the builder rather than by anybody remembering, and either one alone empties the list today.

Rule one — the wording must be the corrected wording

Every receipt records what we told the person we would do to their footage, and that sentence is hashed into the record. An earlier version of it named a redaction tool we do not run, claimed licence plates were covered when they are not, and described a product rather than what our code does. Receipts written before that correction still carry it.

They cannot be corrected. Each record's hash covers that wording, and every later record's hash covers the one before it, so rewriting history is either a broken chain or a silent re-hash — which is exactly the tampering this ledger exists to expose. So they are excluded by what they contain, and no future change of date or mind can quietly let them through.

Rule two — the ledger must be one we have committed

The only consent ledger that exists today sits on a developer's machine and is not part of our published code. Every row in it is a test fixture. Publishing one would invent a consent record for a person who never gave one, which is a worse thing to do than publish nothing.

Rule two is what empties the page today. Rule one is written anyway, because it is the rule that still holds on the day a real ledger exists.

What this page can and cannot tell you

Four fields are held back from every published record, because they name a real person and the device they used. That has a consequence worth stating rather than glossing.

It can check linkage. Each record carries the hash of the one before it. Your browser walks that sequence and reports any point where it does not hold. That needs none of the withheld fields.

It cannot recompute an individual record's hash. That calculation needs all the fields, the withheld ones included. A page claiming otherwise would be the dishonest half of an honest mechanism.

The exact fields, the order they are joined in, and the character between them are all carried in the snapshot itself, so the specification cannot drift from the code that implements it.

This snapshot was published on . It carries receipt(s).

What the digest is, and what it is not

The snapshot carries a SHA-256 digest over its entries. That lets you tell whether the file you are reading is the file we published, if you already know the digest.

It is not a signature. Nothing here is signed with a key, and nothing is anchored to an external timestamp — so the digest proves the file is internally consistent, and it does not prove that we produced it or when. Anyone who could replace the file could recompute the digest.

That is a real limit and it is ours to close, not yours to work around. We would rather name it than let the word “verify” in the address bar do work the code has not earned.

How the consent ledger works · Every number we publish