AliExpress: Fingerprinting über die Web-Audio-API

Ein Onlineshop wird geöffnet, und plötzlich verstummt die Musik auf dem Smartphone. Im Browser läuft kein Video, kein Werbespot ist zu hören, und selbst ein stummgeschalteter Tab ändert nichts. Erst wenn der AliExpress-Tab geschlossen wird, schalten die Bluetooth-Kopfhörer wieder sauber zum Telefon zurück.

Was wie ein Fehler in Bluetooth Multipoint klingt, führte den Entwickler Matt Callaghan zu zwei stark verschleierten JavaScript-Dateien auf der AliExpress-Homepage. Beide erzeugten im Hintergrund einen laufenden Web-Audio-Graphen. Der Pegel am Ausgang war null, hörbar war also nichts. Für Browser, Betriebssystem und Kopfhörer blieb der Audiopfad trotzdem aktiv.

Der Fund ist technisch faszinierend, weil ein unbeabsichtigter Hardware-Nebeneffekt eine unsichtbare Browser-Messung verriet. Er ist sicherheitspolitisch noch interessanter, weil Web Audio nur ein Baustein war. Die Skripte prüften zusätzlich Canvas, WebGL, Bildschirm, Hardware, unterstützte Medienformate, WebRTC und Nutzerinteraktionen. Das Ergebnis sieht nach einem umfassenden Browser- und Geräte-Fingerprint aus.

Der Bluetooth-Fehler, der keiner war

Callaghan verwendet Multipoint-Kopfhörer, die gleichzeitig mit PC und Smartphone verbunden sind. Normalerweise hört er Musik vom Telefon. Sobald der PC tatsächlich Audio wiedergibt, übernimmt dieser die Wiedergabe. Genau dieser Prioritätswechsel blieb plötzlich hängen, wenn AliExpress in Firefox oder Chrome geöffnet war. Andere Browser hatte er nicht getestet.

Die üblichen Verdächtigen schieden aus. Es gab keine Audio- oder Videoelemente, keinen Aufruf von HTMLMediaElement.play(), keine aktive Media Session und keine erkennbare Mediendatei im Netzwerkverkehr. Auffällig war nur, dass die Störung einige Sekunden nach dem Laden der Seite einsetzte.

Callaghan instrumentierte deshalb die Web-Audio-API. Er ersetzte den Konstruktor von AudioContext durch einen Wrapper, protokollierte neue Audio-Kontexte und überwachte Verbindungen über AudioNode.connect(). Dabei erschienen zwei laufende Kontexte, deren Stack-Traces auf diese Skripte zeigten:

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Beide lagen unter einem AWSC-Pfad und wirkten aufgrund ihrer Funktionen wie Bestandteile einer Alibaba-Infrastruktur für Browser-Sicherheit und Missbrauchserkennung. Diese Zuordnung ist plausibel, aber aus den Dateinamen allein nicht abschließend bewiesen. Alibaba Cloud dokumentiert für sein Anti-Bot Web SDK allerdings ausdrücklich einen Web-Collector, der zusammen mit einer serverseitigen Auswertung eingesetzt wird.

Das Verhalten ließ sich enger eingrenzen: Nach dem Blockieren beider Skriptfamilien wurden in Callaghans Kontrollmessung weder die Audio-Kontexte noch die Verbindungen zum Audio-Ausgang angelegt. Die Homepage und die normale Produktsuche funktionierten in seinem Test weiter.

Was der Web-Audio-Graph genau macht

Web Audio ist keine versteckte Abhörfunktion, sondern eine leistungsfähige Browser-Schnittstelle für Spiele, Synthesizer, Videokonferenzen und andere interaktive Anwendungen. Statt nur eine Audiodatei abzuspielen, verbindet eine Website einzelne Verarbeitungsknoten zu einem Graphen.

Die untersuchten AliExpress-Skripte bauten vereinfacht diese Kette auf:

OscillatorNode mit Sägezahnwelle
  -> AnalyserNode
  -> ScriptProcessorNode
  -> GainNode mit Verstärkung 0
  -> AudioContext.destination

Der Oszillator erzeugt ein bekanntes Signal. Der AnalyserNode stellt Messdaten aus der Verarbeitung bereit, und JavaScript liest die Frequenzwerte aus. Der GainNode setzt den Pegel anschließend auf null. Das Signal wird dadurch nicht hörbar, der Graph bleibt jedoch mit AudioContext.destination und damit dem Echtzeit-Ausgang verbunden.

