Canvas-Bridge

Rendern Sie Canvas und WebGL auf einer echten entfernten GPU, damit die Pixel, die eine Seite ausliest, zu der GPU passen, die der Render-Host tatsächlich hat – die GPU-Strings Ihres Profils setzen Sie passend dazu. Experimentell und per Opt-in – ohne --canvas-bridge-url rendert Clearcote vollständig lokal, genau wie bisher.

Wozu es die Bridge gibt

Clearcote rendert Canvas/WebGL auf der GPU, die der Host-Rechner tatsächlich hat. Gibt ein Profil eine andere GPU an als die des Hosts, können strenge Anti-Detect- bzw. Browser-Tampering-Prüfungen, die die gerenderten Pixel mit der angegebenen Hardware vergleichen, die Abweichung bemerken – per Software bringen Sie eine GPU nicht dazu, exakt die Pixel einer anderen GPU auszugeben. Die Canvas-Bridge beseitigt diese Abweichung: Statt lokal zu rendern und nur den String der GPU zu spoofen, leitet sie die Canvas-/WebGL-Operationen an einen entfernten Host mit der GPU weiter, die Sie präsentieren möchten, und liefert dessen echte Pixel zurück. Weil sie die Operationen weiterleitet (keine feste Bibliothek vorab aufgezeichneter Bilder), kommt sie mit den meisten generierten Canvases zurecht, nicht nur mit bekannten Prüfskripten.

So funktioniert es

Die Readback-APIs – getImageData, toDataURL, readPixels und measureText – liefern die authentischen Pixel des Bridge-Hosts; das lokale Farbling-Rauschen entfällt auf dem Bridge-Pfad (die Bridge-Pixel sind die Ground Truth). Als Transport dient ein WebSocket mit einem kompakten binären Nachrichtenstrom. Die Pixel stammen von der GPU, die der Render-Browser hat.

text

  clearcote (your automation host)         bridge host (real GPU)
  +-----------------------------+          +-------------------------+
  | page: getImageData /        |  ops --> | render browser          |
  |       toDataURL / readPixels |         | renders on the real GPU,|
  | CanvasBridgeClient  <-- pixels ---------|  reads back the pixels  |
  +-----------------------------+          +-------------------------+

Was Sie brauchen

