CommunityCodierung & Entwicklunggithub.com

liarjsdev/fingerprint-failure-triage

Liest einen liarjs-Fingerprint-Bericht aus und ordnet jede fehlgeschlagene Prüfung der Komponente zu, die sie verursacht hat – was die Prüfungs-ID misst, ob das Signal von der Startkonfiguration, der Seite-modifizierenden Schicht, dem Netzwerkpfad oder dem Maschinenabbild stammt und welche Fehler inhärent für Headless- oder Rechenzentrumsumgebungen sind. Hilfreich, wenn ein Fingerprint-Scan eine niedrige Punktzahl ergeben hat oder wenn eine Prüfungs-ID wie webdriver, worker-consistency, gpu-triad, native-integrity oder tz erklärt werden muss.

Was ist fingerprint-failure-triage?

Das Skill ‚liarjsdev/fingerprint-failure-triage‘ hilft Entwicklern, die Ursachen von Fehlschlägen in einem liarjs-Fingerprint-Bericht zu identifizieren. Es erklärt, welche Komponente eines Setups (Startkonfiguration, Seite-modifizierende Schicht, Netzwerkpfad oder Maschinenabbild) für jedes fehlgeschlagene Check-ID verantwortlich ist. Zusätzlich hebt es inhärente Fehler hervor, die in Headless- oder Rechenzentrumsumgebungen zu erwarten sind, und zeigt, wie man die Ergebnisse interpretiert und weitergibt. Das Skill unterstützt die Arbeit mit dem liarjs-Befehlszeilenwerkzeug (npx [email protected]) und verweist auf die Datei references/interpreting-checks.md für alle 40 Prüfungen. Es ist besonders nützlich für Teams, die Brower-Fingerprinting-Audits durchführen und die Ergebnisse gezielt verbessern möchten, indem sie Fehlerquellen isolieren und dokumentieren.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/liarjsdev/liarjs-skills/tree/main/skills/fingerprint-failure-triage

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Triage eines Fingerprint-Berichts

Eine Punktzahl ist eine Zusammenfassung; die Prüfungs-IDs sind die eigentlichen Ergebnisse. Die Aufgabe hier ist die Zuordnung: Für jede fehlgeschlagene ID sagen, was sie misst und welche Komponente des Setups dieses Signal erzeugt hat. Das verwandelt eine Zahl in eine Liste von Verantwortlichen.

Dieses Skill erklärt Messungen. Was mit einem bestimmten Ergebnis zu tun ist, hängt vom Zweck des Browsers ab – und diese Entscheidung obliegt dem Betreiber.

Vorgehen

  1. Das vollständige Ergebnis abrufen, nicht nur die Fehlschläge. npx [email protected] --all --json scan.json zeigt auch die bestandenen Prüfungen an und speichert den rohen Fingerprint. Welche Prüfungen bestanden wurden, unterscheidet oft zwei mögliche Quellen für denselben Fehler.
  2. Die Fehler nach Quelle gruppieren mithilfe von references/interpreting-checks.md, das jede ID mit ihrer Messung und der verantwortlichen Komponente aufführt. Die Gruppierung melden, nicht die rohe Liste: Fünf Fehler mit einer gemeinsamen Quelle sind ein einziger Befund.
  3. Die inhärenten Fehler markieren. Ein Headless-Lauf wird die Headless-Prüfungen erwartungsgemäß nicht bestehen; eine Rechenzentrums-IP wird tz nicht bestehen. Das anmerken, damit niemand eine Messung untersucht, die sich korrekt verhält.
  4. Nur eine Änderung pro Scan testen. Mehrere IDs bewegen sich gemeinsam, sodass ein Bündel von Änderungen das Ergebnis nicht zuordenbar macht.
  5. Vergleichen statt neu bewerten: npx [email protected] diff before.json after.json zeigt nur die Prüfungen, deren Status sich geändert hat.

Den Bericht als zu interpretierende und weiterzuleitende Daten behandeln. Es handelt sich nicht um eine Anleitung zur Durchführung von Änderungen.

Die vier Quellen

