Website View, Automation Signals, and the Shared Browser

The WebDriver specification defines a webdriver-active flag and exposes it through navigator.webdriver. Standards- conforming automation uses that signal so content can know that the user agent is under remote control.

Chromium also changes renderer feature state for some debugging launch modes. In this fork, launching with remote debugging port zero was associated with the AutomationControlled path. The service and launchers therefore use a fixed, non-zero loopback port—9222 by default—and refuse zero.

That reduces two direct signals:

1. the port-zero launch path is avoided; and
2. a renderer switch can make the native Navigator::webdriver() getter return false.

It does not erase all side effects of DevTools Protocol control.

Each automation or named profile can own a file called HardenedWebsiteView.json. The default document has schema version 3, one profile baseline, and a list of exact-origin rules.

A simplified example looks like this:

{
  "schemaVersion": 3,
  "default": {
    "cameraSource": "fake",
    "microphoneSource": "fake",
    "locationSource": "fake",
    "persona": {},
    "exposures": {
      "automation": "hide"
    }
  },
  "rules": [
    {
      "origin": "https://example.test",
      "cameraSource": "real"
    }
  ]
}

The actual default contains named persona and exposure fields. The important contract is structural:

• default supplies the profile baseline;
• rules override selected values for exact HTTP(S) origins;
• unknown expert fields are retained rather than silently discarded; and
• schema normalization never invents a different persona to make invalid input look successful.

hardened_website_view.py normalizes documents, canonicalizes origins, resolves policy, preserves future fields, writes atomically, and produces warnings. Origin validation rejects paths, credentials, non-HTTP schemes, invalid ports, queries, and fragments.

The editor is embedded under chrome://settings/privacy. It intentionally shows the raw JSON document so an expert can edit the full stable contract.

The page component website_view.ts uses sendWithPromise to call getHardenedWebsiteView and setHardenedWebsiteView. The browser-side WebsiteViewHandler resolves those WebUI messages, validates the minimum document shape, forces the current schema version, and atomically writes inside the active profile.

This interface is privileged Chrome WebUI, not an HTTP endpoint available to arbitrary sites. A normal page cannot use it to read another profile’s policy file.

The Chrome DevTools Protocol is powerful enough to inspect and control pages. Giving every application the endpoint would also give it broad control over the shared profile. Hardened Chromium instead keeps CDP private and exposes a narrower application protocol.

flowchart LR
  subgraph Clients[Local applications]
    A[App A]
    B[App B]
  end
  A -->|app identity + secret| Broker
  B -->|app identity + secret| Broker
  Service[Service owner/health manager] --> Broker[Loopback broker]
  Service --> Browser[One visible Chromium]
  Broker -->|private CDP| Browser
  Browser --> TA[App A tab]
  Browser --> TB[App B tab]
  Broker --> Store[Jobs, events, schemas, outputs]

The stable entry point is hardened-chromium-service. capabilities discovers the protocol without starting Chromium. ensure serializes concurrent callers, starts missing components once, and returns an authenticated broker description. status probes without mutation. Browser closure and broker restart have separate ownership rules so a service repair does not silently close the user’s window.

The shared default profile is visibly marked with a blue border because local applications can create and control tabs within it. Named private profiles use a red boundary under hardened privacy and are not exposed to broker clients. Blue takes precedence when a profile is application-accessible.

Each job event has an application ID, job ID, per-job sequence, timestamp, type, and data. Subscription establishes one atomic boundary between retained replay and live fanout, avoiding a gap during connection setup.

Clients persist the latest sequence they processed. If retained history no longer covers that cursor, the broker emits resync_required; the client reads current REST state and resumes from the reported latest sequence. Slow readers have bounded queues and are closed rather than consuming unbounded memory.

The design keeps live fanout ahead of batched JSONL persistence so synchronous disk writes do not sit on the WebSocket latency path.

Several constraints are deliberate:

• CDP binds only to loopback and uses a non-zero port.
• Apps use the broker instead of discovering or receiving the CDP endpoint.
• Authentication mode cannot be silently mixed between token and no-auth clients on the same broker.
• The browser renderer sandbox remains enabled.
• Named private profiles are not application backends.
• Source choice never grants camera, microphone, or location permission.
• Closing the shared browser requires a distinct confirmed operation.

No-auth mode exists for deliberate trusted loopback setups, but every caller must use it consistently. Loopback is a network boundary, not proof that every local process is trustworthy.

navigator.webdriver === false is not a complete identity. A site can still look for:

• behavioral regularity or missing human input;
• CDP-induced timing and page-state effects;
• unusual background execution and stable visibility/focus values;
• virtual media content, capabilities, labels, and performance;
• disabled APIs or compatibility differences;
• rendering, canvas, WebGL, font, audio, and client-hint surfaces not yet normalized by Website View;
• network address, TLS, proxy, and request-pattern signals; and
• the distinct behavior of this compiled fork.

The defensible claim is narrow: the project changes specific browser-reported signals, protects selected user defaults, virtualizes selected sources, and mediates local automation through a smaller control plane. It is not a proof of non-detectability, and the warning system is designed to keep that limitation visible.

← Previous: Protecting User Actions and Physical Devices · Back to the series index