Home → Use cases

Use cases

The same tool, three quite different problems. What they share is needing several browser sessions that a website cannot tell are related.

What the three have in common

Different industries, one technical problem: several accounts on the same platform, from the same office, that must not read as the same person. Every case below reduces to the same three requirements, and it is worth knowing them before reading any of the pages.

Separation that survives inspection. Logging out and back in is not separation — the cookies clear but the machine does not change. Two accounts opened from one browser share a canvas signature, a font list, a WebGL renderer and a set of hardware values, and those match whether or not anyone is signed in. A profile has to carry its own version of all of it.

An address that matches the story. A profile claiming a London locale from a datacenter IP in Frankfurt has contradicted itself before the page finishes loading. The proxy, the timezone and the language have to agree, which is why each profile binds its own rather than sharing one connection.

Handover that is not a password. Agencies lose staff, sellers hire VAs, QA teams rotate. If access means knowing a password, removing access means changing every password. Team members exist for exactly this: separate logins, scoped to the profiles each person actually works on.

Not sure which applies?

The underlying mechanics are the same in every case — what links accounts, what isolation actually covers, and why coherence matters more than hiding. That is covered in running multiple browser profiles, and you can see what your own browser reveals with the fingerprint test.