AdsPower Sicherheitsrisiken: Das 4,7-Mio.-$-Datenleck und warum offizielle Plattformen wichtig sind

Im Januar 2025 erlitt AdsPower — einer der am weitesten verbreiteten Anti-Detect-Browser — eine Sicherheitsverletzung, die zu rund 4,7 Mio. $ an gestohlener Kryptowaehrung fuehrte. Der Angriff war kein Brute-Force-Hack und keine Phishing-Kampagne. Es war eine Supply-Chain-Kompromittierung: schaedlicher Code wurde ueber den browsereigenen Erweiterungs-Update-Mechanismus eingeschleust und extrahierte still Credentials aus Nutzerprofilen, ganz ohne erforderliche Nutzerinteraktion.

Dieser Vorfall ist nicht deshalb bedeutsam, weil Sicherheitsverletzungen in Software ungewoehnlich waeren — das sind sie nicht — sondern weil er grundlegende Schwachstellen im Anti-Detect-Browser-Modell selbst offenlegte. Die Angriffsvektoren, die dieses Leck moeglich machten, sind keine Bugs, die man patchen kann. Sie sind strukturelle Merkmale der Funktionsweise von Anti-Detect-Browsern.

Dieser Artikel liefert eine detaillierte technische Analyse dessen, was geschah, warum Anti-Detect-Browser fuer diese Art von Angriff besonders verwundbar sind, welche breiteren Sicherheitsimplikationen sich fuer Meta-Werbetreibende ergeben und wie offizielle API-Plattformen wie Wevion diese Risikokategorien vollstaendig eliminieren.

Fuer einen breiteren Vergleich von Anti-Detect-Browsern gegenueber API-basierten Tools lesen Sie unsere umfassende Analyse.

---

Was geschah: Das Leck im Januar 2025

Chronologie der Ereignisse

Der Angriff entfaltete sich im Januar 2025, als AdsPower-Nutzer begannen, nicht autorisierte Transaktionen aus Kryptowallets zu melden, die ueber ihre Browserprofile zugaenglich waren. Das Muster war konsistent: Nutzer, die Krypto-Wallet-Erweiterungen (MetaMask, Phantom, Coinbase Wallet und andere) in ihren AdsPower-Profilen installiert hatten, stellten fest, dass Gelder ohne ihre Autorisierung transferiert worden waren.

Der Angriffsmechanismus

Die Untersuchung ergab, dass es sich um eine Supply-Chain-Kompromittierung handelte, die auf die Erweiterungs-Update-Pipeline von AdsPower abzielte:

1. Erste Kompromittierung: Angreifer verschafften sich Zugang zu den internen Systemen von AdsPower, die fuer die Verteilung von Erweiterungs-Updates verantwortlich sind. Die genaue Methode des Erstzugriffs wurde nicht oeffentlich bekannt gegeben.

2. Einschleusen der schaedlichen Nutzlast: Die Angreifer betteten schaedlichen JavaScript-Code in ein legitim aussehendes Erweiterungs-Update ein. Der Code war auf Unauffaelligkeit ausgelegt — er veraenderte weder das sichtbare Verhalten des Browsers noch das der Erweiterung.

3. Automatische Verteilung: Weil AdsPower, wie alle modernen Browser, Erweiterungs-Updates automatisch anwendet, wurde der schaedliche Code an alle aktiven Installationen ausgespielt, ohne jegliche Nutzerinteraktion zu erfordern.

4. Credential-Extraktion: Der schaedliche Code zielte gezielt auf browserbasierte Kryptowallet-Erweiterungen ab. Er ueberwachte Wallet-Interaktionen und extrahierte:

   • Private Keys
   • Seed-Phrasen (mnemonische Wiederherstellungsphrasen)
   • Wallet-Passwoerter
   • Daten zur Transaktionssignierung

5. Datenexfiltration: Die extrahierten Credentials wurden an angreifergesteuerte Server uebertragen, wo sie zum Leerraeumen der Kryptowallets verwendet wurden.

Die Auswirkungen

