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.
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.
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.
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.
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.
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?
What happens when the user clicks a link to a disallowed domain?
How are single-page application navigations handled?
Do the rendering-layer defences degrade page performance?
Can the protected application detect that it is running inside this isolation?
What happens at session end?
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.