IzzyOnDroid

• Intro
• App-Listen
• Artikel
• Bücher
• Downloads
• App-Repo
• Impressum

Was hat es mit den Modulen in Android Apps auf sich?

Die Verwendung von Modulen in der (App-) Entwicklung ist ein großartiges Konzept: Das Rad muss nicht jedes Mal neu erfunden werden, Fehlerbehebung sowie die Ergänzung neuer Funktionalitäten können an zentraler Stelle erfolgen – und jeder Entwickler sich auf den Bereich konzentrieren, in dem er oder sie am besten ist. Das ist die Kernidee hinter vielen nützlichen Modulen, die zur Funktionalität von Apps beitragen. Daher gibt es auch recht viele davon, die spezielle Bereiche abdecken; etwa Datenbank-Interaktionen, GUI Elemente, Datei-Operationen, und so weiter. Davon profitieren letztendlich alle – Entwickler und Anwender gleichermaßen.

Dann gibt es da eine zweite Kategorie von Modulen, welche nicht direkt zur eigentlichen Funktionalität der App beitragen – aber dennoch einen überwiegend gerechtfertigten Zweck verfolgen: Analytics. Ihr Zweck ist es, Bugs und Fehlverhalten nachvollziehbar zu machen – damit Entwickler die Ursache einfacher identifizieren und beheben können. Außerdem sammeln sie meist auch Statistiken dazu, wie der Anwender die App benutzt – damit Entwickler hier gegebenenfalls Verbesserungen vornehmen können.

Letztendlich bleiben dann noch Werbe-Module zu nennen: Da Entwickler guter Apps in der Regel eine Menge Zeit in diese investieren, möchten sie das verständlicherweise nach Möglichkeit auch honoriert haben. Leider jedoch sind die wenigsten Anwender bereit, auch nur einen lumpigen Euro dafür auszugeben (das Geld ist ja gerade erst für das High-End-Gerät draufgegangen) – also müssen sich Entwickler etwas anderes einfallen lassen. Gemäß einer 2016 durchgeführten Studie enthalten über 41% aller Apps im Google Play Store mindestens ein Werbemodul, und ist es durchaus gebräuchlich, gleichzeitig mehrere Werbemodule verschiedener Anbieter in einer App zu verwenden. Doch diese zweite Kategorie – also Analytics und Werbemodule – hat ihren Preis.

Generelle Auswirkungen, unabhängig vom Modul

Zunächst einmal benötigt jedes Modul natürlich Platz, und vergrößert somit die App. Das bedeutet auch, dass es am Speicherplatz Eurer Geräte knabbert. Zweitens verursachen Analytics genau wie Werbemodule zusätzlichen Netzwerkverkehr: Statistiken und weitere Informationen müssen hoch, sowie Werbung heruntergeladen werden – was sich wiederum auf Euer Datenkontingent auswirkt.¹ Sobald sie einmal laufen, verwenden sie sowohl CPU als auch RAM – und Akku. Zu guter Letzt: findet sich in einem solchen Modul ein Bug oder Datenleck, betrifft das natürlich auch die App selbst.²

Für die Module, die zur eigentlichen Funktionalität der App beitragen (erste Kategorie), kann dies weitgehend ignoriert – und im Allgemeinen das Gegenteil angenommen werden: Existiert ein Bug in einem verbreiteten Modul, wird er dort vermutlich schneller behoben als in jeder einzelnen App, welche diese Funktionalität selbst implementiert hätte (und alle das Modul verwendenden Apps profitieren nach einem entsprechenden Update automatisch davon). Da die Funktionalität hier ohnehin benötigt wird, gibt es auch keine zusätzliche Verwendung von irgend etwas, seien es lokale Ressourcen oder Netzwerk-Traffic.

Mit der zweiten Gruppe verhält es sich etwas anders – nicht zuletzt, da einige dieser „Drittanbieter-Helfer“ ziemlich gierig zu sein scheinen. Hat der App-Entwickler hier eine „unweise“ Entscheidung getroffen, könnten diese weit mehr tun als von ihm/ihr beabsichtigt. Einige dieser Analytics- und Werbemodule sind bereits dafür bekannt, recht aggressiv in die Privatsphäre der Anwender einzudringen – und/oder auch in ihrem „lokalen Umgang“ recht lästiges Verhalten an den Tag zu legen (Popups, Werbung die sich als Benachrichtigung oder Systemwarnung ausgibt, etc.). Wann immer ich ein solches Modul identifiziert habe, ist dieses bei der entsprechenden App in meinen App-Listen mit einem entsprechenden Icon verziert – welches auf Details zum Verhalten verlinkt.

Detaillierte Informationen zu diesen „Schnüffel-Modulen“ sind nicht leicht zu finden – schon gar keine kompilierte Liste mit entsprechenden Hinweisen. Wer danach sucht findet nahezu ausschließlich Treffer aus der Perspektive von Entwicklern, die sich damit befassen, wie man mit geringst möglichem Aufwand das meiste Geld verdienen kann. Auf den Seiten der Modul-Ersteller, welche die jeweiligen Frameworks beschreiben, wird Privatsphäre so gut wie nie erwähnt. Ein klassisches Beispiel wäre die HeyZap FAQ: Über 100 Fragen und Antworten finden sich dort – doch nicht eine einzige befasst sich mit Datenschutz, Privatsphäre, oder auch nur irgend etwas in diesem Umfeld – es geht fast ausschließlich darum wie man Geld macht, wie man mehr Geld macht, wie man schneller Geld macht, wann man das Geld bekommt … Offensichtlich interessieren sich weder die Betreiber dieser Netze noch die Entwickler um den Anwender als Person, sondern ausschließlich als „Ziel“ bzw. „Mittel zum Zweck“. Wenn Daten die Währung der Zukunft sind, werden wir hier nach Strich und Faden ausgeraubt.

Als ich mich daher in diesem Jahr an den Frühjahrsputz meiner App-Listen gemacht habe³ versuchte ich daher, Informationen zu den meist genutzten dieser Module zu finden. Das Ergebnis möchte ich hier mit Euch teilen.

Die Studie

Wie geschrieben bin ich all meine App-Listen durchgegangen und habe jede einzelne App hinsichtlich der von ihr verwendeten Module untersucht. Als Quelle dafür diente hauptsächlich AppBrain. AppBrain nutzt seine App AppBrain Ad Detector, welche Android-Anwender auf ihren Geräten installieren können, um auf selbigen Geräten ebenfalls installierte .apk Dateien hinsichtlich verwendeter Module zu untersuchen. Die Ergebnisse werden auf der Website bei den entsprechenden Apps angezeigt.

In einem ersten Lauf erstellte ich so eine Liste verwendeter Module, wobei ich mich auf Analytics- und Werbemodule konzentrierte (daher fehlen auch beispielsweise Module wie das von Facebook und anderen sozialen Netzen). Zu jedem dieser Module ergänzte ich, sofern auffindbar, die für die Integration verlangten Permissions – sowie Hinweise auf bereits berichtetes „auffälliges Verhalten“. Letzteres gestaltete sich schwierig – speziell die Frage, welche Suchbegriffe (und -maschinen) ich dafür heranziehen sollte; die meisten diesbezüglichen Berichte fand ich eher als „Beifang“ einer anderen Suche, wenn ich eine der gefundenen Studien im Detail durchging. Insbesondere die Namen einiger Module und die Art, wie Suchmaschinen arbeiten, brachten spezielle Komplikationen mit sich: Eine „wörtliche Suche“ scheint unmöglich. Als ich beispielsweise nach Informationen zu „MobileAppTracking“ suchte, wurde der Name einfach in seine Bestandteile zerlegt – und die Suchergebnisse bezogen sich lediglich allgemein auf „mobile app tracking“, „tracking mobile apps“ etc. Ganz egal, ob ich den Begriff "quotete", oder sogar sein explizites Auftauchen in Suchergebnissen +"erzwingen" wollte. Daher sind mir mit Sicherheit einige Berichte und Studien entgangen, nicht nur im genannten Beispiel.

