What a sealed Session seals — and what it does not.
What it's for
Open two Accounts and they are two separate browsers. Different cookies, different storage, different Fingerprint, different exit — and nothing an ordinary browser shares between tabs (a login, a stored value, a tracking cookie) crosses from one to the other. This page is the honest account of what that seal covers, and the few places it is deliberately looser.
One Account, one sealed partition
Each Account gets its own on-disk partition. Its cookies and storage are written there and read only from there, so signing in as one Account leaves the others untouched.
Every Session of an Account shares that one partition
The flip side: open the same Account twice — two Sessions, side by side on the wall — and they share the one partition. That's deliberate. They are the same identity, so they carry the same cookies and stay signed in together.
Three Accounts open at once — three sealed browsers on one machine.shot-sessions · 3 Accounts open on the wall, each its own exit + Fingerprint
Pop-ups stay inside the Account
A window.open or a target="_blank" link is the classic escape hatch — in a plain browser it can spawn a window on the default session, with none of the Account's disguise. Umbra catches it.
Where the seal is deliberately looser
Two exceptions, both worth knowing before a drop.
The captcha harvester is shared. When a site throws a CAPTCHA or a Google sign-in, the solve runs in one shared helper Session — not behind the Account's own exit.
WebRTC hardening needs an exit. The policy that stops WebRTC surfacing your real IP is applied only to Accounts that have a proxy.