• Finanzielle Verluste: Rund 4,7 Mio. $ an gestohlener Kryptowaehrung ueber betroffene Nutzer hinweg
• Angriffsumfang: Jeder Nutzer mit Krypto-Wallet-Erweiterungen in seinen AdsPower-Profilen war potenziell kompromittiert
• Keine Nutzeraktion erforderlich: Der Angriff war aus Sicht der Nutzer voellig passiv — das kompromittierte Update installierte sich automatisch
• Versagen des Vertrauensmodells: Nutzer hatten dem Update-Mechanismus von AdsPower vertraut, der zum primaeren Angriffsvektor wurde
• Verlaengertes Expositionsfenster: Weil der schaedliche Code ueber ein vertrauenswuerdiges Update verteilt wurde, war die Zeit zwischen Kompromittierung und Entdeckung erheblich

AdsPowers Reaktion

AdsPower bestaetigte das Leck, machte das kompromittierte Erweiterungs-Update rueckgaengig und erklaerte, der Vorfall sei das Ergebnis eines kompromittierten internen Systems. Das Unternehmen fuehrte zusaetzliche Sicherheitsmassnahmen ein, darunter:

• Verbessertes Code-Signing fuer Erweiterungs-Updates
• Zusaetzliche Code-Review-Prozesse
• Striktere Zugriffskontrollen fuer die Update-Pipeline

Diese Massnahmen adressieren zwar den spezifischen Angriffsvektor dieses Vorfalls, beheben aber nicht die strukturellen Schwachstellen, die dem Anti-Detect-Browser-Modell inhaerent sind.

---

Warum Anti-Detect-Browser besonders verwundbar sind

Das AdsPower-Leck war kein isolierter Vorfall, der durch nachlaessige Sicherheitspraktiken verursacht wurde. Es nutzte Schwachstellen aus, die in die grundlegende Architektur von Anti-Detect-Browsern eingebaut sind. Diese strukturellen Risiken zu verstehen, ist fuer jeden essenziell, der die Sicherheit seiner Werbeinfrastruktur bewertet.

1. Anforderungen an tiefen Systemzugriff

Anti-Detect-Browser benoetigen umfangreiche Berechtigungen, um zu funktionieren:

• Kontrolle ueber den Browserprozess: Veraenderung von Rendering-Engines, Abfangen von API-Aufrufen, Aenderung des Browserverhaltens auf niedriger Ebene
• Erweiterungsverwaltung: Installieren, Aktualisieren und Steuern von Erweiterungen, die mit dem Inhalt von Webseiten interagieren
• Zugriff auf die Netzwerkschicht: Routing von Traffic ueber Proxys, Verwaltung von Verbindungen pro Profil
• Dateisystemzugriff: Lesen und Schreiben von Profildaten, Fingerprint-Konfigurationen und zwischengespeicherten Credentials
• Zugriff auf Hardware-APIs: Veraenderung der Antworten von Hardware-Abfrage-APIs (WebGL, Canvas, Audio usw.)

Dieser breite Zugriff ist kein Bug und kein Versehen — er ist fuer die Kernfunktionalitaet des Fingerprint-Spoofings erforderlich. Aber er bedeutet auch, dass jede Kompromittierung des Anti-Detect-Browsers dem Angreifer Zugriff auf all diese Faehigkeiten gewaehrt.

Das zugrunde liegende Sicherheitsprinzip: Je mehr Berechtigungen ein System benoetigt, desto groesser seine Angriffsflaeche. Anti-Detect-Browser benoetigen nahezu vollstaendigen Zugriff auf Browser-Ebene und schaffen damit eine maximale Angriffsflaeche.

2. Risiken des Erweiterungs-Oekosystems

Anti-Detect-Browser unterstuetzen Browser-Erweiterungen — und viele Nutzer verlassen sich fuer ihre Workflows auf Erweiterungen (Werbeverwaltungstools, Kryptowallets, Passwortmanager, Produktivitaetstools). Dies schafft mehrere Risikovektoren:

• Erweiterung-zu-Erweiterung-Zugriff: Erweiterungen im selben Browserprofil koennen miteinander interagieren. Eine kompromittierte Erweiterung kann Daten aus anderen Erweiterungen auslesen.
• Zugriff auf Seiteninhalte: Erweiterungen mit entsprechenden Berechtigungen koennen Webseiteninhalte lesen und veraendern, darunter Formulardaten, Session-Tokens und Authentifizierungs-Cookies.
• Ausfuehrung von Hintergrundprozessen: Erweiterungen koennen Hintergrundprozesse ausfuehren, die bestehen bleiben, solange der Browser geoeffnet ist, und so eine dauerhafte Datensammlung ermoeglichen.
• Vertrauen in den Update-Mechanismus: Erweiterungs-Updates werden automatisch angewendet. Ist der Update-Mechanismus kompromittiert — wie bei AdsPower geschehen — erhalten alle Installationen den schaedlichen Code.

