Enterprise Remote Browser Isolation System

0) Problem Restatement

Oracle asked: design a remote browser isolation (RBI) system for enterprises. Instead of loading websites directly on employees' laptops (where malicious code could infect the device), each browsing session runs in an isolated, disposable virtual node in the cloud. Only a safe stream (rendered pixels or sanitized page content) reaches the user's device. If a site is malicious, it only harms a throwaway container, never the laptop or the corporate network.

1) Requirements

• The user opens a website → it runs in a remote isolated browser → the user sees and interacts with it smoothly.
• Isolation: one session per container or microVM, destroyed after use.
• Low latency (feels like local browsing), video and audio support.
• Policies: which sites are isolated (all, or only risky categories), whether file downloads and uploads, copy/paste and printing are allowed.
• Thousands of concurrent sessions across regions. Audit logs.

2) Architecture

flowchart LR
    U["User browser / agent"] -->|"URL request"| GW["RBI gateway - auth, policy"]
    GW --> ORCH["Session orchestrator"]
    ORCH --> POOL["Warm pool of isolated nodes (microVMs)"]
    POOL --> RB["Remote headless browser"]
    RB -->|"fetch web"| NET["Internet via egress proxy"]
    RB -->|"rendered stream (WebRTC / pixels or safe DOM)"| U
    U -->|"mouse, keyboard, scroll events"| RB
    RB --> FS["File sanitizer (CDR) for downloads"]
    GW --> LOG[("Audit logs")]

3) Key Parts

• Gateway and policy: authenticate the user (SSO), and decide isolate or allow based on the URL category, user group and risk score.
• Session orchestrator: assigns a node from a warm pool (pre-started microVMs with a browser ready), because cold starts would add seconds. It scales the pool with demand per region, and destroys the node after the session ends (or on idle timeout). No state carries over between users.
• Isolation technology: microVMs (e.g., Firecracker) or hardened containers (gVisor), each with no access to internal networks, and egress only through a filtering proxy.
• Rendering and streaming (two common modes):
• Pixel streaming: encode the remote screen as video (WebRTC/H.264) and send it. It's the most secure (no page code reaches the device), but uses more bandwidth, and text can look slightly less crisp.
• DOM reconstruction: send a sanitized version of the page (no scripts). Lighter and crisper, but more complex to make safe.
• Input forwarding: the client sends mouse, keyboard and scroll events over the same low-latency channel.
• Files: downloads pass through content disarm and reconstruction (CDR) (rebuild the file without active content like macros) or are blocked by policy. Uploads are allowed only by policy and scanned.
• Placement: sessions run in the region closest to the user for low latency.

4) Scale and Cost

• Each session needs CPU, memory and a GPU or video encoder. Pack sessions per host, and autoscale host pools per region by time of day.
• Idle sessions are suspended or terminated quickly, and per-tenant quotas apply.
• Monitor the p95 input-to-display latency, stream quality, and node startup time.

5) Wrap-Up

Route policy-selected browsing through a gateway to an orchestrator that hands each session a pre-warmed, fully isolated microVM running a remote browser, with egress only through a filtering proxy, and destroys it afterwards. Stream only safe output (encoded pixels via WebRTC, or sanitized page content), forward user input back, sanitize or block file transfers, place sessions near users, and autoscale warm pools per region while logging everything for audit.