Document and metadata authenticity analysis

Under the Canada Evidence Act and section 34.1 of Ontario's Evidence Act, the party relying on an electronic document must prove its authenticity, and integrity is shown through the system that recorded or stored it. A forensic analysis provides evidence on both points.

Questions we are asked to examine include:

• Was this contract, minute or memo created on the date it bears, or later?
• Was a clause added or changed after the document was signed or sent?
• Is this PDF a faithful copy of the original, or was it edited?
• When was this photograph taken, and has it been manipulated?
• Who authored or last edited the document, and on what system?

Office documents, PDFs and images carry internal metadata: author and last-modified-by names, created and modified dates, total editing time, revision numbers, the application and version that produced the file, and, for photos, camera details and sometimes GPS location (EXIF data). Inconsistencies are often revealing; a document dated 2019 that was produced by software released in 2022 needs an explanation.

Embedded metadata is also easy to change and is changed innocently all the time. Templates carry the original author's name forward, 'Save as' resets some dates but not others, and PDF printers record the conversion time rather than the drafting time. A finding based only on embedded metadata is weak, and a careful report will say so.

Documents stored in SharePoint, OneDrive or Google Drive usually have server-side version history that the user cannot easily alter: each saved version, with the time and the account that saved it. The Microsoft 365 unified audit log (searched through Microsoft Purview Audit) and Google Drive audit events add records of file creation, modification, download and sharing, subject to their retention limits.

These sources are often decisive. If a document said to have been signed in March first appears in version history in September, the question largely answers itself. We collect version history through eDiscovery or admin exports so it can be verified, rather than relying on screenshots.

Where the document was created on a computer we can examine, the operating system adds another layer, consistent with the approach in NIST SP 800-86. Windows NTFS file systems keep multiple sets of timestamps for each file, plus a change journal; macOS keeps comparable records. Recent-file lists, shortcut files, application caches, backup copies and print logs can place a document on a device at a particular time.

Comparing these system records with the document's internal metadata is how backdating is usually detected. Changing a computer's clock or editing metadata leaves traces in other places, and those traces rarely all line up.

Our reports separate what the evidence shows from what it is consistent with. 'The file was first saved to the user's OneDrive on September 14' is a finding. 'The document was therefore created in September' is an inference that depends on whether earlier copies may exist elsewhere, and the report says so.

Conclusions are graded: consistent with the stated history, inconsistent with it, or not determinable from the available evidence. Where the report is for court, it is prepared to meet the applicable expert evidence rules.

1. 01

   Keep the original file and where it came from

   The native file is essential. A printout or a re-saved PDF loses most of the evidence.

2. 02

   Don't open and save

   Opening a document in an editor can change its metadata. Copying it by drag-and-drop can change file system dates.

3. 03

   Preserve the source system

   The laptop, cloud account or email where the document lived holds the corroborating evidence. Place holds on cloud accounts and set devices aside.

4. 04

   Collect forensically

   We collect native files, version history and device images with hash values and a chain-of-custody record, following ISO/IEC 27037.