Arcan's Radical Browser Vision: Challenging Chrome's Dominance with Decoupled Design
#Regulation

Arcan's Radical Browser Vision: Challenging Chrome's Dominance with Decoupled Design

Trends Reporter
3 min read

The Arcan project proposes a fundamental rethinking of browser architecture by rejecting the document-to-application evolutionary path of Chrome and Firefox, instead designing from first principles as a security-focused application runtime.

Featured image

For decades, browsers have followed an evolutionary path from document viewers to full application platforms – a trajectory that created architectural compromises Chrome, Firefox and others still grapple with today. The Arcan project presents a radical counterproposal: What if browsers weren't designed around documents at all, but rebuilt as secure application runtimes from the ground up?

The Document Trap

Traditional browsers suffer from what Arcan developers term "the document trap" – the gradual accretion of features that transformed static page viewers into monolithic application platforms. As creator Björn Ståhl explains: "It doesn't take many feature requests for a static document to become a dynamic application, similar to how few wrong turns it takes to make a regular language grammar into a recursively enumerable one."

Arcan Explained – A browser for different webs. | Arcan Slide about the general idea behind Arcan (2015)

This evolution created fundamental architectural tensions:

  • Security vs Complexity: Sandboxing requirements ballooned as browsers absorbed more functionality
  • Monolithic Design: Tight coupling between rendering, networking, and UI layers
  • Privilege Escalation: Documents gradually gained application-level execution capabilities

The result is illustrated in Chrome's process architecture, requiring intricate IPC between dozens of components:

Arcan Explained – A browser for different webs. | Arcan Simplified chrome composition, taken from Inside Look at a Modern Web Browser

Arcan's Application-First Philosophy

Arcan inverts the traditional approach by assuming the "networked application endgame from the start." Instead of evolving from documents to apps, it begins with three core principles:

  1. Planar Processing: Strict separation between document preparation (handled externally) and application execution
  2. Static Applications: Compiled packages that can't dynamically load external code
  3. Recursive Navigation: Links launch new browser instances rather than modifying current state

Chart highlighting Arcan's evolution Arcan's architecture evolution compared to traditional browsers

Security Through Division

Arcan achieves privilege separation through dedicated external processes:

Process Responsibility Security Focus
Decode Media processing, format parsing Input validation
Encode Recording, streaming, sensors Privacy protection
Network Resource retrieval, discovery Connection security
Terminal OS integration System boundary control

Each process operates under strict capability-based security models. The Encode process, for example, requires no filesystem access after initialization, reducings its attack surface to just three system calls.

SHMIF: Purpose-Built IPC

Where Chrome uses the generic Mojo IPC system, Arcan implements SHMIF – a specialized IPC protocol optimized for display server operations. This design rejects flexibility in favor of:

  • Crash Resilience: State migration between processes
  • Alternative Representations: Built-in accessibility pathways
  • Minimal Attack Surface: Fixed message types validated against real-world use cases

"The generic approach comes at a cost," notes Ståhl. "Code generated creeps into, or even dictates, the design of both sides and it ends up much bulkier." In security testing, generic IDL systems historically proved vulnerable to fuzzing attacks where purpose-built protocols fared better.

Counterarguments and Challenges

Critics might question:

  1. Can Arcan's static application model support modern web interactivity?
  2. Does recursive navigation create unacceptable resource overhead?
  3. Will developers accept a complete break from document-centric paradigms?

The project addresses these through its Arcan-a12 networking layer, which provides compatible networking primitives while maintaining architectural separation. Early benchmarks suggest the process model adds less than 5% overhead versus monolithic designs.

As browsers face increasing scrutiny over security flaws and complexity, Arcan's decade-long development offers a compelling alternative vision: What if we stopped trying to fix the document-to-application transition and designed for applications from the start? The project now approaches its 1.0 milestone with working implementations demonstrating this philosophy.

For technical details, explore the Arcan source and project documentation.

Comments

Loading comments...