Isolated Web Apps (IWA) — Deep Dive
Chrome's Secure Packaged App Model: Signed Web Bundles, Offline-First, and Exclusive APIs
Isolated Web Apps (IWA) are a new distribution model for web applications. Rather than being served from a live HTTPS server, IWAs are packaged as cryptographically signed Web Bundles, installed locally, and run under a stricter security model — enabling access to powerful APIs like Direct Sockets unavailable to normal web pages.
馃幆 Why Do Isolated Web Apps Exist?
The web's security model has a critical weakness: if the server itself is compromised, malicious code reaches all users. This is why Signal chose Electron over the web — they wanted signed, versioned packages that couldn't be silently tampered with at the server level.
IWAs are Google's answer: bring the Electron/native-app trust model to the web platform. Additionally, some APIs (Direct Sockets) are too powerful for ordinary websites — IWAs provide a safe container where the heightened security justifies expanded capabilities.
馃彈️ How IWAs Work
馃摝 Signed Web Bundles
All app resources packaged into a single .swbn file signed with Ed25519. The public key hash becomes the app's identity — no domain name needed.
馃敆 isolated-app:// Scheme
IWAs use isolated-app://[key-hash]/ URLs. Identity is tied to the signing key, not a domain — unlike HTTPS where domain control = app control.
馃洝️ Enforced CSP + COOP/COEP
Chrome injects strict CSP: default-src 'self', no inline scripts, Trusted Types required. Plus COOP same-origin and COEP require-corp.
馃攧 Monotonic Versioning
Updates via new signed bundle at update_manifest_url. Version must be monotonically increasing to prevent downgrade attacks.
// Enforced CSP:
Content-Security-Policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval';
connect-src 'self' https: wss: blob: data:; require-trusted-types-for 'script';
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
// Build:
npm install -g wbn-sign
wbn-sign --input ./dist --output ./app.swbn --key ./private.pem
// Manifest:
{ "version": "1.0.0", "update_manifest_url": "https://example.com/update.json" }馃殌 APIs Exclusive to IWAs
| API | What It Does | Why Only IWAs |
|---|---|---|
| Direct Sockets API | Raw TCP/UDP connections to any host | Bypasses CORS — too dangerous for normal pages |
| Controlled Frame API | Embed/control third-party content like WebView | UI redress risk on normal pages |
| SharedArrayBuffer | High-performance shared memory between threads | IWAs are guaranteed cross-origin isolated |
| Broader File System Access | File System Access with fewer sandbox restrictions | Higher trust level enables broader access |
馃彚 Who Uses IWAs?
| Organization | Use Case | Notes |
|---|---|---|
| Google (Internal) | ChromeOS system apps, Chrome internal tooling | Primary driver of the IWA proposal |
| Signal (Motivation) | IWA motivated by Signal's need for signed web apps | Signal chose Electron; IWA is the web alternative |
| Enterprise/Corporate | Internal tools needing direct socket connections | Deploy via policy without app stores |
| ChromeOS Apps | Replacing deprecated Chrome Apps with offline IWAs | Demonstrated at Google I/O 2023 |
| Security-Sensitive Apps | Password managers, wallets, healthcare records | Signed bundle as trust anchor |
馃摝 Distribution & Limitations
OS/browser app stores distribute signed bundles. Future Chrome Web Store could host IWAs.
IT admins push IWAs to managed ChromeOS devices via enterprise policy, implicitly trusted.
Bundled inside .msi/.dmg — native-looking installer wrapping a signed web bundle inside.
- Not yet GA — behind Chrome flags or enterprise policies as of 2025
- Chrome/ChromeOS only — no Firefox, Safari, or Edge support planned
- Limited tooling — requires wbn-sign CLI; no mainstream IDE integration
- Not for most apps — you lose URL discovery, deep linking, and fast server-side deploys
Written by Alex R. | Coding with Alex | Tags: IWA, Isolated Web Apps, Chrome, Web Bundles, Direct Sockets, ChromeOS