Genau diese Verbindung erklärt den Nebeneffekt. Null Lautstärke bedeutet nicht null Verarbeitung. Der Browser berechnet den Graphen weiter, und auf Callaghans Windows-System reichte das offenbar aus, um den PC-Audiopfad aktiv zu halten. Der automatische Multipoint-Wechsel der Kopfhörer interpretierte den PC deshalb weiterhin als aktive Quelle.

Für eine rein rechnerische Messung wäre ein OfflineAudioContext naheliegender. Er rendert einen Audio-Graphen direkt in einen Speicherpuffer, ohne ihn an die Lautsprecher oder das Audiogerät des Betriebssystems zu schicken. Beim AliExpress-Graphen liegen Oszillator und Analyse außerdem vor dem auf null gesetzten Ausgang. Die Verbindung mit dem Live-Ausgang lieferte für die bereits ausgelesenen Frequenzdaten keinen erkennbaren Zusatznutzen, verursachte aber den sichtbaren Nebeneffekt.

Mozilla hatte denselben Effekt schon 2023 protokolliert

Callaghans Kopfhörer lieferten 2026 den öffentlichkeitswirksamen Hinweis. Der zugrunde liegende Browser-Effekt war bei Mozilla jedoch bereits seit November 2023 als Bug 1863193 erfasst. Der ursprüngliche Bericht zu Firefox 119 beschrieb AliExpress-Seiten, die unter Windows 11 einen dauerhaften Audio-Power-Request auslösten. powercfg /requests meldete einen aktiven Audiostream, obwohl im Tab keine Wiedergabe angezeigt wurde. Der Rechner wechselte deshalb nicht mehr automatisch in den Ruhezustand. Nach dem Schließen des Tabs verschwand die Anforderung.

Mozilla-Entwickler Karl Tomlinson aktivierte daraufhin das Web-Audio-Logging. Das Protokoll zeigte zweimal genau die später von Callaghan beschriebene Kette aus OscillatorNode, AnalyserNode, ScriptProcessorNode, stummem GainNode und AudioDestinationNode. Tomlinson beobachtete eine ähnliche dauerhafte Gerätenutzung in Chrome und hielt fest, dass AliExpress sie mit AudioContext.suspend() beenden könnte.

Das ist eine wichtige unabhängige Bestätigung. Der Hardware-Nebeneffekt beruht nicht nur auf Callaghans Interpretation eines verschleierten Skripts. Mozilla hatte den laufenden Graphen und seinen Einfluss auf die Windows-Energieverwaltung Jahre zuvor direkt im Browser protokolliert. Der Bug ist weiterhin offen. Er zeigt zugleich, dass die Verantwortung geteilt ist: AliExpress hätte den Kontext nach der Messung suspendieren können, der Browser könnte einen effektiv stummen und nicht mehr benötigten Graphen aber ebenfalls früher vom Audiogerät lösen.

Kein Mikrofon, kein Ultraschall aus dem Raum

Hier ist sprachliche Präzision wichtig. AliExpress nahm in diesem Test weder das Mikrofon auf noch lauschte die Seite auf Töne im Zimmer. Mikrofonzugriff würde über getUserMedia() laufen und eine Berechtigung des Nutzers voraussetzen.

Ebenso irreführend ist die Vorstellung, der Shop habe ein Ultraschallsignal über die Lautsprecher ausgesendet und anschließend physisch wieder eingefangen. Die Messung fand innerhalb der Audioverarbeitung des Browsers statt. Die Sägezahnwelle wurde berechnet, analysiert und vor der Ausgabe auf null gesetzt. Der Kopfhörer-Effekt entstand, weil der virtuelle Graph trotzdem am realen Ausgang hing.

Weshalb identische Berechnungen unterschiedlich ausfallen können

Digitale Signalverarbeitung besteht aus vielen Gleitkommaoperationen. CPU-Architektur, verwendete mathematische Bibliotheken, Compilerentscheidungen, Browserimplementierung und Rundungsverhalten können kleine Abweichungen erzeugen. Der Web-Audio-Standard nennt OscillatorNode, DynamicsCompressorNode, Sample-Rate, Latenz und Zeitmessungen ausdrücklich als mögliche Fingerprinting-Flächen. Browser sollen diese Unterschiede deshalb begrenzen.

