What Non-Native Digital Artefacts Can—and Cannot—Establish

Share this post

Screenshots, forwarded messages, PDFs, copied files and platform downloads often arrive in a case before the original device, native file or complete metadata is available. They may appear clear and persuasive. The practical question is what the artefact can reliably establish, what it cannot establish on its own, and what further acquisition or corroboration may be needed.

The central distinction is between content and provenance. A non-native artefact may preserve or depict content in a particular form. It is generally weaker evidence of who created the underlying content, when it was originally created, whether it was edited before capture, or how it travelled through a platform or system.

For litigators and investigations professionals, that distinction should shape both acquisition priorities and the language used in reporting.

Content is not the same as provenance

A screenshot can depict text or images in the rendering contained in the file received. A PDF can preserve visible text, images and certain container-level metadata. A platform export may contain structured messages, timestamps, identifiers and associated media. A forwarded email may retain some message content and visible headers.

These may be useful findings. They should not automatically be extended into conclusions about original authorship, original creation time, account ownership or server-side activity.

Non-native artefacts are often rendered, converted, copied or exported representations. During those processes, metadata may be rewritten, removed or replaced with information about the new file or operation. Server-side records, authentication events, delivery logs and other context may not be included.

A defensible examination should therefore describe the artefact received, the information it contains, how it was obtained and the limitations that remain. Those technical findings should remain separate from legal conclusions about admissibility, intent or evidentiary weight.

Screenshots and photographs of screens

A screenshot generally captures pixel output: a visual rendering contained in the received file. It normally does not preserve the original device’s filesystem-level metadata or the platform’s server-side provenance. Metadata found in the screenshot file may describe that file or aspects of the device or file-generation process; it does not necessarily describe the native content displayed.

A bounded statement might be:

The file contains a rendering of the specified text or images, and the supplied bitstream has the recorded SHA-256 digest.

That statement does not, without separate support, establish when the screen was captured, what device or application state was present, that the content was displayed on a live device, or that the rendering was not altered before the file was supplied. Those matters require independent capture context, reliable provenance or other corroboration.

Screenshots can be edited locally, re-rendered or produced by photographing a screen. These possibilities do not establish that a particular screenshot was manipulated. They do mean that image-forensic analysis should be treated cautiously. Detector outputs are probabilistic, depend on the relevant editing or recapture pipeline and require appropriate validation, versioning and error-rate information before supporting a high-confidence conclusion.

Where the original source is unavailable, useful preservation steps include retaining the supplied file unchanged, recording its cryptographic digest, documenting how and when it was obtained, and seeking the same content from the native device or platform. Overlapping screenshots may help document continuity of a visible sequence, but they do not replace acquisition of the underlying source.

Platform exports and downloads

Vendor-provided archives may be more informative than isolated screenshots because they can provide structured data such as messages, timestamps, identifiers and attached media. Their contents, formats and included fields vary by vendor and version. A user archive should not be assumed to contain server-side logs, IP addresses, complete delivery records or deleted material.

The relevant question is not whether an export is “official” in the abstract. It is what the particular export process states that it contains, what it omits, and how the file was obtained and preserved.

An archive may support a finding that its manifest contains particular messages or timestamps. Without further evidence, it may not establish that the export is a complete account history, that the account was controlled by a particular person at the relevant time, or that a timestamp represents the server event required for a chronology conclusion.

Where the issue is important, platform preservation, provider-held material or another acquisition mechanism may be options to consider. Their availability and suitability depend on the platform, retention conditions, applicable authority, jurisdiction and the advice of the relevant legal and provider-process advisers. No single route is universally available or appropriate.

PDFs, printed documents and exported files

A PDF may contain text, images and metadata associated with the PDF container, such as a document producer or modification time. An embedded image may also contain EXIF or XMP fields. Those fields should be treated as metadata of the examined container or embedded object as received unless the origin, preservation and transformation history of the metadata can be demonstrated.

Conversion through a save-as operation, virtual printer, embedding process or re-export can rewrite or remove fields. Extracted metadata therefore does not necessarily belong to the original capture or native file.

The PDF should be preserved as received and its supplied bitstream recorded. If it was generated from a native export, the native export and relevant export settings should be requested. Where image provenance is material, available cryptographically signed provenance, such as C2PA Content Credentials, may provide corroboration if the credentials can be verified and their signer chain understood.

C2PA credentials do not establish that content is factually true. They record asserted origin and edit history through a cryptographically signed manifest. Their absence is not proof of manipulation, because adoption across devices, platforms and toolchains remains incomplete.

