Was ist Browser-Fingerprinting?Wie Sites Sie ohne Cookies verfolgen

Sie können jeden Cookie löschen, zu einer neuen IP wechseln und ein Inkognito-Fenster öffnen, und eine Site kann Sie dennoch bei der nächsten Anfrage wiedererkennen. Das ist Browser-Fingerprinting in Aktion. Anstatt eine ID auf Ihrem Gerät zu speichern, leitet die Site eine aus der Art ab, wie Ihr Gerät hundert kleine Fragen beantwortet: welchen Browser Sie betreiben, wie Ihre GPU eine Kurve zeichnet, wie Ihr Audio-Stack eine Zahl rundet, wie Ihr TLS-Handshake geformt ist. Kombinieren Sie genug dieser Antworten und Sie erhalten einen Wert, der über Sitzungen hinweg stabil und nahezu einzigartig ist.

Für Ingenieure, die scrapen, ist das die Abwehr, die sich nicht um Ihren Proxy kümmert. Das Rotieren von IPs löst ein Problem und lässt Fingerprinting unberührt, weshalb eine „saubere" Residential-IP Sie immer noch auf eine Blockierungsseite schicken kann. Dieser Artikel erklärt, was ein Fingerprint tatsächlich ist, die Signale, aus denen er besteht, warum die Kombination Sie identifiziert, und den Teil, der für das Scraping am wichtigsten ist: Wie Sie Ihren Fingerprint kohärent halten, damit IP und Browser miteinander übereinstimmen.

Was ein Browser-Fingerprint ist

Ein Browser-Fingerprint ist ein abgeleiteter Bezeichner, der aus der Konfiguration und dem Verhalten gebaut wird, die Ihr Browser einer Seite gegenüber offenbart. Ein Skript liest Dutzende von Eigenschaften, hasht die Kombination und erhält einen Wert, der bei jedem Besuch tendenziell gleich bleibt. Nichts wird auf Ihr Gerät geschrieben. Die Site braucht Ihre Erlaubnis nicht und muss nichts auf Ihrer Seite speichern, weil die ID aus Ihrer Umgebung bei jedem Besuch neu berechnet wird.

Das mentale Modell, das wichtig ist: Ein Fingerprint ist zustandslos und abgeleitet, während ein Cookie gespeichert ist. Ein Cookie ist ein Token, das die Site auf Ihrem Rechner platziert hat, also entfernt das Löschen die Verbindung. Ein Fingerprint wird bei jedem Mal frisch aus Ihrer Hardware und Software berechnet, sodass es nichts auf Ihrer Seite zu löschen gibt. Dieser einzige Unterschied ist der Grund, warum Fingerprinting die drei Dinge überlebt, nach denen die meisten Menschen greifen, um anonym zu bleiben:

• Cookies löschen. Es gibt kein gespeichertes Token zu löschen; die ID wird neu berechnet.
• IPs wechseln. Die IP ist nur ein Signal unter vielen, und die meisten Signale kommen vom Browser, nicht vom Netzwerk.
• Inkognito- oder Privatmodus. Private Fenster blockieren Verlauf und Cookies, setzen aber denselben Bildschirm, dieselben Schriften, dieselbe GPU und denselben TLS-Stack frei, sodass der Fingerprint sich kaum ändert.

Die Signale, aus denen ein Fingerprint besteht

Ein Fingerprint ist nicht ein Wert, er ist ein Stapel von Signalen, die auf verschiedenen Ebenen gesammelt werden. Einige kommen direkt aus der Anfrage, einige werden von JavaScript nach dem Laden der Seite gelesen, und eines wird gesetzt, bevor einer Ihrer Codes überhaupt ausgeführt wird. Zu wissen, auf welcher Ebene jedes Signal liegt, ermöglicht es Ihnen, später über Konsistenz nachzudenken.

Signale auf Anfrage-Ebene

Die günstigsten Signale kommen direkt von der HTTP-Anfrage, bevor eine einzige Zeile JavaScript ausgeführt wird:

• User-Agent und Header. Der Browser und die Version, die Sie angeben, sowie der genaue Satz und die Reihenfolge der Header, die eine Anfrage trägt. Echte Browser senden einen konsistenten, vorhersehbaren Header-Satz; ein bloßer HTTP-Client sendet normalerweise weniger Header, in einer anderen Reihenfolge, was ein einfaches Verräter-Zeichen ist.
• Accept-Language und Zeitzone. Die Sprachen, die Ihr Browser bewirbt, und über JavaScript die Zeitzone, die Ihr System meldet. Eine US-Datacenter-IP kombiniert mit einer Moskauer Zeitzone und einem vietnamesischen Sprachheader ist eine offensichtliche Inkonsistenz.
• Bildschirm und Farbtiefe. Auflösung, verfügbare Bildschirmfläche, Geräte-Pixelverhältnis und Farbtiefe. Häufige Werte werden von Millionen geteilt; ungewöhnliche grenzen Sie schnell ein.

