Text messages as evidence

A screenshot of a conversation proves that someone had a phone and a camera. What separates an exhibit from a screenshot is being able to say where the messages came from, that they have not changed since, and what was left out.

What a court is actually deciding

Two different questions get collapsed into the word "admissible", and keeping them apart is most of the work.

902(14) covers data copied from an electronic device where the copy is authenticated by digital identification — in practice, a hash — described in a certification by a qualified person. It removes the need to call a witness to say the copy is a copy. It does not decide relevance, hearsay, or whether the messages come in at all.

Any tool that tells you its output is "court admissible" is describing a decision it does not get to make. What a tool can do is produce a copy and describe it accurately enough that the question becomes easy to answer.

Why a hash is the part that matters

A SHA-256 digest is a 64-character fingerprint of a file. Recomputing it over the same file gives the same value every time; changing a single byte — one character in one message — gives a completely different one. That is what makes it useful: it is not a claim that the file is unaltered, it is a value anyone can check for themselves.

Which is why the digest has to be taken over the source database, not over the PDF. A hash of the PDF proves the PDF has not changed since it was made, which nobody was asking. A hash of the chat.db or sms.db it was made from lets the other side take the same file, run the same command, and get the same answer.

shasum -a 256 messages.db      # macOS and Linux
certutil -hashfile messages.db SHA256   # Windows

What every CertifiedCopy export states

The first page of every PDF, and the header rows of every CSV, carry the same block:

• The source file's name and byte size.
• Its SHA-256 digest.
• When the export was produced, in UTC and in local time.
• The version of the tool that produced it.
• The conversation, and every participant as both display name and raw handle.
• The number of messages included.
• The date range requested and the range actually found. Those differ whenever a conversation does not span the whole window, and stating only the request would imply coverage that is not there.

The last one is the one people miss. An export labelled "January to June" that in fact contains nothing after March is not wrong, but it invites a question that is much easier to answer before it is asked.

Do this before you export anything

1. Stop the device changing. Messages get deleted, edited and unsent. An export records what is there when you take it, not what was there last month.
2. Keep the source file. The digest in the export is only checkable against the file it was computed from. Archive the chat.db or the backup folder alongside the PDF, unmodified.
3. Export the whole conversation, then narrow. A range chosen first and widened later looks like a range chosen to suit. Produce the full thread, keep it, and derive any narrower exhibit from the same source.
4. Note what is not in it. Attachments live outside the messages database. Deleted messages are usually gone. Messages in iCloud may never have reached the backup at all — see reading an iPhone backup.

Questions that get asked about digital exports

Nothing is uploaded. The database is read in your browser and the PDF is built there too.