Ein Web-Audio-Ergebnis ist aber kein magischer Hardware-Seriencode. Mehrere Geräte können denselben Wert liefern, und ein Browser kann die Ergebnisse vereinheitlichen oder verändern. Erst im Verbund mit weiteren Merkmalen steigt die Wiedererkennbarkeit.

Das Verfahren ist mindestens seit 2016 im Einsatz

Audio-Fingerprinting ist keine neue Entdeckung aus dem Jahr 2026. Steven Englehardt und Arvind Narayanan untersuchten für ihre 2016 bei ACM CCS veröffentlichte OpenWPM-Studie eine Million Websites. Sie fanden AudioContext-Fingerprinting in drei Skripten auf insgesamt 67 Websites. Zwei der Skripte nutzten die Technik nach ihrer manuellen Analyse tatsächlich aktiv.

Auch dort erzeugte ein Oszillator ein bekanntes Signal, das nach der Verarbeitung ausgelesen und gehasht wurde. Eine der dokumentierten Varianten führte den Graphen über einen AnalyserNode, einen ScriptProcessorNode und einen stummen GainNode zum Ausgang. Das ist strukturell bemerkenswert nah am AliExpress-Muster. Schon die Princeton-Forscher betonten, dass kein Mikrofon benötigt wird und dass Fingerprinting-Techniken üblicherweise miteinander kombiniert werden.

Neu am AliExpress-Fall ist also nicht die Grundidee. Neu ist der konkrete Fund auf einem der größten Onlinemarktplätze, die breite Kombination weiterer Merkmale und vor allem der Nebenkanal, durch den die Messung auffiel.

Der Tonwert war nur ein Puzzleteil

In den untersuchten Bundles fand Callaghan Abfragen und Messungen zu zahlreichen weiteren Merkmalen:

• Canvas-Rendering und toDataURL()
• WebGL-Renderer, Erweiterungen und Shader-Präzision
• Bildschirm- und Viewport-Abmessungen sowie Device Pixel Ratio
• hardwareConcurrency und deviceMemory
• installierte Browser-Plugins und unterstützte Medienformate
• WebRTC-Verhalten und Performance-Timing
• Maus-, Touch-, Fokus- und Scroll-Ereignisse
• Gerätebewegung und Ausrichtung
• Eigenschaften, die auf Browser-Automatisierung oder Bots hindeuten können

Der Code enthielt außerdem Routinen zum Serialisieren und Verschlüsseln von Ergebnissen sowie zur Übertragung mit fetch() oder sendBeacon(). Damit ist auf der Client-Seite belegt, dass eine breite Menge fingerprinting-tauglicher Daten erhoben und an Alibaba-Dienste gesendet werden kann.

Nicht belegt ist, was serverseitig daraus entsteht. Aus dem Browser lässt sich weder die Speicherdauer noch die spätere Verknüpfung mit Konten, Bestellungen, anderen Alibaba-Angeboten oder Werbeprofilen ablesen. Callaghan formuliert diese Grenze selbst ausdrücklich.

AliExpress nennt in seiner Datenschutzrichtlinie unter anderem Browser- und Betriebssystemdaten, Hard- und Softwaremerkmale, eindeutige Gerätekennungen, Nutzungsmuster und Interaktionen. Als Zwecke nennt das Unternehmen neben Betrieb und Personalisierung auch die Erkennung von Betrug, Geldwäsche und Sicherheitsvorfällen. Die Richtlinie macht die beobachtete technische Ausführung dadurch nicht transparent, sie zeigt aber, dass umfangreiche Geräte- und Nutzungsdaten grundsätzlich Teil des beschriebenen Datenmodells sind.

Fingerprinting ist nicht automatisch Werbetracking

Browser-Fingerprints werden in sehr unterschiedlichen Zusammenhängen eingesetzt. Werbenetzwerke können damit einen Browser trotz gelöschter Cookies wiedererkennen. Onlineshops und Zahlungsdienste nutzen ähnliche Signale aber auch für Risikobewertung, Kontoübernahmen, Coupon-Missbrauch, Scraping, Bots oder automatisierte Käufe.

