Fingerprint-Flags

Die Identität steuern Sie über Chromium-Kommandozeilen-Switches. Das SDK setzt sie anhand benannter Optionen; mit dem offenen Build können Sie sie auch als args an Ihren eigenen Launcher übergeben.

Die meisten Switches gibt es in beiden Builds. Einige sind dem lizenzierten Build vorbehalten (Kostenlos mit GitHub oder Pro) – die Switch-Liste unten kennzeichnet sie mit der Engine-Revision, in der sie hinzugekommen sind. Ohne Lizenzschlüssel startet das SDK den offenen Build, in dem diese Optionen wirkungslos sind.

Das Seed-Modell

Alles hängt an --fingerprint=<seed>. Aus dem Seed (einer Ganzzahl oder einem beliebigen String) wird die Persona deterministisch abgeleitet – und er verrauscht die beiden Render-Schnittstellen, die unten unter Wo Farbling greift aufgeführt sind:

Seit dem lizenzierten Chromium-156-Build (r51) läuft diese Ableitung im Clearcote-Persona-Dienst: Der Launcher fragt ihn bei jedem Start mit dem Run-Token der Lizenz an und übergibt die signierte Persona an den Browser, der ohne sie nicht startet. Gleicher Seed, gleiche Identität wie auf r50. Offline-Lizenzen bleiben auf r50, bis es ein Offline-Persona-Paket gibt.

• Gleicher Seed ⇒ gleiche Identität bei jedem Start auf demselben Rechner mit derselben Browser-Version – ein wiederkehrender Besucher. Alles, was eine Seite auslesen kann, kommt identisch zurück: GPU, Bildschirm, Hardware, Schriften und Stimmen sowie die Ergebnisse von Canvas, WebGL und Audio. Die einzige Ausnahme ist die geschätzte Verbindungsgeschwindigkeit (Round-Trip-Zeit und Bandbreite in navigator.connection), die wie in Chrome Ihrem echten Netzwerk folgt.
• Neuer Seed ⇒ eine frische, plausible Identität.
• Das Canvas- und WebGL-Rauschen wird pro Website abgeleitet (angelehnt an Braves Farbling), daher unterscheiden sich diese Hashes von Domain zu Domain. Die Persona selbst – GPU, Bildschirm, Hardware, Schriften – ist überall dieselbe, wie bei einem echten Rechner auch.

Derselbe Seed auf verschiedenen Rechnern

Die Grafikkarte, die eine Persona angibt, stammt vom Hersteller der Karte, mit der der Rechner tatsächlich rendert (NVIDIA, Intel oder AMD). So gehören die Pixel und Grafik-Limits, die eine Seite misst, zu der Art von Karte, die der Seite gemeldet wird. Auf einem Rechner ohne Grafikkarte gibt die Persona integrierte Grafik an: ab 154 r37 die von Intel oder AMD, unter r36 nur die von Intel. Auf Rechnern, deren Karten von unterschiedlichen Herstellern stammen, meldet ein Seed daher eine andere Grafikkarte – das ist so gewollt.

Im lizenzierten Build ab 154 r36 kann der GPU-Hersteller des Rechners auch die übrige Hardware verändern. Ein Einsteiger-Rechner hat keine dedizierte Grafikkarte. Auf einem Rechner mit NVIDIA-Karte gibt ein Seed, der Einsteiger-Hardware angeben würde (4 bis 6 Prozessor-Threads, 4 bis 8 GB Arbeitsspeicher, ein kleiner Bildschirm), deshalb stattdessen mindestens Mittelklasse-Hardware an – und nie einen Touchscreen. Etwa die Hälfte aller Seeds meldet daher auf einem NVIDIA-Rechner eine andere Zahl an Prozessor-Threads und eine andere Arbeitsspeichergröße als auf einem Rechner mit Intel- oder AMD-Grafik oder ganz ohne Grafikkarte, einige auch eine andere Bildschirmgröße. Auf Rechnern mit demselben GPU-Hersteller ist die Identität eines Seeds dieselbe.