In einem weiteren Durchlauf (wiederum durch alle App-Listen mit derzeit über 14.000 Apps) prüfte ich, welche Apps die im ersten Lauf identifizierten agressiven Module verwenden, und markierte sie entsprechend. Anzumerken ist, dass lediglich etwa 13.000 Apps aus den Listen auch im Google Play Store und somit bei AppBrain gelistet sind, sowie dass nicht zu jeder App bei AppBrain auch Details verfügbar waren: Bei etwa jeder sechsten bis achten App fehlten sie, da offensichtlich kein Anwender oben genannter Ad Detector App auch diese installiert hatte.

Zu guter Letzt extrahierte ich Statistiken aus der Datenbank meiner Funde.

Untersuchte Module

Modul	Permissions4	URL	OK	Notes
AdColony	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE	Project Setup	?5	Ads
AdBuddiz	INTERNET	Integration	?	Ads
Adjust	INTERNET, ACCESS_WIFI_STATE	SDK Permissions	?	Analytics
Adlantis	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE	Adlantis SDK	?6	Ads
AdMarvel	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE {, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, WRITE_CALENDAR, RECORD_AUDIO}	Integration Guide		Ads
Admob	INTERNET, ACCESS_NETWORK_STATE {,ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION}	Integration / Location data		Ads
Adstir	INTERNET, ACCESS_NETWORK_STATE	Android Apps	?	Ads
AdWhirl	INTERNET, ACCESS_NETWORK_STATE	?	?7	Ads
AerServ	INTERNET, ACCESS_NETWORK_STATE, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION {, WRITE_EXTERNAL_STORAGE}	SDK Integration	~8	Ads
Airpush	ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION ACCESS_NETWORK_STATE ACCESS_WIFI_STATE INTERNET READ_PHONE_STATE WRITE_EXTERNAL_STORAGE	Integration		Ads
Amazon Mobile Ads	INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE {, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION}	Quick Start	?9	Ads
AppBrain SDK	INTERNET, ACCESS_NETWORK_STATE	AppBrain SDK	?10	Ads
AppLovin	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE	Mediation Guide	?11	Ads
AppNext	INTERNET {, GET_ACCOUNTS12}	Android SDK (PDF)	?13	Ads
Appodeal	INTERNET, ACCESS_NETWORK_STATE, ACCESS_COARSE_LOCATION, WRITE_EXTERNAL_STORAGE	Integration	?14	Ads
AppsFlyer	INTERNET, ACCESS_NETWORK_STATE {,ACCESS_WIFI_STATE, READ_PHONE_STATE}	Integration	?15	-
Avocarrot	INTERNET ACCESS_NETWORK_STATE ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION	Manifest	?16	Ads
Axonix	INTERNET {, ACCESS_NETWORK_STATE}	Manifest		Ads
CallDorado	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION READ_PHONE_STATE PROCESS_OUTGOING_CALLS WRITE_EXTERNAL_STORAGE RECEIVE_BOOT_COMPLETED READ_CONTACTS WRITE_CONTACTS SYSTEM_ALERT_WINDOW	FAQ		Ads
Cauly Ads	?	?	?	Ads
Chartboost	INTERNET ACCESS_NETWORK_STATE {WRITE_EXTERNAL_STORAGE ACCESS_WIFI_STATE READ_PHONE_STATE}	Integration	?17	Ads
Comscore Analytics	INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE	Github	?	Analytics
Conversant	INTERNET ACCESS_NETWORK_STATE {WRITE_CALENDAR WRITE_CONTACTS WRITE_EXTERNAL_STORAGE}	Android SDK	?18	Ads
Crashlytics	INTERNET	Install	~19	Analytics
Daum Ads	?	?	?	Ads
display.io	information only available after login	?	?20	Ads
Facebook	INTERNET	Getting Started	?21	-
Flatiron Media	?	?	?	Ads
Flurry	INTERNET ACCESS_NETWORK_STATE WRITE_EXTERNAL_STORAGE ACCESS_FINE_LOCATION	Integration		Analytics
Fyber	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE	Setting up	?22	Ads
Google Analytics	INTERNET, ACCESS_NETWORK_STATE	DevGuide		Analytics
HeyZap	INTERNET ACCESS_NETWORK_STATE	FAQ	?23	Ads
inMobi	INTERNET ACCESS_NETWORK_STATE {ACCESS_WIFI_STATE CHANGE_WIFI_STATE READ_LOGS VIBRATE RECORD_AUDIO WRITE_EXTERNAL_STORAGE ACTIVITY_RECOGNITION READ_CALENDAR WRITE_CALENDAR}	Integration		Ads
Inneractive	?	?	?	Ads
Intowow	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE, SET_ORIENTATION	Integration Guide	?24	VideoAds
Kochava	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE	SDK Integration	?25	Ads
LeadBolt	INTERNET ACCESS_NETWORK_STATE	Integration		Ads
LiveRail	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE	Manifest permissions	?26	Ads
Localytics	INTERNET, WAKE_LOCK {, GCM, ACCESS_FINE_LOCATION, BOOT}	Developers	?27	Analytics
mAdserve	INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, ACCESS_FINE_LOCATION	Manifest	?	Ads
Madvertise	INTERNET ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION	Sample	?	Ads
MdotM	INTERNET ACCESS_NETWORK_STATE {ACCESS_WIFI_STATE READ_PHONE_STATE WRITE_EXTERNAL_STORAGE}	AndroidSDK	?28	Ads
mediba ad	?	?	?	Ads
Mediba Admaker	?	?	?	Ads
Metaps	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE READ_PHONE_STATE	How to implement	?29	Ads
Millennial Media	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE ACCESS_FINE_LOCATION WRITE_EXTERNAL_STORAGE NFC BLUETOOTH WRITE_CALENDAR VIBRATE RECORD_AUDIO	Integration Guide		Ads
Mixpanel	INTERNET ACCESS_NETWORK_STATE BLUETOOTH	Reference	?30	Analytics
Mobclix	INTERNET ACCESS_NETWORK_STATE	PhoneDevelopers		Ads
MobFox	INTERNET, ACCESS_NETWORK_STATE	AndroidSDK	?31	Ads
MobileAppTracking	INTERNET, ACCESS_NETWORK_STATE	Quick Start	?	Ads
mobileCore	INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, READ_PHONE_STATE, WRITE_EXTERNAL_STORAGE, WAKE_LOCK	Integration	?32	Ads
MobPartner	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE READ_PHONE_STATE WRITE_EXTERNAL_STORAGE	AndroidSDK		Ads
MoPub	INTERNET, ACCESS_NETWORK_STATE, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, WRITE_EXTERNAL_STORAGE	Getting Started		Ads
Nend	INTERNET	NendSDK	?	Ads
Pollfish	INTERNET	Quick Guide	?33	Surveys
PubNative	INTERNET ACCESS_NETWORK_STATE {, ACCESS_COARSE_LOCATION}	Native Library	?34	Ads
RevMob	ACCESS_NETWORK_STATE ACCESS_WIFI_STATE INTERNET READ_PHONE_STATE	Gist		Ads
Smaato	INTERNET ACCESS_NETWORK_STATE READ_PHONE_STATE ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION READ_CALENDAR WRITE_CALENDAR WRITE_EXTERNAL_STORAGE	Android Permissions		Ads
Smart AdServer	INTERNET ACCESS_COARSE_LOCATION	SafeDK	?	Ads
Splunk MINT	INTERNET	Integration	√35	Analytics
Sponsorpay	INTERNET READ_PHONE_STATE	Manifest	?36	Ads
StartApp	INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE {, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, BLUETOOTH, RECEIVE_BOOT_COMPLETED}	Getting Started		Ads
Supersonic	INTERNET, ACCESS_NETWORK_STATE	Getting Started	?37	Ads
Tap for Tap	INTERNET ACCESS_NETWORK_STATE ACCESS_WIFI_STATE READ_PHONE_STATE ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION WRITE_EXTERNAL_STORAGE GET_TASKS GET_ACCOUNTS ACTIVITY_RECOGNITION CALL_PHONE WAKE_LOCK GCM	Android Sample		Ads
Tapjoy	INTERNET, ACCESS_NETWORK_STATE {, ACCESS_WIFI_STATE, READ_PHONE_STATE}	Getting Started	?38	Ad
Tenjin	?	Homepage	?	Analytics
Umeng	INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, READ_PHONE_STATE	Integration		Social/Analytics
Unity Ads	INTERNET, ACCESS_NETWORK_STATE	Integration	?39	Ads
Vungle	INTERNET, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE	Getting Started	?40	VideoAds
Yandex Metrica	INTERNET, ACCESS_NETWORK_STATE {, ACCESS_COARSE_LOCATION}	Initialize / Manifest	?41	Analytics

