Capability

Every session is its own isolated browsing environment

Each ZeroLeak session opens the protected application inside its own browser context — a fresh profile with no shared cookies, no shared storage, no shared session state. The user can only navigate to allowed domains, cannot open new tabs or pop-ups, and the rendered pixels themselves carry anti-automation defences before they reach the user's screen.

When two users access the same protected application through ZeroLeak, they should not be able to see each other's session data, share cookies, or influence each other's browsing state in any way. And neither user should be able to escape the protected application's domain — clicking a malicious link, opening an unintended pop-up, or navigating somewhere policy does not allow. Browser context isolation is the layer that enforces all of this. Each session runs in its own browser context with no shared state; a strict domain allowlist intercepts navigation attempts before they happen; new tabs and pop-ups are blocked at the source; and the rendered pixel stream itself carries continuous, low-level modifications that frustrate automation tools trying to read or interact with the session from outside.

Per-session
Isolated browser context — own cookies, own storage, own state, no sharing
Allowlist
Domain enforcement at the request layer, link layer, and SPA polling layer
Kiosk mode
No new tabs, no pop-ups, no right-click menu — one session, one allowed surface

Shared browser state is leakage; uncontrolled navigation is escape

A naive remote browser shares one browser process between many users. Cookies set in one session show up in the next; localStorage data crosses session boundaries; authentication state from one user can be inherited by another. Even when the protected application itself is well-behaved, the shared browser becomes a side-channel that bypasses every application-level access control.

And then there is navigation. A user with view-only access to a single internal dashboard clicks a phishing link inside that dashboard, opens a new tab to a personal account, or follows an external link they did not intend to. Without enforcement at the browser layer, the session escapes the protected application — and now the protected application's session token, the user's identity, and the active browsing state are visible to whatever the browser navigates to.

Browser context isolation closes both. Every session runs in its own browser context with no shared state. The browser itself enforces an allowlist of domains the session can reach, and blocks every channel a user might use to navigate elsewhere — new tabs, pop-ups, link clicks to disallowed domains, programmatic navigation by the page itself.

Isolation at the browser, enforcement at the boundary

Each session gets its own browser context inside the rendering engine, completely separate from every other session's state. A strict domain allowlist sits at the navigation layer — request interception, single-page-app navigation polling, and link-click interception together make sure the session never reaches a domain it was not permitted to reach. Underneath, the rendered pixels themselves carry continuous low-level modifications that disrupt automation tools attempting to read or interact with the session.

Per-session browser context with no shared state

Each user session opens inside its own isolated browser context — a fresh profile with its own cookie jar, its own local storage, its own session state. Two users on the same protected application have completely independent browsers; nothing from one session is visible to the other. Session end disposes the context entirely; no state survives.

Strict domain allowlist enforced at navigation

Every navigation attempt is intercepted before it executes. The request layer blocks disallowed domains at the network level; link clicks inside the page are intercepted in the rendering layer; single-page application navigation (pushState, replaceState) is caught by polling. The session simply cannot reach a domain outside its allowlist, whether the user tries deliberately or the page tries on its own.

New tabs, pop-ups and right-click menu blocked

The kiosk-style browser does not let the user open new tabs, spawn pop-ups, or use the right-click context menu. Every channel a user might use to escape the protected application is closed at the browser configuration. The user works inside the session that was opened for them — no more, no less.

Anti-automation defences applied to the rendered pixels

Beneath the visible content, the rendered pixel stream carries continuous low-level modifications — randomised noise, subtle colour shifts, micro element displacement, sub-pixel jitter. These do not affect what the user sees but they disrupt automation tools (Selenium, Puppeteer scripts, screen-scrapers) trying to read or interact with the session from outside the official input channel.

What the isolation layer enforces

Each behaviour below is configured per protected service and enforced at the browser layer, not in the protected application's code. The protected application does not have to be aware that any of this exists — the boundary is invisible from inside the application's runtime.

Fully isolated browser context per session

Each session runs in its own browser context — a Chromium-level construct that gives the session its own cookie jar, its own local storage, its own service worker registry, its own permissions, its own session state. Two sessions on the same protected application share nothing at the browser level.

Network-level request interception

Every navigation request — main document, sub-document, fetch, XHR — passes through an interceptor that checks the destination domain against the session's allowlist. Disallowed domains are blocked before the connection is even established. There is no race condition between the user clicking and the navigation being checked.

Single-page-app navigation polling

Modern single-page applications navigate by calling pushState or replaceState without making a network request. A simple request interceptor would not catch these. ZeroLeak also polls the current URL on a short interval inside the page, so SPA navigations to disallowed paths are caught and reverted within seconds.

Link-click interception inside the rendered page

Anchor elements with disallowed targets, window.open() calls, programmatic location changes — all are intercepted inside the rendered page before they execute. The user clicking a link they should not be able to follow gets blocked at click time, not after the network request has already started.

Tab and pop-up blocking

The browser is configured so that any attempt to create a new browsing target — by the user, by the page, by a script — is intercepted and discarded immediately. The session always has exactly one visible tab, which is the protected application's tab.

