How this record is kept

1. How an item enters the record

Each account has a private email address. Anything sent to it is received by our email provider, handed to our receiving program, and written to the record in a single step.

• The receipt time is read from our database's clock, in UTC, at the moment the entry is written. It does not come from the sender's phone or computer, and the account holder cannot set or change it.
• We keep the subject line, the message text, the address the message came from, the complete set of email headers as received, and every attachment. Message text is kept whole, including quoted and forwarded history, up to 50,000 characters.
• Each attachment is stored byte for byte as received. A file over 100 MB, or beyond the account's storage allowance, is logged with its name, size and fingerprint but the file itself is not kept, and the entry says so.
• A receipt is emailed back to the sending address with the receipt time and a link to the entry.
• We keep the message as our receiving program parsed it, not the raw email file. The one exception is an email forwarded as an attachment, which is kept byte for byte (see below).

2. Digital fingerprints

A digital fingerprint is a fixed-length code computed from content with a standard cryptographic hash function. The same content always gives the same fingerprint; any change, however small, gives a different one; and the content cannot be recovered from the fingerprint. We use the 256-bit member of the SHA-2 family of hash functions, published by NIST in FIPS 180-4, which standard tools select with the option sha256.

• File fingerprint: computed over the exact bytes of the attachment as received, before storage. To recompute it yourself: shasum -a 256 <file> on a Mac, sha256sum <file> on Linux, certutil -hashfile <file> SHA256 on Windows. The fingerprint is shown beside every file in the app and in the exported record.
• Message fingerprint: one fingerprint over the whole message as received, so that no part of it can change without the fingerprint changing. It is computed over the following text, encoded as UTF-8: the receipt time in the form YYYY-MM-DDTHH:MM:SS.ffffffZ (UTC, six decimal places); a line break; the sending address; a line break; the subject; a line break; the message text; a line break; the headers exactly as the database stores them (a JSON object). A missing part is an empty string.
• The entry's proof download includes that text exactly as stored, so the message fingerprint can be recomputed with any hashing tool and compared with the value shown in the app.
• Both fingerprints are set when the entry is written and pinned by the database from then on.

3. What is fixed, and what the account holder can change

These rules are enforced inside the database itself, by triggers that run on every change. They apply to the account holder and to our own application alike.

• Fixed from the moment of receipt: the receipt time, the sending address, the headers, the subject, the message text, the message fingerprint, each file's fingerprint and the stored file itself. An attempt to change any of these is silently reverted by the database; there is no setting, plan or support request that unlocks them.
• The account holder can add a title, notes, a category, and a place in their own filing tree. They can also set the date and time the event actually happened, which is kept separately from the receipt time and is always labelled by its source: the receipt time, the photo's own metadata, or the account holder's entry.
• Every such change is written to an append-only log with the previous value, the new value and the time of the change. The log can be read by the account holder but cannot be edited or deleted by anyone through the application.
• Entries can be withdrawn from view and restored. Both actions are logged. Nothing withdrawn is deleted; withdrawn entries are left out of the export and the calendar until restored, and stay listed on the account's withdrawn-items page.

4. Times and time zones

All times are stored in UTC. The app shows them in the account holder's chosen time zone, and the calendar files each entry under the local day in that zone. The sealed receipt time is shown in both UTC and local time on every entry.

• For photographs, we read the capture time the camera embedded in the file. When the account holder has not set an event date, the entry is filed under that capture time, and the entry says the date came from the photo.
• Three cases are shown for a photo: an original camera capture with the device named; a file edited after capture, with the software that last saved it; or no camera details at all. The third case is normal for screenshots, downloads and images from messaging apps, and is never treated as a sign of anything.
• The receipt time is when an item reached us, which may be long after the event. The event time is the account holder's statement, and is labelled as such.

5. Independent timestamps

Once a night we ask two systems outside our control to certify that the fingerprints received that day existed at that moment. This shows a fingerprint existed before the stamp, and that neither the account holder nor we could have altered the item since without the proof failing.