Die beiden Zwecke schließen einander nicht aus. Dieselbe Gerätekennung kann gleichzeitig Sicherheits- und Marketinginteressen dienen. Aus dem gefundenen JavaScript allein lässt sich jedoch keine konkrete websiteübergreifende Werbekampagne nachweisen. Wer aus dem Fund direkt „AliExpress verfolgt jeden Nutzer über alle Websites“ ableitet, geht über die vorhandenen Belege hinaus.

Für die Sicherheitsbewertung bleibt der Fall trotzdem problematisch:

• Die Messung begann bereits auf der allgemeinen Homepage und nicht erst bei Login oder Zahlung.
• Die Skripte waren stark verschleiert und für Nutzer praktisch nicht nachvollziehbar.
• Die Datenerhebung umfasste wesentlich mehr als ein einzelnes Anti-Bot-Signal.
• Der laufende Audio-Graph war in der Oberfläche nicht sinnvoll erkennbar und ließ sich durch Stummschalten des Tabs nicht beenden.
• Eine Hintergrundfunktion griff so weit in den lokalen Audiopfad ein, dass externe Hardware ihr Verhalten änderte.

Eine nachvollziehbare Betrugsabwehr braucht nicht zwingend eine öffentliche Implementierungsanleitung. Sie braucht aber Datenminimierung, eine klare Zweckbindung und eine Oberfläche, deren Verhalten nicht im Widerspruch zu den Erwartungen des Nutzers steht. Ein stiller Shop-Tab sollte keinen Echtzeit-Audiopfad belegen.

Wie eindeutig war dieser Audio-Fingerprint wirklich?

Der Firefox-Entwickler Tom Ritter extrahierte die betreffende Web-Audio-Berechnung und verglich sie mit Telemetriedaten von Firefox. Das Ergebnis relativiert alarmistische Darstellungen erheblich.

Seit Firefox 118 verwendet Web Audio auf allen Plattformen die mathematische Bibliothek FDLIBM, um systemabhängige Abweichungen zu reduzieren. In Ritters Auswertung entfielen 99,24 Prozent der Nutzer auf nur drei Ergebniswerte. Bei weiteren 0,76 Prozent schlug der Messpunkt fehl und lieferte null. Die drei großen Gruppen ließen sich im Wesentlichen auf CPU-Klassen zurückführen: x86 beziehungsweise x64 ohne FMA, x64 mit FMA und ARM mit NEON.

Für die konkrete AliExpress-Methode bedeutet das: Unter Firefox war der Audiowert für fast alle untersuchten Nutzer nicht individuell. Er verriet eher eine grobe Prozessorgruppe als ein einzelnes Gerät. Eine kleine lange Ausreißergruppe mit weiteren Werten blieb allerdings bestehen, und gerade seltene Werte können die betreffenden Systeme stärker hervorheben.

Fingerprinting arbeitet mit Kombinationen. Bildschirmgröße, Zeitzone oder CPU-Klasse sind für sich genommen meist banal. Canvas, WebGL, Schriftarten, Hardwareangaben, Browsermerkmale, Interaktionsmuster und ein vorhandener Login können zusammen wesentlich trennschärfer sein. Der Web-Audio-Wert muss deshalb nicht eindeutig sein, um im Gesamtscore nützlich zu bleiben.

Browser-Schutz ist ein Wettrüsten mit Nebenwirkungen

Browser verfolgen unterschiedliche Strategien. Firefox vereinheitlicht bestimmte Berechnungen und blockiert bekannte Fingerprinting-Dienste. Seit Firefox 145 sind weitergehende Schutzmaßnahmen zunächst im privaten Modus und bei strengem verbessertem Schutz vor Aktivitäten aktiv. Mozilla betont selbst, dass aggressivere Vereinheitlichung legitime Funktionen brechen kann.

Brave verändert fingerprinting-taugliche Resultate wie Canvas- und Web-Audio-Werte leicht. Dieses sogenannte Farbling ist innerhalb einer Sitzung und Website stabil, soll aber zwischen Websites und Sitzungen unterschiedliche Resultate liefern. Damit bekommt eine Anwendung weiterhin plausible Werte, kann sie aber schlechter als dauerhafte globale Kennung verwenden.

