Architecture

How Clearcote layers privacy and identity control onto Chromium — transparently.

The stack

Clearcote is a thin, auditable stack. Each layer is open and replaceable:

text

            Chromium  (Google, BSD-3)
                |
   ungoogled-chromium  ->  removes Google services, telemetry, integration
                |
       Clearcote patches  ->  engine-level identity & privacy controls
                |
   reproducible build  ->  checksummed, signed, rebuildable by anyone
                |
        Clearcote Browser  +  Playwright / Puppeteer drop-in

Engine-level, not script injection

Most "stealth" tooling injects JavaScript to overwrite navigator properties at runtime. That is brittle and self-revealing — the overrides themselves become a fingerprint (wrong prototype chains, getter timing, missing native code stringification).

Clearcote instead modifies the C++ engine. The values a page reads are produced by the same code paths Chromium always uses, so there is no injected layer to detect. This covers APIs that JavaScript can't cleanly intercept at all.

Coherent, per-site identity (farbling)

Randomizing each signal independently produces an identity that doesn't add up — a dead giveaway. Clearcote derives all signals from a single seed, combined with the site's registrable domain, so values are:

Internally consistent — platform, GPU, timezone and locale agree with each other.
Stable per site — the same site sees the same identity across a session.
Decorrelated across sites — different domains see different values, so you aren't linkable across the web.

This per-eTLD+1 model is inspired by Brave's farbling approach.

Coherent persona — one seed, one believable machine

Clearcote goes a step beyond per-signal noise. A single --fingerprint seed derives one coherent Windows persona — a single believable machine whose properties agree with each other. From the seed it draws a hardware tier (CPU cores and RAM that actually ship together — never 20 cores with 4 GB), a matching screen resolution, colour depth and device-pixel ratio, a coherent GPU, and a real Chrome version.

Hardware-class properties stay constant for the session — a real machine doesn't change its core count or screen size between sites — while the noisy per-render surfaces (canvas, WebGL pixels, audio) remain per-site farbled, so you stay decorrelated across domains.

Why it matters: the strongest modern detection signal isn't any single value, it's internal contradiction — a machine that claims one OS but renders like another, or pairs a high-core CPU with too little RAM. Deriving every signal from one persona table guarantees they tell the same story. It runs off the same --fingerprint seed you already pass (no new flags), and is Windows-only by design.

What it controls

Canvas 2DWebGL rendererAudioContextFontsTimezoneUser-Agent + UA-CHhardwareConcurrencydeviceMemoryScreen geometryClient rectsnavigator.webdriverHeadless hintsClosed shadow rootsWebRTC proxy-IP

Build target

The current target is Windows x64, cross-compiled from Linux against Chromium 149. The full recipe — and every cross-build gotcha — is documented so anyone can reproduce it. See Build from source.