JavaScript-gerenderte Signale

Diese erfordern eine echte Rendering-Engine. Ein einfacher HTTP-Client kann sie überhaupt nicht erzeugen, und ihre Abwesenheit ist selbst ein Signal.

• Schriften. Die auf Ihrem System installierten Schriften, abgetastet durch Messen, wie Test-Strings gerendert werden. Die Kombination ist überraschend charakteristisch.
• Canvas-Fingerprinting. Die Seite zeichnet Text und Formen auf ein unsichtbares HTML5-Canvas und liest dann die Pixel zurück. Ihr spezifischer Mix aus GPU, Treibern, Anti-Aliasing und Schriften-Rasterisierung erzeugt winzige geräteabhängige Unterschiede, und das Hashen der Pixeldaten ergibt eine stabile Signatur.
• Audio-Fingerprinting. Die Web Audio API erzeugt einen Ton durch einen Oszillator und Kompressor und liest dann den resultierenden Puffer. Die genaue Gleitkomma-Ausgabe hängt von Ihrem Audio-Stack und Ihrer Hardware ab, sodass der abgeleitete Wert auf Ihrem Gerät konsistent und auf anderen Geräten unterschiedlich ist.
• WebGL und GPU. Die WebGL API meldet Ihre Renderer- und Anbieter-Strings und wie sie 3D-Szenen zeichnet, wodurch die GPU und der Treiber hinter dem Browser offenbart werden.

Der Canvas-Lesevorgang ist klein genug, um ihn zu zeigen. Die Seite zeigt dieses Canvas nie an; sie zeichnet es außerhalb des Bildschirms und serialisiert das Ergebnis:

const canvas = document.createElement("canvas")
const ctx = canvas.getContext("2d")

ctx.textBaseline = "top"
ctx.font = "14px Arial"
ctx.fillText("Crawlbase fingerprint \u{1F4A1}", 2, 2)

// Same code, different pixels per GPU/driver/font stack.
const signature = canvas.toDataURL()
const fp = hash(signature)

Das Signal, das die meisten Clients falsch machen: TLS / JA3

Der Handshake erfolgt vor HTTP, vor JavaScript, vor allem, was Sie im Code kontrollieren. Wenn Ihr Client eine TLS-Verbindung öffnet, sendet er ein Client Hello, das die unterstützten Cipher-Suites, Erweiterungen und elliptischen Kurven in einer bestimmten Reihenfolge auflistet. Diese Form ist für eine gegebene Client-Bibliothek und Version konsistent, und das Hashen ergibt einen JA3-Fingerprint. Chromes Handshake sieht wie Chrome aus; Pythons requests sieht wie Python aus.

Das ist die Ebene, die die meisten Scraper stolpern lässt und die kein User-Agent-String beheben kann. Sie können jeden Header so setzen, dass er behauptet, Safari auf einem iPhone zu sein, aber wenn Ihr TLS-Handshake zu einer Python-HTTP-Bibliothek auf Linux passt, stimmen die beiden Ebenen nicht überein, und ein Verteidiger, der sie vergleicht, sieht die Lüge sofort. Der Handshake wird von Ihrem Netzwerk-Stack gesetzt, nicht von Ihren Headern, sodass das Fälschen bedeutet, den Client selbst zu ändern.

Warum die Kombination Sie identifiziert

Kein einzelnes Signal ist einzigartig. Millionen von Menschen betreiben dieselbe Browser-Version bei 1920x1080. Die Macht liegt in der Kombination: Stapeln Sie Browser, Betriebssystem, Schriften, Zeitzone, Canvas-Hash, Audio-Hash, WebGL-Renderer und TLS-Form zusammen, und der gemeinsame Wert wird selten genug, um Sie herauszugreifen. Studien über echten Datenverkehr setzen die Geräteidentifikation irgendwo im Bereich von 90-99%, und Sie sollten diese als beobachtete Zahlen aus bestimmten Datensätzen behandeln, nicht als Garantie dafür, dass jeder Browser eindeutig identifizierbar ist.

Dieselbe Eigenschaft, die Fingerprinting für Betrugsprävention und Bot-Erkennung nützlich macht, macht es zu einem Datenschutzanliegen: Es verfolgt über Sitzungen hinweg ohne Zustimmung und ohne etwas, das auf Ihrem Gerät gespeichert wird. Für Scraper ist die Schlussfolgerung enger und schärfer. Ihr Tooling sendet eine Kombination von Signalen, und wenn diese Kombination wie Automatisierung aussieht oder intern widersprüchlich ist, werden Sie markiert, unabhängig davon, wie gut Ihre IP ist.