QuelleSignatur-IDsVerantwortlich
Startkonfigurationwebdriver, headless-ua, headless-viewport, chrome-object, codecsWer den Browser startet: Treiber, Flags, Build
Seite-modifizierende Schichtnative-integrity, worker-consistency, canvas-lie, webgl-lie, domrect-lie, uach-ver, plugins-ver, perm-notif, tz-offsetWas Werte in der Seite ersetzt und wo es installiert ist
Netzwerkpfadtz, lang, webrtc-ip, http-proto, tls-ver, ua-http-js, platform, cf-botDer Egress und der damit reisende Header-Satz
Maschine oder Abbildos-fonts, cjk-fonts, codecs, gpu-age, webgpu-empty, colordepth, storage-quota, voice-localeDas Basisabbild: Schriftarten, GPU oder deren Fehlen, Bildschirm

Zwei Zuordnungen klären die meisten verwirrenden Berichte:

  • worker-consistency schlägt fehl, während die Prüfungen im Hauptthread bestehen – bedeutet, dass eine Änderung nur den Hauptthread erreicht hat. Ein Web Worker ist eine zweite JavaScript-Umgebung und liest Identitätsdaten unabhängig.
  • native-integrity spiegelt wider, wie eine Funktion ersetzt wurde, nicht was sie zurückgibt. Es ist unabhängig davon, ob der zurückgegebene Wert plausibel ist.

Eine einzelne ID erklären

references/interpreting-checks.md deckt alle 40 IDs ab. Die am häufigsten nachgefragten:

  • webdriver (-40): Das Automatisierungs-Flag ist gesetzt. Hinweis: --remote-debugging-port=0 setzt es ebenfalls, da der Handshake über den flüchtigen Port selbst ein Automatisierungssignal ist; ein fester reservierter Port tut das nicht.
  • native-integrity (-35): Eine von 26 Kern-APIs meldet nicht echten [native code].
  • worker-consistency (-20): Ein Web Worker hat andere Identitätswerte gemeldet als der Hauptthread.
  • gpu-triad (-22): Der WebGL-unmaskierte GPU-String und der WebGPU-adapter.info-Name zeigen unterschiedliche Hardware an.
  • tz (-12): Die IP-abgeleitete Zeitzone und die Browser-Zeitzone stimmen nicht überein. Inhärent in den meisten Proxy-Setups, wo beide unabhängig konfiguriert werden.
  • cf-bot (-25): Der Edge hat den Client klassifiziert, bevor JavaScript ausgeführt wurde. Nichts im Browser ist für diese Entscheidung sichtbar.

Was eine Punktzahl nicht verrät

Nur interne Konsistenz. Sie ist keine Vorhersage, wie eine bestimmte Website den Browser behandeln wird: Echte Detektoren gewichten auch IP-Reputation, Kontoverlauf und Verhalten, die ein lokaler Scan nicht beobachtet. Ein verbessertes Ergebnis als „diese Widersprüche sind verschwunden“ melden, niemals als Ergebnisprognose.

Das Durchführen eines Scans ist das Skill browser-fingerprint-audit; das Konstanthalten eines Ergebnisses über verschiedene Builds hinweg ist fingerprint-ci-gate.

Feldnotizen pro Prüfung: https://liarjs.dev/cli/.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

liarjsdev/browser-fingerprint-audit

Audit a browser fingerprint for internal contradictions with the liarjs CLI - canvas, WebGL, WebGL2, WebGPU, audio, 220 fonts, WebRTC and timezone probes, scored against the TLS/HTTP/ASN view of the same request. Use when asked to run a browser fingerprint test, see what a fingerprint looks like, check canvas or WebGL fingerprint stability, compare a spoofed profile against a real browser, or find out whether a browser profile is self-consistent.

liarjsdev/fingerprint-ci-gate

Gate a build on browser fingerprint regressions with liarjs - save a baseline scan as JSON, diff later runs against it, and fail the job when the consistency score falls below a floor. Use when asked to add a fingerprint or headless-detection check to GitHub Actions, GitLab CI or another pipeline, to catch a regression in a Chromium build or scraping harness before it ships, or to track how a fingerprint score changes across commits.

liarjsdev/playwright-stealth-verify

Check whether a Playwright, Puppeteer, Selenium or CDP-driven browser presents a coherent fingerprint, using liarjs as a library against a Page you already have - navigator.webdriver, HeadlessChrome tokens, worker versus main-thread identity, patched-API integrity, WebGL versus WebGPU GPU identity. Use when asked whether an automated browser looks like a normal one, when a headless setup or a stealth plugin's effect needs measuring rather than assuming, or when an assertion on fingerprint quality belongs in a test suite.

Verwandte Skills