Collection is bidirectional. Most investigators are burned not by a clever adversary but by a platform doing exactly what it advertises: telling the subject who looked at their profile, suggesting the investigator to the subject as someone they may know, or marking a story as viewed. The default failure is not a leaked IP address. It is being logged into a real account.

OPSEC effort should be proportionate. Answer three questions before you spend a day building infrastructure — or before you decide you need none.

Over-engineering costs too: a locked-down setup gets CAPTCHA'd, rate-limited and blocked, so you collect less, and unusual configurations are themselves distinctive. Blend in where blending in is the goal. And before working out how to view something safely, check whether an archive already holds it () — a snapshot tells the target nothing.

What a site or platform can learn from a visit:

Accept-Language

Logged-in accounts are the big one. Authentication converts an anonymous request into an identified one, and the leaks are features: profile-view notifications and viewer lists, story and video view lists, "people you may know" suggestions driven by contact-list and interaction graphs, read receipts, follower and list notifications, mutual-connection displays. Some fire with no action beyond loading a page.

Per-surface checks, what each platform category exposes, and the settings that do and don't help: reference/attribution-surface.md.

Research identity and real identity never touch. Not "mostly" — one crossing links them permanently, and it is not reversible once a platform has correlated it. The specific leaks, roughly in order of how often they burn people:

Build one only when observation genuinely requires an account, and read the ToS section below first. A brand-new empty account is both useless and conspicuous: it can't see much and it looks exactly like what it is, so it gets blocked, challenged, or banned at the moment you need it. Personas need plausible history and age, so create them well before the case that needs them and let them accumulate ordinary activity. Maintain a small stable rather than one per investigation.

Coherence is the whole game: name, locale, language, timezone, posting hours, interests, and connections all agreeing with each other and with the platform's demographics. A persona claiming a city while posting on that city's night schedule is a contradiction a human notices instantly.

Step-by-step build, identifier sourcing, ageing schedule, and the maintenance routine: reference/persona-runbook.md.

Hard limit, regardless of mandate: personas are for observation — not for eliciting private information, inducing anyone to act, or gaining entry to closed systems or groups on a false pretext you have no authorization to make.

Tor is the strongest tool here and the wrong one most of the time: exit addresses are publicly enumerable, so a monitored target sees "someone using Tor looked at this" — more attention-getting than an ordinary visit — and platforms treat Tor logins as high-risk, triggering the verification challenges that kill a persona.

Residential proxies deserve a specific warning: many pools are assembled from consumer devices enrolled through bundled SDKs whose users did not meaningfully consent, and your traffic exits through a stranger's home connection — an ethical problem and potentially a legal one for both of you. Know how your provider sources its pool, or don't use one.

Verify whatever you choose: check the exit address and its ASN, confirm DNS resolves through the tunnel, and block WebRTC, which reveals addresses independently of it.

One case, one environment. A dedicated VM per case is the clean answer; a dedicated browser profile is the minimum. Containerised tab isolation separates cookies but not fingerprint — a convenience, not a boundary. Across setups: no personal accounts ever signed in; snapshot clean and roll back between cases; keep notes and downloads in the case's encrypted store; never open a target's document or PDF in an environment that can reach your real identity.

Compartmentation means a persona used on case A is never used on case B. Two targets who compare notes — and targets in one ecosystem do — reconstruct your operation from the overlap. Same for numbers, emails, proxies, and avatars.

Never authenticate to anything belonging to the target. Not their portal, not their wifi, not a login with credentials found in breach data, not a "forgot password" flow to confirm an account exists. That is the line between open-source research and unauthorized access, and it does not move because the password was easy to find.

After any collection action, grade what the target could know.

Log exposure events as they happen, with timestamps. Reconstructing them after a case goes wrong is guesswork, and the client will ask.

Objective: is a supplier's named director active in an industry forum? Subject is a small business owner, not technically sophisticated, but the forum is niche and members notice new accounts.

Posture: commercial VPN, dedicated browser profile, an existing aged persona from the stable — not a new one, because the forum's member list shows join dates.

The dead end that matters: the forum blocks the VPN's ranges outright. Instead of escalating tooling, the archive route () yields cached thread pages containing most of what was needed, with no contact at all. Graded clean.

One question still needs a live profile page. The persona logs in from a consumer connection rather than the VPN, in the forum's working hours, views the profile, and leaves. The forum has no "who viewed" feature, so exposure is graded anonymous contact — with a note that the administrator can still read access logs.

Not done: a professional-network profile view of the same person, because that platform notifies. The question it would have answered went into the report's gaps section instead. A tipped-off subject costs more than an unanswered secondary question.

OPSEC is a precondition, not a producer of selectors. Run it before , , , and any interactive step in or . Check avatars with , strip uploads with , prefer to live visits, and log exposure events so can state what the subject may know.

Say this plainly: fake accounts violate most platforms' terms of service. Accurate-information requirements are near-universal, the accounts get banned, and the ban can take your collection with it. Terms breach is generally a contract matter rather than a crime, but the boundary between breaching terms and unauthorized access is jurisdiction-specific and has been litigated both ways. Decide with counsel whether your mandate covers it, and record it.

Impersonating a real, identifiable person is a far more serious matter than an invented persona — a number of jurisdictions criminalise online impersonation specifically (California Penal Code § 528.5 is one example), and it exposes you to defamation and civil claims. Impersonating a law-enforcement officer, government official, or lawyer is a criminal offence in its own right in many places, including under US federal law, and no investigative mandate covers it.

Also: a persona is personal data processing under GDPR-style regimes when used to collect on living people, and the persona's own conduct is attributable to your organisation. See ../../ETHICS.md. If you cannot justify the persona in writing, do not create it.