navigator.cpuPerformance in Chrome 152: Neues Signal zur Erkennung für Anti-Detection und Scraping

Am 25. August 2026 kam Chrome 152 in den stabilen Kanal für Windows, Mac, Linux, ChromeOS und Android — und brachte die Eigenschaft navigator.cpuPerformance mit sich. Eine Zahl von 0 bis 4, die die Website synchron liest, ohne Berechtigungen und ohne einen einzigen Rechenzyklus. Es ist als Hinweis für Videoanrufe und Streams gedacht: einem schwachen Gerät 240p ohne Hintergrundunschärfe zuzuweisen, einem leistungsstarken 1080p mit Effekten. Zwei Wochen nach der Veröffentlichung diskutiert die Scraping-Industrie etwas anderes: Anti-Bot-Systeme haben ein günstiges und stabiles Signal über die Hardware, auf der Ihr Browser läuft.

Was genau gibt der Browser aus

Die Eigenschaft gibt nicht die Gigahertz-Zahl oder das Modell des Prozessors zurück, sondern eine „Kategorie“ der Leistung. Laut der Erläuterung von WICG gibt es vier Tiers plus null:

• 0 — das Gerät konnte nicht klassifiziert werden;
• 1 — praktisch ungeeignet für schwere Aufgaben;
• 2 — schwach, aber funktionsfähig;
• 3 — komfortabel für normale Szenarien;
• 4 — leistungsstark, mit Spielraum für Multitasking.

Die Spezifikation verbietet ausdrücklich die Offenlegung des Anbieters, des Modellnamens und der Anzahl der Kerne, verlangt HTTPS und verfolgt das Ziel der Privatsphäre: Jede Kategorie sollte einen signifikanten Anteil an Geräten im Internet abdecken — etwa Hunderte verschiedener CPU-Modelle, damit der Wert das Publikum nicht auf einige wenige einschränkt.

Die tatsächliche Implementierung in Chromium stellte sich als einfacher heraus als die Spezifikation. In der Analyse von Zyte wird gezeigt, dass die Klassifizierung sich vor allem auf die Anzahl der logischen Kerne und auf eine festgelegte Tabelle von Erhöhungen und Absenkungen stützt: Die Frequenz wird überhaupt nicht berücksichtigt, obwohl die Spezifikation dies erlaubt. Erhöhungen erhalten AMD Ryzen, Intel Gracemont-Kerne, Apple Silicon und Intel Core Ultra; Absenkungen — Intel Atom und Prozessoren der Core 2-Ära. Die grobe Zuordnung sieht so aus: Ein-Kern- und sehr schwache Maschinen fallen in die erste Kategorie, zwei bis vier Kerne ergeben die zweite, vier bis zehn Kerne oder moderne energieeffiziente Chips — die dritte, und acht oder mehr Kerne bei Core Ultra, Apple M-Serie und alles ab zehn Kernen — die vierte.

Warum dies ein Erkennungssignal ist und nicht einfach ein weiterer Byte Entropie

Der Wert selbst ist schwach: fünf Optionen entsprechen etwa 2,3 Bit Entropie, weniger als die Sprache der Benutzeroberfläche. Die Gefahr liegt in drei anderen Eigenschaften.

Es ist kostenlos. Um die tatsächliche Geschwindigkeit der JS-Ausführung mit Timing zu erfassen, muss das Erkennungsskript den Prozessor für Dutzende von Millisekunden beanspruchen, was im Profiler deutlich sichtbar ist. Hier — synchrones Lesen der Eigenschaft, null Kosten, null Spuren.

Es ist stabil. Der Wert hängt nicht von der Auslastung des Geräts zum Zeitpunkt der Überprüfung ab: Es ist die Klasse der Hardware, nicht die aktuelle Auslastung. Zwischen Sitzungen, Neustarts und IP-Wechseln bleibt es dasselbe — das heißt, es eignet sich als Teil eines langlebigen Profilidentifikators.

Es wird auf Konsistenz überprüft. Das ist das Wichtigste. Moderne Anti-Bot-Engines sperren selten aufgrund eines einzelnen Feldes — sie suchen nach internen Widersprüchen im Set. Ein Gerät, das die vierte Kategorie angibt, muss dies mit einem plausiblen navigator.hardwareConcurrency, einem vernünftigen navigator.deviceMemory, einer modernen GPU-Renderer-Zeile und einer entsprechenden JS-Ausführungsgeschwindigkeit bestätigen. Ein Profil, das Tier 4 angibt und dabei einen Benchmark wie eine Dual-Core-VM ausführt, wird durch triviale Kreuzprüfungen erfasst.

