Firebase steckt in 1.048 der 2.247 Android-Apps, die wir auf Bytecode-Ebene auseinandergenommen haben. 47 Prozent, und nichts anderes in unserem Korpus kommt da heran. Diese eine Tatsache bedeutet, dass Google gar nicht deinen Homescreen sehen muss, um zu wissen, was du letzten Dienstag gemacht hast. Google weiß es bereits, denn der Code, der meldet “Nutzer hat um 21:47 Uhr den Checkout-Bildschirm geöffnet”, ist direkt in die Wetter-App, die Einkaufs-App und das Spiel deines Kindes einkompiliert. Gleiche Firma, gleiche Leitung, drei verschiedene Icons.

Das ist der Punkt, den die meisten übersehen, wenn sie fragen, was ein Tracker eigentlich ist. Ein Tracker ist keine schurkenhafte App, die dich heimlich im Hintergrund ausspioniert. Es ist auch keine Malware im klassischen Sinne. Es ist eine Software-Library, ein SDK (Software Development Kit), das ein Entwickler in sein Projekt eingefügt hat, weil es etwas Nützliches tut: Abstürze messen, Installationen zählen, eine Werbung anzeigen oder herausfinden, welche Marketingkampagne einen Nutzer gebracht hat. Das Tracking ist ein Nebeneffekt eines Dienstes, den der Entwickler eigentlich wollte.

Es läuft in der App, nicht neben ihr

Diese Unterscheidung ist wichtiger, als es klingt. Ein Tracker bekommt kein eigenes Permission-Fenster. Er taucht nicht als separater Prozess in deinen Akku-Einstellungen auf. Er läuft im selben Speicherbereich wie die App, die du geöffnet hast, erbt sämtliche Permissions, die diese App bereits besitzt, und schickt eigene Netzwerkanfragen über den Netzwerk-Stack der App. Aus Sicht des Betriebssystems gibt es keinen Unterschied zwischen “die App hat das Wetter abgefragt” und “das eingebettete Analytics-SDK der App hat sich bei einem Server in Virginia gemeldet.” Beides sieht so aus, als würde die App einfach ihre normale Arbeit machen.

Deshalb bringen dich Permission-Audits nur halb ans Ziel. Du kannst einer Taschenlampen-App den Standortzugriff verweigern und trotzdem drei SDKs in ihr haben, die dein Gerätemodell, deinen Mobilfunkanbieter, die Bildschirmauflösung, den Akkustand und die Liste der installierten Apps melden, und für keine dieser Angaben ist ein Permission-Dialog nötig.

Die fünf Arten, und was jede davon eigentlich will

Nicht alle Tracker wollen dasselbe. Wer sie alle in einen Topf wirft, gerät entweder in Panik wegen nichts oder übersieht genau die, die wirklich wichtig sind.

Analytics-SDKs (Firebase, Amplitude, Mixpanel) wollen Verhaltensdaten: angesehene Bildschirme, angetippte Buttons, verbrachte Zeit. Meist dienen sie der Produktverbesserung, aber der rohe Event-Stream verlässt in der Regel in dem Moment, in dem er erfasst wird, die Kontrolle des Entwicklers.

Attribution-SDKs (AppsFlyer, Adjust, Kochava, Branch) existieren nur, um die Frage zu beantworten, “welche Werbeanzeige hat diese Person zur Installation der App gebracht.” Dafür brauchen sie die Advertising ID deines Geräts, noch bevor du irgendetwas anderes in der App getan hast, manchmal noch bevor du sie überhaupt zum ersten Mal geöffnet hast. Diese Kategorie ist für die meisten Nutzer unsichtbar, weil sie nichts damit zu tun hat, dass Werbung auf deinem Bildschirm auftaucht. Es ist reine Hintergrund-Infrastruktur.

Ad-Exchange-SDKs (Meta Audience Network, AppLovin, Unity Ads, ironSource) sind diejenigen, die tatsächlich die Auktion durchführen, die entscheidet, welche Werbung du siehst. Sie sammeln die granularsten Signale, weil die Auktion mit besseren Targeting-Daten mehr Geld einbringt.