WebKit begrenzt verschiedene Fingerprinting-Flächen in Safari, etwa lokal installierte Schriften und bestimmte Geräteinformationen. Bei besonders riskanten Schnittstellen verzichtet WebKit teilweise ganz auf eine Implementierung, solange kein aus seiner Sicht sicherer Weg existiert. Das zeigt den grundlegenden Konflikt: Dieselben Schnittstellen, die komplexe Webanwendungen ermöglichen, vergrößern auch die Messfläche des Browsers.

Kein normaler Browser kann garantieren, dass jede Form von Fingerprinting verschwindet. Wenn ein einzelnes Merkmal vereinheitlicht wird, weichen Anbieter auf andere Merkmale oder Verhaltenssignale aus. Und eine besonders exotische Kombination aus Erweiterungen, Schriften und manuellen Schutzschaltern kann den eigenen Browser im schlechtesten Fall sogar seltener machen.

Was Nutzer konkret tun können

Die sinnvollste Basis ist ein aktueller Browser mit aktivem Fingerprinting-Schutz. Bei Firefox ist für die weitergehende Schutzstufe der strenge verbesserte Schutz vor Aktivitäten oder ein privates Fenster relevant. Brave aktiviert seine Shields und Fingerprinting-Abwehr standardmäßig. Bei Safari sollte die aktuelle Betriebssystem- und Browserversion eingesetzt werden. Tor Browser und Mullvad Browser gehen für sensible Sitzungen weiter: Sie versuchen, möglichst viele Nutzer mit einem ähnlichen Browser-Fingerprint in derselben Gruppe erscheinen zu lassen. Eigene Abweichungen und zusätzliche Erweiterungen sollte man dort gerade nicht hinzufügen.

Private Fenster allein sind keine vollständige Antwort. Sie begrenzen gespeicherten Zustand, machen Hardware- und Browsermerkmale aber nicht automatisch unsichtbar. Auch das Löschen von Cookies setzt einen Fingerprint nicht auf dieselbe Weise zurück wie eine Cookie-ID.

Ein VPN löst ein anderes Problem. Es ersetzt die sichtbare öffentliche IP-Adresse und schützt je nach Einsatz den Transportweg zum VPN-Anbieter. Es verändert aber nicht automatisch Canvas, WebGL, Audio-Berechnungen, Schriftarten oder Hardwaremerkmale. Ein VPN kann deshalb sinnvoll sein, ist für sich allein jedoch kein Schutz gegen Browser-Fingerprinting.

Die beiden Skripte gezielt mit uBlock Origin blockieren

Callaghan veröffentlichte zwei bewusst enge Filter für uBlock Origin:

! AliExpress AWSC fingerprinting scripts
||assets.aliexpress-media.com/g/AWSC/uab/*/collina.js$script,domain=aliexpress.com
||assets.aliexpress-media.com/g/AWSC/fireyejs/*/fireyejs.js$script,domain=aliexpress.com

Nach dem Eintragen unter Meine Filter müssen bereits geöffnete AliExpress-Tabs geschlossen werden. Ein nachträglich blockiertes Skript beendet keinen Audio-Kontext, den es zuvor schon angelegt hat.

Diese Regeln sind eine Momentaufnahme. Pfade, Versionen und Dateinamen können sich ändern. Da die Skripte vermutlich zur Anti-Bot- und Risikoinfrastruktur gehören, können außerdem zusätzliche CAPTCHAs oder Probleme bei Anmeldung und Checkout auftreten. Wer eine legitime Transaktion nicht abschließen kann, sollte die Regel testweise nur für diesen Vorgang deaktivieren und den Tab anschließend wieder schließen.

Den gesamten Host assets.aliexpress-media.com auf DNS-Ebene zu sperren, wäre deutlich gröber. Dort können weitere Shop-Ressourcen liegen. Eine schmale URL-Regel ist deshalb kontrollierbarer als eine pauschale Domain-Sperre.

JavaScript komplett abzuschalten ist selten praktikabel

Ohne JavaScript kann diese Messung nicht laufen. Moderne Shops funktionieren dann allerdings kaum noch. Eine globale Abschaltung erzeugt außerdem einen ungewöhnlichen Browserzustand und ersetzt keine saubere Trennung von Konten, Profilen und sensiblen Tätigkeiten.