• Each fingerprint is first combined with a random 16-byte value, so no fingerprint can be identified from the proof. The results are built into a hash tree whose single top value, the root, stands for all of them.
• The root is sent to a public RFC 3161 timestamp authority (currently DigiCert, with Sectigo and FreeTSA as fallbacks). It returns a signed token stating the time, which we store.
• The same root is submitted to the OpenTimestamps calendars, which commit it to the Bitcoin blockchain. That proof completes within hours and from then on depends on no company, including the timestamp authority and us.
• Every entry offers three downloads: a proof document listing its fingerprints, random values and the path to the root; the timestamp token; and the ledger proof. The document spells out the commands to check each of them with standard tools (openssl ts -verify for the token, the OpenTimestamps client for the ledger).
• Checking a proof needs neither our cooperation nor our continued existence.

6. Original emails forwarded as attachments

An email forwarded in the normal way becomes part of the account holder's own message, so what we can show is that the account holder sent us that text at the receipt time. An email forwarded as an attachment arrives intact as its own file, and most sending systems sign their outgoing mail (DKIM). We check that signature.

• We read the stored bytes of the attached original, find each signature, fetch the signing domain's published key from DNS, and check the signature against the headers and body it covers. The result is recorded once and never updated, together with the DNS record used, so the check can be repeated after the sender rotates keys.
• “Signed by example.com, unchanged since” means the sending domain's mail system signed these exact headers and this exact body and both still match. It does not by itself prove which person wrote the message; that is a matter for the sending domain.
• “No sender signature” is common and says nothing about the message. “Could not be confirmed” usually means an email app rewrote the message when saving it; the file is still kept exactly as it reached us.

7. Where the record is kept, and who can reach it

Database and sign-in: Supabase, London region. Website and processing: Vercel, London region. Email receiving and file storage: Cloudflare. Data is encrypted in transit (TLS 1.3) and at rest (AES-256).

• Every table is protected by row-level security: a signed-in account can read only rows that belong to it. This is enforced by the database, not by our application code.
• Links to stored files are signed and expire after 15 minutes.
• Our own processes that need wider access (receiving mail, the nightly timestamp job, the signature check) run on servers only. Their credentials are never sent to a browser.
• Sign-in is by a single-use link emailed to the account's address. There are no passwords.
• We do not read records. The single exception, where we have good reason to believe an account is being used unlawfully, is set out in full in our Terms.

8. Export, deletion, and what outlives deletion

The account holder can export the whole record, or a single entry, as a PDF at any time. The export carries, for each entry, the receipt time in UTC, the event time in the account holder's time zone, the sender, the message text, every file's name and fingerprint, the independent-timestamp line and, where present, the result of the original-message check.

• Deleting an entry or an account permanently erases the readable record: files, messages, notes, arrival details and everything that identifies the account holder, from live systems and from backups as they cycle out.
• One thing is kept: an anonymous list of file fingerprints with the day each first arrived. It identifies no one and cannot be turned back into a file. It exists so that a file the account holder still holds can later be confirmed as the one that arrived on that day.
• Nightly timestamp batches are kept. A deleted entry's leaf is removed with it; the batch root on its own reveals nothing about any entry.
• The deletion schedule is set out in the Privacy Policy: four months of read access after a subscription ends, with reminders, before deletion; inactive free accounts reminded and then deleted.

9. What we do not do

• We do not alter, re-encode, compress or “clean up” anything received.
• We do not track anyone inside the app. Public pages carry a cookie-free count of visits and nothing else.
• We do not make claims about how a record will be treated by any court, tribunal, employer or authority. A record kept this way answers the question “how do we know this was not changed later?”; what it shows about the events is for the reader to weigh.
• We do not vouch for the truth of anything in a record. We vouch for when it reached us and that it has not changed since.

10. Changes to this page

• Version 1, 5 November 2026: first publication. Covers receipt, fingerprints, fixed fields and logged changes, times, independent timestamps, original-message verification, storage and access, export and deletion.