Die entscheidende Erkenntnis: Das AdsPower-Leck war keine Browser-Schwachstelle und keine Erweiterungs-Schwachstelle im herkoemmlichen Sinne. Es war eine Kompromittierung der Vertrauenskette zwischen dem Anbieter und den Erweiterungen des Nutzers. Jeder Anti-Detect-Browser mit Auto-Update-Mechanismus traegt dasselbe strukturelle Risiko.

3. Modell der Credential-Speicherung

Anti-Detect-Browser speichern Login-Credentials innerhalb von Browserprofilen, weil sie so dauerhafte Sessions aufrechterhalten:

• Gespeicherte Passwoerter: Nutzer speichern Plattform-Credentials der Bequemlichkeit halber, um wiederholte Logins zu vermeiden
• Session-Cookies: Aktive Session-Tokens werden in Profildaten gespeichert und halten den Login-Status ueber Neustarts hinweg aufrecht
• Authentifizierungs-Tokens: OAuth-Tokens, API-Keys und andere Authentifizierungs-Credentials, die von Erweiterungen oder Websites gespeichert werden
• Zahlungsinformationen: Kreditkartendaten, Rechnungsadressen und Zahlungs-Tokens, die vom Autofill-System des Browsers gespeichert werden

Diese zentralisierte Credential-Speicherung ist ein hochwertiges Ziel. Ein einziges Leck legt jede in jedem Profil gespeicherte Credential offen — ueber jede Plattform hinweg.

Der Kontrast zu OAuth-basierten Tools: In einem OAuth-Modell erhaelt oder speichert das Drittanbieter-Tool niemals das Passwort des Nutzers. Selbst wenn das Tool kompromittiert wird, erhaelt der Angreifer Tokens mit begrenztem Umfang, die widerrufen werden koennen, nicht die tatsaechlichen Credentials.

4. Risiken der Proxy-Schicht

Anti-Detect-Browser leiten Traffic ueber Proxy-Anbieter und fuegen damit der Vertrauenskette eine weitere Instanz hinzu:

• Abfangen von Traffic: Waehrend der meiste Proxy-Traffic verschluesselt ist, uebernimmt der Proxy-Anbieter die DNS-Aufloesung und kann potenziell unverschluesselten Traffic abfangen
• Kompromittierung von Proxy-Credentials: Werden Proxy-Credentials zusammen mit Browserprofilen gespeichert, kompromittiert ein Browser-Leck auch den Proxy-Zugang
• Geteilte Infrastruktur: Viele Nutzer teilen sich dieselben Proxy-Anbieter und schaffen damit ein zentralisiertes Ziel fuer Angreifer

5. Automatische Update-Mechanismen

Genau der Mechanismus, der Anti-Detect-Browser beim Fingerprint-Spoofing effektiv haelt — automatische Updates, die auf Aenderungen bei der Plattform-Erkennung reagieren — ist zugleich der Mechanismus, ueber den schaedlicher Code verteilt werden kann. Das ist kein loesbares Problem, ohne die Funktionsweise von Updates grundlegend zu aendern:

• Vertrauensmodell: Nutzer muessen darauf vertrauen, dass jedes Update des Anbieters legitim ist
• Keine Nutzerpruefung: Updates werden automatisch ohne Pruefung durch den Nutzer angewendet
• Globale Verteilung: Ein einziges kompromittiertes Update erreicht alle Installationen gleichzeitig
• Tarnungsfaehigkeit: Schaedlicher Code kann so gestaltet werden, dass er wie legitime Fingerprint-Updates aussieht

---

Breitere Sicherheitsimplikationen fuer Meta-Werbetreibende

Das AdsPower-Leck zielte auf Kryptowallets ab, aber derselbe Angriffsmechanismus haette auf jegliche ueber Browserprofile zugaenglichen Daten abzielen koennen — einschliesslich Meta-Werbedaten.

Was in Anti-Detect-Browserprofilen gefaehrdet ist

