Why is searching only for the suspect’s name unreliable?¶

title: Why is searching only for the suspect’s name unreliable? subtitle: The relevant data may use a nickname, contact label, account ID, telephone number or no human-readable name at all. slug: why-is-searching-only-for-the-suspects-name-unreliable series: mobile-extraction-and-reader-reports section: searching-and-preserving-results card_type: question_card content_type: foundation risk_level: normal pathway_order: 15 section_order: 2 status: draft owner: IF Digital last_updated: '2026-07-25' version: '0.1' review_gate: pending review_mode: ai-assisted review_timebox_mins: 30 qa_gate: pending qa_count: 0 pipeline_ref: PIPELINE_PRG_001 pipeline_version: '1.1' public_safe: true video_ready: true word_count: 528 estimated_read_time_seconds: 218 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - mobile evidence - name search - identity - negative result - search limitations sources: - title: SWGDE Best Practices for Mobile Device Forensic Analysis url: https://www.swgde.org/documents/published-complete-listing/20-f-005-swgde-best-practices-for-mobile-device-forensic-analysis/ - title: 'Cellebrite Reader: UFDR Report Viewer for Investigators' url: https://cellebrite.com/en/products/cellebrite-inseyets/reader/ - title: 'NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics' url: https://csrc.nist.gov/pubs/sp/800/101/r1/final

Why is searching only for the suspect’s name unreliable?¶

The relevant data may use a nickname, contact label, account ID, telephone number or no human-readable name at all.

Script¶

Searching for a person’s name is an obvious place to start.

It is a poor place to stop.

Mobile data often identifies people through accounts, numbers and internal identifiers rather than a consistent human-readable name.

A chat application may store the participant as a telephone number or account ID.

A contact may be saved under a nickname, relationship, business name or insulting label.

A conversation may display the name chosen by the device owner rather than the person’s real name.

An application may store a username that bears no resemblance to either.

Some records contain no name at all.

A call log may show only a number.

A browser record may contain an account token.

A photograph may be linked to a contact through a database reference rather than visible text.

A notification may show only part of a username.

Names also vary.

Steven may appear as Steve, Ste, Stephen or a spelling error.

A surname may change, be omitted or be stored with a title.

A person may use another alphabet, transliteration or language.

A company account may be operated by an individual without naming them.

People also deliberately disguise identities.

A drug supplier may be stored as “Plumber”.

A victim may appear under a false name used by the suspect.

An online account may use an alias shared with several people.

The reverse problem also occurs.

A common name can produce hundreds of irrelevant results.

A search for “John” may match contacts, message content, document authors, calendar entries, street names and application data.

The result count may look impressive while providing little useful attribution.

So treat the name as one identifier within a wider identity set.

Build from known information:

full name;

shortened name;

nicknames;

former names;

common misspellings;

usernames;

telephone numbers;

email addresses;

social-media handles;

account IDs;

vehicle registrations;

addresses;

business names;

and distinctive phrases.

Then use the report to discover more.

A known phone number may reveal a contact label.

That label may lead to a username.

The username may appear in another application.

A profile image may connect records that use different text identifiers.

Keep the links evidence-based.

A contact saved as “Dave” does not prove the number belongs to the Dave you are investigating.

It is evidence that the device or account associated that label with the number.

You still need corroboration from provider, account, device or contextual records.

The common mistake is:

“The suspect’s name does not appear, so they had no contact.”

The search tested whether that string appeared in the material made available to the report.

It did not test every possible representation of the person.

Another mistake is:

“The name appears 200 times, so the phone contains extensive contact with the suspect.”

The hits may be duplicated, unrelated or contained in imported address books and group data.

Review the artefact type and context.

A careful negative conclusion might say:

“No results were identified for these name variants in the available report.”

Then list the other identifiers searched and any limitation in the extraction or report.

A person is not one search term.

Search the identity as a collection of linked identifiers, and keep each link open to challenge.

A name search tests one representation of identity. It doesn’t test every account, number, device or label connected to the person.

Related questions¶

• How should I search a mobile extraction report?
• What alternative names, usernames and identifiers should I search?
• Does the absence of a message, call or application prove it wasn’t there?

Source notes¶

• SWGDE Best Practices for Mobile Device Forensic Analysis
• Cellebrite Reader: UFDR Report Viewer for Investigators
• NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics