Forem: Jani Hautakangas

How to Build an Enterprise Browser

Jani Hautakangas — Mon, 16 Feb 2026 18:01:28 +0000

Originally posted on Medium

The concept of an enterprise browser was something I hadn’t paid much attention to until recently, when I found myself in discussions with teams building these systems.

Having worked as a contractor for over ten years, I’ve frequently used managed browsers such as Chrome and Edge. Yet I rarely considered what actually goes into making them “enterprise-ready.” My work has primarily involved Chromium engine internals, including the content layer, Blink, and hardware integration, rather than the browser application layer itself.

During those discussions, I realized how interesting enterprise browsers are, especially in safety-critical environments. I recalled multiple situations in my career where a hardened enterprise browser would have been far more practical than the complicated stacks of VPNs, VDI setups, and jump hosts required just to access secure development environments.

The Enterprise Browser Blueprint

Before tearing down the Chromium source code, we must define what “enterprise-grade” actually means. It boils down to five core pillars:

Centralized Policy Enforcement Engine: A remotely managed control plane that defines, distributes, and enforces browser behavior across all managed instances.
Identity- and Context-Aware Access Control: An identity-integrated runtime that evaluates access decisions based on user identity, device posture, network context, and real-time risk signals.
Data Loss Prevention (DLP): A protection layer that monitors and restricts sensitive data flows within and between web applications.
Insights and Reporting: Centralized telemetry and proactive security event reporting for visibility and auditability.
Zero Trust Engine: A continuous verification model enforcing least-privilege access by validating identity and session risk throughout the lifecycle of a session. “Never Trust, Always Verify.”

Managed Standard Browsers vs. Commercial Solutions

Managed Standard Browsers (Chrome & Edge)

These are “enterprise-light” versions of everyday browsers. They are essentially consumer Chromium binaries with management hooks.

Google Chrome Enterprise: Managed via Chrome Browser Cloud Management (CBCM).
Microsoft Edge for Business: Deeply integrated with Microsoft Entra ID and Microsoft ecosystem.
Policy & DLP Capabilities: Both provide an extensive set of enterprise policies, built-in data loss prevention capabilities, Safe Browsing integration, identity-based access controls, and centralized reporting through their respective management platforms.
Enterprise Connectors: These are integration frameworks that allow the browser to send telemetry and content (such as file uploads or clipboard data) to third-party security providers for real-time analysis.

Commercial Enterprise Browsers

These are typically hardened Chromium derivatives or wrapper-based architectures designed specifically for security boundaries.

Granular Policy Extensions: Hyper-specific controls over browser internals.
Enhanced Data Loss Prevention: These tools implement advanced content inspection to redact sensitive data in real-time and prevent unauthorized data movement between applications via the clipboard or file uploads.
“Last Mile” Visibility: By enforcing policies within the browser runtime and renderer process, these solutions gain visibility into the DOM and user interactions that are invisible to network-level security tools.
Full control over the browser runtime: The ability to modify or instrument components of the rendering engine and JavaScript execution environment when necessary.
Tailored per client: The entire browser lifecycle and feature set can be customized to meet the specific compliance or operational needs of a single customer.

Why Build a Custom Enterprise Browser?

n my case, this project is driven by curiosity and the fact that no open-source project currently provides a full enterprise browser stack. However, for organizations in high-stakes industries such as Defense, Intelligence, or High-Frequency Trading, the reasoning goes far deeper than curiosity.

The Sovereignty Gap

While Chrome and Edge offer a vast number of security, reporting, and policy enforcement features, they are fundamentally designed to operate within the Google or Microsoft ecosystems. For organizations with extreme security requirements, this creates a “Sovereignty Gap” that only a custom-built solution can bridge.

Building a custom browser allows us to achieve:

De-Google the Core: Completely strip proprietary Google service dependencies that standard browsers require for background tasks, sync, and telemetry.
Google Services are Not Allowed: Ensure that no part of the browser attempts to communicate with Google-owned endpoints, eliminating “phone-home” traffic.
External Cloud is Forbidden: Architect the management and reporting plane to exist entirely within a private, air-gapped, or sovereign cloud environment.
Deep Runtime Instrumentation: Inject advanced controls deep into the renderer and JavaScript engine to monitor and block malicious behavior at the instruction level.
Per-client Hardened Runtime: Tailor the specific security surface area such as disabling specific Web APIs or hardware acceleration based on the unique risk profile of a specific client or mission.
Traceability & Determinism: Achieve full source-level auditability and deterministic builds, ensuring that every binary can be verified and every runtime decision can be traced back to a specific line of code.

Building a Custom Enterprise Browser

Almost every enterprise browser is Chromium-based. There is a good reason for that: it provides many necessary building blocks out of the box. Even when full implementations are not available, the necessary interfaces usually are. Therefore, it is significantly more practical to build on top of Chromium than to start from scratch, especially considering that for many users, the word “browser” effectively means Chrome.

To make it a true enterprise tool, several components must be implemented:

Cloud Management
Device Management and Reporting Servers
Secure Browsing Services
Zero Trust Engine

From a Chromium integration perspective, the following require extension or replacement:

Cloud Service Integration: Connecting the browser to the management plane.
Policy Handlers: Implementing specialized handlers for proprietary security constraints.
DLP Logic: Enhanced data loss prevention mechanisms integrated into the runtime.
“Last-mile” Control: Advanced controls injected deep into the Chromium engine.

Implementing the Foundation

There are many approaches to implementing an enterprise browser, and there is no single correct path. It requires significant effort on both the cloud and browser sides. However, given the AI tooling available today, the barrier to entry is significantly lower than it was just a few years ago.

My approach leverages Chromium’s modular architecture while maintaining a clean “downstream” build model:

Protocol Compatibility: Use Chromium’s existing protobuf interfaces for management services.
Identity: Rely on a third-party IdP (Identity Provider), as identity management is its own domain.
De-Google: Gradually remove Google service dependencies from Chromium components, replacing them with custom implementations.
Branding: Apply custom branding to establish a unique identity.
Build System: Instead of a messy fork, I use a sibling browser layer model to manage downstream updates.

The “eb” Build Tool

I created the eb (Enterprise Browser) build tool, heavily inspired by Brave’s tooling. It pulls a specific Chromium tag and patches the source to include the enterprise_browser layer as a sibling to the standard /chrome directory.

Enterprise Browser Cloud Management (EBCM)

This is where policy rules are defined and assigned to users via JIT (Just-In-Time) provisioning. EBCM integrates with a third-party IdP to provide user authentication and maps policies to specific user roles.

Enterprise Browser Device Management Server (EBDM Server)

The EBDM acts as the backend authority:

OIDC Authentication: The browser presents a signed ID token issued by the IdP to prove identity.
Policy Fetching: The server sends a protobuf payload containing settings (e.g., “Disable Incognito”).

Sign-in & Policy

I adapted Chromium’s OIDC authentication interceptor to authenticate users directly against my EBCM via the IdP. Currently, the system supports global policy settings driven through Chromium’s device management protobuf definitions.

The project is available on GitHub:

Note: The project is currently in a very early prototyping stage.

This lays the foundation. Deeper dives into enterprise browser architecture will follow.

Ladybird Browser in an Embedded Web Runtime

Jani Hautakangas — Sat, 29 Nov 2025 10:44:57 +0000

Originally posted on Medium

In my previous blog post, I showed how to build and create an experimental web runtime using Isar, Debian Bookworm, and WPEWebKit. In that post, I also mentioned that I had a Ladybird version incubating. Now it’s time to reveal it.

Ladybird is a completely new browser, built from scratch instead of relying on any existing browser codebases. It has its roots in SerenityOS, but has since diverged into its own project. The project is still in its early phases, so I didn’t expect much to work. To my surprise, it’s already rendering pages quite well. Even WebGL works!

Integrating Ladybird

Ladybird depends on components that aren’t available in Debian Bookworm, such as the Skia and ANGLE graphics libraries. For those, I created dedicated recipes.

It also requires newer versions of some Debian libraries that aren’t in Bookworm or its backports repository (e.g. libpng with APNG support). For those, I ended up creating a backports repository of my own.

Custom Debian Backports