Ab 154 r37 stammt die Auswahl an Karten, aus der die Rechner eines Herstellers schöpfen, aus echtem Browser-Traffic: Jedes Modell ist so wahrscheinlich, wie es in der Praxis vorkommt, sodass eine Flotte von Personas wie eine Flotte echter Rechner aussieht. Die meisten Seeds geben unter r37 daher eine andere Karte an als unter r36; die übrige Hardware wird wie unter r36 abgeleitet.

Seit dem 2026-10-26 (r52, und auch beim Start von r51, weil der Persona-Dienst die Identität ableitet) ist der Standard das Persona-Schema 7: Die Grafikkarte bestimmt die Art des Rechners – Laptop oder Desktop, Prozessorgeneration, Threads, Arbeitsspeicher und Bildschirm, einschließlich der Anzeigeskalierung, mit der Laptops tatsächlich laufen. Ein Seed ergibt einen anderen Rechner als vor diesem Datum.

So behält ein Seed über Rechner hinweg eine einzige Identität:

• Nutzen Sie ihn auf Rechnern mit demselben GPU-Hersteller – etwa mit einem einzigen Servertyp in der Produktion.
• Legen Sie den GPU-Hersteller fest, indem Sie --fingerprint-gpu-host-vendor=nvidia (oder intel, amd) in den args Ihres Launchers übergeben. Die Persona leitet ihre Identität dann überall so ab, wie sie es auf einem Rechner mit einer Karte dieses Herstellers täte. Legen Sie den Hersteller der Rechner fest, auf denen die Persona überwiegend läuft: Auf einem Rechner mit der Karte eines anderen Herstellers passt die angegebene Karte nicht mehr zu der, die rendert.
• Behalten Sie unter r45 bis r51 erstellte Identitäten (vor dem 2026-10-26) mit persona_schema=5 / personaSchema: 5 (--fingerprint-schema=5) und solche von 154 r37 bis 155 r44 mit persona_schema=4 / personaSchema: 4. Beide Schemas sind eingefroren: Ein Seed leitet auf ihnen dauerhaft dieselbe Identität ab.
• Behalten Sie unter 154 r36 erstellte Identitäten mit persona_schema=3 / personaSchema: 3 (--fingerprint-schema=3). Jeder Seed leitet dann Feld für Feld genau das ab, was er unter r36 abgeleitet hat – die Grafikkarte eingeschlossen.
• Behalten Sie vor r36 erstellte Identitäten mit persona_schema=2 / personaSchema: 2 (--fingerprint-schema=2). Jeder Seed leitet dann Feld für Feld genau das ab, was er unter 153 r29 bis 154 r35 abgeleitet hat: Die Grafikkarte folgt weiterhin dem Hersteller des Rechners, die übrige Hardware nicht.

Ohne Seed gibt es keine Identität pro Persona: Jeder Start auf derselben Art von Rechner sieht gleich aus. Geben Sie jeder Identität einen eigenen Seed.

Sie hätten lieber die Identität eines echten Rechners statt der synthetischen, aus dem Seed abgeleiteten? Erfassen Sie mit dem Collector ein Spender-Chrome und importieren Sie es über --fingerprint-profile=<gzip+base64 JSON> (oder die SDK-Option fingerprint_profile / fingerprintProfile, die das gzip+base64 für Sie übernimmt) – statt eines Seeds. Felder, die im Profil vorhanden sind, überschreiben, was der Browser sonst melden würde; fehlende Felder fallen auf die Standardwerte des Browsers zurück. Übergeben Sie keinen --fingerprint-Seed zusätzlich zu einem Profil: Der Seed fügt Canvas-Rauschen hinzu, das strenge Bewertungen neben den Werten eines echten Rechners als Manipulation lesen, und die Identität liefert bereits das Profil (siehe Profile und Persistenz). Beide Builds lesen importierte Profile; im lizenzierten Build greifen sie ab 151 r19 vollständig. Wie Sie ein erfasstes Profil über das SDK importieren, zeigt die Playwright-Anleitung.

Wo Farbling greift – und wo bewusst nicht