Session-Replay-SDKs (FullStory, UXCam, Glassbox) zeichnen buchstäbliche Interaktionsspuren auf, manchmal einschließlich Formulareingaben, sodass ein Produktteam sich eine Video-Rekonstruktion dessen ansehen kann, was du auf dem Bildschirm getan hast. Diese haben schon echte Skandale ausgelöst, wenn sie Dinge erfasst haben, die sie nicht erfassen sollten, wie zum Beispiel Teile von Kreditkartennummern.

Crash- und Performance-Monitore (Crashlytics, Sentry, Bugsnag) sind die am wenigsten alarmierenden der fünf Arten, wobei “am wenigsten alarmierend” immer noch bedeutet, dass Geräte-Identifikatoren, Stack Traces und manchmal Nutzer-IDs hochgeladen werden, sobald etwas kaputtgeht.

Die Hälfte der Apps in unserem Korpus trägt mindestens einen, ein Viertel trägt vier oder mehr, und das geschäftigste Prozent trägt siebzehn oder mehr, übereinandergestapelt, jede meldet an eine andere Firma, jede mit ihrer eigenen Aufbewahrungsrichtlinie, die der App-Entwickler meist auch nicht genau gelesen hat.

Der Schlüssel, der alles verbindet

Der Grund, warum ein Tracker ein Profil von dir über Apps hinweg erstellen kann, die du nie miteinander in Verbindung gebracht hast, ist ein einziger Identifikator: die Google Advertising ID (GAID), die still in deinen Geräteeinstellungen liegt. Jedes SDK aus jeder dieser fünf Kategorien kann dieselbe ID abfragen, wenn der Entwickler es so eingerichtet hat. So können das Attribution-SDK in deiner Essenslieferungs-App und das Ad-SDK in einem Mobile Game beide mit derselben GAID an Kochava melden, und das Backend von Kochava muss dich nirgendwo einloggen lassen, um zu wissen, dass es dasselbe Handy ist, das beides tut. Das ist keine Spekulation, das ist das gesamte Geschäftsmodell der Mobile Measurement Partner (MMP)-Branche, und es ist legal, irgendwo in einer Datenschutzerklärung offengelegt, die du nie geöffnet hast.

Das Zurücksetzen deiner GAID in den Android-Einstellungen unterbricht diese Verknüpfung vorübergehend, aber jedes SDK, das schon einmal ausgelöst hat, hat die Verbindung bereits hergestellt, und die meisten stellen sie innerhalb von Tagen wieder zu einem frischen Profil zusammen, weil Behavioral Fingerprinting (Bildschirmgröße, Zeitzone, Akkukurve, Reihenfolge der Installationen) die Punkte wieder verbindet, ganz ohne die alte ID zu benötigen.

Was sich dadurch wirklich an deiner Denkweise ändern sollte

Der eigentlich nützliche Perspektivwechsel ist nicht “lösche verdächtige Apps.” Es geht darum zu erkennen, dass die Tracker-Frage nie eine Frage einzelner schwarzer Schafe war. Es geht um eine kleine Zahl von SDK-Anbietern, vielleicht zwei Dutzend, die wirklich relevant sind, die in der Mehrheit der Apps auf deinem Handy sitzen, und jeder von ihnen kann einen Ausschnitt deines Tages sehen, den keine einzelne App jemals zugeben würde, für sich selbst zu erfassen. Scan-Tools wie die, die wir bei AppXpose entwickeln, können dir sagen, welche SDKs in einer bestimmten APK enthalten sind, aber sie können dir nicht sagen, was diese SDKs mit den Daten machen, sobald sie dein Gerät verlassen haben, denn dieser Teil passiert in Serverräumen, die du niemals prüfen kannst. Die ehrliche Erkenntnis ist: “Permissions prüfen” war nie genug, und ist es immer noch nicht.