Wie Fingerprinting Scraper blockiert

Anti-Bot-Systeme sammeln denselben Stapel von Signalen von Ihrem Scraper, die sie von einem echten Besucher sammeln, und stellen dann zwei Fragen. Erstens: Sieht das überhaupt wie ein echter Browser aus? Zweitens: Stimmen die Ebenen miteinander überein? Die meisten Scraper scheitern an der zweiten Frage, selbst wenn sie die erste bestehen, und das ist die Erkenntnis, die verändert, wie Sie bauen.

Hier ist die Falle. Sie kaufen rotierende Residential-IPs, setzen einen überzeugenden User-Agent, und werden trotzdem blockiert. Die IP-Rotation hat ihre Arbeit getan, aber Fingerprinting hat nie die IP isoliert betrachtet. Es betrachtete das ganze Bild, und das Bild war inkonsistent:

• Ein konstanter Fingerprint hinter rotierenden IPs. Wenn jede Anfrage einen Canvas-Hash und eine TLS-Signatur teilt, während sich die IP jedes Mal ändert, haben Sie ein „Gerät", das weltweit teleportiert. Dieses Muster ist selbst eine Markierung.
• Intern inkonsistente Ebenen. Eine Linux-Datacenter-TLS-Signatur, die über ihren User-Agent behauptet, Safari auf einem iPhone zu sein. iOS Safari erzeugt diesen Handshake nicht, und es läuft nicht auf dieser Hardware. Der Widerspruch ist das Verräter-Zeichen.
• Fehlende Signale, die ein echter Browser immer hat. Kein Canvas, kein WebGL, kein Audio-Kontext, ein dünner Header-Satz. Ein echter Browser produziert all das; ein bloßer HTTP-Client produziert keines davon, und die Lücke ist offensichtlich.

Die Regel lautet also nicht „mehr rotieren". Die Regel lautet Konsistenz über alle Ebenen hinweg. Der IP-Ursprung, die Header, der TLS-Handshake und die JavaScript-gerenderten Signale müssen alle dieselbe plausible Person auf demselben plausiblen Gerät beschreiben. Das ist dasselbe Kohärenzproblem hinter dem Umgehen von Cloudflare und Vermeiden von Bot-Erkennung und ein großer Teil des Grundes, warum Scraper auf CAPTCHAs beim Scraping stoßen: Die Herausforderung wird oft durch einen inkohärenten Fingerprint ausgelöst, nicht allein durch die IP.

Was Sie tatsächlich dagegen tun können

Sie haben drei realistische Wege, und sie tauschen Aufwand gegen Kontrolle ab.

• Einen echten oder Headless-Browser betreiben, der rendert. Eine echte Browser-Engine erzeugt echte Canvas-, WebGL-, Audio- und Schriften-Signale, und ihr TLS-Handshake stimmt mit ihrem User-Agent überein, weil es dieselbe Software ist. Das schließt die Lücke der „fehlenden Signale" und die Lücke des „TLS stimmt nicht mit dem Browser überein" in einem Schritt. Die Kosten sind Geschwindigkeit und Ressourcen: Rendering ist weit ressourcenintensiver als ein einfacher Abruf.
• Einen Anti-Detect-Browser verwenden. Diese Tools geben jeder Sitzung ein bewusst gestaltetes, intern konsistentes Profil und variieren Signale gemeinsam, damit die Ebenen plausibel bleiben. Nützlich für kleinere, sitzungsintensive Arbeit; die Verwaltung vieler kohärenter Profile in großem Maßstab ist eine eigene Aufgabe.
• Eine verwaltete Lösung verwenden. Ein Dienst, der den gesamten Fingerprint für Sie kohärent hält, einen glaubwürdigen Browser präsentiert und ihn mit einer passenden IP kombiniert, sodass Sie auf einen einzigen Endpunkt zeigen, anstatt den Stack selbst zu pflegen.

Seien Sie ehrlich mit sich selbst über die zweitattraktivste Option: einen konsistenten Fingerprint mit rohen HTTP-Anfragen von Hand zu basteln. Es ist im Prinzip machbar, aber schwierig und fragil. Sie müssen den TLS-Handshake dem behaupteten Browser anpassen, den genauen Header-Satz und die Reihenfolge senden, die ein echter Browser sendet, und das alles synchron halten, während sich Browser-Versionen ändern und die Erkennung weiterentwickelt. Ein veralteter Wert, und die Ebenen stimmen wieder nicht überein. Für die meisten Teams überwiegt der Wartungsaufwand die Einsparungen, weshalb Rendering oder eine verwaltete Schicht normalerweise gewinnt. Wenn Sie das umfassendere Playbook möchten, lesen Sie wie man Websites ohne Blockierung scrapt.