Fuer Meta-Werbetreibende, die Anti-Detect-Browser nutzen, sind typischerweise folgende Daten in Browserprofilen gespeichert:

Der Kaskadeneffekt

Ein einziges Leck eines Anti-Detect-Browsers kann durch mehrere Systeme kaskadieren:

1. Facebook-Session-Tokens kompromittiert → Angreifer hat vollen Zugriff auf Werbekonten
2. Business-Manager-Zugang kompromittiert → Angreifer kann auf alle verknuepften Werbekonten, Seiten und Zahlungsmethoden zugreifen
3. Zahlungsmethoden kompromittiert → Angreifer kann nicht autorisierte Werbung schalten und das Geld des Opfers ausgeben
4. Kundenkonten kompromittiert (Agenturen) → Das Leck betrifft nicht nur die Agentur, sondern jeden Kunden, dessen Konten ueber die kompromittierten Profile verwaltet werden
5. Persoenliche Konten kompromittiert → Sind persoenliche Facebook-Konten in denselben Profilen eingeloggt, werden auch persoenliche Daten offengelegt

Das ist kein theoretisches Szenario. Es ist die logische Fortfuehrung des Angriffsmechanismus, der im AdsPower-Leck demonstriert wurde — haette der schaedliche Code statt auf Kryptowallets auf Facebook-Session-Tokens abgezielt, haetten die Auswirkungen auf Meta-Werbetreibende noch verheerender ausfallen koennen.

---

Wie sich offizielle API-Plattformen unterscheiden

Der grundlegende Sicherheitsunterschied zwischen Anti-Detect-Browsern und offiziellen API-Plattformen ist architektonischer, nicht inkrementeller Natur.

Das OAuth-Sicherheitsmodell

Offizielle Plattformen wie Wevion verbinden sich ueber OAuth mit Meta, das so funktioniert:

1. Nutzer authentifiziert sich direkt bei Meta: Sie loggen sich auf facebook.com ein — das Drittanbieter-Tool sieht Ihr Passwort nie
2. Meta stellt ein begrenztes Token aus: Das Token hat spezifische, begrenzte Berechtigungen (Werbung verwalten, Berichte lesen usw.)
3. Token ist widerrufbar: Sie koennen das Token jederzeit in den Meta-Einstellungen widerrufen und so den Zugriff des Tools sofort kappen
4. Token enthaelt kein Passwort: Selbst wenn das Token gestohlen wird, kann der Angreifer weder Ihr Passwort aendern noch auf andere Plattformen zugreifen
5. Meta ueberwacht die Token-Nutzung: Ungewoehnliche Token-Aktivitaet loest die Sicherheitssysteme von Meta aus

Was nicht gespeichert wird

Mit einer OAuth-basierten Plattform:

• Keine gespeicherten Passwoerter: Die Plattform erhaelt niemals Ihr Meta-Passwort
• Keine Session-Cookies: Es gibt keine Browser-Sessions, die gekapert werden koennten
• Keine Browser-Erweiterungen: Es gibt kein Erweiterungs-Oekosystem, das kompromittiert werden koennte
• Keine lokale Credential-Speicherung: Credentials existieren nur als verschluesselte Tokens auf den Servern der Plattform
• Keine Proxy-Schicht: Der Traffic laeuft direkt zwischen den Servern der Plattform und Metas API

Sicherheitsvergleichstabelle

---

Wevions Sicherheitsarchitektur

Wevion ist mit einem Sicherheitsmodell konzipiert, das die im AdsPower-Leck ausgenutzten Angriffsvektoren eliminiert:

Keine Credential-Speicherung

Wevion speichert, uebertraegt oder hat niemals Zugriff auf Ihr Meta-Passwort. Die Authentifizierung erfolgt vollstaendig ueber den OAuth-Flow von Meta. Wevion erhaelt lediglich das OAuth-Token, das Meta mit den von Ihnen autorisierten spezifischen Berechtigungen ausstellt.

Keine Browser-Erweiterungen

Wevion ist eine Webanwendung — es gibt keine Browser-Erweiterungen, keine lokalen Installationen und keine Auto-Update-Mechanismen, die kompromittiert werden koennten. Die Oberflaeche laeuft in Ihrem Standardbrowser, und das Backend kommuniziert mit Metas API von Server zu Server.

Keine Proxy-Schicht