Findet sich in der „OK“ Spalte ein Icon, verlinkt dies auf Details zum entsprechenden Modul/Netzwerk – genau wie das entsprechende Icon in meinen App-Listen. Weitere Informationen füge ich ggf. später noch hinzu, ohne dabei jedoch die Studie selbst zu aktualisieren. Da meine Informationen bestenfalls lückenhaft sind, ist Feedback jederzeit willkommen: Findet jemand Artikel, die sich mit einem solchen Modul aus Sicht von Privatsphäre und Datensicherheit beschäftigen, lasst es mich bitte wissen!

Erkenntnisse

Einige Dinge, die mir während meiner Recherchen auffielen:

• Die meisten „free Apps“ haben mindestens ein Werbemodul integriert. Viele verwenden mehr als nur eines, manche bis zu 10, bei einer App fand ich gar 15 – während eine Studie sogar eine App mit 28 Werbemodulen identifizierte!
• Normalerweise kann man sich der Tracker entledigen, indem man zur Bezahlversion der jeweiligen App greift. Meine Recherche ergab jedoch, dass dies selbst bei Vorhandensein von Bezahlversionen nicht immer greift: Etwa jede vierte Bezahl-App enthält nach wie vor Tracker, etwa jede fünfte Werbemodule; in einem Fall erhielt die Bezahlversion sogar einen Tracker mehr als die zugehörige Gratis-App. Eine Studie aus dem Jahr 2015 bestätigt dies und schreibt, dass 85%-95% aller gratis Apps sowie etwa 60% aller Bezahl-Apps zumindest einen Tracker enthalten, sowie dass die meisten Bezahl-Versionen die selben Tracker wie ihre gratis Pendants verwenden. In vielen anderen Fällen ist die Bezahlversion nichts anderes als ein „Lizenz-Modul“, welches man zusätzlich zur Gratisversion installieren muss. Dadurch wird zwar (hoffentlich) die Anzeige von Werbung unterdrückt, das Werbemodul selbst verbleibt jedoch auf dem Gerät.
  Liebe Entwickler, wenn Ihr mir sagen wollt „es ist zwar noch da, aber nicht mehr aktiv“ fühle ich mich ungefähr so sicher, als würdet Ihr mir ein Auto mit eingebauter Bombe verkaufen und versichern, sie sei ja nicht scharf. Ich glaube Euch vielleicht, dass Ihr sie nicht absichtlich scharf gemacht habt – aber Ihr habt sie nicht gebaut, wie könnt Ihr daher sicher sein?
• Während die meisten Analytics- und Werbemodule angemessene Permissions verlangten, erscheinen andere recht aggressiv. Einige verursachten mir Gänsehaut und ließen meine Haare zu Berge stehen: Ich hätte nie gedacht, dass sie derart offensichtlich auf Datenfang gehen würden! Schaut selbst in obiger Modul-Liste nach und achtet besonders auf Millennial und CallDorado. Entwicklern, die derartige Module in ihre Apps integrieren, kann man m. E. nicht trauen – und ich würde auch ihre anderen Apps meiden. Wer weiß, welche „Ostereier“ dort lauern.
• In den API Beschreibungen sowie „Privacy Policies“ fand ich einige Hinweise zu gesammelten Daten. Natürlich unterscheiden diese sich je nach Anbieter. Dennoch bestätigen meine Funde grob, was MobileAppScrutinator auf Seite 6 berichtet: Etwa ein Viertel der Kandidaten greift auf die AndroidID zu, etwa ein Fünftel auf die IMEI. Etwas weniger als 10% interessieren sich für die WiFi MAC-Adresse, Serial Nummer, IMSI und Telefonnummer. Die beschriebene Grafik geht nicht auf andere Daten wie Standort, Kontaktlisten sowie Anruflisten ein (ein Teil davon deckt die Grafik auf Seite 11 ab: Mehr als 10% sammelt Informationen zum Netzbetreiber, ca. 5% Standort-Daten, weniger als 5% Konten und Kontaktlisten). Wo ich entsprechende Informationen finden konnte, sind diese bei den Modul-Beschreibungen vermerkt.
  Genannte Studie fand überdies heraus, dass die Daten oft unmodifiziert (d. h. weder gehasht noch verschlüsselt), und oftmals gar im „Klartext“ (also nicht per HTTPS/SSL) übermittelt werden. Dies macht es dann auch für „Lauscher“ (so genannte „Men in the Middle“) einfach, diese Informationen mitzuschneiden – etwa in öffentlichen WLAN-Netzwerken.
• Besonders alarmierend fand ich (Sammlungen von) ATS in Apps, welche sensible Informationen verarbeiten. Ob es das Wert ist, Werbung für Tampons zum richtigen Zeitpunkt zu erhalten (um ein Beispiel herauszugreifen) ist im besten Fall fragwürdig – aber wenn es zu Informationen bzgl. meiner Finanzen, Gesundheitsdaten etc. geht (und ja, dies schließt auch generell meine Kalenderdaten und Adressbücher ein) bestehe ich darauf, dass in einer solchen App keine Schnüffler enthalten sind.
• Bei meinem ersten Durchlauf identifizierte ich 15 Module⁴² mit Belegen für ihr invasives Eindringen in die Privatsphäre der Nutzer. In obiger Tabelle sind diese mit einem „Monitoring Icon“ versehen, welches zu Details meiner „Fundstücke“ verlinkt. Ist ein Modul nicht derart markiert heißt dies nicht, es wäre „sauber“ – sondern lediglich, dass ich (u. a. aufgrund bereits geschilderter Schwierigkeiten mit den Suchmaschinen) keine Belege finden konnte.
• Zu manchen Modulen konnte ich überhaupt keine Informationen finden (z. B. Daum Ads, Cauly Ads). Wie haben Entwickler nur herausgefunden, wie sie diese Module in ihre Apps einbinden können? Andere Module (z. B. display.io) geben Details nur Preis, wenn man sich zuvor registriert. Was haben diese zu verbergen?
• Der Begriff „free“ im Namen einer App zeigt mit etwa 95%iger Sicherheit an, dass selbige mindestens ein Werbemodul enthält (ich fand nur wenige Ausnahmen). Die Wahrscheinlichkeit steigt auf 100% bei Verwendung von „All Caps“ (also „FREE“). Was sich analog aus dem Begriff „best“ ableiten ließe, konnte ich jedoch nicht feststellen
• Die Begriffe „no ads“ bzw. „ad free" bedeuten nicht automatisch, dass betreffende App keine Werbemodule enthält – sondern bestenfalls, dass sie keine Werbung anzeigt. Letzteres habe ich jedoch nicht überprüft.
• Bestenfalls fragwürdig: Apps mit der Aufgabe, sich um den Schutz der Privatsphäre zu kümmern, jedoch ATS enthalten. Ein klares No-Go für mich – aber davon gibt es einige. Ich habe darauf gewartet, derartige Kandidaten auch bei den Ad Blockern zu finden – was jedoch glücklicherweise nicht der Fall war
• Besonders hohe Konzentrationen an ATS fand ich in Bereichen die versprachen, dass man etwas „besonders günstig“ bekommt: billiger Telefonieren, günstiger Tanken. Mit Erleichterung fand ich besonders niedrige Konzentrationen in einigen sensibleren Bereichen, etwa Home-Banking, Arzt und Apotheke. Gemischte Resultate hingegen in anderen sensiblen Bereichen wie Kinderschutz. Ganz besonderen Spaß hatte ich bei Bearbeitung unserer allzeit beliebten „Anti-Virus“ Apps (siehe Anti-Malware): Entfernt man alle „markierten“ Kandidaten aus der Liste – und anschließend auch noch die übrigen, für welche AppBrain ATS ausweist – bleibt kaum eine Hand voll übrig.⁴³ Wer unter diesem kläglichen Rest einen namhaften Kandidaten vermutet, wird enttäuscht sein: Die haben sich allesamt disqualifiziert
• Ich habe die Empfehlungen zur Integration von Modulen in „Deine App“ (u. a. um die verlangten Permissions herauszufinden) sowie Hinweise/Diskussionen dazu, welches Ad-Modul man am besten verwenden sollte untersucht. Begriffe wie „Privatsphäre“ oder „Datenschutz“ fielen nirgends – geschweige denn, dass die gar diskutiert wurden. In einigen Fällen gab es zu einem Modul eine FAQ: Das gleiche Ergebnis dort. Alles drehte sich nur ums liebe Geld: wie mache ich Geld, wie mache ich mehr/schneller Geld, wann werde ich bezahlt … Besonders erschreckend fand ich, was die CallDorado FAQ (jupp, kein HTTPS) auf die Frage antwortete, ob ein Anwender nicht durch Verwendung des Moduls zur Deinstallation der App bewegt werden könnte: Caller ID services are very popular with users. Users will not uninstall you app. („CallerID Services sind bei Anwendern sehr beliebt. Sie werden die App nicht deinstallieren.“) Aha. Mit Speck fängt man Mäuse. Mehr zu CallDorado hier:

