Am 12. Juli 2026 veröffentlichte ein Ingenieur des Anti-Scraping-Unternehmens Scrapfly einen technischen Blogbeitrag, der eine beunruhigende Entdeckung offenlegte: Seit Chrome 148 liefert eine unscheinbare mathematische Funktion, Math.tanh(), auf verschiedenen Betriebssystemen leicht unterschiedliche Ergebnisse. Das heißt: Jede Webseite, die Sie eine einzige Zeile Mathematik ausführen lässt, kann bestimmen, ob Sie Windows, macOS oder Linux verwenden.
▲ Bildquelle: Screenshot des Scrapfly-Blogbeitrags
Die Entdeckung stand am selben Tag auf der Startseite von Hacker News und erhielt 207 Upvotes sowie 90 Kommentare. Die Reaktion der Entwicklergemeinschaft ließ sich mit „Überraschung“ umschreiben – man war gewohnt, dass Browser-Fingerprints über Canvas-Rendering, WebGL-Darstellung oder Audiobearbeitung, diese „schweren Geschütze“, Nutzer verfolgen, und hätte nie gedacht, dass schon eine gewöhnliche Hyperbeltangens-Funktion zum Erkennen des Betriebssystems taugt.
Dieselbe Rechenaufgabe, drei verschiedene Antworten
Ein konkretes Beispiel verdeutlicht dies. In der Browserkonsole von Chrome 150 ergibt die Eingabe von Math.tanh(0.8), also die Berechnung des Hyperbeltangens von 0,8, auf drei realen Maschinen mit unterschiedlichem Betriebssystem drei verschiedene Resultate:
| Betriebssystem | Rückgabewert von Math.tanh(0.8) |
|---|---|
| Linux (glibc) | 0.6640367702678491 |
| macOS (libsystem_m) | 0.664036770267849 |
| Windows (UCRT) | 0.6640367702678489 |
Achten Sie auf die letzten Ziffern. Linux weist eine Stelle mehr auf als macOS und den größten Wert; macOS liegt eine Stelle unter Windows und in der Mitte; der Wert von Windows ist etwas kleiner. Die Unterschiede liegen nur in der letzten oder vorletzten Stelle und sind für das bloße Auge kaum wahrnehmbar – für einen Computer jedoch genügen sie als eindeutige Signatur des Betriebssystems.
Interessant: Nicht jede Eingabe erzeugt Differenzen. Laut Scrapflys Testdaten stimmen etwa drei Viertel der Eingabewerte auf allen drei Systemen exakt überein. So liefern Math.tanh(0.5) auf Linux, macOS und Windows alle denselben Wert 0.46211715726000974. Bei tanh(0.7) unterscheidet sich nur der Linux-Wert von den beiden anderen, bei tanh(0.9) wiederum nur Windows. tanh(0.8) ist genau der „sweet spot“, der alle drei voneinander trennt.
▲ Bildquelle: Screenshot der Scrapfly-Vergleichstabelle
Das bedeutet: Ein Tracker muss keine komplizierten Operationen ausführen. Einige wenige Math.tanh()-Aufrufe auf der Webseite, die Wahl einiger kritischer Eingabewerte und der Vergleich der Ergebnisse genügen, um das Betriebssystem des Besuchers abzuleiten. Behauptet der User-Agent des Besuchers, er nutze macOS, während der tanh-Wert typisch für Linux ist – dann tarnt sich dieser Besucher mit hoher Wahrscheinlichkeit.
Wessen Schuld? Bug oder Schicksal der Mathematik?
Mancher Leser mag an dieser Stelle fragen: Ist das ein Bug in Chrome?
Die Antwort ist feiner. Es ist nicht vollständig ein Bug, doch eine unbeabsichtigte Nebenwirkung eines „Patches“.
Vor Chrome 148 verwendete die V8-Engine (das JavaScript-Ausführungskernstück von Chrome) für Math.tanh eine eigene, gebündelte Mathematikbibliothek namens fdlibm. Da auf allen Plattformen derselbe Code lief, stimmte Math.tanh unabhängig davon, ob der Nutzer Windows, macOS oder Linux nutzte, stets exakt überein – und verriet folglich nichts über das Betriebssystem.
Ende 2025 jedoch reichte das V8-Team eine Codeänderung ein (Commit c1486295ae5), die die Implementierung von Math.tanh von der eigenen fdlibm auf die C++-Standardbibliothek std::tanh umstellte. Der Beweggrund war vernünftig: Reduktion des eigenen Codeumfangs von V8, Nutzung der auf Betriebssystemebene bereits hochoptimierten Mathematikbibliotheken, theoretisch auch Leistungsgewinn. Die Änderung erschien mit V8 14.8.57, was Chrome 148 entspricht.
Das Problem: Die zugrunde liegenden Mathematikbibliotheken der verschiedenen Betriebssysteme (glibc unter Linux, libsystem_m unter macOS, UCRT unter Windows) implementieren die Hyperbeltangens-Funktion nicht identisch.
Dies ist eine grundlegende mathematische Beschränkung. Der IEEE-754-Standard legt das Speicherformat und die Genauigkeitsanforderungen der Grundrechenarten (Addition, Subtraktion, Multiplikation, Division, Quadratwurzel) fest, erzwingt für trigonometrische, exponentielle und hyperbolische Funktionen – die „transzendenten Funktionen“ – jedoch keine „korrekte Rundung“, also keine Garantie, dass das Ergebnis bis zum letzten Binärbit präzise ist. Der Grund ist praktischer Natur: Eine korrekt gerundete Berechnung wäre rechnerisch extrem aufwendig und würde die Leistung stark beeinträchtigen. Daher hat jede Betriebssystem-Bibliothek eigene Näherungsalgorithmen, Koeffiziententabellen und Konstanten; das Ziel ist, den Fehler bei gewahrter Geschwindigkeit innerhalb einer „minimalen Genauigkeitseinheit“ (ULP) zu halten.
Folglich ist die kleine Differenz von Math.tanh über verschiedene Betriebssysteme hinweg seit Chrome 148 im Wesentlichen ein Ausdruck der Vielfalt mathematischer Näherungsalgorithmen. Es ist kein Bug, den man einfach „reparieren“ könnte – vielmehr ist es ein seit Jahrzehnten bestehender Kompromiss im Bereich der Gleitkomma-Arithmetik: Geschwindigkeit gegen Genauigkeit. Dass dieser Kompromiss in der Browser-Ebene als Benutzeroberfläche sichtbar wird, verwandelte ihn unversehens in eine Undichtigkeit des Datenschutzes.
Nicht nur tanh – eine undichte Stelle, die den ganzen Browser durchzieht
Noch beunruhigender: Math.tanh ist nur die Spitze des Eisbergs.
Wie der Scrapfly-Blog darlegt, unterliegt grundsätzlich jede Browser-API, die über die Mathematikbibliothek des Wirtsbetriebssystems (libm) rechnet, demselben Risiko der Undichtigkeit. Dazu zählen die trigonometrischen Funktionen in CSS (sin(), cos(), tan() usw.) sowie der Dynamische Kompressor der Web-Audio-API. All diese Funktionen stützen sich für die Gleitkommaberechnung auf die Mathematikbibliothek des zugrunde liegenden Betriebssystems.
Mit anderen Worten: Selbst wenn das Chrome-Team Math.tanh repariert, bleibt das Fenster für Fingerprinting bestehen, solange auch nur eine einzige API die Mathematikfunktion des Wirtsbetriebssystems aufruft, ohne dies zu vereinheitlichen.
Es ist ein klassisches „Whack-a-Mole“-Rüstungsrennen. Browser-Entwickler bemühen sich, jede Undichtigkeit zu verschließen, durch die sich die Identität eines Nutzers verraten könnte, während Tracker und Anti-Scraping-Systeme ständig neue Signale suchen. Die Geschichte des Fingerprintings ist eine Geschichte stets neu entdeckter Fronten: von Canvas zu WebGL, von der Font-Liste bis zur Audio-Wellenform, nun bis zur Differenz mathematischer Funktionsergebnisse. Jedesmal, wenn Entwickler ein Leck stopfen, findet der Tracker das nächste Merkmal, das völlig unmöglich als Hinweis erscheinen konnte.
Die gespaltene Reaktion der HN-Gemeinschaft
Die Diskussion auf HN zeigte zwei völlig verschiedene Perspektiven.
Ein Teil der Entwickler meint, die Entdeckung habe für den gewöhnlichen Nutzer begrenzte praktische Folgen. Der Nutzer „Aurornis“ wies darauf hin, die meisten Nutzer fälschten ihren User-Agent nicht, sodass die Erkennung des Betriebssystems über tanh dem Tracker keine zusätzliche Information liefere – der User-Agent verrate der Webseite ohnehin das verwendete System. Er hält den Fund für bedeutsamer bei der Eingrenzung der Browser-Version, räumt aber ein, dass dies nur ein kleines Puzzleteil unter vielen Fingerprint-Signalen sei.
Die Perspektive anderer ist grundverschieden. Der Nutzer „jeroenhd“ wies darauf hin, dass die Entdeckung gerade für Anti-Scraping-Unternehmen wie Scrapfly deshalb wichtig ist, weil sie Crawler-Programme als echte Browser tarnen müssen. Ein Crawler auf einer Linux-Virtualisierung, der vorgibt, ein Chrome unter macOS zu sein, wird durch den tanh-Rückgabewert als sein wahres Betriebssystem entlarvt – und das Anti-Scraping-System erkennt so mühelos einen Bot.
Der Autor neigt zu der Auffassung, dass beide Seiten recht haben. Für den gewöhnlichen, ehrlichen Browser-Nutzer ist die Undichtung von Math.tanh tatsächlich überflüssig – der User-Agent verrät der Webseite ohnehin das System. Für Nutzer jedoch, die ihre Identität verbergen wollen (ob aus Datenschutzgründen oder zum Zweck des Datensammelns), bedeutet dieses neu entdeckte Signal: Sie müssen nicht nur den User-Agent fälschen, sondern auch die Rückgabewerte der mathematischen Funktionen.
Dies wirft eine tieferliegende Frage auf: In einer Internetarchitektur, wie viele unserer als „neutral“ und „standardisiert“ erachteten Infrastrukturen geben stillschweigend einzigartige Signale über unsere Geräte weiter? Eine Mathematikfunktion, eine Zeile CSS, eine Audio-Bearbeitung – eigentlich keine Anhaltspunkte für Identität, werden durch die Vielfalt der zugrunde liegenden Implementierungen zu faktischen Tracking-Markern.
Was nun geschehen wird
Aktuell betrifft diese Undichtung Chrome 148, 149 und 150. Das Chrome-Team hat sich zu dem Problem noch nicht öffentlich geäußert. Das Scrapfly-Team erklärt, zur vollständigen Schließung der Undichtung müsste der Browser auf jeder Ebene (V8, Blink, Web Audio) eine einheitliche Mathematikbibliothek verwenden oder zumindest die Ausgaben „glattbügeln“. Dies könnte jedoch Leistungsverluste nach sich ziehen und stellt bei Kompatibilität und Wartung eine nicht geringe Herausforderung dar.
Für den gewöhnlichen Nutzer gilt: Kein Grund zur Panik. Die Entdeckung ist eher ein interessantes, aber nicht dringendes neues Signal in der Forschung zum Datenschutz, kein schwerwiegender Sicherheitsfehler, der zum Verlust Ihres Kontos führt. Beachtenswert ist sie, weil sie einen Trend markiert – die digitale Spur des Nutzers wird zusehends schwerer vollständig zu verbergen.
Die eigentliche Bedeutung dieser Geschichte liegt vielleicht in einer allgemeineren Beobachtung: In der komplexen Abhängigkeitskette von Software-Systemen kann jede noch so unbedeutende Entscheidung auf der untersten Ebene unerwartete Folgen für den Datenschutz auf der oberen Ebene haben. Eine Code-Bereinigung des Chrome-Teams, ursprünglich gedacht zur Reduktion von Redundanz und Steigerung der Leistung, öffnete unversehens ein neues Fenster zur Erkennung des Betriebssystems. In diesem Sinne ist die Geschichte von Math.tanh ein klassisches Beispiel für „Absicht und Nebenwirkung“.
Referenzen:
- Scrapfly: Browser Math OS Fingerprint
- HN-Diskussion (item?id=48884853)