Wer eine Schnittstelle verrauscht, gewinnt Unverkettbarkeit und bezahlt mit Kohärenz – und dieser Tausch lohnt sich nicht überall. Clearcote verrauscht die beiden Schnittstellen, bei denen das Rauschen der gewöhnlichen Hardware-Streuung am nächsten kommt, und lässt den Rest unverrauscht – denn dort fällt ein verrauschter Wert stärker auf als ein geteilter. Unverrauscht heißt allerdings nicht unangetastet: Einige Werte werden trotzdem komplett durch Persona-Werte ersetzt; die Tabelle und der Hinweis darunter führen das aus. Manche Prüftools schlagen dennoch auf das Rauschen selbst an; wenn das eine Rolle spielt, schaltet fingerprintNoise: false es ab und behält die Identität bei (siehe Wie Erkennung funktioniert).

Die praktische Folge für die Arbeit mit mehreren Accounts: Canvas und WebGL trennen Ihre Identitäten, gerendertes Audio und Client-Rects nicht. Das sind Eigenschaften der Maschine darunter – derselbe Host rendert dieselbe Audio-Pipeline und setzt Text mit denselben Schriften beim selben Pixel-Ratio, egal welcher Seed geladen ist, genau wie bei zwei verschiedenen Menschen auf identischer Hardware. Korreliert eine Zielseite speziell über diese Werte, sind getrennte Rechner die Antwort, nicht ein anderer Switch.

Eine Ausnahme sollten Sie kennen: Die drei Skalare des AudioContext folgen sehr wohl der Persona. sampleRate, baseLatency und outputLatency kommen aus der Persona, sobald eine aktiv ist – über einen --fingerprint-Seed oder ein importiertes Profil –, sodass sie zwischen Identitäten variieren, statt das Audio-Backend des Hosts preiszugeben. Ist keins von beiden gesetzt, werden alle drei unverändert vom echten Rechner durchgereicht. Eine Rate, die die Seite ausdrücklich anfordert, wird nach wie vor respektiert, und outputLatency läuft weiterhin durch Chromes eigenen, berechtigungsabhängigen Quantisierer. Ab 153 r26 folgt baseLatency außerdem der Render-Größe, die die Seite anfordert, und ein Kontext, der noch nicht mit dem Rendern begonnen hat, meldet dieselbe Latenz wie ein reguläres Chrome.

Wo das Rauschen landet (r57)

Ab r57 verändert das Rauschen beim Auslesen von Canvas und WebGL im lizenzierten Build ein Pixel nur dann, wenn keiner seiner vier Nachbarn dieselbe Farbe hat. Flache Flächen – eine einfarbige Form, ein gefüllter Block, ein geleerter Hintergrund – werden genau so zurückgelesen, wie sie gezeichnet wurden, wie auf echter Hardware. Textkanten, Kurven und Verläufe tragen weiterhin das Rauschen des Seeds, sodass Profile unterschiedliche Canvas-Hashes behalten. Vor r57 wurde auch eine flache Fläche innerhalb eines Auslesens verrauscht, sodass ein Prüfer, der eine einfarbige Form zeichnet und hasht (PixelScans „Masking detected“), beweisen konnte, dass die Pixel verändert wurden.

Ein teilweises WebGL-readPixels (ein Rechteck, kleiner als die Canvas) sieht die Pixel direkt außerhalb nicht. Standardmäßig liest die Engine deshalb das Rechteck zusammen mit einem Rand von einem Pixel in einem einzigen GPU-Auslesen, sodass jedes Randpixel genau das Rauschen erhält, das ihm ein vollständiges Auslesen der Canvas gibt, und das Auslesen so lange dauert wie in Chrome.

Beide Einstellungen gelten für jede Art, wie eine Seite die Pixel lesen kann (getImageData, toDataURL, toBlob, readPixels), sodass Auslesungen einer Canvas weiterhin übereinstimmen. Engines vor r57 verhalten sich immer wie flatAreaNoise: true, und das SDK und der Profile Manager lassen beide Einstellungen dort weg. In Docker setzt du CC_FLAT_AREA_NOISE und CC_WEBGL_READ_MARGIN. Die Einstellungen gibt es ab SDK 0.68.8 und Profile Manager 0.40.0.

