Isolation

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.

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.

What a website can ask your device for

A resale page can ask a browser for a lot: your camera, your microphone, your screen, your clipboard, your location, a USB or Bluetooth device. Umbra answers those the same way for every Account, from one fixed list, so nothing depends on a prompt you might misread seconds before a drop.

The same answer is given whether a page quietly checks a permission or asks for it — the two used to be able to disagree, which is how a page could read your screen layout through getScreenDetails() while the switch that was meant to stop it only covered the asking. An embedded frame from another site gets nothing unless the outer page hands it that one permission, and even then only your Account's spoofed location, never your real device.

Location and notifications: your decision, per Account and per site

Those two were always allowed. They still are by default — an Account you have never touched behaves exactly as before, and its Site permissions card says Default — allowed (nothing recorded yet) — but you can now decide. Open the Account, go to the Fingerprint tab, and use Site permissions:

Location value vs. permission to share it. The card starts by naming the Account's configured location — the position in its Fingerprint, kept on its exit's region. That value is what a site would see. Location sharing decides whether a site may see it at all. Blocking leaves the value untouched; allowing never hands over this computer's real position.

When a change takes effect. Every page opened or reloaded after you save follows it. A page that is already open on a site you just blocked keeps what it was given — an ongoing location watch there keeps receiving positions — until it reloads, because the browser holds that page's existing grant. The card tells you how many such pages are open and offers Reload them now; nothing reloads on its own, since a reload can cost a queue place.

What lasts. Decisions are saved on the Account: they survive a restart, and moving the Account to Recently deleted and restoring it keeps them. Deleting it permanently removes them, and a new Account starts on the default.

Open in Chromium is different. The external browser has its own permission system: it asks in its window and remembers per site in the Account's Chromium folder. Neither the refusals above nor an Account's Site permissions apply there — the Account's Chromium details say so under Decided by Chromium itself. If you allow location in that window, the site reads the Account's position, not this computer's.

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.