Where a Website Meets Chromium

Chromium separates untrusted web execution from privileged browser services. The renderer contains Blink and JavaScript execution. The browser process owns tabs, profiles, permissions, and most policy. Dedicated utility, audio, video, network, and GPU processes perform narrower jobs. Mojo interfaces carry typed messages between those processes.

That separation is a security property, not an inconvenience to work around. This fork keeps the renderer sandbox and changes policy at the narrowest layer that already owns each decision.

flowchart LR
  Site[Website JavaScript] --> Blink[Blink DOM and Web APIs]
  Blink --> Renderer[Sandboxed renderer process]
  Renderer <-->|Mojo IPC| Content[Content browser layer]
  Content --> Chrome[Chrome UI, profiles, permissions]
  Content --> Utility[Audio/video/utility processes]
  Utility --> Device[OS or private media source]
  Content --> PM[Performance Manager]

Chromium’s own multi-process architecture document describes the browser/renderer split and the corresponding host objects. Blink’s renderer overview then divides web-platform implementation into core and modules.

When JavaScript reads document.hidden, asks document.hasFocus(), handles a keydown, calls navigator.clipboard.readText(), or inspects screen, it is executing a Web API implemented by Blink. The relevant code is mostly under:

• third_party/blink/renderer/core for the DOM, editing, input, focus, and window model;
• third_party/blink/renderer/modules for APIs such as Clipboard and Idle Detection; and
• third_party/blink/renderer/platform for generated runtime-feature state.

Changing only JavaScript prototypes after page load would be shallow. A page could keep an early reference, use a different realm, compare descriptors, or reach another code path. This project instead changes the C++ implementation that supplies the value or performs the default action. For example, Document::hidden() returns the hardened value at the native getter, while FocusController changes the renderer’s web-facing focus decisions.

Renderer hooks are not automatically enough. A renderer receives lifecycle state from the browser process, and a camera request eventually leaves Blink. Those flows also need browser-side changes.

Code under chrome/ is product behavior layered on Content. This is where the fork adds controls a user can see and operate:

• camera, microphone, and location source selection inside the normal permission experience;
• a red boundary for private named profiles and a blue boundary for the shared application-accessible profile; and
• a Website view editor inside chrome://settings/privacy.

The Website View editor uses a WebUI message handler rather than granting a web page filesystem access. The TypeScript component sends a privileged WebUI message; WebsiteViewHandler reads or atomically writes HardenedWebsiteView.json beneath the active profile. Ordinary websites cannot call that handler.

sequenceDiagram
  participant U as User
  participant S as chrome://settings
  participant H as WebsiteViewHandler
  participant P as Profile JSON
  participant C as Content policy cache
  participant W as Website
  U->>S: Edit and save policy
  S->>H: WebUI message
  H->>P: Atomic write
  C->>P: Asynchronous refresh
  W->>C: Request camera/mic/location
  C-->>W: Exact-origin or profile-default source

Blink runtime-enabled features are generated controls used throughout the renderer. Chromium explicitly supports downstream overrides in runtime_enabled_features.override.json5, as described by the upstream runtime-feature documentation.

This fork defines two important modes there:

• HardenedPrivacyMode, which gates the compatibility-breaking privacy and user-agency behavior; and
• HardenedCurrentScreenOnly, which narrows the web-visible display model independently.

The same override file removes a set of powerful or high-entropy APIs from the default build. Command-line switches carry configuration that must be known at process start. Content explicitly propagates relevant switches to renderers or utility processes; otherwise adding a browser-process flag would not affect the process that implements the API.

There are three different expectations, and mixing them produces misleading claims:

1. A standards contract. Specifications define properties, events, permissions, and algorithms. Deliberately returning a different lifecycle value can be a compatibility break even when it serves the fork’s goal.
2. A Chromium implementation choice. Timer throttling, process allocation, freezing, and automatic discarding include browser policy beyond the basic Web API contract.
3. A site’s inference. A site can combine standards-visible values with timing, rendering, network, input, and device observations. No single property proves the real host state.

The next articles use “suppressed,” “redirected,” “filtered,” or “virtualized” for the mechanism actually implemented. “Bypass” is reserved for the narrower cases where a page cancels a user action and the hardened browser deliberately performs its protected default anyway.

The public repository intentionally carries every file added or changed by the fork, while omitting hundreds of thousands of unchanged Chromium files and its large upstream history. A builder checks out the pinned upstream revision and restores the overlay paths on top.

This makes the public repository reviewable and small, but it changes how a reader interprets it. A large file in the overlay is not necessarily entirely new; often only a small native hook differs from upstream. The meaningful review is the comparison against the documented base revision. Porting to a newer Chromium release likewise means replaying and validating those semantic hooks, not copying old files blindly over a new tree.

This architecture can reduce or substitute specific signals. It cannot prove that a site will view the browser as stock Chromium, nor can it make unrelated fingerprint surfaces disappear. The changed binary is itself a distinct user agent implementation. Always-visible documents and foreground-scheduled tabs can also create unusual timing and resource patterns.

That is why the rest of this series pairs every mechanism with its residual signals and compatibility cost.

Next: Changing What a Website Can Observe →