Certified backups

What a certified backup is

Every Text2Store backup already records a checksum of everything it captured, so the app can tell later whether a file has changed. A certified backup adds one more thing at the exact moment that checksum is written: it sends a fingerprint of it to an independent Timestamping Authority (DigiCert, using the open RFC 3161 standard) and stores the signed reply alongside the backup. That reply is a trusted witness that the backup existed, exactly as captured, at that specific time. Nothing about the backup itself changes: same files, same speed, same everything, just one small file added.

It is a property of the archive (the saved backup on your computer), separate from a verified export (the .zip you hand someone). The two work together, see below.

Turning it on

Certification is a checkbox on the backup dialog, Certify this backup, and it is on by default. The choice sticks: once set, it applies to every future backup on that computer, including the ones with no dialog (Archive now, a menu-triggered backup), until you change it. There is nothing to configure per device or per backup beyond that.

You need an internet connection at the instant a certified backup is made, one small request sends only a 32-byte fingerprint, never your messages or files. If you are offline, or the timestamp service happens to be unreachable, Text2Store does not fail the backup or fake a certificate. It finishes the backup normally, keeps it (a backup is too valuable to throw away over a missing timestamp), and tells you plainly: "Backup saved, but not certified." The archive is complete and safe; it will just stay an ordinary, uncertified backup. To get a certified one, back up again once you're online.

What the checkmark means

Certification shows up as the same small badge everywhere: a rosette seal with a checkmark. It is deliberately quiet, a fact about the backup's provenance, not an alert, so you will see it in three places:

• In your list of backups, a small gray checkmark badge sits beside a certified archive's date, the same weight as the lock icon shown on an encrypted one. Hovering it explains: "Certified backup: its creation time is anchored with a trusted timestamp."
• Under a conversation list, when the open backup is certified, the same badge appears in green with the words "Certified backup," beneath the conversation and message counts.
• In the Verified Export dialog, the badge appears again, colored to match the claim: green and "From a certified backup" when the source archive is certified, gray and "Verified as of today" when it is not. See below for what that difference actually means for the export.

What it proves

An ordinary backup can already tell you, later, whether a file has changed since the backup was made, but the record it checks against lives right next to the files it protects. Someone with access to the raw files could, in principle, edit one and quietly regenerate that record to match. A certified backup closes that gap by putting the witness outside anyone's reach: the timestamp is signed by DigiCert's private key, which nobody except DigiCert holds, not you, not Text2Store, not an attacker. Regenerating the local record after the fact changes its fingerprint, which no longer matches the sealed timestamp, so the mismatch is caught.

That is what answers "you could have edited the messages after you backed up, then handed this over," the same way a verified export's timestamp answers "you edited this after you exported it," just anchored two steps earlier: at backup time instead of export time.

Why it can only happen at backup time

Certification cannot be added to a backup after the fact, and Text2Store will never offer a way to do that. A timestamp obtained later only proves the backup existed later, which is exactly the gap certification exists to close. So the checkbox lives in one place, the backup dialog, and nowhere else. If you have an important backup that was not certified, the only path is to make a fresh one with the box checked.

How it strengthens a verified export

Certification does not gate verified export: you can still export a tamper-evident .zip from any backup, certified or not, and it stays exactly as useful as it always was. What changes is how far back the export's proof reaches.

• From a certified backup: the export carries the backup's own creation-time timestamp forward, so the export's chain of proof reaches back to when you backed up, not just when you exported. The certificate inside the export states this plainly: attachments are byte-for-byte identical to a backup trusted-timestamped on that date, and the transcript was extracted from it.
• From an uncertified backup: the export is timestamped as usual at export time, and is exactly as tamper-evident as before. It just cannot speak to what happened between the backup and the export, because nothing witnessed the backup itself. The export honestly says so: "Verified as of today. This backup wasn't certified when it was made, so integrity before today isn't attested."

Either way, the export is real and independently verifiable; certification only ever adds an earlier anchor, it never takes anything away.

That "byte-for-byte identical" claim isn't taken on faith from the original certification event. Before building an export from a certified backup, Text2Store independently re-checks the backup's messages database, its file index (which attachment belongs to which message), and the other records the export depends on, against the backup's own integrity baseline, right then, not just once back when the backup was made. A change to any of them after certification is caught and the export refuses to build, rather than silently carrying forward a certified badge that no longer matches what's actually in the backup.

What it does not prove

The same honest limits that apply to a verified export apply here, one step earlier:

• That the phone wasn't manipulated before the backup. Certification anchors "unchanged since Text2Store captured it," not "the device was truthful when it was captured."
• How it will be received. Text2Store never claims a certified backup or the exports made from it will be accepted by any particular recipient or process. What weight a record carries is always the recipient's decision. See the verified export page for the full discussion.
• Anything about a backup made before this feature existed, or one where the box was left unchecked. Certification is never retroactive, by design.

The technical anchor

Certification uses the same open standard as verified export, RFC 3161 trusted timestamps signed by DigiCert, and the same in-app verifier checks it: it re-hashes the backup's integrity record, confirms the signature chains to DigiCert's pinned root, checks it was valid at the attested time, and reports the result. The mechanism, the standard, and how to check it entirely by hand with standard tools are documented in full on the verified export page's technical section, since both features share the identical verification code and the identical trust anchor.

Troubleshooting

"Refusing to build a verified export: … no longer matches this archive's integrity baseline …"

The pre-export check described above found that one of the files a certified backup depends on has changed since it was certified, possibly bit-rot on the disk it's stored on, possibly tampering. The export is refused rather than built from an archive that no longer matches what was certified. Click that archive's own Verify button for the same diagnosis with more detail. If it turns out to be bit-rot, a fresh backup gives you a clean, newly-certified copy; the affected archive and your other archives are otherwise unaffected.

"… it's no longer on disk."

A file the backup's own integrity record expects is missing, most often something was deleted from inside the archive's folder by hand. As above, Verify that archive for detail, and back up again if you need a certified copy of that device.

Questions?

Email hello@text2store.com and we'll help.