I created a new GitHub repository, debian-backports, which includes a GitHub Actions workflow that downloads package source tarballs from upstream repositories and overlays Debian build rules.

The workflow uses QEMU to build both amd64 and arm64 versions of the Debian packages. Finally, it publishes the APT repository (created with reprepro) to GitHub Pages.

The repository is available at: kodegood.github.io/debian-backports

Isar/BitBake Recipes

As mentioned, I wrote new recipes for some dependencies like Skia and ANGLE, and then for Ladybird itself.

I also applied a couple of patches on top of Ladybird. The main one strips out the browser chrome from Ladybird’s UI, since that’s not needed in a web runtime.

Ladybird uses Qt as its UI library on Linux and Windows. For now, I simply commented out parts of the code, but since Ladybird has a web content view API, a better long-term approach would be to implement a separate lightweight Qt content view.

Demo

The demo setup is similar to what I had with the WPE version

Debian Bookworm as the base platform
A slightly customized Weston IVI-shell
Ladybird browser, built from source
Hardware: Raspberry Pi 5

Known issues:

IME integration is not working, meaning no virtual keyboard
YouTube is not working. For now, Big Buck Bunny plays via a local page and local file using the video tag

Results

From the build configuration menu you can select Ladybird to be built.

Finally, after flashing the image to the Raspberry Pi 5:

Note: This is just a tech demo, not a full production web runtime

If you’d like to try it, the project’s README has setup instructions.

The project is available on GitHub as webruntime-debian.

Build Embedded Debian Web Runtime with the Power of Isar

Jani Hautakangas — Sat, 29 Nov 2025 10:29:11 +0000

Originally posted on Medium

When most people think about building something for embedded devices, Yocto is the first tool that comes to mind.

But there’s another option worth considering, one that blends the stability of Debian with the flexibility of BitBake. In this post, I’ll walk you through how I used Isar (Integration System for Automated Root filesystem generation), Debian Bookworm, and WPEWebKit to create an experimental embedded web runtime running on a Raspberry Pi 5 and Intel NUC, and why this approach might be worth trying in your next project.

Why Isar?

The build process in Isar will feel familiar if you’ve worked with Yocto: each component is defined in a BitBake recipe, and you can create dependency trees in the same way.

The biggest difference is that Isar builds everything around Debian tooling and packaging. It fetches packages directly from upstream Debian repositories, giving you stable and well-tested packages out of the box.

That said, you can still build from source, customize configurations, and add your own packages.

I’ve been using Isar for some time in a client project to create and maintain Debian platforms for a fleet of industrial PCs. Ever since, I’ve thought it would be a handy tool for creating an embedded web runtime. So, I decided to give it a try and figured others might be interested in the process too.

The Demo Setup

For this demo, I used:

Debian Bookworm as the base platform
A slightly customized Weston IVI-shell
WPEWebKit, built from source (version 2.48.3)
Hardware: Raspberry Pi 5 and an old Intel NUC (still in its box after many years!)

For configuration, I used kas (a tool that makes it easy to set up BitBake-based projects) and kas-container to run the build in a container, avoiding the need to install Isar and its dependencies locally.

Implementation

I started by creating a configuration structure for my needs, plus BSP layer recipes for the Raspberry Pi 5 and Intel NUC.

I implemented a few Weston modules to make the system UI look more polished than the default Weston setup.

Next, I wrote the recipes to build the Weston modules and WPEWebKit.
I wanted Weston to run as a dedicated webruntime user, which required additional configs and PolicyKit rules.

Getting WPEWebKit up and running took several iterations, a few quirks, and some patching here and there but eventually it worked.

Results

The result was a config screen where you can select the desired build configuration:

Once you hit Build, you’ll see the familiar BitBake process in the terminal:

Finally, after flashing the image to the Raspberry Pi 5:

Note: This is just a tech demo, not a full production web runtime. Each application launches a separate WPEWebKit instance, and there’s no runtime manager to coordinate them.

If you’d like to try it, the project’s README has setup instructions.

Debian 13 support is already in progress, and there’s an experimental branch with early Ladybird browser engine integration but it’s not finished and currently does not even compile.

The project is available on GitHub as webruntime-debian.