Surface vs. Island: When Your Browser Should Stay Yours
Surface vs. Island
When your browser should stay yours.
Forked Chromium browsers solve real problems. Here is where the architecture caps out, and where Surface picks up: native patch cadence, no migration tax, on-prem control plane, data sovereignty.
Same problem space. Different physics.
Island and Surface both want to make the browser the policy boundary. The difference is what sits inside that boundary and who runs it.
Island
Forked Chromium plus a vendor-hosted management console.
- A Chromium-based browser installed in place of Chrome or Edge on each managed endpoint.
- Policy, telemetry, and configuration delivered from the Island Management Console, hosted by Island.
- Security patches arrive after Island ingests the upstream Chromium release, re-applies its modifications, re-builds, re-signs, and ships through its managed-update channel.
- Strong containment surface: clipboard rules, screenshot blocks, watermarking, and instrumentation deeper than any public extension API can reach.
Surface
A managed extension plus an on-prem control plane the customer runs.
- A managed extension that runs inside the Chrome, Edge, or Firefox the employee already uses.
- Control plane deployed on customer infrastructure: Docker, Kubernetes, virtual machines (VMs), bare metal, or air-gapped.
- Browser security patches flow on the upstream vendor's native cadence. No Surface step sits between Chromium and the endpoint.
- Detection runs on-device. Telemetry stays inside the customer's perimeter. No multi-tenant vendor cloud in the data path.
Three constraints a forked Chromium browser cannot remove
These are not implementation flaws. They follow from the model. Every Chromium-fork product (Island, Prisma Access Browser, Mammoth, Surf, Citrix Secure Browser) inherits them.
A vendor step between Chromium and your fleet
When Chromium ships a security release, Chrome and Edge users absorb it on the upstream timeline. A forked-Chromium browser does not: the fix must be ingested, re-applied over the fork's modifications, re-built, re-signed, released through the vendor's managed channel, and then picked up by the fleet. Palo Alto Networks publishes a monthly Chromium roll-up for Prisma Access Browser (PAN-SA-2026-0007) for exactly this reason. Island, Mammoth, Surf, and every other fork vendor are on the same cycle.
For V8 remote code execution (RCE)-class fixes, the delay between upstream patch and full fleet deployment is the window in which a forked browser is materially less protected than the Chrome it replaced. Surface runs on the customer's existing Chrome, Edge, or Firefox, patched on the vendor's native cadence. No Surface step in the middle.
A cloud management plane you do not run
Island is delivered as a service. The Island Management Console (policy, telemetry, configuration, often Data Loss Prevention (DLP) samples) is hosted by Island. For many customers, that hosted model is the entire point of buying a software-as-a-service (SaaS) product.
For regulated finance, healthcare, government, defense, critical infrastructure, and anyone with serious data residency obligations, the logic does not hold. You are being asked to send sensitive browsing data (the pages your users visit, the data they paste) to a third-party cloud in order to protect that data from going to third parties. Surface instead runs entirely on the customer's own infrastructure, air-gapped if needed, with no outbound calls to a vendor cloud and no foreign-jurisdiction processing.
Replacing a browser is a deployment project
Replacing Chrome or Edge on every endpoint is a project, not a configuration change. Even with strong Mobile Device Management (MDM) tooling, real rollouts produce user retraining, helpdesk load around quirky web-app behavior, extension and SaaS compatibility friction, and a long tail of "I just use my personal Chrome for that" workarounds that quietly dilute the containment story.
A managed extension is a push. It lands inside the browser the employee already opens every morning: the UI does not change, the compatibility surface does not change, helpdesk tickets do not spike. That replacement cost never shows up on a comparison sheet; it shows up in quarter one of the rollout, and it disappears entirely with an extension.
An honest capability comparison
Both products do real engineering. The chart below shows where each architecture genuinely wins. Island has containment depth an extension cannot reach. Surface has deployment, patch cadence, and sovereignty a forked browser cannot offer.
| Feature | Recommended Surface Extension plus on-prem control plane | Island Forked Chromium plus cloud console |
|---|---|---|
| On-premises deployment (no vendor cloud) | Fully supported | Not supported |
| Adaptive browser security (Surface Vision, on-device, signature-free) | Fully supported | Not supported |
| Air-gapped network support | Fully supported | Not supported |
| Native upstream browser patch cadence | Fully supported | Not supported |
| Works with the browser the employee already runs | Fully supported | Not supported |
| Zero migration cost | Fully supported | Not supported |
| Watermarking, screenshot block, copy/paste containment | Partial or limited | Fully supported |
| Managed browsing environment for unmanaged or BYOD endpoints | Partial or limited | Fully supported |
| Hooks into the rendering pipeline below extension APIs | Not supported | Fully supported |
| Full data sovereignty (no third-party processing) | Fully supported | Partial or limited |
| Identity, data, and AI-agent action in one platform | Fully supported | Partial or limited |
| Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) integration | Fully supported | Partial or limited |
Architectural capabilities. Containment depth credit to Island reflects the engineering reality of a forked browser. Sovereignty and deployment credits to Surface reflect a customer-hosted control plane.
When Island is the right call
Island has done real engineering on the enterprise browser model. There are deployments where a forked, vendor-hosted browser is a better fit than an extension, and we say so on the record.
Contractor and BYOD fleets
To deliver a fully managed browsing environment to devices it does not own, including bring-your-own-device (BYOD) endpoints, an extension is structurally a worse fit. A managed browser solves the unmanaged-endpoint problem cleanly.
Containment-heavy workflows
Surfacing a high-risk web application inside a watermarked, copy-paste-restricted, screenshot-blocked browser instance for a controlled audience is exactly what a forked browser is for.
Heterogeneous browser baseline
If the browser estate is so fragmented that standardizing on a new managed browser is easier than rolling out an extension across the mix, the migration tax math flips.
In those situations a managed browser solves the problem in a way an extension cannot. The mistake is treating the enterprise browser model as the default for everyone, when most regulated and sovereignty-first organizations are better served by a managed extension on the browser they already run.
Keep your browser.
Keep your perimeter.
Surface deploys as a managed extension on Chrome, Edge, or Firefox, with a control plane that runs entirely on your infrastructure. Same browser your users already use. Same Security Operations Center (SOC) stack you already run.