DuckDuckGo on Windows: WebView2 and Tracker Blocking

This article explores how the DuckDuckGo browser for Windows utilizes Microsoft's Chromium-based WebView2 runtime to render web pages while simultaneously layering its own proprietary tracker blocking lists. By combining an operating system-level rendering engine with custom network interception and script injection, DuckDuckGo delivers a lightweight, privacy-focused browsing experience without the need to maintain a full fork of the Chromium source code.

The WebView2 Foundation

Unlike browsers such as Brave or Vivaldi, which fork and modify the massive Chromium codebase, DuckDuckGo for Windows builds its browser on top of Microsoft Edge WebView2. WebView2 is a runtime component built into Windows that allows developers to embed web content into native applications using the Chromium engine.

By using WebView2, DuckDuckGo avoids the heavy engineering overhead of compiling and updating Chromium on its own. Instead, it relies on the underlying Windows operating system to keep the core rendering engine secure and up to date, while DuckDuckGo builds the user interface and privacy features as a native Windows wrapper around that engine.

Network Request Interception

Because DuckDuckGo does not modify the Chromium source code directly, it must apply its tracker blocking lists externally. It achieves this by utilizing WebView2’s built-in network interception APIs.

When you load a webpage in DuckDuckGo, the browser registers an event handler with the WebView2 runtime—specifically hooking into the WebResourceRequested event. This allows the DuckDuckGo application to pause and inspect every single network request (such as scripts, images, and stylesheets) the Chromium engine attempts to make before the request actually leaves your device.

Layering the Tracker Radar Lists

Once DuckDuckGo intercepts a network request from WebView2, it evaluates the request against its own local database, known as the DuckDuckGo Tracker Radar. This is a continually updated, proprietary list of known third-party tracking domains, scripts, and behavioral profiles.

The process works in milliseconds:

  1. WebView2 attempts to fetch a resource from a URL.
  2. DuckDuckGo intercepts the URL and checks the domain against its local Tracker Radar blocklist.
  3. Checks are also made against a list of exceptions to ensure blocking the tracker won't break the website's core functionality.
  4. If the URL is identified as a tracker, DuckDuckGo instructs the WebView2 API to cancel the request or return an empty response. The tracker is blocked before any connection to the third-party server is established.

Script Injection for Advanced Protection

Blocking network requests via lists is only part of DuckDuckGo's privacy layer. Modern trackers also use browser fingerprinting and first-party cookies, which cannot be stopped by domain blocklists alone.

To combat this, DuckDuckGo uses another WebView2 feature that allows the host application to inject custom JavaScript into a webpage before any of the website's own scripts are allowed to run. DuckDuckGo injects its own privacy scripts into the WebView2 environment to alter or restrict access to specific browser APIs (like canvas, audio, or battery status) that trackers use to fingerprint your device. This same injection method is used to automatically detect and hide cookie consent pop-ups, selecting the most private options on the user's behalf.

Isolating Browser Telemetry

A common concern with using a Microsoft-provided Chromium runtime is underlying telemetry. DuckDuckGo addresses this by configuring the WebView2 environment parameters upon launch to disable crash reporting and usage data collection that would normally go to Microsoft or Google. Furthermore, because WebView2 is purely a rendering component and not the full Microsoft Edge browser, it lacks the built-in bloatware, shopping extensions, and account-syncing services found in standard Chromium browsers.