No-Gos und Fragwürdigkeiten

In einigen Bereichen sind ATS ein klares No-Go. Hier ein paar Beispiele – und ja, für alle genannten gibt es „Missetäter“:

• „Privacy Advisors“. Wie soll mich jemand bzgl. Privatsphäre beraten, der sie selbst missachtet?
• Anti-Malware/Security Suites. Diese sollten den Anwender vor Angriffen schützen – und nicht noch selbst neue offene Scheunentore einbauen. Sowohl Werbe- als auch einige Analytics-Module stellen Sicherheitsrisiken dar, wie Studien belegen.
• Diebstahlschutz/Geräte-Finder. Wenn ich eine solche App verwende, sollte sie gefälligst den Dieb tracken, und nicht mich!
• Security Cams. Ernsthaft? Wohin berichten diese und was?
• Verschlüsselung/Entschlüsselung sensibler Daten (einschließlich Mail, Messaging etc.) Das brauche ich hoffentlich nicht zu erklären. Falls doch, ein kleiner Hinweis: Module haben Zugriff auf alles, auf das auch die Host-App Zugriff hat. Wenn ich das Gefühl habe, dass ich gewisse Informationen verschlüsseln sollte, möchte ich gerade nicht, dass Dritte darauf Zugriff haben. Wenn ich hingegen Information frei zugänglich machen möchte, würde ich sie wohl kaum verschlüsseln.
• Password-Safes. Genau so.
• Apps, welche Root-Zugriff (ACCESS_SUPERUSER) benötigen: Hier stellen ATS ein besonders hohes Sicherheitsrisiko dar – da sie (und ihre Inhalte, sprich: Werbung) mit eben der selben Machtfülle (root) ausgestattet werden! Daher wäre beispielsweise eine SuperUser App mit ATS ein absolutes No-Go für mich – aber ja, auch solche Kandidaten gibt es. Außerdem werdet Ihr ziemlich suchen müssen, wollt Ihr einen Root Checker ohne ATS finden.
• Apps für Kinder. Ein doppeltes No-Go hier: eines für das Tracking von Kindern – und ein weiteres dafür, ihnen etwas (Ads) unterzujubeln, mit dem besonders die jüngeren von ihnen (noch) nicht kompetent umgehen können.
• Apps, die „sehr persönliche Informationen“ wie Kalender, Kontakte, Medikamente, Finanzen etc. verwalten. Siehe oben.

Statistiken

Diese Studie habe ich in mehreren Schritten ausgeführt – welche (nach einigen Wochen harter Arbeit) in obiger Modul-Liste, entsprechenden Markierungen in meinen App-Listen, sowie den folgenden Statistiken über die Verteilung ausgewählter ATS in Apps geführt haben. Wie bereits erwähnt, lagen für etwa jede sechste bis achte App keine Informationen vor. Da ich unglücklicherweise zu spät bemerkte, nicht zwischen „verwendet keine Tracker“ und „es liegen keine Daten vor“ unterschieden zu haben (und nicht noch einmal mehrere Wochen an einem Extra-Lauf für präzisere Werte verbringen wollte), habe ich für die Statistiken von der Gesamtzahl untersuchter Apps 10% abgezogen. Die folgenden Werte sind daher eher als „optimistisch“ bzw. „Untergrenze“ zu betrachten. Dies gilt insbesondere auch, da ich bei der Auswahl von Apps für meine Listen bereits darauf geachtet habe, besonders „verdächtige“ Kandidaten außen vor zu lassen.

Statistik/Modul	Anzahl	Prozent
Alle Apps -10%	11.925	100.00
Alle Paid -10%	1.917	16.08
Alle mit Trackern	5.364	44.98
Alle mit Ads	4.758	39.90
Paid mit Trackern	445	23.21
Paid mit Ads	347	18.10
Admob	4.659	39.07
Google Analytics	708	5.94
Flurry	665	5.58
MoPub	304	2.55
inMobi	163	1.37
Millennial	146	1.22
StartApp	136	1.14
Umeng	97	0.81
Smaato	44	0.37
Airpush	33	0.28
LeadBolt	27	0.23
Mobclix	19	0.16
RevMob	19	0.16
CallDorado	13	0.11
Tap 4 Tap	8	0.07
MobPartner	2	0.02

Diese Statistiken beziehen sich nur auf die Module, die in ihnen auch explizit benannt sind. Ist daher z. B. von „Alle mit Trackern“ die Rede, bezieht sich das auch nur auf die genannten Tracker. Absolute Zahlen (also solche, die alle existierenden Tracker mit einbeziehen) würden somit weit höher ausfallen. Dennoch lässt die Tabelle einige Rückschlüsse zu:

• Etwa jede zweite App im Google Play Store ist mit mindestens einem bekannten ATS „infiziert“.
• Das gleiche gilt für etwa jede vierte kostenpflichtige App.
• Wenig überraschend ist Google AdMob das bei Weitem meist verwendete Werbe-Modul. Bei den Analytics-Modulen liegen Google Analytics und Flurry Analytics etwa gleichauf.
• Glücklicherweise werden die aggressivsten Module nur relativ selten genutzt: weniger als jede 80ste App verwendet Millennial Media, und lediglich etwa jede tausendste CallDorado.
• Dennoch: Wer für einen bestimmten Zwecke eine App sucht, die völlig frei von ATS ist, wird es schwer haben – selbst bei Bereitschaft, dafür Geld zu investieren.

Wofür werden die verlangten Permissions verwendet?

Es mag offensichtliche und berechtigte Gründe für Ads, Statistiken und Analytics geben. Aber es existiert definitiv ein Missbrauchs-Potential, welches in vielen Fällen auch (eben so offensichtlich) genutzt wird. Einige Hinwese finden sich beispielsweile in McAfee´s 2014 mobile security report:

• GET_TASKS: In Deinem Leben schnüffeln, Verteidigungslinien (installierte Sicherheits-Apps) umgehen
• GET_ACCOUNTS: Konten für „Identitäts-Diebstahl“ finden⁴⁴
• READ_PHONE_STATE: Das Gerät identifizieren, um App übergreifend zu tracken (gewöhnlich per IMEI/DeviceID), den Netzbetreiber in Erfahrung bringen
• ACCESS_COARSE_LOCATION / ACCESS_FINE_LOCATION: Standort-Profile anlegen, Bewegungen verfolgen.⁴⁵
• READ_SMS / RECEIVE_SMS / RECEIVE_MMS / SEND_SMS: Betrügerische Aktivitäten (man denke beispielsweise an SMS TAN)

Und jetzt ein paar Dinge, die John wohl übersehen hat:

• ACCESS_NETWORK_STATE / ACCESS_WIFI_STATE⁴⁶: Erkennen, ob überhaupt ein Netzwerk verfügbar ist (um z. B. Ads zu laden) – aber ebenso Netzwerk-Informationen sammeln (welche Netzwerke sind in Reichweite?) und darüber den ungefähren Standort ermitteln (z. B. via IP sowie bekannte WLAN Netzwerke)
• CHANGE_WIFI_STATE: Um den Netzwerk-Zugriff zu aktivieren, wenn der Benutzer explizit „offline gegangen“ ist (etwa per „Flugmodus“), damit weiterhin Werbung geladen und Daten versendet werden können (evtl. auch für Real-Time Tracking des Standorts?)
• INTERNET: recht offensichtlich: um Werbung herunter- und gesammelte Daten hochzuladen
• ACTIVITY_RECOGNITION: die Bewegungsart des Anwenders identifizieren. Ist er ein Radler? Ein Jogger? Autofahrer?
• READ_CALENDAR / WRITE_CALENDAR: um Werbung zu platzieren sowie die Zeitplanung des Anwenders in Erfahrung zu bringen. Stichworte aus Kalender-Einträgen sind für das Profiling sehr interessant. Insbesondere sich wiederholende Termine. Oder solche mit „brisanten Stichworten“…
• READ_LOGS: Nach sensiblen Informationen fischen, die andere Apps dort hinterlassen haben könnten
• RECORD_AUDIO: Aushorchen von Unterhaltungen? Puppenhäuser bestellen?
• VIBRATE: „Damit ich Dich besser nerven kann“ (und Du meine Werbe-Anzeigen nicht verpasst)
• WRITE_EXTERNAL_STORAGE: Puffern/Zwischenspeichern von Werbematerial (z. B. Videos)?

Noch ein Hinweis zu READ_PHONE_STATE: ATS wollen gewöhnlich Zugriff auf Geräte-IDs. Werden mehrere Apps mit dem gleichen Modul auf dem selben Gerät genutzt, können so die gesammelten Informationen prima zu Profilen zusammengefasst werden: welche Apps ein Anwender nutzt, lässt sich so leicht feststellen (da sie alle die gleiche Geräte-ID übermitteln). Und darüber auch die persönlichen Interessen, zusammen mit den anderen gesammelten Daten. Von einer App gesammelte PII lassen sich nun mit von einer anderen app gesammelten PII verbinden. Hat auch nur eine dieser Apps Zugriff auf Konten-Informationen, und das entsprechende Modul macht sich das zu Nutze, lassen sich z. B. auch die Email-Adressen des Anwenders mit einbringen; so wird dann aus einem „Geräte-bezogenen Profil“ ein „Personen-bezogenes Profil“. Nix mit „anonym“.

So kommt denn Longitudinal Analysis of Android Ad Library Permissions (auf Seite 6) wenig überraschend zu dem Schluss:

Unfortunately for users, however, most of the permission creep seems directed not at making the ad libraries work more smoothly and efficiently (with the possible exception of the ACCESS NETWORK STATE permission), but at extracting additional data about the user. Permission growth occurs largely in the permissions needed to uniquely identify the device (and, by extension, the user), such as READ PHONE STATE and ACCESS WIFI STATE, and in permissions that make ads more obtrusive, such as VIBRATE. It is possible that some of the permission growth relates to an increasing ability of ad libraries to incorporate rich media such as video […] However, most seems to be simply related to the collection of additional data on the user.

(„Zum Nachteil des Anwenders zielen die meisten Permissions nicht darauf ab, die Werbemodule [in seinem Sinne, d. Ü.] effizienter und besser zu machen (mit der wahrscheinlichen Ausnahme der ACCESS NETWORK STATE Permission), sondern um zusätzliche Informationen über ihn abzuschöpfen. Zusätzliche Permissions beziehen sich häufig auf die Identifikation des Gerätes (und darüber des Anwenders), wie etwa READ PHONE STATE und ACCESS WIFI STATE, sowie das Modul aufdringlicher zu machen, wie etwa VIBRATE. Es ist möglich, dass sich einige der zusätzlichen Permissions auch auf die zunehmenden Möglichkeiten von Werbemodulen zum Einbezug von „Rich Media“ wie etwa Videos beziehen […] Wie auch immer, die meisten scheinen einfach nur darauf ausgelegt, zusätzliche Informationen über den Anwender zu sammeln.“)

Sind „targeted Ads“ nicht ein typisches „Win-Win“?

Es wird oftmals argumentiert, „targeted Ads“⁴⁷ seien eine typische Win-Win Situation: Der Werbetreibende spart sich Zahlungen für Ads, die eh niemand anschaut – und der Anwender Belästigungen durch Werbeanzeigen, die ihn ohnehin nicht interessieren. Doch das ist nur eine nette Theorie, die sich darauf verlässt, dass alle fair spielen – was leider nicht die Regel zu sein scheint. Logisch: Wenn der Werbetreibende weiß, dass man sich für eine Reise nach Irland interessiert, kann er dazu passende Angebote anzeigen – und der Anwender sich das passendste Angebot heraussuchen. Mit der über den Anwender aggregierten Information könnte er aber ebenso wissen, dass Du ganz dringend unbedingt morgen in Dublin sein musst (und daher keine Zeit hast, alle Angebote gründlich zu prüfen) – und schickt dann höherpreisige Angebote. Weiß eine Versicherungsgesellschaft um Deine „riskanten Hobbies“, möchte sie Dir sicher nicht ihren günstigsten Tarif verkaufen. Oder überhaupt irgend einen. Außerdem muss, wie eine Cornelly Studie hervorhebt, mobile Werbung als potentiell böswillig betrachtet werden – targeted oder nicht. Die selbe Studie merkt an dass viele Anbieter von Werbemodulen, einschließlich AdMob, MoPub, und AdMarvel, Werbung über unverschlüsseltes HTTP ausliefern – der bereits genannte „Man in the Middle“ kann also relativ problemlos böswilligen Code einschleusen.

Davon abgesehen ist das Anzeigen von Werbung nicht das Einzige, was diese Datensammler tun. Nicht selten stehen diese Daten zum Verkauf (oftmals auch gleich die ganze sammelnde Firma). Desweiteren sollte man auch an „Datenpannen“ denken: Die von den verschiedenen Modulen gesammelten Daten sind quer über das Netz verstreut gespeichert. Was, wenn sie in die falschen Hände geraten? Identitäts-Diebstahl ist eine Sache. Erpressung eine weitere. Änderungen in der Politik eines Landes können das, was heute „normal“ erscheint, morgen zu einem Grund für Verfolgung machen. Um nur einige Punkte zu nennen. Neben dieser ganzen Datensammelei sind ein weit offensichtlicher (und sichtbarerer) Teil des aggressiven Marketings nervende Popups und andere „unerwünschte Unterbrechungen“. Nicht zu vergessen bereits angedeutetes „Malvertising“, bei dem schädliche Werbeinhalte mit „Malware Inside“ auf unsere Geräte gelangen, da das entsprechende Werbenetzwerk es mit der Sorgfaltsprflicht bei der Prüfung geschalteter „Anzeigen“ nicht so genau nahm.

Es lässt sich bereits schwerlich sagen, wo die Daten eines Anwenders seitens dieser Sammler regulär (d. h. „planmäßig“) hingelangen. Daher kann man auch kaum beurteilen, wie sicher sie „dort“ gespeichert sind. Abgesehen vom fraglichen „Nutzen“, sind die mit „targeted Advertising“ einhergehenden Risiken bzgl. der persönlichen und privaten „Lebensinhalte“ eher hoch. Nach meiner bescheidenen Meinung überwiegen die Risiken klar den eventuellen Nutzen (des Anwenders, wohlgemerkt). Insbesondere, da derart viele „Sammler“ involviert sind, und es scheinbar keiner mit meiner Privatsphäre all zu genau nimmt.

Wie gelangen diese Module an meine Daten?

Zum Einen tun sie das ganz direkt. Wie bereits aufgezeigt, muss der App-Entwickler bei der Einbindung des entsprechenden Moduls für dieses eine Reihe Permissions anfordern, damit es überhaupt funktioniert – so lässt sich an diesen Berechtigungen bereits erahnen, was man zu erwarten hat. Aber es gibt noch mehr. Ein Fakt, auf den ich bereits des Öfteren hingewiesen habe, sei an dieser Stelle durch eine Studie belegt. How mobile apps leak user data that’s supposedly off-limits schreibt:

The researchers found that the root cause of the privacy leakage is the lack of isolation between the ads and mobile apps. Adopting HTTPS wouldn’t do anything to protect the ad traffic.

(„Die Forscher fanden heraus, dass die Grundursache für das „Entweichen“ privater Informationen die fehlende Isolierung zweischen den Ads und den mobilen Apps ist. Selbst die Verwendung von HTTPS hilft nicht, den Werbe-Traffic zu schützen.“)

Mit anderen Worten: Worauf auch immer eine App Zugriff hat, darauf kann auch jedes in sie integrierte Modul zugreifen.⁴⁸ Verlangt also ein harmlos aussehendes kleines Werbemodülchen lediglich INTERNET, stürzt es vielleicht nicht gleich ab, wenn seiner Host-App keine weitere Permission zur Verfügung steht. Dennoch wäre es jedoch in der Lage, auf z. B. Adressbücher und Kalender des Anwenders zuzugreifen, sollte die Host-App über entsprechende Befugnisse verfügen. Und könnte natürlich die dort gefundenen Daten auf einen beliebigen Server hochladen, die INTERNET Permission hat es ja in jedem Fall. Es gibt keine Isolierung zwischen einer App und den von ihr verwendeten Modulen, obwohl sie dringend nötig wäre. Einer der Gründe, warum ich keine derartige App (mit ATS) benutzen würde, sobald persönliche Daten ins Spiel kommen. Und dabei denke ich u. a. an SMS (Nachrichten, Kontakte), Telefonie (Kontakte, Anrufliste), Kalender, Aufgabenlisten, Passwort-Safes, Finanzen, Gesundheit – um nur ein paar Bereiche zu nennen. Selbstverständlich hat da jeder seine eigenen Vorstellungen und Maßstäbe, ich möchte da niemandem Vorschriften machen – nur zum Denken anregen. Schließlich gibt es sogar Budget-Manager mit Anbindung an Facebook und Twitter, tut Euch also keinen Zwang an

Wie kann ich mich schützen?

McAfee schreibt:

When deciding to accept and download an app, ask yourself if the purpose of the app truly meets the access requested. If something seems unnecessary, it probably is. Learn more about the permissions an app may ask for.

(„Wenn man die Permissions einer App akzeptiert und sie herunterlädt sollte man sich fragen, ob der Zweck der App wirklich den verlangten Zugriffsberechtigungen entspricht. Schaut etwas unnötig aus, ist es das oft auch. Lernt mehr über die Permissions, welche Apps anfordern.“)

Das ist oft keine einfache Sache. Wer würde etwa erwarten, dass eine Taschenlampen-App die Permission CAMERA tatsächlich benötigt, um auf das Blitzlicht zugreifen zu können? Glücklicherweise haben einige Entwickler damit begonnen zu erklären, wofür sie einzelne Berechtigungen anfordern – direkt in der Beschreibung ihrer Apps. Bestehen Zweifel (z. B. weil dies nicht erklärt ist, oder in der Erklärung Lücken bestehen), sollte man die entsprechenden Entwickler kontaktieren – und ihnen dabei auch gleich nahelegen, diese Lücken zu schließen. Eine gute Idee ist es auch, erfahrenere Android-Nutzer im Forum zu fragen, ob sie eine Erklärung haben. Oder die Liste mit Permissions hier bei IzzyOnDroid zu konsultieren, die auch einige Erklärungen beinhaltet. Im Kontext dieses Artikels sollte man sich auch bewusst sein, dass mehrere Apps das gleiche ATS enthalten – und somit, wie oben beschrieben, reichhaltige Profile erzeugen können⁴⁹ – eine Tatsache, die auch von einer weiteren Studie bestätigt wird: Trackers können mehr Informationen sammeln, wenn sie in mehreren auf dem gleichen Gerät von gleichen Anwender installierten Apps präsent sind (siehe Grafik dort auf Slide 17). Im Schnitt teilt ein Anwender Daten mit ca. 25 Trackern, wenn sowohl gratis als auch kostenlose Apps genutzt werden.

Ein Handicap ist dass, selbst wenn man um die Bedeutung einer Permission weiß, man noch lange nicht sagen kann wofür sie letztendlich wirklich benutzt wird.⁵⁰ Man kann raten – aber wer sagt einem, dass man damit richtig liegt? Oder dass eine App eine Permission nicht für mehrere Dinge nutzt, einschließlich einiger, denen man nicht zustimmen würde? Aus Mobile Privacy: Is There An App For That?, Seite 69:

Android allows developers to request access to data, but does not provide a way to specify how the data will be used and for what purposes, when the permission list is presented to users. Users therefore have no way of knowing how an app will use the requested permission to access their call logs for example. While the practice by mobile operating systems of giving users more control as to what data apps can access is laudable, it is inherently flawed if apps do not have to specify how and why the data is processed.

(„Android bietet Entwicklern die Möglichkeit, Zugriff auf Daten anzufordern – bietet jedoch bei der Präsentation der Berechtigungs-Liste [bei der Installation einer App, d. Ü.] keinen Weg anzugeben, zu welchem Zweck dies geschieht. Anwender haben somit keine Möglichkeit zu wissen, wie eine App beispielsweise mit der Berechtigung zum Zugriff auf Anruflisten umgeht. Während die Praxis mobiler Betriebssysteme, Anwendern mehr Kontrolle über den Zugriff von Apps auf ihre Daten zu geben, löblich ist, ist sie immanent mangelhaft wenn Apps nicht spezifizieren können, wie und warum diese Daten verarbeitet werden.“)

Ein weiterer Grund im Zweifelsfall diejenigen zu kontaktieren, die über mehr Erfahrung verfügen – zum Beispiel in Foren. Doch auch einige der Werbemodul und Privacy-Checker können sich als hilfreich erweisen – zumindest in Bezug auf Apps, die man bereits auf seinem Gerät installiert hat. Eine solche App, Lumen Privacy Monitor, wurde in der Studie Tracking the Trackers verwendet, die in unten stehenden Lese-Empfehlungen erwähnt ist.

Wer so sicher gehen will wie möglich, verwendet ausschließlich Apps aus dem offiziellen F-Droid Repository. Das Team dort kompiliert die Apps selbst aus dem öffentlich einsehbaren Quellcode, den sie zuvor auch selbst geprüft haben. Etwaige Werbemodule oder andere „unfreie Dinge“ werden dabei entweder komplett entfernt – oder in der jeweiligen App-Beschreibung explizit ausgewiesen (z. B. „Tracking you“ oder „unfree dependencies“).

Kontaktiert die Entwickler. Im Einzelfall sind sie sich der mit den jeweiligen Modulen verbundenen Risiken gar nicht bewusst. Beschreibt ihnen Eure Bedenken (und verlinkt optional auf diesen, auch in Englisch verfügbaren, oder ähnliche Artikel). Empfehlt ihnen, riskante Module durch weniger aggressive zu ersetzen. Sofern ihnen etwas an der Privatsphäre (und Zufriedenheit) ihrer Nutzer liegt, sollten sie Euch nicht ignonieren. Empfehlt ihnen ggf. auch eine „Bezahlversion“, die völlig frei von ATS ist (oder, falls eine solche bereits existiert: Kauft und nutzt sie!) Bietet eine Spende an, oder initiiert eine „Bug Bounty“⁵¹ bzw. beteiligt Euch an einer solchen, sofern sie bereits existiert.