Die gesamte Kommunikation zwischen Wevion und Meta erfolgt ueber die offizielle Marketing API ueber HTTPS. Es gibt keine Proxy-Infrastruktur, kein Routing von Traffic ueber Dritte und keine zusaetzliche Netzwerkschicht, die kompromittiert werden koennte.

Verschluesselte Token-Speicherung

OAuth-Tokens werden auf den Servern von Wevion verschluesselt gespeichert (at rest). Selbst im Fall eines Server-Lecks werden Tokens nicht im Klartext gespeichert.

Rollenbasierte Zugriffskontrolle

Wevions 6-stufiges RBAC-System stellt sicher, dass Teammitglieder nur die fuer ihre Rolle notwendigen Berechtigungen haben. Die Credentials eines Media Buyers koennen nicht auf Abrechnungsdaten zugreifen. Ein Betrachter kann keine Kampagnen aendern. Das begrenzt den Schadensradius jeder einzelnen kompromittierten Credential.

Audit-Trail

Jede ueber Wevion durchgefuehrte Aktion wird mit Nutzerzuordnung, Zeitstempel und betroffenen Ressourcen protokolliert. Das schafft Nachvollziehbarkeit und ermoeglicht eine schnelle Reaktion auf Vorfaelle, wenn ungewoehnliche Aktivitaet erkannt wird.

Widerrufbarkeit von Tokens

Wenn Sie ein Sicherheitsproblem vermuten, koennen Sie das OAuth-Token von Wevion jederzeit in den Meta-Einstellungen widerrufen. Das entfernt Wevions Zugriff sofort, ohne Ihr Meta-Konto, Ihr Passwort oder andere verbundene Dienste zu beeintraechtigen.

---

Praktische Sicherheitsempfehlungen

Ob Sie weiterhin Anti-Detect-Browser nutzen oder zu einer API-basierten Plattform wechseln — diese Praktiken reduzieren Ihre Risikoexposition:

Fuer Nutzer von Anti-Detect-Browsern

1. Speichern Sie niemals hochwertige Credentials in Browserprofilen: Speichern Sie keine Passwoerter fuer Finanzkonten, Zahlungssysteme oder Kryptowallets in Anti-Detect-Browserprofilen
2. Aktivieren Sie 2FA auf allen Plattformen: Selbst wenn Session-Tokens gestohlen werden, fuegt 2FA eine Schicht hinzu, die umgangen werden muss
3. Nutzen Sie getrennte Profile fuer Werbung und Krypto: Vermischen Sie Werbekonto-Profile nicht mit Kryptowallet-Profilen
4. Ueberwachen Sie ungewoehnliche Aktivitaet: Pruefen Sie Werbekonten, Zahlungsmethoden und verbundene Apps regelmaessig
5. Begrenzen Sie Erweiterungs-Installationen: Installieren Sie nur essenzielle Erweiterungen in Anti-Detect-Profilen — jede Erweiterung vergroessert die Angriffsflaeche
6. Aktualisieren Sie mit Vorsicht: Erwaegen Sie, Auto-Updates zu verzoegern und Change-Logs zu pruefen, bevor Sie sie anwenden

Fuer Nutzer API-basierter Plattformen

1. Pruefen Sie OAuth-Berechtigungen regelmaessig: Stellen Sie sicher, dass verbundene Tools nur die Berechtigungen haben, die sie benoetigen
2. Widerrufen Sie Tokens fuer ungenutzte Tools: Wenn Sie ein Tool nicht mehr nutzen, widerrufen Sie sein OAuth-Token in den Meta-Einstellungen
3. Nutzen Sie RBAC angemessen: Weisen Sie Teammitgliedern die minimal notwendigen Berechtigungen zu
4. Ueberwachen Sie den Audit-Trail: Pruefen Sie Aktionsprotokolle regelmaessig auf ungewoehnliche Aktivitaet
5. Aktivieren Sie 2FA fuer Ihr Meta-Konto: Das schuetzt das Hauptkonto, das die OAuth-Tokens ausstellt

Fuer alle Media Buyer