Einen Render-Host – einen beliebigen Rechner, dessen GPU Sie präsentieren möchten (eine Windows-GPU für eine Windows-Persona). Seine GPU wird zur Canvas-Identität, die Ihre Profile präsentieren; wählen Sie also Hardware, die zur gewünschten Persona passt (eine NVIDIA-Maschine, um NVIDIA zu präsentieren, und so weiter). Verbinden Sie den Server per --backend cdp mit einem regulären Chrome, das Sie auf diesem Rechner betreiben (empfohlen), oder nutzen Sie --backend local mit einem Clearcote-Binary.
Einen privaten Netzwerkpfad zwischen Ihrem Automatisierungs-Host und dem Bridge-Host. Die Bridge spricht unverschlüsseltes WebSocket (ws://) – betreiben Sie sie immer über ein privates Netzwerk oder einen verschlüsselten Tunnel (Tailscale, WireGuard oder SSH-Portweiterleitung). Geben Sie den Bridge-Port nie im öffentlichen Internet frei.

Einrichtung

1. Starten Sie den Render-Server auf dem Host mit echter GPU. Das ist ein kleiner Python-Koordinator, der einen Headless-Browser steuert und die weitergeleiteten Operationen auf dessen echtem Canvas nachspielt; die zurückgelieferten Pixel sind also genau das, was diese GPU erzeugt. Die echte GPU des Render-Hosts wird zur Canvas-/WebGL-Identität. Mit --backend cdp gibt der Server beim Start den Renderer-String der Render-GPU aus (render GPU='ANGLE (…)') – notieren Sie ihn für Schritt 3. Mit --backend local lesen Sie die Strings stattdessen aus einem regulären Chrome auf demselben Rechner aus.

bash

pip install playwright    # one-time (no browser download needed for CDP)

# a regular Chrome on the GPU host, started with --remote-debugging-port=9222
# --user-data-dir=<a separate folder> (Chrome ignores the port on its default profile);
# its CDP URL is webSocketDebuggerUrl from http://127.0.0.1:9222/json/version
python tools/canvas-bridge-server/server.py \
    --backend cdp \
    --cdp-url ws://127.0.0.1:9222/devtools/browser/... \
    --port 8443

# Or let the server launch a Clearcote binary itself:
# python tools/canvas-bridge-server/server.py \
#     --backend local \
#     --chrome /path/to/clearcote/chrome.exe \
#     --port 8443

2. Tunneln Sie die Verbindung. ws:// ist unverschlüsselt – bringen Sie beide Hosts in dasselbe Tailscale-/WireGuard-Netz oder leiten Sie den Port über SSH weiter. Der Server bindet standardmäßig an localhost; unter Tailscale/WireGuard starten Sie ihn deshalb mit --host <that interface's IP>. Der SSH-Weg unten funktioniert ohne Anpassung:

bash

ssh -N -L 8443:localhost:8443 user@bridge-host
# the bridge is now reachable at ws://127.0.0.1:8443

3. Starten Sie den Client (Ihr Automatisierungs-Clearcote) mit Verweis auf die Bridge und mit den Strings der Render-GPU – den Renderer exakt so, wie der Server ihn ausgegeben hat, den Vendor als Google Inc. (<first name in the renderer>), z. B. Google Inc. (Intel). Die Bridge sorgt dafür, dass die Pixel zur Render-GPU passen, diese Angaben dafür, dass auch die gemeldeten Strings passen. Ohne sie widersprechen sich der GPU-Name der Persona und die Pixel aus der Bridge:

bash

--canvas-bridge-url=ws://127.0.0.1:8443 \
--no-sandbox \
--fingerprint=<seed> \
--fingerprint-gpu-vendor='Google Inc. (Intel)' \
--fingerprint-gpu-renderer='ANGLE (Intel, Intel(R) UHD Graphics ... D3D11)'

Flag	Bedeutung
--canvas-bridge-url	Bridge-Endpunkt `ws://host:port`. Erforderlich, um die Bridge zu aktivieren.
--canvas-bridge-auth	Optionale HTTP-Basic-Zugangsdaten `user:secret` für ein Deployment, das dem Server eine Authentifizierung vorschaltet. Der Referenzserver prüft sie nicht; verlassen Sie sich für die Zugriffskontrolle also auf das private Netzwerk oder den Tunnel.
--no-sandbox	Erforderlich – der Client öffnet den Bridge-Socket aus dem Renderer-Prozess heraus, und das blockiert die Sandbox.
--fingerprint	Der Seed Ihrer Persona.
--fingerprint-gpu-vendor / --fingerprint-gpu-renderer	Die Strings der Render-GPU: der Renderer exakt so, wie der Server ihn ausgegeben hat, der Vendor als `Google Inc. (<first name in the renderer>)`.
--canvas-bridge-mode	Richtlinie pro Origin: `off`, `all` (Standard), `allow` oder `deny`.
--canvas-bridge-allow / --canvas-bridge-deny	Kommagetrennte eTLD+1-Listen für `mode=allow` bzw. `mode=deny`.
--canvas-bridge-fallback	Verhalten bei einem Cache-Miss mit kaltem Cache: `block` (Standard) wartet auf die Bridge; `local` liefert lokale Pixel, statt zu blockieren.

Aus dem SDK

Das SDK (Node, Python und .NET; aktuell 0.31.1) bietet eine vollwertige Option canvasBridge / canvas_bridge / CanvasBridge. Sobald Sie eine Bridge-URL setzen, erzeugt das SDK die Switches und ergänzt automatisch --no-sandbox. Dieselbe Allow-List-Richtlinie in einem vollständigen Startskript finden Sie unter Beispiele.

javascript

const browser = await clearcote.launch({
  fingerprint: "user-1",
  gpuVendor: "Google Inc. (Intel)",                                // "Google Inc. (<first name in the renderer>)"
  gpuRenderer: "ANGLE (Intel, Intel(R) UHD Graphics ... D3D11)",   // exactly as the server printed it
  canvasBridge: {
    url: "ws://127.0.0.1:8443",
    auth: "user:secret",
    mode: "allow",
    allow: ["example.com"],
    fallback: "local",
  },
});

Prüfen, ob es funktioniert

Bei erfolgreicher Verbindung schreibt der Client canvas-bridge: connected to <host>:<port> ins Log (starten Sie mit --enable-logging=stderr --v=1, um es zu sehen).
Laden Sie eine Seite, die eine Canvas-/WebGL-Oberfläche hasht – bei verbundener Bridge passen die Hashes zur GPU des Bridge-Hosts, nicht zu der Ihres Automatisierungs-Hosts. Schnelltest: Führen Sie dasselbe canvas.toDataURL() mit und ohne Bridge aus; die Ergebnisse unterscheiden sich.
Ist die Bridge nicht erreichbar, loggt Clearcote eine Warnung und fällt auf lokales Rendering zurück – eine falsch konfigurierte Bridge degradiert kontrolliert und macht die Seite nie kaputt.

Hinweise & Grenzen

Canvas-Identität = der Bridge-Host, nicht der Seed. Alle Profile, die sich einen Bridge-Host teilen, teilen sich auch dessen Canvas-/WebGL-Hash und lassen sich darüber miteinander verknüpfen. Für viele nicht verknüpfbare Identitäten betreiben Sie einen Bridge-Host (GPU) pro Identitätsgruppe.
Latenz. Ein Pixel-Readback, der den Cache der Bridge verfehlt, ist ein blockierender Netzwerk-Roundtrip (5 s Timeout, danach lokaler Fallback), sofern fallback nicht local ist; die Engine lädt nach jedem Zeichenvorgang vorab, sodass wiederholte Pixel-Lesezugriffe auf ein unverändertes Canvas nicht warten müssen. Jeder measureText-Aufruf ist weiterhin ein Roundtrip. Betreiben Sie den Bridge-Host im selben LAN bzw. Rechenzentrum; verzichten Sie bei latenzkritischen, Canvas-lastigen Seiten auf die Bridge.
Prozedurale WebGL-Texturen laufen über die Bridge. Bei Texturquellen aus Bildern, 2D-Canvas, Video, ImageBitmap und 3D fällt das jeweilige Canvas auf lokales Rendering zurück; es bleibt korrekt, läuft aber nicht über die Bridge.
Auf dem Client ist --no-sandbox erforderlich, und der Transport ist unverschlüsselt – also immer tunneln und den Bridge-Port nie öffentlich freigeben.

Experimentell. Im offenen Build seit v0.1.0-pre.12 und im lizenzierten Build. Die maßgebliche Referenz (mit der vollständigen Tabelle zur Fehlerbehebung) ist die Canvas-Bridge-Anleitung auf GitHub. Die meisten Setups brauchen die Bridge nicht – die Standard-Steuerung auf Engine-Ebene finden Sie unter Fingerprint-Flags.