Umgehen des erweiterten Schutzes gegen Audio-Fingerprinting in Safari 17

 (fingerprint.com)
1 Punkte von GN⁺ 2024-03-11 | 1 Kommentare | Auf WhatsApp teilen
  • Safari 17 fügt im privaten Modus jedem Audio-API-Sample zufälliges Rauschen hinzu, um Audio-Fingerprints zu destabilisieren; FingerprintJS reagiert darauf mit einem neuen Fingerprinting-Algorithmus, der dieses Rauschen reduziert
  • Die bisherige Methode nutzt die Summe von 500 Audio-Samples als Kennung; dadurch wird Safaris Rauschbereich größer als die Unterschiede zwischen Browsern, wodurch die Stabilität verloren geht
  • Die neue Methode erzeugt massenhaft verrauschte Kopien desselben Audio-Samples und reduziert die Schwankung des Werts mit (min+max)/2 sowie Rundung signifikanter Stellen
  • Durch die Verbindung eines square OscillatorNode, eines DynamicsCompressorNode und eines BiquadFilterNode wurden die Unterschiede zwischen Browsern vergrößert; der minimale Unterschied beim 3396. Sample der ausgewählten Browser stieg auf 0.0014%
  • Der neue Algorithmus ersetzt ab FingerprintJS 4.2.0 den bisherigen Audio-Fingerprint; die Berechnungszeit steigt zwar um das 1,5- bis 2-Fache, bleibt aber auch auf leistungsschwachen Geräten kurz

Wie Safari 17 Audio-Fingerprints destabilisiert

  • Audio-Fingerprinting rendert ein Audiosignal mit der Audio API und OfflineAudioContext des Browsers und bildet anschließend durch Summieren der Samples eine einzelne Kennzahl als Identifikator
  • Dieser Identifikator besitzt Stabilität, da er sich auch nach dem Löschen von Cookies oder dem Wechsel in den Inkognito-Modus nicht ändert; die Eindeutigkeit ist jedoch nicht hoch, weil viele Nutzer denselben Wert teilen können
  • Safaris erweiterter Fingerprint-Schutz ist standardmäßig im privaten Modus aktiviert und im normalen Modus deaktiviert; er gilt sowohl für Desktop als auch für Mobilgeräte
  • Die Schutzfunktion wirkt sich auch auf die Screen API und Canvas API aus, hier geht es jedoch nur um die Audio API
  • Ist die Schutzfunktion aktiviert, multipliziert Safari jedes Audio-Sample mit individuellem zufälligem Rauschen
    • Ein verrauschtes Sample liegt zwischen sample*(1-magnitude) und sample*(1+magnitude)
    • Die Verteilung ist gleichverteilt
    • Da Safari weiterhin entwickelt wird, können sich Implementierungsdetails mit der Zeit ändern

Stellen in der Audio API, an denen Rauschen angewendet wird

  • Safari wendet Rauschen an mehreren Schnittstellen an, über die Audiosignale ausgelesen werden können
  • Da sich das Rauschen bei jeder Anwendung ändert, verändert sich der Audio-Fingerprint im privaten Modus von Safari 17 bei jeder Berechnung
  • In Safari 17 auf einem M1 MacBook Air schwankt der Fingerprint zwischen 124.03516 und 124.04545; die Differenz beträgt etwa 0.008%
  • Der kleinste bestehende Unterschied zwischen Audio-Fingerprints verschiedener Browser beträgt 0.0000023% und ist damit deutlich kleiner als Safaris Rauschbereich
  • Um das Rauschen zu beseitigen, müsste auf etwa eine Nachkommastelle gerundet werden; bleiben jedoch weniger als 6 Stellen übrig, lassen sich einige Browser schwer unterscheiden, wodurch die Eindeutigkeit sinkt

