Security & architecture

Truth-Check answers a simple question: how do you prove that a photo or video truly existed, in this form, at a given date, place and from a given device? A file alone proves nothing — its EXIF metadata is trivially editable.

Our approach: at capture time, the app collects the media and its context (date, GPS coordinates, device model, resolution), then creates a timestamped, frozen record on the server. That record receives a unique verification code and becomes publicly viewable. The proof therefore does not depend on the file you are handed, but on an independent server record.

Creation follows a deterministic path, with no algorithmic decision:

1. The app transmits the media and its metadata to the backend over an encrypted connection (HTTPS/TLS).
2. The server assigns a trusted timestamp (generated server-side, not supplied by the client) and a unique 10-character verification code, free of ambiguous characters.
3. The media is stored and the whole (content + metadata) is written to the database within an atomic transaction.
4. Once written, the record can no longer be modified by a client: only authorized server operations may touch it.

The result is a public page truth-check.com/<code> showing the proof and its context.

Let us be precise, because this is where many services overstate. Truth-Check does not currently apply a per-certificate asymmetric signature (RSA/ECDSA). So we will not talk about a 'cryptographic seal' that we do not perform.

Integrity rests on a set of very real guarantees:

• Server-authoritative record: the database security rules forbid any write or modification from a client. A certificate can only be created or altered by the backend.
• Server timestamp: the date is set by the server, not the device, which prevents back-dating.
• SHA-256 fingerprint for files issued via the API (see below), allowing any later alteration to be detected.
• Platform encryption at rest and in transit (see below).
• Public verification: anyone can inspect the original record and compare it to the file presented.

We apply a minimization logic. For a certificate, we keep:

• The media (a photo, or for video a reconstructed animated GIF — the raw video is never stored);
• The capture metadata: timestamp, GPS coordinates, device model, resolution;
• The information the user chooses to attach (holder name, email);
• The verification code, status and expiry date.

The media must remain viewable since the very purpose of the product is public verification: it is served via a non-guessable URL. We store no card data (payments delegated to Stripe and Apple).

Some data is never kept in clear, only as a SHA-256 fingerprint:

• Passwords of protected certificates: stored as salt:SHA-256 (random per-certificate salt), never in clear.
• Verified issuers' API keys: only the prefix and a SHA-256 hash are kept; the full key is shown once, at creation.
• Files issued via the Issuer API: a SHA-256 fingerprint of the file is computed server-side and stored, allowing later verification that a document has not been altered by a single byte.

For full honesty: password hashing uses a salted SHA-256 (single pass), not a slow key-derivation function such as bcrypt/Argon2. This is something we document openly.

Since we do not apply a per-certificate asymmetric signature, there is no certificate signing private key to protect — and therefore none to steal.

The platform's only sensitive secrets (Firebase Admin SDK credentials, payment provider keys, API secrets) are stored as encrypted environment variables and in the platform's secret manager, never in the source code nor exposed on the client side.

We prefer to describe precisely what exists rather than invoke an 'HSM' or a 'Cloud KMS' that we do not use for certificates.

• In transit: all communications between the app, the API and storage go over HTTPS/TLS.
• At rest: data is encrypted by the Google Cloud platform (provider-managed server-side AES-256 encryption for Firestore and Cloud Storage). This encryption is a guarantee of the underlying infrastructure, not an application layer we added — we state that clearly.

We design to limit the damage. In case of compromise:

• No signing private key can be stolen — there is none.
• Certificate passwords and API keys are only exposed as hashes, not reversible to clear text.
• No payment data is present: Stripe and Apple hold it, not us.

That said, let us stay transparent: certificates are designed to be public and media is served via non-guessable URLs — an attacker reading the database would see content already meant for public verification, together with the associated metadata. This is why we recommend only certifying what is meant to be shared.

Creating a certificate is entirely deterministic: capture → metadata → timestamped record. No language model, no generative AI, takes part in this chain.

It is a design choice: a proof must be reproducible and auditable. Making integrity depend on a statistical, non-deterministic model that may evolve would undermine the very trust we seek.

AI exists elsewhere in the product, clearly separated from certification: for example an optional transcription of a video's audio (third-party service), displayed with a disclaimer and with no effect on the validity of a proof.

This is the most important distinction to grasp.

• Truth-Check establishes a proof of provenance and integrity: this media was captured at this date, place, device, and has not been modified since. That is objective and verifiable.
• Truth-Check does not produce an algorithmic 'credibility score' such as 'this image is 87% true'. Such a score would be subjective, opaque and gameable.

In other words, we prove the context and technical authenticity, not the truth of the content — the latter belongs to human judgment, which we equip rather than replace.