Idle timeout and graceful shutdown

Each session tracks user interaction. If the user is idle for longer than the configured timeout, the session is gracefully terminated, the browser context is disposed, and (when configured) a webhook notifies the coordinator so downstream policy can update. No abandoned isolated browsers consuming memory.

Rendering-layer defences applied beneath the visible content

Beyond per-session isolation and the navigation boundary, the rendered pixel stream itself carries continuous low-level modifications. Their purpose is to disrupt automation tools — scripts that would otherwise read the session screen, identify elements, and interact through unofficial channels — without affecting how the page looks or behaves for the human user.

01

Randomised low-amplitude pixel noise

A canvas overlay continuously draws low-amplitude random noise across the rendered page. The human eye perceives a faint texture at most; OCR and template-matching scripts that try to read the screen lose the consistent pixel boundaries they depend on. Noise intensity and refresh rate are configurable per protected service.

02

Subtle colour-tint shifts

A translucent overlay applies a slowly varying random colour tint across the rendered page. White and black areas still appear effectively white and black to the eye but their actual pixel values shift. Vision-based automation tools that match against colour signatures lose their reference.

03

Continuous micro blur

A very light continuous blur is applied as a screen filter. Every frame is slightly different in its high-frequency detail, making it harder for OCR and pattern-matchers to find stable feature points. The user does not perceive the blur at normal reading distance.

04

Element micro-shift via CDP injection

Page elements are randomly displaced by 1-3 pixels relative to their normal position. The shift is below human perception but breaks scripts that locate elements by absolute screen coordinates. Automation tools cannot rely on a stable element position from one frame to the next.

05

Sub-pixel jitter (anti-Selenium)

On a short interval, the entire rendered surface is translated by a few pixels — too small to disrupt reading, large enough to defeat automation tools that depend on consistent absolute pixel coordinates for input simulation. Selenium-style replay attacks lose their anchor points.

Where per-session isolation matters

Operational technology and SCADA consoles

Critical infrastructure interfaces where any cross-session state leakage or unintended navigation could affect physical systems. Per-session isolation guarantees that two operators on the same console cannot see each other's session, and the strict allowlist ensures neither leaves the operational console for an external link.

Internal enterprise applications with view-only roles

Internal dashboards, audit interfaces, reporting tools accessed by many users — including contractors and external auditors. Each session is its own browser, the access policy is enforced at the navigation layer, and the rendering-layer defences resist automation by anyone trying to scrape the screen.

Document and deal-room access

Per-session context means a contractor viewing one deal room cannot see cookies, search history, or session tokens from a different contractor on a different deal room. The allowlist ensures the deal-room session never navigates into the wider internet.

Research and clinical-trial portals

Trial portals where multiple researchers access patient data under strict disclosure boundaries. Per-session isolation enforces the boundary at the browser layer; the allowlist enforces it at the navigation layer; the rendering defences resist automation from anyone trying to scrape data through the screen channel.

Common questions

Is this the same as Chrome incognito mode?
Conceptually similar but enforced at a different layer. Incognito mode is a profile setting that the user can leave; browser context isolation is a per-session container managed by ZeroLeak — the session has no choice about its isolation, and no UI control to disable it. The user cannot accidentally or deliberately escape into a regular profile.
What happens when the user clicks a link to a disallowed domain?
The click is intercepted before the navigation executes. The session stays on the current page and (optionally) shows a notification that the destination is not permitted. The event is recorded in the session log so the operator can see what was attempted. No partial navigation, no third-party request, no leakage of the session token to the disallowed destination.
How are single-page application navigations handled?
Modern SPAs change the URL via pushState or replaceState without making a network request — a simple request interceptor would miss these. ZeroLeak runs a polling check inside the page on a short interval; if the URL changes to a disallowed path, the session is immediately navigated back to a safe state. The polling interval is short enough that any disallowed SPA navigation lasts seconds at most.
Do the rendering-layer defences degrade page performance?
The pixel noise overlay uses a downscaled canvas (typically quarter-resolution) refreshed at modest rates to keep CPU and memory usage low. Colour-shift overlay and micro blur are CSS-level filters. The cumulative impact is small enough to run hundreds of concurrent sessions on commodity hardware.
Can the protected application detect that it is running inside this isolation?
It does not need to and is not designed around it. The protected application sees a standard headless browser environment. The isolation, allowlist, kiosk constraints and rendering defences all operate outside the application's runtime — the application is not asked to cooperate with them and cannot disable them.
What happens at session end?
The browser context is disposed entirely. Cookies, local storage, service workers, cached pages, in-memory state — all gone. There is nothing for the next session opened on the same protected service to inherit. If configured, a coordinator webhook fires with the session ID and end reason so downstream policy or audit systems can update.

See per-session isolation in a live demo

We will run two sessions side-by-side on the same protected application, show that nothing leaks between them, attempt to navigate outside the allowlist, and try to drive the session with an external automation tool — and show what happens.