Die drei Schritte des neuen Algorithmus

  • Der neue Audio-Fingerprinting-Algorithmus von FingerprintJS durchläuft drei Schritte, um das von Safari hinzugefügte Rauschen zu reduzieren
    • Reduktion der Varianz des Rauschens
    • Vergrößerung der Abstände zwischen den Browser-Identifikationszahlen
    • Entfernung des verbleibenden Rauschens durch Rundung
  • Der bisherige Audio-Fingerprint ist die Summe von 500 Audio-Samples; wird jedem Sample gleichverteiltes Rauschen hinzugefügt, nähert sich das Gesamtrauschen des Fingerprints einer Normalverteilung an
  • Der Mittelwert einer Normalverteilung muss aus dem Mittel vieler Samples geschätzt werden; der Mittelwert einer Gleichverteilung lässt sich dagegen mit (min+max)/2 aus weniger Samples präzise schätzen
  • Im Experimentcode benötigte die Normalverteilung bei gleicher Präzisionsanforderung 524,288 Samples, während bei der Gleichverteilung 4,096 Samples ausreichten
  • Die neue Methode wechselt vom Summen-Fingerprint zur Erfassung nur eines einzelnen Audio-Samples, um gleichverteiltes Rauschen zu behandeln
  • Wegen dieser Änderung ist der neue Fingerprint nicht mit dem bisherigen kompatibel; für eine Umstellung ohne Verlust von Besucher-Identifikatoren ist ein eigener Ansatz nötig

Verrauschte Kopien desselben Audio-Samples erzeugen

  • Mehrfaches Aufrufen von getChannelData auf einer AudioBuffer-Instanz funktioniert nicht
    • Das Rauschen wird einmal pro AudioBuffer-Instanz angewendet
    • getChannelData derselben Instanz gibt dasselbe Signal zurück
  • Führt man den gesamten Prozess zur Erzeugung des Audiosignals mehrfach aus, lassen sich viele AudioBuffer-Instanzen erzeugen; für die Fingerprint-Berechnung ist das jedoch zu langsam
    • Für 6.000 verrauschte Samples lag die schnellste Zeit auf einem M1 MacBook bei 7 Sekunden
    • Bei 60.000 schaffte Safari es nicht, die Aufgabe abzuschließen
  • Ein besserer Ansatz ist, eine AudioBuffer-Instanz zu erzeugen, die dasselbe Audiosignal wiederholt
    • Das erste Audiosignal wird gerendert, getChannelData wird jedoch nicht aufgerufen
    • Ein zweiter, längerer OfflineAudioContext wird erstellt, und das ursprüngliche Signal wird als AudioBufferSourceNode verwendet
    • Mit loop, loopStart und loopEnd wird ein Teil des ursprünglichen Signals wiederholt
    • Nach der Wiederholung fügt Safari Rauschen hinzu, wodurch Kopien desselben Audio-Samples mit jeweils unterschiedlichem Rauschen entstehen
  • Mit dieser Methode lassen sich die benötigte Anzahl an verrauschten Kopien mit nur zwei Audio-Renderings erzeugen
  • Das Rauschen verschwindet nicht vollständig, aber die Varianz wird kleiner als beim ursprünglichen Audio-Sample
    • 8,192 Kopien: Bereich über 100 Ausführungen 0.000387%, auf einem M1 MacBook 2.6ms
    • 65,536 Kopien: 0.0000123%, 4.1ms
    • 262,144 Kopien: 0%, 7.5ms

Unterschiede zwischen Browsern bei Audio-Samples vergrößern

  • Reduziert man die Zahl der Kopien, verbessert sich die Performance, aber die Varianz der Ergebnisse steigt; daher wird das Basissignal geändert, um die Unterschiede zwischen Browsern bei Audio-Samples zu vergrößern
  • Nach Experimenten mit mehreren integrierten Audio-Nodes ergab sich folgende Signalerzeugungskette, bei der die Sample-Unterschiede zwischen Browsern größer werden
  • Das 3396. Sample des Audiosignals zeigte die größten Unterschiede zwischen Browsern; dieser Wert wurde durch den Vergleich aller Samples mehrerer Browser gefunden
  • In der ausgewählten Browser-Stichprobe betrug der kleinste Unterschied dieses neuen Samples 0.0014%
    • Das ist größer als der kleinste Unterschied des bisherigen Fingerprints von 0.0000023%
    • Dadurch können gröbere Rauschunterdrückung und Rundung angewendet werden

