privacyportal
Back to Compass
Path consoleIdentity & Accountsmedium risk

Separate identities and accounts

Split public, work, and sensitive personas so one mistake does not expose everything.

1–2 hoursAnyone juggling public, work, and sensitive online personas 1 starting tool

Target outcome

Public, work, and sensitive activity stay in isolated browser contexts

Do this first · quick win

If you only do one thing today: create a dedicated browser profile or container for sensitive activity and stop logging into personal accounts there.

Setup queue

Start with verified tools

Compare the fit, keep the ones you want in My Stack, then open the verified setup guidance.

Brave

applications

Choose Brave profiles when you need separate browser containers for public, work, and sensitive personas on one machine.

applicationsEvidence pending
Visit project
More compatible tools (3)

BrightID

applications

Optional Web3 layer after browser separation — use when apps need proof-of-personhood without uploading government IDs to every service.

applicationsEvidence pending
Visit project

Iden3

infrastructure

Choose iden3 when you want programmable identity credentials for apps you build or operate.

infrastructureOpen source
Visit project

Self Protocol

applications

Choose Self when you need reusable identity proofs with selective disclosure in Web3 apps.

applicationsOpen source
Visit project

Understand · act · verify

Your path

Nothing is detected automatically. You decide when a step is done or needs another review.

  1. 1

    Write down the personas you need — public, work, sensitive — and what each is allowed to touch.

    Step 1 · Not started

    • Personas defined: You have a written list of what public, work, and sensitive personas may access.
  2. 2

    Create separate browser profiles or containers: one for public browsing, one for work, and one for sensitive activity — never cross-login between them.

    Step 2 · Not started

    • Browser containers separated: Each persona has its own browser profile or container and you have not cross-logged in.
  3. 3

    Assign each persona its own email inbox and password-manager vault; disable autofill on sensitive profiles.

    Step 3 · Not started

  4. 4

    Move one high-risk service (messenger, cloud, social) into the sensitive container and delete old sessions elsewhere.

    Step 4 · Not started

    • High-risk service migrated: At least one sensitive service runs only inside the sensitive container with old sessions revoked.
  5. 5

    Optional Web3 step: link a BrightID proof to apps that need sybil resistance without uploading government IDs everywhere.

    Step 5 · Not started

  6. 6

    Review monthly for shared phone numbers, recovery emails, or payment cards that link personas back together.

    Step 6 · Not started

How you know it worked

  • Public, work, and sensitive activity stay in isolated browser contexts
  • Credentials and sessions do not bleed across personas
  • Optional Web3 identity proofs are available without repeating KYC uploads

Watch out

Password reset flows that send SMS to one phone number undo multi-account separation.

Synced browser history and shared Wi‑Fi names can correlate personas.

Logging into the same service from two containers links them through the provider's session graph.

Key terms
Browser container
An isolated browser profile or cookie jar that keeps logins, cookies, and history separate from other personas.
Persona
A deliberate identity slice — public, work, or sensitive — with its own accounts and access rules.
Sybil resistance
Mechanisms that limit fake accounts without requiring full government ID for every service.