Building a privacy-respecting browser on Chromium is not primarily a philosophical challenge. It is an engineering challenge. Chromium’s architecture assumes the presence of Google services at every level of the stack. Removing them is not a matter of deleting a few files; it requires understanding which calls are load-bearing, which are optional, and which are so deeply embedded that removing them breaks something upstream.
This is a technical account of how we approach that problem. We focus on the categories of modifications we make, the reasoning behind each, and the places where we had to accept trade-offs. We don’t publish our full patch set as open source at this stage (we are a small team and cannot maintain the support load), but we believe the engineering community deserves to understand how this class of work is done.
Why Chromium
The decision to build on Chromium rather than Firefox or a from-scratch engine is worth stating explicitly, because it is the question we get most often.
Web compatibility is the overriding concern. Chromium has the largest site-compatibility surface area of any browser engine. Sites are tested on Chrome and assumed to work on Chrome. Sites that break in Safari usually fix themselves quickly because Safari users complain and developers care about Apple users. Sites that break in an obscure privacy browser built on a different engine do not get fixed; they just lose those users.
V8 is also the most heavily hardened JavaScript engine in existence. The security research effort that has gone into V8 over fifteen years is not something a small team can replicate. The hardened JIT compiler, the memory safety work, the sandbox architecture — these are real and important. Throwing them away for architectural purity is a trade-off we are not willing to make.
The correct framing is: Chromium is the right foundation; the surveillance infrastructure built on that foundation is not part of the deal.
The Google services layer: what it is
Chromium is genuinely open-source. Google Chrome is Chromium plus a layer of proprietary Google services tightly integrated into the browser’s normal operation. Some of these services are benign or useful; some are surveillance infrastructure. Most are somewhere in between. The relevant categories for our work:
Google Update (Omaha/Keystone). The update mechanism that checks for new browser versions and installs them. Chromium itself has an update stub; it contacts Google servers. We replace this with our own update infrastructure.
Google Safe Browsing. Two modes exist: Standard Safe Browsing (local list updated periodically, no URL-by-URL transmission) and Enhanced Safe Browsing (sends every URL to Google in real time). Standard mode is privacy-acceptable; Enhanced is not. We keep Standard mode, remove Enhanced, and do not offer Enhanced as an option.
RLZ tracking. A protocol that encodes information about how Chrome was installed and links it to search queries. Used by Google to attribute search traffic to Chrome. We remove RLZ entirely.
Field trial seeds (Finch). Chromium receives experiment configuration from Google servers that controls feature flags, A/B test groups, and behaviour changes without a browser update. The identifier used to request these seeds can be used to correlate your browser instance across sessions. We remove Finch entirely; features are configured at build time.
UMA / crash reporting. User Metrics Analysis: the telemetry pipeline described elsewhere. We remove the UMA client and replace crash reporting with our own opt-in infrastructure.
Google Sign-In integration. Chromium includes UI for syncing browsing data to a Google account. We remove the Google-specific sync UI entirely; users who want account-based features use Dart’s own account system.
Google APIs in the address bar. Chromium’s omnibox sends keystrokes to Google for search suggestions and URL completion by default. We replace the default search provider architecture to use user-configured providers; there is no hard-coded Google fallback.
What we keep
We want to be precise about what we keep, because the answer is not “nothing Google.”
V8, Blink, and the core rendering engine. These are the parts of Chromium that make web pages work. We keep them in full and track Chromium’s upstream for security patches.
Standard Safe Browsing. The local-list version provides meaningful protection against known phishing and malware sites without transmitting individual URLs. The trade-off between privacy and safety here is acceptable; we document it clearly.
Certificate Transparency infrastructure. CT logs are public and don’t leak browsing data. We keep CT enforcement.
Chrome Root Store. The certificate root store maintained by Google is technically sound and widely used. We keep it with the option for enterprise customers to customise it.
WebAuthn/FIDO2 implementation. Chromium’s passkey and hardware security key implementation is one of the best available. We keep it and extend it with our own hardware identity layer.
The hard patches: Finch removal
Removing Finch (Chrome’s field trial system) was the hardest single patch we wrote. Finch is deeply embedded in Chromium’s feature flag system; many features in the codebase check their state against Finch-controlled experiments. When Finch is removed naively, features that are Finch-controlled become undefined in their state, and the browser behaves unpredictably.
Our approach: we replaced the Finch client with a stub that returns build-time-baked feature states. For each Finch-controlled feature we care about, we made an explicit decision at build time about the correct state for Dart (enabled or disabled) and hardcoded it. This required auditing several hundred feature flags, which was labour-intensive but has the advantage of making our feature configuration fully deterministic: the same source tree always produces the same browser behaviour, with no dependency on what a Google server decided to send us this week.
The hard patches: omnibox telemetry
The omnibox (address bar) in Chromium is architecturally coupled to search provider suggestions in a way that makes it difficult to separate “user is typing a URL” from “send this keystroke to Google.” The suggestion pipeline is event-driven and the Google provider is the default with special-case handling throughout the codebase.
Our modification: we removed the special-case handling for the Google search provider, made the search provider list fully user-configurable with no hard-coded defaults, and changed the suggestion pipeline to only fire network requests when a non-Google provider is configured by the user. The result is that address bar keystrokes produce local history and bookmark completions instantly, and send to a search provider only if the user has configured one and has typed enough characters to qualify as a search intent.
What we didn’t remove (and why)
CRLSets — compressed certificate revocation lists distributed by Google and baked into Chrome — are checked on a schedule. This involves a network request to Google’s update infrastructure. We keep this because certificate revocation checking is a meaningful security function, and the alternative (OCSP) is both slower and more privacy-invasive (it reveals which sites you’re visiting to the CA). We document this in our security page.
Staying current with Chromium upstream
The ongoing engineering cost of a Chromium fork is not writing the patches; it is maintaining them as Chromium evolves. Chromium produces a new major version approximately every four weeks. Each merge requires rebasing our patch set against the new tree, resolving conflicts, and verifying that nothing broke.
We track Chromium’s stable channel with approximately a two-week lag to allow time for rebase and testing before shipping. Security patches to Chromium that are classified as critical (CVE score 9.0 or higher) are cherry-picked immediately and shipped as out-of-band updates, regardless of where we are in the release cycle.
This is the most resource-intensive part of maintaining a Chromium fork and the reason many privacy-focused Chromium forks have struggled to stay current. We have invested heavily in build automation and regression testing to make this sustainable for a small team.
The layer we add
Removing Google’s surveillance infrastructure produces a browser that is more private than Chrome but is not yet Dart. The features that make Dart distinct — the local AI agent, hardware-bound identity, BYOM model layer — are built on top of the cleaned Chromium base as new extensions to the browser architecture, not as modifications to Chromium’s core code.
This separation matters for maintainability: Chromium upgrades affect the base layer but not our extensions, which reduces the surface area of every rebase. It also means that our privacy modifications and our feature additions can be reasoned about independently.
We will publish more technical detail about the agent and identity architectures in future posts. If you have specific questions about the Chromium modifications described here, write to security@dartbrowser.com.