Kohärente sekundäre Schnittstellen

Über die verrauschten Signale hinaus sorgt die Engine dafür, dass die sekundären Schnittstellen der Persona mit einem echten Chrome auf der Plattform der Persona übereinstimmen. Standardmäßig setzt das SDK die Plattform auf das Betriebssystem Ihres Hosts; die Windows-spezifischen Werte unten gelten für eine Windows-Persona.

• WebGL-Limits (WebGL1 + WebGL2) folgen der GPU der Persona, soweit dieser Rechner sie tatsächlich einhalten kann. Ein Limit wird nie höher gemeldet, als der echte Treiber durchsetzt; auf einem Software-Renderer liegen einige Werte daher unter denen der genannten GPU.
• UNMASKED_RENDERER / UNMASKED_VENDOR bleiben für die ganze Session konstant – eine GPU auf jeder Website, passend zur Persona, statt eines verräterischen Werts pro Origin.
• navigator.getBattery() meldet einen Desktop am Stromnetz (lädt, Level 1.0, keine Entladung), navigator.connection das Profil eines Privatanschlusses (effectiveType 4g, gerundete rtt/downlink, saveData aus).
• navigator.keyboard.getLayoutMap() liefert ein US-QWERTY-Layout, und unter einer Windows-Persona meldet AudioContext die Samplerate und Latenz des Windows-Audio-Stacks.
• Hell oder dunkel – ab 154 r32 bevorzugt die Persona ein Farbschema (etwa jede dritte dunkel; --fingerprint-color-scheme=light|dark legt es fest), und prefers-color-scheme, matchMedia, der Header Sec-CH-Prefers-Color-Scheme und die CSS-Systemfarben stimmen alle überein. Das SDK (0.41.0+) lässt die Farbschema-Emulation von Playwright auf einem solchen Build ausgeschaltet, damit nichts dem widerspricht.
• Schriften – unter einer Windows-Persona hat Text die Zeilenhöhen und die gängigen Schriftbreiten eines Windows-Rechners, und Schriften, die eine Seite per Name anfordert, verhalten sich wie unter Windows (154 r32). Eine echte, auf dem Rechner installierte Schrift wird als sie selbst verwendet; unter Linux führen Sie Ihre eigenen mit fontDirs auf.
• window.getScreenDetails() meldet einen einzigen, kohärenten Monitor; @media (pointer: fine) / (hover: hover) entsprechen einem Desktop mit Maus.
• URLs – unter einer Windows-Persona liefert new URL("C:/").protocol den Wert file:, und ab 153 r26 führt jeder Weg, auf dem eine Seite eine URL bauen kann, zum selben Ergebnis. navigator.share / canShare sind passend zum Windows-UA verfügbar.
• WebGPU – Adapter-Info sowie Limits/Features von navigator.gpu folgen derselben GPU wie WebGL (im lizenzierten Build eingeschränkt auf das, was der Host leisten kann).
• Locale – Accept-Language, navigator.language, die vollständige Liste navigator.languages und Intl (Main-Thread + Worker) stammen alle aus einer Liste (acceptLanguage oder geoip). Das SDK setzt --accept-lang und --lang für Sie; wenn Sie die Switches direkt übergeben, setzen Sie beide.
• Sprachausgabe – speechSynthesis liefert die Stimmen der Persona, einschließlich der Google-Netzwerkstimmen, die ein Chrome dieser Version auflistet (153 r27). fingerprintVoices: false behält stattdessen die eigenen Stimmen des Rechners bei (152 r22).
• Hardware – der Messwert zur Prozessorgeschwindigkeit (navigator.cpuPerformance) folgt der Persona statt des echten Prozessors (152 r20), und die Speicherobergrenze für Skripte (performance.memory.jsHeapSizeLimit) folgt dem Arbeitsspeicher, den die Persona angibt (153 r26).
• Codecs & Geräte – MediaCapabilities.decodingInfo() meldet eine Codec-Matrix der Persona, enumerateDevices() einen Satz Mediengeräte der Persona (IDs stabil pro Seed, leere Labels vor der Berechtigung).
• UA-CH High-Entropy – bitness=64 / wow64=false / model; unter einer Linux-Persona ist platformVersion leer, so wie es echtes Chrome unter Linux meldet (153 r26). navigator.storage.estimate() meldet ein realistisches Speicherkontingent auf der Festplatte, wenn Sie storageQuota setzen.

