How to verify this site.

Current state: the C2PA signing infrastructure is designed and the cert chain is built. The public-trust step runs through Adobe's Content Authenticity Initiative sponsorship process, which is a six to eight week timeline from here. Three parallel paths are in flight: through IMS, through TruePE, and as an individual contractor through the Adobe AIOS programme. One of them lands. Until then, the verifier reads untrusted issuer on the embedded manifest.

What lands when the cert arrives: every static image in /public carries an embedded C2PA manifest verifiable via the canonical standard (spec v2.3, January 2026). The signing identity is a CAI-chained leaf bound to truepe.co.uk with the emailProtection extended-key-usage. The manifest declares author, publisher, training-mining position (not allowed), and the honest AI-collaboration assertion. The manifest verifies cryptographically and the issuer-trust badge reads green because the chain terminates at a root on Adobe's public trust list.

Why the deferral is honest, not a workaround: this is the same pattern the open data initiative followed in its first window of opportunity, where the public verification layer arrived later than the infrastructure beneath it. Designing the protocols and being honest about which steps are live, which are in process, and which are weeks away is itself the testament-grade discipline the site is here to demonstrate.

PDFs — V04, not V03. The publicly distributed c2patool binary lacks the PDF handler (it's behind a c2pa-rs feature flag). For V03 we sign PNGs and explicitly skip PDFs with an honest log line at build time. PDF signing path for V04 is either Adobe PDF Services (PAdES + C2PA sidecar) or c2patool with the PDF feature flag enabled when it ships in the public release.

Authentication on this site is WebAuthn — hardware-bound credentials, no shared secret in transit, no link in your inbox to leak via Referer. The credential lives on your device's secure element (Touch ID, Windows Hello, a FIDO2 security key). The server holds only your public key + a sign counter.

First-party identity. The user identifier in our store is a random UUID, not your email. The email + display name you enter at registration are first-party metadata so Ian knows who submitted; they are never the authentication primitive.

Device-binding, honestly. If your platform syncs passkeys (iCloud Keychain, Google Password Manager) your credential follows your account. If it does not (a hardware key, a non-syncing browser profile) the passkey is bound to that device. Be honest with yourself about which model you are in — there is no third option, only the truth about your authenticator.

Session model. A successful ceremony issues a short-lived (30 min) HttpOnly + Secure + SameSite=Strict session cookie, signed by a rotating server secret. The session does not extend automatically; if you come back tomorrow, you authenticate again. Hardware-bound, expiring, cryptographic — the three legs of the Anthropic Zero-Trust frame applied to a contact form.

Submissions are written to an append-only log in Vercel KV. No in-place edits, no deletes. Right-to-be-forgotten requests are honoured by appending a tombstone entry pointing at the original record — the deletion event itself becomes part of the log. Retention is 24 months. See the legal page for the full retention shape.

HSTS, strict CSP, X-Frame-Options DENY, COOP / CORP same-origin, Permissions-Policy with WebAuthn allow-list and Topics / FedCM disable-list. Inspect the Response Headers tab on any page to verify. The CSP keeps 'unsafe-inline' only as long as Next 14 hydration needs it; V04 migrates inline scripts to nonces.