DEV Community: Jani Hautakangas

How to Build an Enterprise Browser — Branding

Jani Hautakangas — Tue, 26 May 2026 16:22:01 +0000

In the first post I sketched out what an enterprise browser is and laid the foundation for my proof-of-concept, enterprise-browser-chromium. One bullet in that post was “Branding: Apply custom branding to establish a unique identity.” In practice that one bullet means touching strings, themes, build flags, installer code, Mac bundles, Windows resource sections, and Linux desktop files. This post is dedicated to that one bullet.

What “branding” really is in Chromium

Chromium ships as a generic open-source browser; Google Chrome is the proprietary product built on top of it. Anything trademarked (the Chrome logo, the “Google Chrome” name, certain installer artwork) sits behind a small set of build switches and is omitted from the public build. Branding, in source terms, is the answer to a handful of questions asked at build time: what product name to use, where icons and OS-level assets live, and what the product calls itself in the UI and installer.

How Chromium wires the branding switch

The whole branding system starts with a single GN argument declared in build/config/chrome_build.gni:

declare_args() {
  is_chrome_branded = false
  # ...
}

When that argument flips to true, Chromium’s build switches to Google’s proprietary identity. (Internally the if/else keys off a derived is_internal_chrome_branded = is_chrome_branded && enable_src_internal; the second flag pulls in Google’s src-internal repo and isn’t available to public builds.) Two path variables, set in the same file, are what the rest of the build consumes:

if (is_internal_chrome_branded) {
  branding_path_component = "google_chrome"
  branding_path_product   = "google_chrome"
} else {
  branding_path_component = "chromium"
  branding_path_product   = "chromium"
}

Almost everything else flows from those two strings:

branding_path_component selects the subdirectory inside chrome/app/theme/ for icons and artwork.
branding_path_product selects the .grd file used for branded strings.

In C++, the same switch surfaces as a BUILDFLAG. build/BUILD.gn generates branding_buildflags.h, which gives Chromium code two flags:

#if BUILDFLAG(GOOGLE_CHROME_BRANDING)
  // Google Chrome only
#elif BUILDFLAG(CHROMIUM_BRANDING)
  // Chromium (or any non-Google branded build)
#endif

In Grit (the string and resource format), the same switch appears as <if expr="_google_chrome">. In Java, it appears as BuildConfig.IS_CHROME_BRANDED.

A downstream browser tells the build about itself, supplies parallel assets, and the rest of the build picks them up automatically.

The BRANDING file

Each brand has a plain-text BRANDING file at the root of its theme directory. Enterprise Browser’s looks like:

COMPANY_FULLNAME=KodeGood
COMPANY_SHORTNAME=KodeGood
PRODUCT_FULLNAME=Enterprise Browser
PRODUCT_SHORTNAME=Enterprise Browser
PRODUCT_INSTALLER_FULLNAME=Enterprise Browser Installer
PRODUCT_INSTALLER_SHORTNAME=Enterprise Browser Installer
COPYRIGHT=Copyright @LASTCHANGE_YEAR@ Jani Hautakangas <jani@kodegood.com>. All rights reserved.
MAC_BUNDLE_ID=com.kodegood.EnterpriseBrowser
MAC_CREATOR_CODE=Cr24

build/util/branding.gni parses this file at GN time and exposes its fields as GN variables (chrome_product_full_name, chrome_mac_bundle_id, and friends). Those variables then flow into:

the Windows .rc resource that decorates the EXE with version metadata,
the Mac Info.plist template, where CFBundleIdentifier and CFBundleName are substituted from these fields,
the Linux installer scripts, which use the company and product names to generate .deb/.rpm package metadata.

The main branding topics

The diagram below shows the parallel enterprise_browser/ tree in the repo. Each topic that follows maps to one or more of these paths.

Product name strings

Chromium splits the product-name-bearing strings into two files:

chrome/app/chromium_strings.grd
chrome/app/google_chrome_strings.grd

They are structurally identical but say Chromium and Google Chrome respectively. The build chooses between them through branding_path_product:

grit_strings("branded_strings") {
  source = "${branding_path_product}_strings.grd"
}

The same pattern is repeated in components/, where there is components_chromium_strings.grd vs components_google_chrome_strings.grd, and again in the settings UI via .grdp partials.

These three pairs exist because they live in three layers: top-level browser strings, settings UI strings, and //components (which is architecturally below //chrome and cannot depend on it).

Doing this rename by hand isn't realistic: the English .grd has hundreds of Chromium mentions, multiplied by 80+ per-locale .xtb files. A broader Chrome/Chromium sweep can also mangle compound terms like ChromeOS and Chromecast, which must survive intact. The only sane path is a script.

Enterprise Browser ships an eb l10n command for this.

⚠ Caveat: a regex sweep across 80+ locales is a placeholder, not a real translation. Non-Latin transliterations and idiomatic phrasing need a real translation pipeline, which this post doesn’t cover.

Themes, icons, and platform artwork

Visual assets live in chrome/app/theme/, organized in three parallel scale tiers:

chrome/app/theme/<brand>/                   # vector + master assets, BRANDING file
chrome/app/theme/default_100_percent/<brand>/  # raster, 1x
chrome/app/theme/default_200_percent/<brand>/  # raster, 2x

Inside <brand>/, the build expects platform subdirectories: mac/app.icns, win/<brand>.ico (and a handful of file-handler icons), and linux/product_logo_*.png.