Für besonders sensible Recherchen kann ein separater, möglichst wenig angepasster Browser sinnvoll sein. Das begrenzt die Verknüpfung mit dem alltäglichen Profil, garantiert aber keine Anonymität. IP-Adresse, Login, Zahlungsdaten und serverseitige Signale bleiben davon unberührt.

Der rechtliche Punkt ist mehr als eine Cookie-Frage

In Europa ist „cookielos“ kein Synonym für „einwilligungsfrei“. Die endgültigen Leitlinien 2/2023 des Europäischen Datenschutzausschusses behandeln den technischen Anwendungsbereich von Artikel 5 Absatz 3 der ePrivacy-Richtlinie bewusst breiter als klassische Cookies. Entscheidend kann auch der Zugriff auf Informationen sein, die im Endgerät gespeichert oder dort durch Software und Hardware erzeugt werden.

Ob die konkrete AliExpress-Implementierung im Einzelfall zulässig ist, hängt unter anderem vom tatsächlichen Zweck, der Notwendigkeit, der regionalen Umsetzung der ePrivacy-Regeln, der Transparenz und der weiteren Verarbeitung ab. Anti-Fraud kann ein legitimer Zweck sein. Das beantwortet aber nicht automatisch, ob jede auf der allgemeinen Startseite erhobene Eigenschaft für diesen Zweck erforderlich ist oder ob eine Einwilligung notwendig wäre.

Dieser Beitrag ersetzt keine rechtliche Prüfung. Technisch zeigt der Fall jedoch, weshalb Cookie-Banner allein die Realität moderner Identifikation nicht vollständig abbilden. Ein Nutzer kann alle sichtbaren Marketing-Cookies ablehnen und trotzdem durch first-party JavaScript vermessen werden.

Testbasis und Grenzen

Ich habe die technische Analyse, die Browserangaben und die öffentlich zugänglichen Richtlinien zuletzt am 31. August 2026 geprüft. Grundlage für den konkreten AliExpress-Fund ist Callaghans dokumentierter Test unter Windows mit Firefox und Chrome sowie seine Instrumentierung der Web-Audio-API. Hinzu kommen Mozillas unabhängig geführter Fehlerbericht, Ritters Auswertung des extrahierten Audioverfahrens, die OpenWPM-Forschung und die Primärdokumentation von W3C, Mozilla, Brave, WebKit, Alibaba Cloud, AliExpress und EDPB.

Die beiden von Callaghan genannten, versionierten Skript-URLs antworteten bei meiner Kontrolle weiterhin mit HTTP 200 und dem Inhaltstyp application/javascript. Ich habe die Skripte jedoch nicht selbst auf einem kontrollierten AliExpress-Konto ausgeführt und den Bluetooth-Nebeneffekt nicht mit eigenen Kopfhörern reproduziert. Andere Betriebssysteme, Browser, Regionen, A/B-Tests oder inzwischen geänderte Skriptversionen können sich anders verhalten. Serverseitige Speicherung, Scoring, Identitätsverknüpfung und Nutzung der übertragenen Messwerte waren nicht sichtbar und sind deshalb keine eigenen Feststellungen dieses Beitrags.

Mein Fazit

Der Fall ist kein Beweis für eine geheime Ultraschallüberwachung und auch kein Nachweis, dass ein einzelner Audiowert jeden Computer eindeutig identifiziert. Er ist ein sehr guter Beleg dafür, wie breit moderne Websites den Browser als Messinstrument verwenden können, ohne dass Nutzer davon etwas sehen.

Die Anti-Fraud-Erklärung ist technisch glaubwürdig. Gerade ein großer Marktplatz muss Bots, Kontoübernahmen, Zahlungsbetrug und Coupon-Missbrauch bekämpfen. Das rechtfertigt aber nicht automatisch jede Messung an jedem Punkt der Customer Journey. Wer schon auf der allgemeinen Startseite Audio-, Grafik-, Hardware-, WebRTC- und Verhaltensmerkmale erhebt, muss sich Fragen nach Erforderlichkeit, Transparenz und Nebenwirkungen gefallen lassen.

Am Ende war es nicht ein Datenschutz-Dashboard, das die Messung sichtbar machte. Es war ein Paar Bluetooth-Kopfhörer, das sich weigerte, so zu tun, als wäre der Browser still.

Bis zum nächsten Mal,
Euer Joe