Experimentell: Canvas-Bridge mit echter GPU

Optional leiten Sie Canvas-/WebGL-Operationen an einen entfernten Host mit echter GPU weiter, sodass Readbacks (getImageData / toDataURL / readPixels / measureText) zu der GPU passen, die Sie präsentieren – selbst auf Hardware, die sie lokal nicht rendern kann. Weil die Bridge die Operationen weiterleitet (keine vorab aufgezeichneten Bilder), kommt sie mit den meisten Canvases zurecht, nicht nur mit bekannten Prüfskripten. Aktiviert wird sie mit --canvas-bridge-url=ws://host:port (plus --no-sandbox); ohne diesen Switch läuft alles vollständig lokal, genau wie bisher. Der Render-Server steuert einen Browser auf dem Host mit echter GPU (ein reguläres Chrome über CDP oder ein Headless-Clearcote). Die vollständige Einrichtung beschreibt die Canvas-Bridge-Anleitung.

Native Metadaten-Overrides & light_stealth

Neben der aus dem Seed abgeleiteten Persona gibt es eine Reihe nativer Einzelwert-Overrides, mit denen Sie einzelne navigator-/screen-Werte direkt spoofen – hardwareConcurrency, deviceMemory, colorDepth, devicePixelRatio, maxTouchPoints und (per Opt-in) die Abmessungen von screen/avail*. Jeder Wert wird direkt von seinem Getter gelesen, mit der Rangfolge Flag > --fingerprint-Persona > echter Host; ein fest gesetzter Wert schlägt also jeden Seed, und die Overrides funktionieren mit oder ohne einen --fingerprint-Seed – die Persona-Mechanik wird dabei nie aktiviert.

Das SDK bündelt eine leichte Teilmenge hinter einem einzigen Flag, light_stealth: Es wendet eines von wenigen kohärenten Metadaten-Bündeln an (hardwareConcurrency, deviceMemory, colorDepth, devicePixelRatio, maxTouchPoints), und zwar ausschließlich über diese nativen Switches. Der Seed wählt nur das Bündel aus und wird nicht an die Engine übergeben; es gibt also kein Canvas- oder WebGL-Rauschen, und alle light_stealth-Sessions auf einem Rechner teilen sich den Canvas-Hash des Hosts – nutzen Sie einen fingerprint-Seed pro Account ohne lightStealth, wenn sich diese Hashes unterscheiden müssen. Der TLS-ClientHello und die echte Browserversion bleiben unverändert. Die Abmessungen von screen werden standardmäßig bewusst nicht gespooft (Opt-in über screenWidth usw.), weil ein gefälschter Bildschirm, der sich nicht mit der echten Render-Fläche in Einklang bringen lässt, leicht auffällt; prüfen Sie auf einem unskalierten Display, ob der gewählte devicePixelRatio dazu passt, oder setzen Sie ihn selbst. Eine explizit gesetzte Option hat immer Vorrang vor dem Preset.

import { launch } from "clearcote";
// one coherent metadata bundle; "my-seed" only picks which one — no seed reaches the engine, so no canvas noise:
const browser = await launch({ lightStealth: true, fingerprint: "my-seed" });

// or set individual values by hand (no --fingerprint needed):
const b2 = await launch({
  hardwareConcurrency: 8,
  deviceMemory: 8,
  devicePixelRatio: 1.25,
  maxTouchPoints: 0,
});

Alle Switches

Filtern Sie nach Name oder Wirkung, oder grenzen Sie auf ein Subsystem ein. Klicken Sie auf einen Switch, um zu lesen, was er bewirkt, und seine kürzeste gültige Form zu sehen.