chrome/app/theme/theme_resources.grd references the in-binary UI resources here via ${branding_path_component} substitution; the platform-specific bundle assets (.icns, .ico, Linux logos) flow in through separate platform bundle and installer rules.

Enterprise Browser keeps its parallel set of these assets under enterprise_browser/app/theme/; the eb branding build step mirrors them into chrome/app/theme/enterprise_browser/ before GN runs.

The branding GN switch

Chromium’s chrome_build.gni only knows about two brands out of the box: chromium and google_chrome. To plug in a third, you have two options: patch the upstream file, or override the GN args before GN runs.

Enterprise Browser currently takes the patch route. build-config-chrome_build.gni.patch adds a new branch to the conditional:

} else if (is_enterprise_browser) {
  branding_path_component = "enterprise_browser"
  branding_path_product   = "enterprise_browser"
}

…and the new is_enterprise_browser argument is declared in enterprise_browser/build/enterprise_browser.gni:

declare_args() {
  is_enterprise_browser = true
}

This works, but carries an ongoing cost. The patch's hunk context sits inside the if / else if / else chain in chrome_build.gni. Any time upstream touches that chain (new branches, reordering, rewritten declarations), the surrounding lines stop matching and the patch needs rebasing. The breakage is mechanical, not logical, but you still have to fix it on every uprev (each time you update to a newer Chromium version).

The better long-term approach skips the patch entirely. GN args declared with declare_args() can be overridden from args.gn: your value wins, the default is skipped. Ship a branding_defaults.gni that sets branding_path_component and branding_path_product, and import it from args.gn before gn gen runs. The upstream file stays untouched, and uprevs become noticeably less painful.

Installer strings and platform packaging

The installer has its own product name, its own shortcut names, and on Windows it registers OS-level rules that include the product name.

Chromium drives a lot of this from a Python script, chrome/installer/util/prebuild/create_installer_string_rc.py. It has a MODE_SPECIFIC_STRINGS dictionary that, for each branding mode (google_chrome, chromium), lists which string IDs to emit into the installer’s resource section.

Enterprise Browser patches that script (chrome-installer-util-prebuild-create_installer_string_rc.py.patch) to add an enterprise_browser mode:

MODE_SPECIFIC_STRINGS = {
  'IDS_APP_SHORTCUTS_SUBDIR_NAME': {
    'google_chrome': [
      'IDS_APP_SHORTCUTS_SUBDIR_NAME',
      'IDS_APP_SHORTCUTS_SUBDIR_NAME_BETA',
      # ...
    ],
    'chromium': [
      'IDS_APP_SHORTCUTS_SUBDIR_NAME',
    ],
    'enterprise_browser': [
      'IDS_APP_SHORTCUTS_SUBDIR_NAME',
    ],
  },
  # ...same shape for IDS_INBOUND_MDNS_RULE_DESCRIPTION, IDS_PRODUCT_NAME, etc.
}

This is the kind of detail that is invisible until you ship a Windows build, and then it becomes a long tail of small symptoms (wrong product name in the Start menu, wrong firewall rule description, etc.) that all trace back to a few entries in this dictionary.

Vector icons inside the UI

Branding is not only the outside of the binary. Vector icons baked into the browser UI (the About-dialog product mark, the new tab page icon, the icon used in profile pickers) live in .icon files under components/vector_icons/<brand>/. Enterprise Browser ships its own product.icon and product_refresh.icon under components/vector_icons/enterprise_browser/.

UI customization: settings layout, new tab page, splash

Beyond names and icons, branding extends to the layout and content of user-facing surfaces too: chrome://settings sections, the new tab page, the first-run welcome, splash and intro screens, the profile picker, the about page. Mechanically this is different work: editing WebUI HTML/TS/CSS under chrome/browser/resources/ plus native C++ that builds the settings tree.

Enterprise Browser has made a start here. The intro flow, the first-run / splash onboarding sequence, and the profile picker are already customized, so the onboarding and sign-in surfaces are visibly Enterprise Browser.

The build-time mirroring tool

Most of the above is data: strings, themes, vector icons, the BRANDING file. The thing that applies them to the Chromium tree is a build step that mirrors your branding files into the right places under src/ before GN runs.

Enterprise Browser does the same thing in tools/eb/eb.py under cmd_branding. The mapping is exactly the parallel set: theme directories (master + both scale tiers), the XTB translation resources, the three string bundles, and the vector icons. Run as eb branding, or implicitly via eb sync.

Wrapping up

Conceptually Chromium’s branding system is a single switch that cascades through dozens of subsystems: one flag, two path variables. The implementation is messier: a long tail of #if BUILDFLAG(GOOGLE_CHROME_BRANDING) blocks, Grit <if expr="_google_chrome"> conditionals, Java checks, and per-mode entries in build scripts. Adding a new brand means making sure all those fences understand your brand.

Enterprise Browser has the foundation in place (GN wiring, theme tree, string bundles, BRANDING file, build-step mirror), but most icons and strings under those directories are still stock Chromium files copied and renamed. Most topics above are partly done at best, with branded artwork, code signing, and the updater’s own branding pipeline (chrome/updater/branding.gni is its own subsystem and isn’t covered here) still ahead. Each piece is small in isolation; most have to be re-checked on every uprev.

Repo: KodeGood/enterprise-browser-chromium.

How to Build an Enterprise Browser

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

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

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

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.