Forwarded messages and copied files

Forwarding and copying can change an item’s evidential characteristics. A forwarded email may retain only the headers preserved by the forwarding application. Routable headers, including some Received information and originating details, may be missing or obscured. A file copied to a new filesystem may acquire local metadata reflecting the copy operation.

A visible timestamp on a forwarded message or copied file may therefore relate to forwarding, saving or export rather than to the original event. It should not be treated as a definitive creation time without corroboration from the native message, original device or relevant server records.

Raw messages, mailbox or native exports and provider records are distinct artefacts. They may preserve different content, headers and transmission context and should not be treated as interchangeable. Where available, investigators may seek the form most relevant to the question being tested, including a raw message or mailbox export for email and separate provider records where transmission or account activity is material. This is a bounded operational recommendation, not a statement that any particular record will be available or legally obtainable.

If only a forwarded message is available, its provenance limitations should be stated clearly and tested against independent material such as account records, related communications, recipient devices or system logs.

Chronology and authorship

Chronology and authorship are claims most likely to exceed what a static artefact can support.

A screenshot may depict a rendering consistent with the claimed capture, but it normally cannot establish on its own when the underlying content was originally created. A copied file may preserve internal metadata while acquiring new filesystem timestamps. A platform export may contain timestamps whose meaning depends on the vendor’s format and processing. A forwarded message may omit the headers needed to reconstruct transmission history.

A name, account identifier or writing style visible in an artefact may be relevant, but it is not the same as independently verified account control or creation of the underlying content. Attribution generally requires corroboration, which may include account-control evidence, authentication events, server records, recipient devices, witness evidence or other independent system records.

Combining independent sources can increase confidence, but it does not remove the need to explain assumptions, gaps and uncertainty. Technical findings should remain separate from legal conclusions about authorship, intent or admissibility.

Integrity: preserve first, interpret second

When an item is received without its original source, its evidential position cannot usually be repaired retrospectively. The immediate objective is to preserve what was actually received and create a transparent record of subsequent handling.

The acquisition record should identify, where available:

who obtained the item, when and how;
the custodian’s account of the device, application or process used;
device identifiers and capture conditions;
the original supplied file or bitstream;
the tools and versions used to calculate a digest;
the recorded digest, preferably including SHA-256; and
each subsequent access, processing step or transfer.

A recorded hash supports comparison or fixity of the preserved bitstream after hashing. It does not establish that the bitstream was complete, unaltered before hashing, accurately collected or representative of the underlying event. It therefore does not prove authenticity, provenance or accurate representation of a native artefact. Fixity must be considered together with acquisition context and provenance analysis.

The role of forensic detection tools

Image and media forensic tools can identify indicators associated with manipulation, splicing, copy-move operations, generated content or recapture. Such methods have error rates and may be affected by recompression, recapture and anti-forensic techniques.

A detector result should be reported as a probabilistic technical finding, not conclusive proof. A defensible report should identify the tool, version, parameters, validation material, relevant test conditions and known limitations. Claims that a detector proves manipulation, origin or attribution require technical validation under conditions relevant to the matter.

Pixel-level analysis alone should not be used to attribute creation or authorship to a named individual without server-side or other independent corroboration.

A practical decision sequence when originals are unavailable

When the original device, native file or complete metadata cannot immediately be obtained:

Preserve the submitted artefact unchanged and record a strong cryptographic digest.
Record how, when and by whom it was obtained, including the device or environment where available.
Consider whether platform, custodian-device or provider-held material should be sought through the applicable process, recognising jurisdictional and retention limitations.
Obtain independent corroboration, such as another message copy, a recipient device, system records, network logs or other relevant evidence.
Inspect available metadata and provenance credentials, without treating their presence or absence as conclusive in isolation.
If forensic detection tools are used, document their versions, parameters, validation evidence and uncertainty.
Report what the artefact contains separately from what it may suggest about source, chronology, authorship or intent.

This approach does not make a non-native artefact equivalent to a native acquisition. It makes its evidential limits visible and helps decision-makers identify the next most valuable acquisition step.

An IVIDENTIA perspective

Non-native digital artefacts are not automatically useless, and they are not automatically conclusive. Their value depends on the question being asked.

They may preserve or depict content in the form supplied. They are generally weaker for establishing provenance, the integrity of the original source, chronology and authorship without additional evidence. The disciplined response is to preserve the item, document its handling, consider appropriate re-acquisition and corroborate material conclusions through independent evidence streams.

For litigation and investigations teams, the key question is whether the proposed conclusion is proportionate to what the artefact and its provenance can actually support.