Beispiele

Das hier sind reine Kommandozeilen-Flag-Sets. Vollständige Workflows für Python und Node finden Sie unter Beispiele.

Eine vollständige, kohärente Windows-Identität:

--fingerprint=acme-tenant-7 \
--fingerprint-platform=windows \
--fingerprint-brand=Chrome \
--accept-lang=en-US,en \
--lang=en-US \
--timezone=America/New_York \
--fingerprint-hardware-concurrency=8

Eine Windows-Identität mit eigenen GPU-Strings, in der Form, in der ANGLE sie unter Windows meldet:

--fingerprint=42 \
--fingerprint-platform=windows \
--fingerprint-gpu-vendor="Google Inc. (NVIDIA)" \
--fingerprint-gpu-renderer="ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 (0x00002504) Direct3D11 vs_5_0 ps_5_0, D3D11)"

Die Strings ändern, was gemeldet wird, nicht, womit gerendert wird: Die Pixel kommen weiterhin von der GPU dieses Rechners. Geben Sie die GPU an, auf der Sie tatsächlich rendern, oder nutzen Sie die Canvas-Bridge. Die Plattform macos ändert im offenen Build nur die Identitäts-Strings (UA, Client Hints, navigator.platform); im lizenzierten Build beschreibt sie seit 155 r47 einen echten Mac, mit Chip, Threads, Arbeitsspeicher, Bildschirm, Grafik-Renderer, macOS-Version und Stimmen, die zusammenpassen. Und android ist eine Mobile-Persona nach dem Best-Effort-Prinzip.

Legen Sie einen Standort zusammen mit seiner Zeitzone fest, damit Geolocation und Uhr übereinstimmen:

--fingerprint=nyc-1 \
--timezone=America/New_York \
--fingerprint-location=40.7128,-74.0060

Die Werte eines echten Rechners importieren

Statt eines synthetischen Seeds können Sie die exakten Werte ausgeben, die ein echtes Chrome gemeldet hat – GPU-Strings + getParameter-Tabelle, Bildschirm, Schriften, Stimmen, Audio. Die Werte werden ersetzt; gerendert wird weiterhin auf Ihrem eigenen Rechner. Ein Profil gibt zwei Accounts also keine unterschiedlichen Canvases – ein --fingerprint-Seed pro Account schon. Nutzen Sie das eine oder das andere, nicht beides: ein Profil für die Werte eines echten Rechners, einen Seed für getrenntes Rendering pro Account. Holen Sie sich ein Profil aus der kuratierten clearcote-profiles-Bibliothek (Tausende Profile echter Rechner, nach GPU-Hersteller getaggt) oder erfassen Sie Ihr eigenes mit dem Collector; laden Sie es anschließend und weisen Sie nach, dass es geladen wurde:

import { launch } from "clearcote";
// path to a captured .json profile, a profile object, or a JSON string
const browser = await launch({ fingerprintProfile: "./real-machine.json" });
// fields present in the profile override what the browser would report;
// absent fields keep the browser's defaults. Pass no fingerprint seed alongside a profile.

Ablauf der Erfassung: Öffnen Sie die Collector-Seite in dem echten Chrome, das Sie klonen möchten, exportieren Sie das JSON und übergeben Sie es über fingerprintProfile (SDK) / --fingerprint-profile (Engine). Prüfen können Sie es mit tools/fingerprint-collect/verify_profile.py.

Was die einzelnen Patches tun

Jeder Switch des offenen Builds entspricht einem lesbaren Engine-Patch: Die Diffs liegen in patches/, eine einzeilige Zusammenfassung jedes Patches in patches/README.md. Switches mit dem Vermerk “lizenzierter Build” stammen aus dem eigenen Patch-Set des lizenzierten Builds, das nicht öffentlich ist.

Kohärenz zählt mehr als jeder Einzelwert: Halten Sie Plattform, Zeitzone, Locale und GPU gemeinsam plausibel. Wie die Engine sie konsistent hält, lesen Sie unter Architektur; warum das JavaScript-Spoofing überlegen ist, unter Wie Erkennung funktioniert.