Separat ergibt sich fast eine klare Trennung zwischen „Rechenzentrum“ und „echtem Benutzer“: Ein typisches Cloud-Instance mit zwei vCPUs meldet ehrlich die erste Kategorie, während Verbraucher-Laptops und -Handys in der dritten bis vierten leben. Für einen Scraper, der auf einem günstigen VPS im Headless-Modus läuft und sich gleichzeitig als gewöhnlicher Chrome unter Windows ausgibt, ist dies eine unangenehme Kombination.

Wie unterscheidet sich das von hardwareConcurrency, das es schon immer gab

Eine berechtigte Frage: Die Anzahl der Kerne las die Website früher über navigator.hardwareConcurrency, und der Speicherumfang über navigator.deviceMemory. Was hat sich geändert?

Die Verknüpfung hat sich geändert. hardwareConcurrency ist eine rohe Zahl, und sie wird seit langem und überall manipuliert: Man setzt acht anstelle von zweiunddreißig ein, und die Frage ist erledigt. cpuPerformance ist eine abgeleitete Größe, die vom Browser selbst anhand einer festgelegten Tabelle berechnet wird. Sobald im Set zwei Felder vorhanden sind, von denen eines aus dem anderen berechnet wird, reißt jede einseitige Änderung die Verbindung zwischen ihnen. Man hat vier Kerne angegeben, aber die Kategorie bleibt vier — logisch erfordert diese Kombination entweder Apple Silicon, Core Ultra oder zehn Kerne; das bedeutet, entweder die Anzahl der Kerne lügt oder die GPU-Zeile, und der Detektor muss nur den Widerspruch bemerken, ohne herauszufinden, wo genau die Lüge liegt.

Genau aus diesem Grund veralten alte Checklisten „welche Felder im Profil zu manipulieren“ nicht punktuell, sondern blockweise: Die richtige Frage ist jetzt nicht „was zu manipulieren“, sondern „welche konsistente Hardwarekonfiguration ergibt sich insgesamt“.

Wer ist am stärksten betroffen

Chromium-only — und das ist kein mildernder Umstand. WebKit hat zu diesem API eine „Gegen“-Position eingenommen, Mozilla hat keine öffentliche Stellungnahme abgegeben, sodass die Eigenschaften in Safari und Firefox wahrscheinlich nicht vorhanden sein werden. Aber der überwiegende Teil der Produktionsautomatisierung — Playwright, Puppeteer, nodriver, Patchright, Agent-Browser — basiert genau auf Chromium. Das heißt, das Signal kommt genau in die Nische, wo es am wenigsten erwartet wird.

Am stärksten trifft das Widerspruch die Emulation mobiler Profile. Wenn ein Anti-Detektionsprofil sich als Android-Smartphone ausgibt und cpuPerformance unter ihm „4“ antwortet, weil der Browser physisch auf einem Desktop mit Ryzen läuft — ist das keine kleine Ungenauigkeit, sondern ein sich gegenseitig ausschließendes Paar von Signalen. Das Gleiche gilt für Farm-Szenarien, in denen Dutzende von Profilen mit unterschiedlichen „Geräten“ auf einer einzigen Hostmaschine leben und daher identische Tiers liefern.

Was ändert sich für den Parsing-Stack

Einige praktische Konsequenzen für diejenigen, die Headless-Browser in großen Mengen betreiben.

• Container erben vom Host. Der Browser in Docker sieht die Kerne der Hostmaschine und nicht die cgroup-Limits — das bedeutet, zehn Container auf einem fetten Server ergeben zehn identische maximale Tiers. Die Vielfalt der Profile, die Sie mühsam im User-Agent erstellt haben, fehlt auf Hardware-Ebene.
• Günstige VPS sind jetzt auffälliger. Zwei vCPUs — das ist die erste Kategorie, und die erste Kategorie auf Desktop-Chrome unter Windows kommt bei echten Menschen nicht oft vor. Früher war ein schwacher Server einfach langsam; jetzt ist er auch markiert.
• Das Signal ist kostenlos für die Website. Schwere Prüfungen wie Timing-Benchmarks werden von Websites selektiv durchgeführt, weil sie Zeit des Benutzers kosten. Das Lesen der Eigenschaft kostet nichts, daher wird es in das Grundset aufgenommen, selbst von den Plattformen, die zuvor nur auf IP-Reputation und Header beschränkt waren.
• Es wird neben Compute Pressure liegen. In den Release-Notizen von Chrome wird ausdrücklich empfohlen, die neue API mit der Compute Pressure API zu kombinieren — das heißt, die Kombination „Hardwareklasse plus beobachtete Last“ ist ursprünglich als Standard-Szenario gedacht, und Anti-Bots müssen nichts Neues erfinden.

