Wiki · Concept · Last reviewed June 25, 2026

Isolated Web Apps

Isolated Web Apps are a WICG proposal and Chrome implementation path for packaging web applications into signed bundles so their code can be verified before higher-trust browser capabilities are exposed.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser security, app isolation, signed web bundles, agents, web governance

Definition

Isolated Web Apps, or IWAs, are an incubating web-platform proposal for applications built with web technologies but delivered with stronger integrity and isolation assumptions than ordinary web pages. The WICG explainer says IWAs are not fetched from live web servers over HTTPS at runtime; they are packaged into Web Bundles, signed by the developer, and distributed through channels such as stores or enterprise configuration.

The related Isolated Contexts draft, published as a W3C Community Group draft on August 26, 2024, is explicit about status: it is not a W3C Standard and is not on the W3C Standards Track. Its core idea is that certain powerful APIs may require a context whose code integrity and isolation can be verified before the browser exposes capabilities that would be too risky for the ordinary visitable web.

How It Works

Chrome's IWA documentation describes the deployment shape. Pages and assets are packaged into a Signed WebBundle file with a .swbn extension and an integrity block. Instead of relying on TLS keys for live server delivery, the bundle is signed with an offline-capable signing key, and the browser verifies the package before installation and update.

IWAs use an isolated-app: URL scheme. The WICG scheme explainer says IWA URLs do not rely on DNS resolution or HTTPS certificate authorities. The host is a Signed Web Bundle ID, derived from the signing-key material and encoded as a hostname-shaped string. The user agent maps that ID to an installed bundle, fetches resources from inside the bundle, and checks whether the signing key is trusted.

The isolation model is not only packaging. The Isolated Contexts draft builds on strict Content Security Policy, cross-origin isolation, storage separation, and integrity verification. Chrome's developer-policy page also points to stronger requirements such as CSP, Trusted Types, least privilege, transparency about privileged APIs, and static integrity for executable logic.

Agent Context

IWAs matter for agent systems because browser agents are moving toward tasks that feel closer to desktop automation than ordinary browsing: local files, device connections, remote desktops, kiosks, enterprise dashboards, and privileged embedded frames. Chrome documentation names capabilities such as Direct Sockets and Controlled Frame as examples of APIs associated with this higher-trust environment.

That does not make an IWA a safe agent by itself. It means the browser has a stronger claim about what code is installed and where it came from. An agent runtime still needs separate authorization, action logging, prompt-injection defenses, user confirmation, and recovery paths.

Governance Use

The governance question is who gets to vouch for web code that asks for unusual power. A normal website can change every time the server changes. An IWA moves some trust from live server state to package identity, signing keys, installation policy, update policy, and attestation. That can help regulated or enterprise deployments review the code that will run in a kiosk, support console, or agent-facing tool surface.

The same shift creates institutional risk. If powerful APIs are available only to attested isolated contexts, whoever controls attestation, allowlists, stores, or enterprise policy can become a gatekeeper. The Isolated Contexts draft warns that browser vendors should be selective about APIs that require this model, because the open web's low barrier to entry is part of its security and civic value.

Limits

An IWA is not a general proof of good behavior. Signed code can still be malicious, overbroad, deceptive, vulnerable, or authorized for the wrong user. Package integrity says that the code matches what was signed; it does not prove that the code should have the requested capability.

It is also not ordinary web deployment. Chrome's introduction warns that IWA architecture excludes some site patterns because pages and assets must be available from the package rather than server-rendered on demand. Treat it as an application packaging and trust model, not as a drop-in performance optimization for every website.

Minimum Evidence Record

A review record should include the bundle ID, signing-key owner, distribution channel, installed version, update manifest or policy source, requested privileged APIs, CSP and Trusted Types posture, installation authority, user or device group, review date, and the exact agent or kiosk workflow that depends on the IWA. Do not store signing secrets or unnecessary user data in the audit record.

Source Discipline

Use WICG documents for proposal status, scheme structure, and isolated-context concepts. Use Chrome documentation for Chrome-specific packaging, policy, and implementation behavior. Do not describe IWAs as a completed W3C standard, and do not infer support in non-Chromium engines unless that engine has published its own position.

Spiralist Reading

Spiralism reads IWAs as a bargain between the open page and the installed machine. The web gains a stronger shell, but the shell comes with gatekeepers, signatures, and distribution records.

The agent-era lesson is to keep the bargain visible. If a browser tool gains power because it is packaged and vouched for, the record should say who vouched, what code was vouched for, what capability was granted, and how the user can withdraw trust.

Sources

Return to Wiki