Stabilisierung des Fingerprints durch Rundung

  • Auch wenn der Rauschbereich eines einzelnen Samples kleiner wird, schwankt der Wert weiterhin; für die Verwendung als finaler Fingerprint ist daher Rundung nötig
  • Da Rauschen nicht als absoluter Wert, sondern relativ zum Audio-Sample-Wert angewendet wird, erfolgt die Rundung nicht nach Nachkommastellen, sondern nach signifikanten Stellen
  • Für die Unterscheidung der ausgewählten Browser reichten 5 signifikante Stellen aus; da jedoch nicht alle Browser und künftigen Änderungen überprüft werden können, werden mehr Stellen verwendet
  • Im privaten Modus von Safari 17 ist je nach Rundungspräzision folgende Anzahl an Kopien für Stabilisierung nötig
    • 6 signifikante Stellen: 15,000 Kopien, bei warmem Safari 17 auf einem M1 MacBook 3ms
    • 7 signifikante Stellen, wobei die letzte Stelle auf ein Vielfaches von 5 gerundet wird: 30,000 Kopien, 4ms
    • 7 signifikante Stellen, wobei die letzte Stelle auf die nächstgelegene gerade Zahl gerundet wird: 70,000 Kopien, 6ms
    • 7 oder mehr signifikante Stellen: 400,000 Kopien, 12ms
  • Die finale Wahl sind 7 signifikante Stellen, wobei die letzte Stelle 0 oder 5 wird; zur Erhöhung der Stabilität wurde die Zahl der Kopien auf 40,000 erhöht
  • Die so gerundete Zahl wird zu einem neuen Audio-Fingerprint, der sich auch bei aktiviertem erweiterten Fingerprint-Schutz in Safari 17 nicht ändert
  • Der neue Fingerprint wird so bewertet, dass er dieselbe Eindeutigkeit wie der bisherige Audio-Fingerprint besitzt

Performance und Ausführungsbeschränkungen

  • Bei einem warmen Browser auf einer leeren Seite ist der neue Algorithmus insgesamt langsamer als der bisherige
    • MacBook Air 2020 Safari 17.3: bisher 2ms, neue Methode 4ms
    • MacBook Air 2020 Chrome 120: bisher 5ms, neue Methode 8ms
    • iPhone 13 mini Safari 17.3: bisher 8ms, neue Methode 12ms
    • Galaxy J7 Prime Chrome 120: bisher 33ms, neue Methode 45ms
    • BrowserStack Windows 11 Firefox 121: bisher 10ms, neue Methode 18ms
  • Die Performance des neuen Algorithmus ist gegenüber dem bisherigen 1,5- bis 2-mal schlechter, die Berechnungszeit bleibt jedoch auch auf leistungsschwachen Geräten kurz
  • Da der Browser manche Aufgaben an den OfflineAudioRender-Thread delegiert, bleibt die Seite während des größten Teils der Audio-Fingerprint-Berechnung reaktionsfähig
  • Die Web Audio API kann nicht in Web Workers verwendet werden, daher lässt sich der Audio-Fingerprint nicht in einem Worker berechnen
  • Zur Performance-Verbesserung kann per User-Agent-String geprüft werden, ob Safari 17 oder neuer verwendet wird; der neue Algorithmus kann nur dort eingesetzt werden, während andere Browser beim bisherigen Algorithmus bleiben

Unterschiede zu Tor und Brave

  • Tor deaktiviert die Web Audio API vollständig, daher ist Audio-Fingerprinting unmöglich
  • Brave fügt Audiosignalen wie Safari 17 Rauschen hinzu, verwendet jedoch eine andere Methode
  • Safari multipliziert jedes Audio-Sample mit einem eigenen Zufallswert
  • Brave erzeugt einmal einen zufälligen Multiplikator namens fudge factor und multipliziert alle Audio-Samples mit demselben Wert
    • Dieser Wert bleibt innerhalb der Seite erhalten
    • Er ändert sich nur in einer neuen normalen Sitzung oder Inkognito-Sitzung
  • In Brave wird auf alle Kopien dasselbe Rauschen angewendet, egal wie viele Kopien eines Audio-Samples erzeugt werden; daher funktioniert der mathematische Ansatz zur Rauschbeseitigung für Safari dort nicht
  • Der frühere Ansatz zur Entfernung von Brave-Rauschen funktioniert jedoch weiterhin, und die neue Methode zur Signalerzeugung, die die Fingerprint-Unterschiede zwischen Browsern vergrößert, kann die Fehlertoleranz erhöhen

Anwendung in FingerprintJS

  • Der neue Audio-Fingerprinting-Algorithmus hat in FingerprintJS die bisherige Methode ersetzt und wurde erstmals in 4.2.0 veröffentlicht
  • Der vollständige Implementierungscode befindet sich im GitHub-Repository von FingerprintJS
  • Der Audio-Fingerprint ist eines von mehreren Signalen, die die Open-Source-Bibliothek zur Erstellung eines Browser-Fingerprints nutzt
  • FingerprintJS schließt nicht pauschal alle im Browser verfügbaren Signale ein, sondern analysiert Stabilität und Eindeutigkeit jedes Signals separat und bewertet dessen Einfluss auf die Fingerprint-Genauigkeit
  • Der Audio-Fingerprint trägt nur wenig zur Eindeutigkeit bei, gilt aber wegen seiner hohen Stabilität als Signal, das die Genauigkeit des gesamten Fingerprints leicht erhöht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-11