Separat sollte die Annahme überdacht werden, dass es ausreicht, einmal ein „gutes“ Profil zu erstellen und es jahrelang wiederzuverwenden. Browser fügen solche Eigenschaften ohne Ankündigungen für Endbenutzer hinzu: Zwischen der Veröffentlichung von Chrome 152 und den ersten öffentlichen Analysen vergingen Wochen, in denen Profile ruhig das neue Feld zurückgaben, ohne etwas zu ahnen. Es macht Sinn, das Set von Feldern einmal pro Release-Zyklus zu überprüfen, und nicht einmal im Jahr.

Was praktisch zu tun ist

1. Erfassen Sie den aktuellen Wert. In der Profilkonsole: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory und die Zeile des WebGL-Renderers. Notieren Sie die vier zusammen und nicht einzeln — Sie werden genau als Kombination überprüft.
2. Vergleichen Sie die Kategorie mit der Legende des Profils. Mobile Legende — erste bis dritte Kategorie, Budget-Laptop — zweite bis dritte, Flaggschiff-Desktop — vierte. Tier 4 als alter Android oder Tier 1 als MacBook der M-Serie sind gleichermaßen verdächtig.
3. Ändern Sie die Eigenschaft nicht direkt. Eine Manipulation über Object.defineProperty wird anhand von Spuren der Überschreibung des Getters und der Abweichung von der tatsächlichen Ausführungsgeschwindigkeit erfasst. Wenn Sie ändern, dann auf der Ebene des Browser-Builds oder über integrierte Mechanismen.
4. Denken Sie an legale Overrides. Chrome gibt dem Benutzer einen Schalter in den Einstellungen (Performance → Speed → Override CPU performance tier), und Administratoren — eine Unternehmensrichtlinie. Es ist nützlich, dies aus beiden Perspektiven zu wissen: Der Wert kann nicht nur „echt“ sein, sondern auch manuell eingestellt werden, und ein massenhaft identischer Override in einem Pool von Profilen wird selbst zu einem Marker.
5. Verteilen Sie die Profile auf unterschiedliche Hardware. Wenn alle Ihre Profile auf einem Server sitzen, wird die Kategorie bei ihnen identisch sein — unabhängig davon, welche Geräte sie darstellen. Dies ist der Fall, wenn ein Park aus mehreren Maschinen mit unterschiedlichen Konfigurationen das Problem ehrlich löst, während ein Patch dies nicht tut.

Details zu einem verwandten Signal derselben Art finden Sie in der Analyse des Fingerabdrucks basierend auf dem Speicherumfang des Geräts, und zu den Stealth-Browsern, die mit solchen Eigenschaften sofort funktionieren, gibt es Benchmarks von nodriver, Camoufox und Patchright.

Wo sind die Proxys hier

Um es klar zu sagen: Proxys beheben nicht den Fingerabdruck des Browsers. cpuPerformance wird auf der Client-Seite berechnet, und keine IP wird ihn ändern. Aber das Anti-Bot-System trifft Entscheidungen auf der Grundlage der Summe der Schichten, und genau an der Schnittstelle der Schichten passiert normalerweise der Ausfall.

Die typische Kette, durch die billige Setups fallen, sieht so aus: IP aus einem bekannten Hosting-Netzwerk, erste Kategorie des Prozessors, Headless-Anzeichen in JS — drei unabhängige Signale, von denen jedes für sich tolerierbar ist, aber zusammen ergeben sie ein eindeutiges Urteil. Es ist billiger und zuverlässiger, die Netzwerkschicht aus dieser Summe zu entfernen, als gegen die Felder des Browsers zu kämpfen: Mit residential IP sieht die Anfrage aus wie der Verkehr eines normalen Heimproviders, und die „Rechenzentrums“-Hypothese fällt für den Detektor weg. Für mobile Legenden gilt die gleiche Logik — mobile Proxys sollten das mobile Profil unterstützen, sonst wandert der Widerspruch einfach vom Prozessor ins Netzwerk.

Kurz gesagt

Chrome 152 hat nicht so sehr einen neuen Fingerabdruck hinzugefügt, sondern eine neue Zeile in die Tabelle der Kreuzprüfungen. Zwei und etwas Bits geben für sich genommen niemanden preis — es ist die Inkonsistenz, die aufgedeckt wird: Das angegebene Gerät muss mit der Klasse des Prozessors, dem Speicherumfang, der Grafikkarte, der Ausführungsgeschwindigkeit und dem Netzwerk, aus dem die Anfrage kam, übereinstimmen. Das Audit der Profile sollte diese Woche mit einer Zeile in der Konsole und der Frage beginnen: „Gibt es so eine Hardware überhaupt für den, für den wir uns ausgeben?“.