MWMichael WinklerBlogbymw.de ↗
Ratgeber

Dein größtes Datenleck hast du selbst eingebaut – wie Werbe-SDKs heimlich Standorte verschicken

Diese Woche hat die EFF vier verbreitete Werbe-Bausteine für Android untersucht – und alle vier geben den Standort deiner Nutzer schon per Voreinstellung weiter. Ich zeige dir, warum die Verantwortung dafür bei dir als Entwickler landet, und wie du deine App in einer halben Stunde prüfst.

Wenn ich über App-Sicherheit rede, denken die meisten an Hacker, die von außen reinkommen. Der Fall, über den ich heute schreibe, ist genau umgekehrt: Das Leck kommt von innen – aus einem Baustein, den du selbst in deine App gezogen hast, freiwillig, mit einer einzigen Zeile in der Build-Datei.

Am 4. August hat die Electronic Frontier Foundation (EFF) eine Untersuchung veröffentlicht, die mich hat aufhorchen lassen. Sie haben sich vier verbreitete Werbe-SDKs für Android angesehen – kleine Bibliotheken, mit denen Apps Anzeigen einblenden und Geld verdienen. Das Ergebnis: Alle vier geben den Standort der Nutzer standardmäßig weiter, sobald die App überhaupt eine Standortberechtigung hat. Nicht nach Rückfrage. Nicht als Ausnahme. Als Grundeinstellung.

Was da genau passiert

Die vier untersuchten Bausteine heißen InMobi, BidMachine, Verves HyBid und Huaweis Petal Ads. Bei InMobi steht es sogar so in der Doku: Die Bibliothek leitet vorhandene Standortsignale automatisch weiter – und der Anbieter empfiehlt, das eingeschaltet zu lassen, weil Anzeigen mit Ortsangabe schlicht mehr Geld bringen.

Der Standort wandert dann in etwas, das Real-Time Bidding heißt: eine Echtzeit-Auktion, bei der in Sekundenbruchteilen um die Anzeige in deiner App geboten wird. An dieser Auktion hängen viele Firmen – und über sie können die Daten bei Datenhändlern landen. Aus „meine App zeigt Werbung" wird so, ohne dass es dir jemand gesagt hätte, „meine App verschickt, wo meine Nutzer gerade stehen".

Der Kernsatz der EFF trifft es genau: Datenschutz sollte nicht davon abhängen, ob ein Entwickler zufällig die richtige Seite in einer SDK-Doku gelesen hat.

Warum das DEIN Problem ist – nicht das der SDK-Firma

Jetzt kommt der Teil, den ich in Kundengesprächen am häufigsten erklären muss. Rechtlich und im Play Store bist du der Verantwortliche für das, was deine App tut – auch für die fremden Bausteine darin.

  • Google hat die Regeln im Juli sogar verschärft. In der Play-Console-Ankündigung vom 15. Juli 2026 steht ausdrücklich, dass die Vorgaben zu Nutzerdaten auch für eingebundene Drittanbieter-Dienste gelten und der Entwickler für Zweckbindung, Offenlegung und Einwilligung verantwortlich bleibt.
  • Die DSGVO sieht es genauso. Der Standort ist ein personenbezogenes Datum. Gibst du ihn ohne Rechtsgrundlage und ohne saubere Einwilligung weiter, haftest du – nicht der SDK-Anbieter in Singapur oder San Francisco.

Anders gesagt: Die Werbe-Bibliothek verdient das Geld, aber das Bußgeldrisiko und der Vertrauensverlust bei deinen Nutzern bleiben bei dir.

So prüfst du deine App in einer halben Stunde

Das ist kein Grund zur Panik, sondern eine überschaubare Aufgabe. So gehe ich vor, wenn ich eine bestehende App übernehme:

  • Liste alle SDKs auf. Öffne deine build.gradle bzw. libs.versions.toml und schreib jede fremde Abhängigkeit auf. Was du nicht kennst, googelst du – gerade Werbe-, Analyse- und „Attribution"-Bausteine.
  • Such gezielt nach Standort. Prüfe, ob deine App überhaupt ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION verlangt. Braucht sie den Standort für ihre eigentliche Funktion nicht, raus damit – dann kann auch kein SDK ihn abgreifen.
  • Lies die Voreinstellungen der Werbe-SDKs. Bei den genannten vier suchst du nach einem Schalter wie „location sharing" oder „passUserData" und stellst ihn bewusst auf aus, wenn du ihn nicht willst.
  • Hol echte Einwilligung ein – ein ehrlicher Consent-Dialog, kein vorangekreuztes Kästchen. Und schreib in deine Datenschutzerklärung, was wirklich passiert.
  • Miss den Datenverkehr. Ein Blick mit einem Netzwerk-Mitschnitt (z. B. dem Charles-Proxy oder dem Android-Studio-Network-Inspector) zeigt dir schwarz auf weiß, welche Server deine App wirklich kontaktiert.

Mein Weg: erst gar keine fremden Datensammler

Ich baue Android-Apps in Kotlin und Jetpack Compose – und wenn eine App keine Werbung braucht, kommt auch kein Werbe-SDK hinein. Das ist die einfachste Sicherheit überhaupt: Was nicht drin ist, kann nichts weitergeben.

Ein Beispiel aus meiner eigenen Werkstatt ist meine Wetter-Seite wetter.bymw.de. Die Wetterdaten holt dort der Server, nicht dein Handy – so gehen deine Koordinaten an eine Stelle statt an sechs Anbieter, und selbst die werden vorher aufs Raster gerundet gespeichert. Kein Tracker, keine Werbe-Auktion, kein „aus Versehen" verschickter Standort. Genau diese Haltung – so wenig Daten wie möglich, und die transparent – bringe ich in jedes Projekt mit.

Wenn du eine App oder Website hast und dir nicht sicher bist, was deine eingebauten Bausteine im Hintergrund tun, schau sie dir mit der Liste oben einmal an. Und wenn du lieber jemanden möchtest, der das für dich prüft oder gleich sauber neu baut, findest du mich auf bymw.de. Kostenlose kleine Helfer für den Alltag – vom Passwort-Generator bis zum QR-Code – liegen unter tools.bymw.de.

Kurzer Hinweis: Dieser Beitrag erklärt die Technik und ordnet sie ein, er ersetzt keine Rechtsberatung. Bei konkreten DSGVO-Fragen sprich mit einem Fachanwalt oder deinem Datenschutzbeauftragten.

Quellen

Hat dir der Artikel gefallen?
#Datenschutz#Android#SDK#DSGVO#App-Entwicklung

Du hast ein Projekt im Kopf?

Ich entwickle Android-Apps und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.

Projekt anfragen →