Meinungen auf Hacker News

  • Eine weitere interessante Technik zur Identifizierung von Nutzern im Web ist GPU-Fingerprinting; sie wurde 2022 unter dem Codenamen „DrawnApart“ vorgestellt.
    Dabei werden per WebGL die Anzahl und Geschwindigkeit der GPU-Ausführungseinheiten gezählt sowie die Abschlusszeiten beim Vertex-Rendering und die Verarbeitung von Stall-Funktionen gemessen.

    1. https://www.bleepingcomputer.com/news/security/researchers-u...
    • Browser sollten standardmäßig einen Software-Renderer verwenden, und wenn sie den Hardware-GPU-Renderpfad öffnen, sollte die Website wie bei Mikrofon oder Kamera eine Nutzerberechtigung anfordern müssen.

  • Heutzutage, besonders wenn man das Interesse an Seitenkanalangriffen betrachtet, funktioniert ein Ansatz, bei dem man gleichverteiltes Rauschen zu Werten hinzufügt, aus denen Daten lecken, so gut wie sicher nicht.
    Denn wenn man mehr Samples sammelt, kann man das Rauschen herausrechnen. Ich weiß nicht, warum Safari das eingebaut hat. Es kann Fingerprinting zwar lästiger machen, aber wie dieser Artikel zeigt, scheint es letztlich in irgendeiner Form weitgehend umgehbar zu sein.

    • Viele der heutigen Privacy-Funktionen von Apple wirken für mich eher wie Marketing.
      Es fühlt sich wie Privacy-Theater an, bei dem wichtiger geworden ist, ob man der Öffentlichkeit eine plausibel klingende Geschichte erzählen kann, als ob es technisch wirksam ist.

  • Kann jemand erklären, warum die Ergebnisse überhaupt unterschiedlich sind? Ich frage mich zum Beispiel, warum Audio-Fingerprinting möglich ist.

    • Der Kern scheint zu sein, dass es in der Web Audio API Algorithmen mit vielen mathematischen Operationen gibt, deren Implementierungen sich je nach Browser leicht unterscheiden, und dass das exakte Ergebnis auch vom Betriebssystem und der CPU abhängt.
      Wenn man mit der Web Audio API ein kleines Signal erzeugt, liefern alle Browser fast dasselbe Ergebnis, aber die winzigen Unterschiede lassen sich nutzen, um sie voneinander zu unterscheiden.
    • Ähnlich wie bei vergleichbaren Techniken in WebGL kommt meiner Ansicht nach viel Entropie aus dem Grafikkartentreiber des PCs und der Hardware selbst.
      Es ist bedauerlich, dass Browserentwickler dem Audio-Buffer-Processing Rauschen hinzufügen müssen, um das zu verhindern.
    • Das war auch mein erster Gedanke, und hier wird es ausführlicher behandelt: https://fingerprint.com/blog/audio-fingerprinting/#why-the-a...
      Kurz gesagt können selbst innerhalb derselben Codebasis unterschiedliche Codepfade, etwa SIMD-Varianten, leicht unterschiedliche Gleitkomma-Ergebnisse erzeugen. Das scheint damit zusammenzuhängen, dass Gleitkommaoperationen empfindlicher auf Dinge wie die Reihenfolge der Operationen reagieren, als man erwarten würde.
    • Sehr wahrscheinlich liegt es an Implementierungsdetails und Compiler-Optimierungen. Gleitkommaaddition ist zum Beispiel nicht kommutativ.
      Selbst wenn derselbe Algorithmus und dieselbe Formel korrekt implementiert werden, können die Ergebnisse leicht voneinander abweichen.

  • Korrigiert mich, wenn ich falsch liege. Der Grund, warum die Fingerprinting-Umgehung hier erfolgreich ist, scheint auf die Entscheidung in der Web-Audio-API-Spezifikation zurückzugehen, die Behandlung des Antialiasings von OscillatorNode so offen zu lassen:
    „Es gibt viele praktische Ansätze, die eine Implementierung wählen kann, um dieses Aliasing zu vermeiden. Unabhängig vom Ansatz ist das ideale zeitdiskrete digitale Audiosignal mathematisch klar definiert. Die Kompromisse bei der Implementierung liegen in den Implementierungskosten in Form von CPU-Nutzung und darin, wie treu dieses Ideal erreicht wird. Es wird erwartet, dass Implementierungen ein gewisses Maß an Sorgfalt aufwenden, um dieses Ideal zu erreichen; auf leistungsschwacher Hardware ist es jedoch vernünftig, Ansätze mit geringerer Qualität und geringeren Kosten in Betracht zu ziehen.“
    Meiner Ansicht nach bedeutet das, dass die hier ausgenutzte Ausgabe von OscillatorNode zwischen Browsern und sogar im selben Browser auf unterschiedlicher Hardware mit ziemlicher Sicherheit nicht deterministisch ist. Die Nichtdeterministik basiert auf der vom Browser gewählten Antialiasing-Methode oder auf mehreren Pfaden, die derselbe Browser je nach Hardware auswählt. Dazu gehören auch Änderungen oder Anpassungen desselben Antialiasing-Algorithmus.
    Warum man das Antialiasing den Browsern überlassen hat, ist mir nicht ganz klar. Hochwertige Audio-Apps oder -Bibliotheken werden die Art, wie Aliasing in den von ihnen erzeugten Signalen vermieden wird, vollständig kontrollieren wollen und nicht den Standardoszillator verwenden. Umgekehrt ist es einer Web-App, die einen beliebigen Antialiasing-Algorithmus und die daraus folgenden browserspezifischen Unterschiede akzeptiert, wahrscheinlich ziemlich egal, ob der Algorithmus eine hartcodierte SIMD-Anweisung oder ein 20 MB großes JavaScript-Web-Audio-Helferframework ist.
    1: https://webaudio.github.io/web-audio-api/#OscillatorNode
    Ich frage mich auch, ob man hier eine ähnliche Lösung anwenden könnte wie Hixie bei der Standardisierung des HTML5-Parsers: Ein Fachexperte spezifiziert einen exakten, deterministischen Antialiasing-Algorithmus, der gut genug funktioniert, und danach verwenden alle Browser diesen. Ein messbarer Performance-Verlust wäre vermutlich nur in Web-Audio-API-Tutorials zu sehen, die Signale mit dem standardmäßigen antialiasenden Oszillator erzeugen.

    • Hochwertiges Antialiasing ist teuer.
      Deshalb möchte man Implementierungen je nach verfügbarer Rechenleistung, Akku usw. entscheiden lassen, wie viel sie dafür aufwenden.

  • Es war töricht, eine Node-Graph-Audio-API in den Browser einzubauen. Es hätte einfach nur AudioWorklet geben sollen.

  • Widerlich

    • Genau mein Gedanke. Interessant, aber widerlich.
      Ich verstehe schon grundsätzlich nicht, warum die Audio-API ohne Zustimmung der Website genutzt werden kann. Das ließe sich scheinbar leicht mit einem einfachen Dialog wie „Diese Website möchte Ihr Audiogerät verwenden“ beheben.
    • Da fragt man sich, ob wir den heutigen Netzwerk-Stack wirklich die nächsten 100 Jahre weiterverwenden sollten.
      Das Internet in seiner jetzigen Form hat den Traum vom Personal Computing ziemlich ruiniert. Unternehmen und Staaten sind gegenüber Einzelpersonen viel zu asymmetrisch mächtig. Sollte meine Technik ohne ausdrückliche Zustimmung Daten an Server senden können?
    • Stimmt. Ich kann nicht glauben, dass diese Leute darauf stolz sind.
      Andererseits: Als ich den Browser-Cache gelöscht und ein VPN eingeschaltet habe, haben sie mich immerhin fälschlich als neuen Besucher erkannt. Trotzdem ist das Geschäftsmodell niederträchtig.
    • Bei fingerprint.com fand ich schon eine gewisse Ironie darin. Das ist ein bisschen so, als würde eine Website eine Lücke zur Vermeidung von Steuerlasten popularisieren, woraufhin die Welt sich angewidert zeigt und die Lücke schließt.
      Selbst wenn das eine wohlwollende Interpretation ist: Es hat großen Wert, solche Forschung zu veröffentlichen und ans Licht zu bringen. Statt zu befürchten, dass alle mehr stehlen, nur weil jemand schreibt, dass ein bestimmter grüner Rucksack einer bestimmten Marke beim Diebstahl hilft, würde ich eher darauf setzen, dass Läden diese Methode danach besser erkennen.

  • Statt zu jedem Sample einen Zufallswert hinzuzufügen, könnte Safari offenbar auch deterministisches Rauschen hinzufügen, das auf einem Schlüssel basiert, der sich jede Stunde ändert.
    Wenn man es als Funktion aus Audio-Sample und Schlüssel gestaltet, ist das Rauschen innerhalb derselben Sitzung gleich, aber eine Stunde später fürs Tracking nutzlos.

    • Wenn man 10 solcher Samples mittelt, kommt man am Ende dem tatsächlichen Wert des Geräts nahe. Je mehr Samples, desto näher.
      Um das zu beheben, muss man den Informationsabfluss selbst beseitigen; ihn nur mit einer Schicht zufälliger Abweichung zu überdecken, reicht nicht.
    • Würde es nicht helfen, wenn das hinzugefügte Rauschen deterministisch nach Origin ist? Dann ließe es sich auch durch übermäßiges Sampling und Mittelwertbildung nicht entfernen.
      Zum Beispiel etwa so: RNG_SEED = HMAC_SHA256(PERSISTENT_SECRET,Location.origin).

  • Ich bin jetzt wirklich bereit, „diese Person“ zu werden, die JavaScript abschaltet und so im Web surft.

    • Das Problem ist: Allein dadurch, „diese Person“ zu sein, gibst du zur Identifikation wahrscheinlich schon mehr als 10 Bit preis.
      Wenn sie anderswo nur ein paar weitere Bits zusammenkratzen, kann man dich eindeutig identifizieren. Nach meinem Maßstab können diese Leute trotzdem zusammen mit dem Rest der Adtech-Branche auf die Golgafrinchan Ark B verfrachtet werden.
    • Viel Glück. Es ist erstaunlich, wie wenig ordentliches altes HTML es im heutigen Web noch gibt.
      Eine Website, die ich neulich besucht habe, verwendete zwar Markup, aber statt es zu HTML zu kompilieren und statisch auszuliefern, wurde es clientseitig per JavaScript gerendert. WTF.
    • Mach mit, es geht tatsächlich. Es gibt eine hervorragende Firefox-Erweiterung namens uMatrix, mit der man JavaScript nicht nur pro Website, sondern auch pro Subdomain leicht abschalten kann; und bei Websites, die ohne JavaScript kaputtgehen, lässt es sich ebenso leicht wieder einschalten.
    • Viel Glück. Ich habe diesen Kampf vor Kurzem aufgegeben, weil ich auf fast jeder Website, die ich besuche, JavaScript wieder einschalten musste, um den Inhalt zu sehen.
      Nicht nur wegen DDoS-Prüfungen wie bei Cloudflare; inzwischen wird sogar das, was eigentlich im HTML der Seite stehen sollte, per JavaScript geladen.
    • Genau aus diesem Grund sollte man im Tor Browser JavaScript ausschalten.
      Je feindseliger das Internet wird, desto richtiger wird diese Entscheidung.

  • Ich verstehe nicht ganz, wie diese Methode mehr als ein paar Tausend eindeutige Kombinationen erzeugen kann.
    Browsertyp × Browserversion × Betriebssystemversion × Beschleuniger-Version × … was noch? Es scheint nicht genug Variation zu geben, um aus der Ferne eindeutig zu sein.

    • Kombinatorik ist eine gnadenlose Herrin.

  • Nimmt diese Technik Fingerprints anhand von Unterschieden bei Hardware, Treibern und Betriebssystem in der Audioverarbeitung, oder betrachtet sie nur die Browser-Software?
    Ich nehme an, es gab oder gibt noch ähnliche Techniken, die Unterschiede der darunterliegenden Grafikgeräte offenlegen.

    • Es funktioniert ähnlich. Audioalgorithmen rufen oft Betriebssystemfunktionen auf und nutzen CPU-Optimierungen.
      Eines der Beispiele im Artikel ist die schnelle Fourier-Transformation (FFT). Jedes Betriebssystem hat eine Version dieser Funktion, aber sie wird im Laufe der Zeit tendenziell optimiert und verhält sich je nach verfügbaren SIMD-Befehlen oft von CPU zu CPU unterschiedlich.