Erwägt, einen AdBlocker zu verwenden. Die meisten (und wirklich effektiven) setzen zwar ein gerootetes Gerät voraus; es gibt aber auch Kandidaten, die ohne root auskommen. Und bevor jetzt die Diskussion losgeht: Nein, dabei geht es nicht darum, den App-Entwicklern „die Butter vom Brot zu nehmen“. Das Schreiben von Apps ist in der Regel harte Arbeit – und so mancher Entwickler hat nicht nur Stunden oder Tage, sondern Wochen, Monate oder gar Jahre in die App investiert. Das sollte natürlich honoriert werden. Aber hier geht es um reinen Selbstschutz: Wie beispielsweise eine Studie aus 2016⁵² zeigt, liefern Ads gelegentlich „bösartige/schädliche Inhalte“ („malicious files“) aus. Und wie dieser Artikel zeigt, dringen ATS aggressiv in unsere Privatsphäre ein. Daher halte ich den Einsatz von AdBlockern für mehr als nur legitim: Lasst Euch keine „Anti-Virus App“ aufschwatzen. Was Ihr wirklich braucht, ist ein guter AdBlocker. Denkt dabei jedoch auch daran, die Entwickler für ihre Arbeit zu entschädigen: Erwerbt die Kaufversion von regelmäßig genutzten Apps (so es sie gibt) – oder sucht Kontakt zu den jeweiligen Entwicklern, um ihnen auf andere Art „ein Bier/Kaffee zu spendieren“, und so die verlorenen Einnahmen wettzumachen.

Solltest Du selbst Entwickler einer (oder mehrerer) Apps sein, noch ein spezieller Hinweis: Eine Studie stellte u. a. auch fest, dass die Integration spezieller Werbemodule negative Auswirkungen auf das Rating einer App haben kann. Auch wenn heutzutage viel zu viele Anwender gegenüber Privatsphäre- und Datenschutz-Themen ignorant sind (und die Verletzung selbiger oft nicht einmal mehr wahrnehmen, machen doch schließlich alle anderen Lemminge auch so) – es gibt noch immer etliche, denen dies wichtig ist. Und die werden auf Dich zeigen (nicht immer ganz zu Recht), weil Du es „übertrieben hast“. Für „End-Anwender“ deutet die Verwendung mehrerer Werbemodule auch automatisch auf „Gier“ hin (andere Gründe sind für sie auch kaum ersichtlich). Diejenigen, denen ihre Privatsphäre wichtig ist, fühlen sich von Dir verkauft – denn sie sind es, die mit ihren Daten und ihrer Privatsphäre dafür zahlen müssen. Das wiegt gleich schwerer, wenn es nicht einmal die Option zum Erwerb einer „sauberen“ Kauf-Version gibt (oder zumindest einer ohne Werbemodule). Verwende nicht die „faule Ausrede“, Du hättest die Module ja deaktiviert. Selbst wenn wir Dir trauen, der Werbeindustrie trauen wir definitiv nicht; was jedoch nicht da ist, kann auch keinen Schaden anrichten. Also lass sie bitte bei der Kaufversion ganz weg. Und schau auch bei der „gratis Version“ genau hin, welche Module Du einbindest – und warum. Wenn Anwender klar sehen können, dass Dir ihre Privatsphäre nicht egal ist, steigst Du auch in ihrem Ansehen: Deine Apps wirken vertrauenswürdiger, werden in der „Privacy-bewussten Community“ öfter empfohlen. Was letztendlich auch auf die restliche Community Einfluss haben wird.

---

Empfohlene Lektüre

Im Folgenden eine Auswahl aus Dokumenten, über die ich bei meiner Studie gestolpert bin – und die ich interessant genug empfand, sie für eine „vertiefende Lektüre“ zu empfehlen. Da die Dokumente selbst auf Englisch sind, belasse ich auch die Zusammenfassung in dieser Sprache: Hilft nix, wenn Ihr das lesen wollt, müsst Ihr ohnehin Englisch können

• Who’s watching you? McAfee Mobile Security Report (PDF, 2014)
  Being issued by famous Anti-Virus expert McAfee, one can expect it exaggerates in direction to have their „protection“ installed. Nevertheless, with that filter in mind (and the fact the article is from 2014), a very interesting reading on some backgrounds.
• Tracking the Trackers: Towards Understanding the Mobile Advertising and Tracking Ecosystem (PDF, 2016)
  This study uses the Lumen Privacy Monitor app (previously known as ICSI Haystack) to understand how mobile apps handle private information, including data leaks and data sharing.
• Investigations into Consumers Preferences Concerning Privacy: An Initial Step Towards the Development of Modern and Consistent Privacy Protections Around the Globe (PDF, 2014)
  Provides alternative definitions of privacy and of invasions of privacy followed by a brief review of the regulatory gap in which most information services companies […] operate, then describes the “myth of anonymization” (and how easy it is today to de-anonymize „anonymized data“). After this comes a description and summary of the surveys themselves: consumers’ attitudes towards privacy, consumers’ attitudes towards protecting their children’s privacy. During this, it deals with privacy violations of search engines, ad networks, social networks, etc.
• A Measurement Study of Tracking in Paid Mobile Applications (2015)
  Powerpoint document with matrix of PII accessed by modules (slides 11-14).
• MobileAppScrutinator: A Simple yet Efficient Dynamic Analysis Approach for Detecting Privacy Leaks across Mobile OSs (2016)
  Focuses on tracking and data collection by advertisers and analytics companies across mobile platforms: We are first to provide detailed analysis and measurement data for both Android and iOS. Includes a matrix of which device identifiers are sent to which domains (page 7), as well as which PII is sent to which domains (page 10).
• An In-Depth Analysis of Online Trackers’ Privacy (PDF, 2014)
  Are They Worth Reading? We analyzed the privacy policies of 75 online tracking companies with the goal of assessing whether they contain information relevant for users to make privacy decisions […] From the conclusion: Only 75 out of these [2,750] companies had English-language privacy policies with content relevant for tracked users, which we analyzed thoroughly. We found that most of these companies are silent with regard to important consumer-relevant practices including the collection and use of sensitive information and linkage of tracking data with personally-identifiable information.
• Mobile Privacy: Is There An App For That? (PDF, 2012; Master’s Thesis with 105 pages)
  The goal of this thesis is to research to what extent third-party apps for smart mobile devices have to comply with relevant EU legislation concerning the processing of personal data. […] This will demonstrate what kind of data are available on smart mobile devices, to what extent developers of apps can access them with or without permission of users, and how these are processed by apps.
• How mobile apps leak user data that’s supposedly off-limits (2/2016)
  Gives some background on how those modules are able to access so much PII: Researchers at the School for Computer Science at the Georgia Institute of Technology recently delved into just how much data users are giving away to pay for free mobile apps. […] We have a permeable membrane between ad networks and mobile app developers to thank for all this dribbling.
• Leakage of Geolocation Data by Mobile Ad Networks (10/2016)
  This research demonstrates how mobile networks leak location data and other sensitive information from mobile phones by sending plaintext, unencrypted transmissions. It is therefore possible that geolocation information, associated with a user, could be captured by government and private sector entities, as well as by nefarious actors.
  Though focused on iPhones, same can be applied to other platforms and holds true also on Android. Read online, or download PDF from the site.
• What Mobile Ads Know About Mobile Users (PDF, 2016, 15 pages)
  We then demonstrate how malicious ads can infer sensitive information about users by accessing external storage, which is essential for media-rich ads in order to cache video and images. […] We conclude with our recommendations for redesigning mobile advertising software to better protect users from malicious advertising.
  This is less about the modules themselves accessing data, but rather about how the ads themselves are isolated to not access PII and other data. For that, it studied four AdSDKs: AdMob, MoPub, AirPush and AdMarvel, and investigated what a fully confined, privilege-separated mobile ad can learn about the user of the device on which it is displayed. So it´s about the dangers ads themselves present.
• IntelliAd Understanding In-APP Ad Costs From Users Perspective (7/2016)
  we aim at understanding the ad costs from users perspective. We utilize app reviews, which are widely recognized as expressions of user perceptions, to identify the ad costs concerned by users. […] Our experimental results provide the developers with suggestions on better incorporating ads into apps and, meanwhile, ensuring the user experience.
  This is a reading for developers who care to take the „UX“ (aka „user experience“ – or: one essential but easily ignored component, end users, as the study puts it) in mind when chosing to embed some ad SDK
• Privacy Concerns in Android Advertising Libraries (PDF, 8/2013, 64 pages)
  Master thesis:
  This work investigates privacy characteristics of Android advertising libraries. Taking a sample of 114,000 apps, we extract and classify their ad libraries. We then seek to understand how they make use of sensitive user data. […] We find that the use of most permissions has increased over the last several years, and that more libraries are able to use permissions that pose particular risks to user privacy and security. [… We] consider information passed directly from the application to the ad library. […] We find that many applications pass personal information directly to their ad libraries, without any need for the library to query the operating system directly.
  Especially see table 3.2 on page 46, which lists privacy related API calls per ad library for some of the most common ad libraries.