Welchen Weg Sie auch wählen, die IP muss noch mit dem Rest kohärent sein. Ein Residential-Ursprung liest sich als echte Person, während ein Datacenter-Bereich das nicht tut, was der Kern des Datacenter- vs. Residential-Proxys-Kompromisses ist, und die Rotation muss die Last verteilen, ohne einen Fingerprint zwischen Kontinenten springen zu lassen. Rotierende Residential-Proxys behandeln die IP-Seite, aber nur ein kohärenter Fingerprint darüber macht die gesamte Anfrage glaubwürdig.

Häufig gestellte Fragen

Was ist Browser-Fingerprinting?

Browser-Fingerprinting ist eine Technik, die einen einzigartigen Bezeichner für Ihr Gerät aus der Konfiguration und dem Verhalten erstellt, die Ihr Browser offenbart, wie Ihr User-Agent, Bildschirm, installierte Schriften, GPU, Audio-Stack und TLS-Handshake. Die Kombination dieser Signale wird zu einem Wert gehasht, der bei Besuchen tendenziell gleich bleibt. Nichts wird auf Ihrem Gerät gespeichert, weil die ID bei jedem Mal aus Ihrer Umgebung neu berechnet wird.

Wie unterscheidet sich ein Fingerprint von einem Cookie?

Ein Cookie ist ein Token, das eine Site auf Ihrem Gerät speichert, sodass das Löschen die Verbindung entfernt. Ein Fingerprint ist abgeleitet und wird bei jedem Besuch frisch aus Ihrer Hardware und Software gemessen, sodass es nichts auf Ihrer Seite zu löschen gibt. Deshalb überlebt Fingerprinting das Löschen von Cookies, das Wechseln von IPs und die Verwendung des privaten Browser-Modus.

Kann ich Fingerprinting durch Löschen von Cookies oder Inkognito-Modus vermeiden?

Nein. Diese Aktionen entfernen gespeicherte Daten, aber ein Fingerprint ist nicht gespeichert; er wird aus Signalen wie Ihrem Bildschirm, Schriften, GPU und TLS-Stack neu berechnet, die der Inkognito-Modus nicht ändert. Private Fenster verbergen Verlauf und Cookies, setzen aber dieselben Geräteeigenschaften frei, sodass sich der Fingerprint kaum verschiebt.

Warum wird mein Scraper trotz rotierender Proxys blockiert?

Weil Fingerprinting die IP nicht isoliert betrachtet. Wenn jede Anfrage denselben Canvas-Hash und dieselbe TLS-Signatur trägt, während die IP rotiert, sehen Sie aus wie ein Gerät, das weltweit teleportiert. Wenn Ihr TLS-Handshake Python auf Linux anzeigt, während Ihr User-Agent behauptet, Safari auf einem iPhone zu sein, widersprechen sich die Ebenen. Beide Muster werden markiert, unabhängig davon, wie sauber die IP ist.

Was ist TLS- oder JA3-Fingerprinting?

Wenn Ihr Client eine HTTPS-Verbindung öffnet, listet das TLS-Client-Hello unterstützte Cipher-Suites, Erweiterungen und Kurven in einer bestimmten Reihenfolge auf. Das Hashen dieser Form erzeugt einen JA3-Fingerprint, der für die Client-Bibliothek und -Version charakteristisch ist. Er wird von Ihrem Netzwerk-Stack gesetzt, nicht von Ihren Headern, sodass er oft einen Scraper entlarvt, dessen User-Agent behauptet, ein Browser zu sein, der er nicht ist.

Was ist der beste Weg, am Fingerprinting vorbeizuscrapen?

Halten Sie Ihren Fingerprint über jede Ebene hinweg kohärent. Betreiben Sie einen echten oder Headless-Browser, damit die gerenderten Signale und der TLS-Handshake tatsächlich mit dem Browser übereinstimmen, den Sie zu sein behaupten, oder verwenden Sie eine verwaltete Schicht, die einen glaubwürdigen Fingerprint mit einer passenden Real-User-IP kombiniert. Einen konsistenten Fingerprint mit rohen HTTP-Anfragen von Hand zu basteln ist möglich, aber schwer zu pflegen, wenn sich Browser und Erkennung weiterentwickeln.

TA

Thomas Adewale

Technischer Redakteur · Crawlbase

Technischer Redakteur bei Crawlbase, der über Proxy-Netzwerke, Rotationsstrategien und die technischen Grundlagen für zuverlässiges Crawling im großen Maßstab schreibt.