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, full 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, 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 the Chromium project ships a security release, Chrome and Edge users absorb it on the upstream timeline. A forked-Chromium enterprise browser does not. The fix has to 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. The advisory is not a knock on their engineering. It is the cadence of the model in the open. Island, Mammoth, Surf, and every other Chromium-fork vendor are on the same monthly cycle, whether or not they publish an equivalent public bulletin.
For V8 RCE-class fixes (the most attacker-relevant component of a browser) the window between upstream patch and full fleet deployment is the window in which a forked enterprise browser is materially less protected than the Chrome it replaced. Surface runs on the customer's existing Chrome, Edge, or Firefox. The browser is patched on the vendor's native cadence. There is 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 DLP samples) is hosted by Island. That is the deployment model Island publicly describes, and for many customers it is the entire point of buying a SaaS product.
For regulated finance, healthcare, government, defense, critical infrastructure, and any organization with serious data residency obligations, the logic does not hold. You are being asked to send sensitive browsing data, including the contents of pages your users visit and the data they paste, to a third-party cloud in order to protect that data from going to third parties.
Surface runs entirely on the customer's own infrastructure. Docker, Kubernetes, VMs, bare metal, air-gapped if needed. No outbound calls to a vendor cloud, no shared multi-tenant database, no foreign-jurisdiction processing of your users' activity.
Replacing a browser is a deployment project
Replacing Chrome or Edge on every endpoint is a project, not a configuration change. Even with strong 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 user-visible UI does not change. The compatibility surface does not change. Helpdesk tickets do not spike. The deployment becomes invisible, which is what a security control on every session should be.
The cost of a browser replacement does not show up on a comparison sheet. It shows up in quarter one of the rollout. It is the cost that disappears entirely with an extension.
Upstream Chromium ships a V8 fix. Then what?
- 1Vendor ingests upstream Chromium drop.
- 2Re-applies fork modifications and policy hooks.
- 3Re-builds, re-signs, re-tests the fork.
- 4Releases through managed-update channel.
- 5Waits for the customer fleet to pick up the new build.
Days to weeks of delta between upstream patch and full fleet coverage, every monthly cycle.
Surface (extension on the user's existing browser)- 1Chromium project ships the fix.
- 2Chrome or Edge auto-update channel delivers it.
- 3The browser the user already runs is patched.
- 4Surface keeps running on top, unchanged.
No vendor step between Chromium and your endpoint. Patch cadence is whatever Chrome or Edge ships.
Your perimeter, or someone else's tenant
Island's value proposition is that the management console is someone else's problem. For most buyers that is a feature. For the regulated, sovereign, and on-prem-first buyer it is the exact wrong answer. Surface is built for the second group.
Island Management Console
Hosted by Island. Cloud-delivered policy and telemetry.
Surface Control Plane
Runs inside your perimeter. Air-gapped supported.
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 |
| SIEM and 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
When the organization needs to deliver a fully managed browsing environment to devices it does not own, an extension model is structurally a worse fit. A managed browser solves the unmanaged-endpoint problem cleanly.
Containment-heavy workflows
Surfacing a specific 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 existing browser estate is so fragmented that standardizing on a new managed browser is operationally easier than rolling out a managed 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.
The sovereign and transparency-focused buyer
If you are the team that already keeps SIEM and EDR data inside your own perimeter, your browser security platform should follow the same rule.
Upstream patch cadence preserved
No vendor sitting between you and Chromium's security releases. When Chrome ships, you ship.
Zero browser replacement
Chrome stays Chrome. Edge stays Edge. Firefox stays Firefox. Migration cost: zero.
On-premises by default
All telemetry, all detection, all policy on your infrastructure. Air-gapped supported.
Identity, data, and action in one platform
One event pipeline, one policy engine, one investigation console. No three vendors to integrate.
The trade-off is honest. You do not get the browser-binary-level hooks that a forked Chromium can take. In return, you keep your browser, your patch cadence, your data, and your independence from a third-party cloud. For the regulated, sovereign, and transparency-focused buyer, that is the only deal that meets the bar. The long-form argument lives in Surface vs. Enterprise Browsers.
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 SOC stack you already run.