Verify identity claims before expanding trust or access

Build an identity-claim ladder instead of a single trust score

Start with what the app actually establishes. A stable profile may show that the same account has returned, while a badge may show that a platform checked a defined attribute at a particular time. Neither automatically confirms a job title, relationship, emergency, outside account or current control of the profile. Write each claim on its own line and label it platform-observed, sender-stated, independently confirmed or unresolved. eSafety describes catfishing as the use of a fabricated online identity and notes that thin or inconsistent profile history can be a signal, not conclusive proof. The practical question is not “Is this person real?” but “What claim must be true before I take this specific next step?”

Read requested actions as stronger evidence than a friendly tone

Look for a change in the requested action: moving immediately to another service, keeping the exchange secret, sharing a home or work routine, adding an account as an administrator, sending private images, revealing a one-time code, paying a fee, opening a file, or introducing more contacts. One signal alone may have an ordinary explanation, so avoid public accusations. Several changes clustered around urgency and reduced visibility justify a pause. Familiar details are not proof; Europol explains that information gathered from public profiles and messages can be combined into convincing contact. A warm conversation should never override the permission boundary you would apply to an unfamiliar request.

Verify through an independent route and reveal as little as possible

Choose a channel already known to you: a saved number, an official directory, a previously established group, or the organisation’s site reached independently. Do not use the phone number, profile link, support address or “verification” contact supplied in the same conversation. Ask only what is needed to confirm the claim; do not send an identity document merely to make the other person prove theirs. The FTC warns that displayed caller identity can be falsified and advises checking with the real person or organisation using independently obtained details. If verification remains unavailable, keep the relationship at its existing access level rather than filling the gap with personal data.

Set a social permission boundary before sharing

Define separate limits for profile visibility, direct messages, files, location, contact discovery, group invitations, external accounts and real-world arrangements. A useful rule is progressive access: one necessary permission, for one stated purpose, for a reviewable period. Declining a request should not require a long explanation. Never share passwords, recovery links or authentication codes, and do not grant device control or account administration to establish goodwill. For an in-person plan, use the ordinary safeguards you would choose for any new contact and tell a known person your plan; the app should not present a digital badge as a substitute for your own boundary.

Preserve a minimal evidence card, then use product controls

Before blocking, when doing so is safe, record the platform, profile URL or in-app identifier, displayed name, date and time, the relevant request, and any report reference. eSafety’s evidence guidance lists platform, URL, usernames and timestamps as useful context. Capture only what supports the report; avoid forwarding the conversation widely or keeping unnecessary private media. Use the app’s report category that best matches impersonation, unwanted contact or deceptive requests, then mute, restrict or block according to the situation. A report is not a promise of removal or identity discovery, so keep its confirmation and check whether profile visibility changed.

Test controls without creating a fake persona

Use your own test account or a consenting test partner. Check whether a new contact can see your full profile, whether a declined request stays declined, whether blocking removes message and discovery access, and whether reporting explains what data will be sent. Do not impersonate another person, bait strangers, upload copied photos or attempt to uncover someone behind an account. Record app version, device, setting, expected boundary and observed result. Repeat after changes to discovery, group invitations, identity labels or blocking. This bounded test provides product evidence while preserving the very social boundaries the checklist is meant to protect.

Keep exploring this topic