• Characterising User Targeting For In-App Mobile Ads (PDF, 2013, 6 pages)
  In this work, we present a novel analysis of targeted advertising in the Google AdMob advertising network and show insights about the relevance of Google user profiles, and the categories of apps used, on the in-app ads served on smartphones. […] Our analysis reveals that, for all comparable experiments, the proportion of targeted ads is in all cases higher than the proportion of contextual ads. Moreover, blocking the targeting (disabling targeting in an AdMob user profile settings) results in a significant drop in the number of received ads with some experimental instances receiving no ads at all. Overall, the number of targeted ads is comparatively lower than the number of generic ads.
• WifiLeaks: Underestimated Privacy Implications of the ACCESS_WIFI_STATE Android Permission (2014, PDF, 8 pages)
  Our analyses reveal that this permission is already used by some companies to collect user Personally Identifiable Information (PII). We also conducted an online survey to study users’ perception of the privacy risks associated with this permission. This survey shows that users largely underestimate the privacy implications of this permission.
  […] PII can be derived from the data related to Wi-Fi interface (Section 3), namely unique identifiers (useful for tracking purposes), device geolocation, travel history and social links between users. […] This raw data may look innocuous, but it is actually possible to either directly access or infer several user PII.
  Page 4 has a table of information accessible via this permission. Page 5 has another interesting table showing top-5 networks (which easily can be assigned to ad modules) accessing those sensitive data. From this article, it e.g. includes inMobi and Google (i.e. AdMob or GA) – but also others I didn´t find any „suspicious reports“ on up to know (Tapjoy, Vungle), and several I didn´t even notice yet.
• Unsafe exposure analysis of mobile in-app advertisements (PDF, 2011, 12 pages; requires Google Account; without login here)
  In this paper, we focus on potential privacy and security risks posed by these embedded or in-app advertisement libraries […] In particular, we first decouple the embedded ad libraries from their host apps and then apply our system to statically examine the ad libraries for risks, ranging from uploading sensitive information to remote (ad) servers to executing untrusted code from Internet sources. Our results show that most existing ad libraries collect private information […] call logs, phone number, browser bookmarks, or even the list of apps installed on the phone. Moreover, some libraries make use of an unsafe mechanism to directly fetch and run code from the Internet, which immediately leads to serious security risks.
  A matrix on information accessed per ad module can be found on page 7. The study a.o. finds ATS invasively collecting PII, disclosing smartphone data to running ads (allowing them to collect data without the user’s permission; example given: Mobclix), unsafely fetching and loading dynamic code (makes malvertising possible and easy). The study finally concludes hat even among some of the most widely-deployed ad libraries, there exist threats to security and privacy. Such threats range from collecting unnecessarily intrusive user information to allowing third-party code of unknown provenance to execute within the hosting app.
• Longitudinal Analysis of Android Ad Library Permissions (4/2013, PDF, 9 pages)
  This paper investigates changes over time in the behavior of Android ad libraries. […] We find that the use of most permissions has increased over the last several years, and that more libraries are able to use permissions that pose particular risks to user privacy and security.
  Especially interesting: table 7 at page 7, listing libraries found in apps removed from Google Play (read the surrounding paragraph for context). In short, apps containing any of those libraries are more likely to be removed from the Playstore. From the set in this article, the table contains Airpush and RevMob.
• Privacy Policy for Advertising SDKs
  Sums up privacy policies/implications from some selected networks.

Ebenfalls relevant

• Leaky Apps Far Riskier Than Mobile Malware (2/2016)
  Some of the data leak behaviors include sending out or broadcasting unique device identifiers, address book, calendar, location or SMS messages, attempting to root a device or capabilities for recording calls, or other user-initiated activity. Privacy invasive activity includes tracking locations, accessing address book, calendar, SMS archives, microphone and other functions, and sending data to ad networks.
  In examining over 315,000 unique iOS and Android apps from the respective platform´s app stores, Appthority found that just over 48% of iOS apps and nearly 87% of Android apps displayed data leakage behaviors.
  Meanwhile over 62% of iOS and 86% of Android apps engage in privacy invasive behavior.
  The full report is available for download here.
• Security and Privacy of Users’ Personal Information on Smartphones (2015, PDF, 202 pages; Doctoral thesis) In my study, I examined the causes and impact of information leaks by clean applications in order to identify the motivation behind accessing users’ personal information without their knowledge. The empirical results indicate that third-party advertising libraries are responsible for privacy breaches. I further extended my research by investigating the built-in tracking settings made available to users by the smartphone operating system. (emphasis mine)
  This doctoral thesis doesn’t focus on ad modules, but deals with them in the general context.
• Who Is Spying On Android Users, Why Do They Do It And What Are They Doing With The Data? (12/2016)
  Mainly deals with data collected by Google, Facebook and Amazon.
• List of Quality of Experience (QoE) applications (2016)
  List of domains with short descriptions and risk ratings – so you can check your logs and adjust your devices’ hosts files.
• Cross-Device Tracking: Measurement and Disclosures (PDF, 2/2017) Our study only looked at the possibility of linking two browsers on two virtual computers. We did not study the ability of companies to track users across mobile applications or other devices leveraging static identifiers such as IDFAs or Android IDs.
• Are these Ads Safe: Detecting Hidden Attacks through the Mobile App-Web Interfaces (2016, PDF, 15 pages)
  Focuses on the ads themselves rather than on specific ad networks or ad modules, and explains some patterns of how malvertizing works:
  Mobile users are increasingly becoming targets of malware infections and scams. Some platforms, such as Android, are more open than others and are therefore easier to exploit than other platforms. In order to curb such attacks it is important to know how these attacks originate. We take a previously unexplored step in this direction and look for the answer at the interface between mobile apps and the Web […]
• Shining the Floodlights on Mobile Web Tracking — A Privacy Survey (PDF, 2013, 9 pages)
  We compare tracking across five physical and emulated mobile devices with one desktop device as a benchmark. […] We confirm many intuitive predictions and report a few surprises.
• Mining Apps for Abnormal Usage of Sensitive Data (PDF, 2015, 11 pages)
  […] we mined 2,866 benign Android applications for their data flow from sensitive sources, and compare these flows against those found in malicious apps. […] malicious apps can be identified by their abnormal data flow alone, without requiring known malware samples.
• Privacy Concerns: Analysis of music applications on Android (PDF, 2014, 11 pages)
  In this article, I will use mitmproxy […]. I will leverage its ability to conduct a man-in-the-middle attack in order to analyze HTTP/S traffic to some of the most popular music applications that are available today on android mobile devices. What results may surprise you.
  In context of this article, it e.g. points out that zip code, year of birth (yob), gender and other id values being sent to third party advertisement companies (in this case, a company called Ando Media – but quotes another study confirming the same for e.g. AdMarvel, AdMob, comScore, GoogleAds and Medialets). The author comes to the conclusion that Spotify and Pandora collect those PII mainly for the purpose to pass it on to those advertisement companies. Seems that’s how you pay for their music.
• Eye on Privacy - January 2014 (PDF, 1/2014, 12 pages; HTML)
  [… this] mobile application, violated Section 5(a) of the FTC Act prohibiting unfair or deceptive acts and practices affecting commerce by failing to disclose that the app transmitted user data, including precise geolocation information and persistent identifiers, to third parties such as advertising networks. This flashlight app certainly is not the only one having done so, but this one was „publically caught int the act“ because it made it to the top apps with millions of downloads. The linked document gives some background on the FTC rulings in this case – but also goes on to implications for other apps/companies. Following that, two more cases are discussed.
• On Ad Library Updates in Android Apps (PDF, 2017, 16 pages)
  Discusses the various expenses involved in updating ad libraries and a.o. finds that in some (13.75%) cases, updates of apps have no chances in the apps’ own code but just in those ad libraries – which developers seem to be forced to update to not lose revenue.