1. Trennen Sie Werbeinfrastruktur von persoenlichen Konten: Nutzen Sie nicht dieselben Credentials oder Geraete fuer persoenliche und geschaeftliche Werbung
2. Nutzen Sie einzigartige, starke Passwoerter: Passwortmanager generieren und speichern starke Passwoerter, ohne sie in Browserprofilen abzulegen
3. Ueberwachen Sie Zahlungsmethoden: Richten Sie Benachrichtigungen fuer ungewoehnliche Abbuchungen auf Karten ein, die mit Werbekonten verknuepft sind
4. Dokumentieren Sie Ihre Sicherheitslage: Wissen Sie, welche Tools Zugriff auf Ihre Konten haben und welche Berechtigungen sie besitzen

---

Das strukturelle Argument

Das AdsPower-Leck ist kein Grund, ausgerechnet AdsPower zu meiden — es ist ein Grund, den Anti-Detect-Browser-Ansatz fuer die Verwaltung hochwertiger Werbekonten zu ueberdenken. Die im Januar 2025 ausgenutzten Angriffsvektoren sind strukturell:

1. Tiefer Systemzugriff → Erforderlich fuer Fingerprint-Spoofing → Nicht entfernbar
2. Erweiterungs-Oekosystem → Erforderlich fuer die Workflow-Funktionalitaet → Nicht vollstaendig absicherbar
3. Credential-Speicherung → Erforderlich fuer dauerhafte Sessions → Schafft zentralisiertes Ziel
4. Auto-Update-Mechanismus → Erforderlich, um der Erkennung voraus zu sein → Schafft Supply-Chain-Risiko

Das sind keine Bugs. Es sind architektonische Anforderungen von Anti-Detect-Browsern. Bessere Sicherheitspraktiken rund um diese Merkmale reduzieren das Risiko, koennen es aber nicht eliminieren.

Offizielle API-Plattformen arbeiten auf einer grundlegend anderen Architektur, in der keiner dieser Angriffsvektoren existiert. Der Kompromiss ist die Plattformspezifitaet — Wevion funktioniert nur fuer Meta, waehrend Anti-Detect-Browser fuer jede Plattform funktionieren — aber fuer Werbetreibende, deren Hauptanliegen Meta-Werbung ist, ist der Sicherheitsvorteil des API-Ansatzes erheblich und waechst weiter.

---

Fazit

Das AdsPower-Leck vom Januar 2025 war ein bedeutendes Sicherheitsereignis, aber seine Tragweite geht ueber die 4,7 Mio. $ an gestohlenen Geldern hinaus. Es zeigte konkret, dass das architektonische Modell von Anti-Detect-Browsern Angriffsvektoren schafft, die in API-basierten Alternativen nicht existieren.

Fuer Meta-Werbetreibende, die erhebliche Werbebudgets verwalten, lautet die Frage nicht, ob Anti-Detect-Browser sicherer gemacht werden koennen — das koennen sie, inkrementell — sondern ob der grundlegende Ansatz, Credentials in einem Drittanbieter-Browser zu speichern, das richtige Sicherheitsmodell fuer die Verwaltung von Werbebudgets ist, die tausende oder zehntausende Dollar pro Tag uebersteigen koennen.

Offizielle API-Plattformen wie Wevion arbeiten mit einem Sicherheitsmodell, in dem Ihre Credentials niemals gespeichert werden, in dem die Authentifizierung ueber Metas eigenes OAuth-System erfolgt und in dem die Angriffsflaeche auf verschluesselte Tokens mit spezifischen, widerrufbaren Berechtigungen beschraenkt ist. Das ist nicht fuer jeden Anwendungsfall per se besser — wenn Sie Multi-Plattform-Browser-Isolation benoetigen, bleiben Anti-Detect-Browser die einzige Option. Aber speziell fuer Meta-Werbung war das Sicherheitsargument fuer API-basierte Tools noch nie staerker.

Starten Sie eine 14-taegige kostenlose Testversion von Wevion, um das Sicherheitsmodell der Plattform mit Ihren eigenen Konten zu bewerten. Keine Kreditkarte erforderlich, keine Credential-Speicherung, kein Risiko fuer laufende Kampagnen.

---

Weiterfuehrende Lektuere

• AdsPower-Alternative fuer Meta Ads: Offizieller API-Zugang
• Wevion vs. Anti-Detect-Browser: Warum offizielle API das Fingerprint-Spoofing schlaegt
• Warum Sie aufhoeren sollten, Anti-Detect-Browser fuer Meta Ads zu nutzen