Architektur

Wie Clearcote Datenschutz- und Identitätskontrollen auf Chromium aufsetzt — transparent.

Der Stack

Der offene Build ist ein schlanker, prüfbarer Stack. Jede Schicht ist offen und austauschbar:

text

            Chromium  (Google, BSD-3)
                |
   ungoogled-chromium  ->  removes Google services, telemetry, integration
                |
       Clearcote patches  ->  engine-level identity & privacy controls
                |
   reproducible build  ->  checksummed, GPG-signed, rebuildable by anyone (open build)
                |
        Clearcote Browser  +  SDK (Playwright objects) / CDP endpoint

Der lizenzierte Build („Kostenlos mit GitHub“ und Pro) ergänzt diesen Stack um Patches, die nicht öffentlich sind. Er wird beim Download per SHA-256 verifiziert, lässt sich aber nicht aus öffentlichem Quellcode nachbauen.

Auf Engine-Ebene statt per Script-Injection

Die meisten „Stealth“-Tools injizieren JavaScript, um navigator-Eigenschaften zur Laufzeit zu überschreiben. Das ist fragil und verrät sich selbst — die Überschreibungen werden selbst zum Fingerprint (falsche Prototypketten, Getter-Timing, fehlende Native-Code-Stringifizierung).

Clearcote ändert stattdessen die C++-Engine. Die Werte, die eine Seite ausliest, entstehen in denselben Codepfaden, die Chromium immer nutzt — es gibt also keine injizierte Schicht, die sich erkennen ließe. Das umfasst auch APIs, die JavaScript überhaupt nicht sauber abfangen kann.

Kohärente Identität, Render-Rauschen pro Website (Farbling)

Wer jedes Signal unabhängig randomisiert, erzeugt eine Identität, die nicht zusammenpasst — und fällt damit sofort auf. Clearcote leitet die Persona aus einem einzigen Seed ab und das Render-Rauschen aus diesem Seed in Kombination mit der registrierbaren Domain der Website:

In sich stimmig — Plattform, GPU, Bildschirm und Hardware passen zueinander; Zeitzone und Sprache kommen aus Ihren Optionen oder aus geoip.
Stabil pro Website — dieselbe Website sieht während einer Session dieselbe Identität.
Render-Rauschen pro Website — Canvas- und WebGL-Readbacks unterscheiden sich von Website zu Website, sodass Render-Hashes über Domains hinweg nicht übereinstimmen. Werte der Hardwareklasse bleiben überall gleich, so wie bei einem echten Rechner.

Dieses Rauschmodell pro eTLD+1 ist von Braves Farbling-Ansatz inspiriert. Das Rauschen ist an den Seed gekoppelt: Ohne --fingerprint-Seed gibt es keines.

Kohärente Persona — ein Seed, ein glaubwürdiger Rechner

Clearcote geht einen Schritt über Rauschen pro Signal hinaus. Aus einem einzigen --fingerprint-Seed entsteht eine kohärente Persona für die Plattform, die Sie nach außen präsentieren — ein einzelner glaubwürdiger Rechner, dessen Eigenschaften zueinander passen. Standardmäßig präsentiert das SDK Ihr Host-Betriebssystem (Windows oder Linux); ein macOS-UA und eine Android-Persona auf Best-Effort-Basis sind auf Wunsch verfügbar. Aus dem Seed zieht es eine Hardwarestufe (CPU-Kerne und RAM, die tatsächlich zusammen verbaut werden — nie 20 Kerne mit 4 GB), eine passende Bildschirmauflösung, Farbtiefe und Device-Pixel-Ratio, eine kohärente GPU und eine echte Chrome-Version.

Eigenschaften der Hardwareklasse bleiben während der Session konstant — ein echter Rechner ändert seine Kernzahl oder Bildschirmgröße nicht von einer Website zur nächsten —, während die veränderten Render-Oberflächen (Canvas- und WebGL-Pixel) pro Website per Farbling verrauscht bleiben, sodass Sie über Domains hinweg dekorreliert bleiben. Client-Rects und gerendertes Audio werden nicht verändert — allerdings kommen sampleRate, baseLatency und outputLatency von AudioContext aus der Persona, sobald eine aktiv ist; was per Farbling verrauscht wird und was bewusst nicht erklärt diesen Kompromiss.

Warum das wichtig ist: Das stärkste Signal moderner Erkennung ist kein einzelner Wert, sondern ein innerer Widerspruch — ein Rechner, der ein Betriebssystem behauptet, aber wie ein anderes rendert, oder der eine CPU mit vielen Kernen mit zu wenig RAM kombiniert. Werden alle Signale aus einer Persona-Tabelle abgeleitet, erzählen sie dieselbe Geschichte. Das Ganze läuft über denselben --fingerprint-Seed, den Sie ohnehin übergeben (keine neuen Flags).

Es gibt drei Wege, eine Identität darzustellen: das light-stealth-Preset (einige Metadatenwerte, kein Seed, kein Rauschen), die oben beschriebene Seed-basierte Persona oder ein erfasstes Profil eines echten Rechners (fingerprint_profile oder profile="auto" aus der lizenzierten Profilbibliothek). Womit Sie am besten anfangen, steht unter Empfehlungen.

Was Clearcote steuert

Canvas 2DWebGL-Renderer (GPU pro Session konstant)WebGL-getParameter-LimitsWebGPU-AdapterSchriftartenZeitzoneSprache (Accept-Language, navigator.languages, Intl)User-Agent + UA-CHTLS-ClientHello-Persona (JA3/JA4)hardwareConcurrencydeviceMemoryBildschirmgeometrieSpeicherkontingentnavigator.webdriverHeadless-HinweiseGeschlossene Shadow RootsWebRTC-Proxy-IPnavigator.getBatterynavigator.connectionTastaturlayout-MapgetScreenDetails / mehrere BildschirmeCSS-Media-Features pointer/hoverAudioContext-Metadaten (Samplerate / Latenz)Sprachsynthese-Stimmennavigator.shareOS-Kohärenz von Laufwerksbuchstaben in URLsKI-Agent im BrowserMediaCapabilities-CodecsenumerateDevicesUA-CH bitness/WoW64

Build-Ziel

Der offene Build zielt auf Windows x64 (per Cross-Compile unter Linux gebaut) und Linux x64 (nativ), auf Basis von Chromium 149; der lizenzierte Build basiert auf Chromium 153. Das vollständige Rezept des offenen Builds — samt jeder Stolperfalle beim Cross-Build — ist dokumentiert, damit es jeder nachbauen kann. Siehe Aus dem Quellcode bauen.