Mastodon IzzyOnDroid


Say thanks!
Privacy Links
↓ Your product here? ↓
Das inoffizielle Android-HandbuchDas inoffizielle Android-Handbuch
Für 16,99 € bei Amazon kaufen
Die Daten, die ich rief: Wie wir unsere Freiheit an Großkonzerne verkaufenDie Daten, die ich rief: Wie wir unsere Freiheit an Großkonzerne verkaufen
Für 9,00 € bei Amazon kaufen
Sie kennen dich! Sie haben dich! Sie steuern dich!: Die wahre Macht der DatensammlerSie kennen dich! Sie haben dich! Sie steuern dich!: Die wahre Macht der Datensammler
Für 9,99 € bei Amazon kaufen
Sie wissen alles: Wie Big Data in unser Leben eindringt und warum wir um unsere Freiheit kämpfen müssen -Sie wissen alles: Wie Big Data in unser Leben eindringt und warum wir um unsere Freiheit kämpfen müssen -
Für 5,69 € bei Amazon kaufen
PRIVATSPHÄRE UND DAS RECHT AUF VERGESSENWERDEN: VERSTÄRKTER SCHUTZ SENSIBLER UND PERSONENBEZOGENER DATENPRIVATSPHÄRE UND DAS RECHT AUF VERGESSENWERDEN: VERSTÄRKTER SCHUTZ SENSIBLER UND PERSONENBEZOGENER DATEN
Für 36,90 € bei Amazon kaufen
TikTok, Snapchat und Instagram - Der Elternratgeber: Risiken und Gefahren kennen - Privatsphäre, Cybermobbing & technische Möglichkeiten: Sichere ... Social Media (Digitale Welt für Einsteiger)TikTok, Snapchat und Instagram - Der Elternratgeber: Risiken und Gefahren kennen - Privatsphäre, Cybermobbing & technische Möglichkeiten: Sichere ... Social Media (Digitale Welt für Einsteiger)
Für 16,90 € bei Amazon kaufen
Hilfe, ich habe meine Privatsphäre aufgegeben!: Wie uns Spielzeug, Apps, Sprachassistenten und Smart Homes überwachen und unsere Sicherheit gefährden (mitp Sachbuch)Hilfe, ich habe meine Privatsphäre aufgegeben!: Wie uns Spielzeug, Apps, Sprachassistenten und Smart Homes überwachen und unsere Sicherheit gefährden (mitp Sachbuch)
Für 9,99 € bei Amazon kaufen
Like me. Jeder Klick zähltLike me. Jeder Klick zählt
Für 6,99 € bei Amazon kaufen
Privatsphäre 4.0: Eine Neuverortung des Privaten im Zeitalter der DigitalisierungPrivatsphäre 4.0: Eine Neuverortung des Privaten im Zeitalter der Digitalisierung
Für 49,99 € bei Amazon kaufen
Stand: 2024-03-28 04:15
Preis & Verfügbarkeit können sich geändert haben.
enhelp

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

Lego Blocks
Lego Blocks; © Public Domain (CC0)
Quelle: Pixabay

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.1 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.2

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 habe3 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:

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“:

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:

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:

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

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“47 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.48 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  :D

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önnen49 – 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.50 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“51 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 201652 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  :D

appsprivacysecurity


  1. Tracking the Trackers (Seite 5) stellt fest, dass 70% der analysierten Apps mindestens 10% ihres Traffics ATS widmen, während mehr als 7% der mobilen Apps mindestens 90% ihres Traffics mit ATS Aktivitäten verbrauchen. Gäbe es keine ATS bezogenen Aktivitäten, würden viele mobile Anwendungen überwiegend offline arbeiten. ↩︎

  2. Siehe z. B.: Truth in Advertising: The Hidden Cost of Mobile Ads for Software Developers (PDF) ↩︎

  3. Das tue ich normalerweise mindestens einmal pro Jahr, damit sie für Euch nützlich bleiben ;) ↩︎

  4. Permissions in geschweiften Klammern sind „optional“ – jedoch meist für Entwickler als „sehr empfohlen für bessere Performance“ (in Bezug auf Kohle, natürlich) markiert. ↩︎

  5. Sammelt u. a. AndroidID, IMEI ↩︎

  6. Adlantis (ein Japanisches Werbenetz) wird in Analysis of Code Heterogeneity for High-Precision Classification of Repackaged Malware als Beispiel für aggressive Werbemodule genannt. Das Dokument erwähnt auch, dass Adlantis auf private Daten des Anwenders zuzugreifen versucht – ohne jedoch Details zu benennen. Die Adlantis Privacy Policy selbst kann man ohne aktiviertes Javascript übrigens nicht einmal lesen – man wird also bereits getrackt, bevor man sich über die Details informieren kann. ↩︎

  7. 2009 von AdMob übernommen, dort integriert, und letztendlich 2013 geschlossen ↩︎

  8. Die AerServ Terms and Conditions schreiben, dass u. a. der (GPS) Standort übertragen wird – und drängt Entwickler, ihre Anwender um ein explizites Opt-In zu ersuchen (also nicht einfach „still und heimlich“ loszulegen). Weiter heißt es dort, dass AerServ explizit nicht wünscht, dass PII übertragen werden, und Entwickler dies entsprechend zu respektieren haben. Sollten sie dennoch PII übertragen, liegt die (rechtliche) Verantwortung beim Entwickler, zuvor das explizite Einverständnis des Anwenders eingeholt zu haben („User Volunteered Data“). Ihre Privacy Policy beschreibt, dass gesammelte Daten u. a. umfassen (jedoch nicht beschränkt sind auf): * information about your device, such as the type and model, manufacturer, operating system, carrier name, Internet Protocol (IP) address, mobile browser, applications using the Services and the version of such applications, and identifiers assigned to your device […] time zone, and network connection type […] geo-location of your device, when location services have been enabled […] information about ads served, viewed, or clicked on.* Weiter: We receive information about consumers from third parties to enable targeted advertising on the website(s) and application(s) that we support.
    Auf der anderen Seite ist (für eine Werbefirma) beeindruckend, was AerServ bezüglich AdBlockern schreibt – insbesondere der Fakt, dass sie die Werbeindustrie für deren Notwendigkeit (sic!) verantwortlich machen. Siehe dazu auch: AerServ Partners With The Media Trust to Ensure Ad Security for Publishers↩︎

  9. Bezüglich vom Endanwender gesammelter Daten verpflichtet Amazon’s Mobile Ad Network Publisher Agreement in Sektion 8d die Entwickler, sie nicht mit PII zu beliefern. Die Übermittlung von Standortdaten ist nur für Anwender außerhalb der EU zulässig, und auch dann nur mit deren explizitem Einverständnis. Das explizite Einverständnis gilt im übrigen für alle Anwender ebenso in Bezug auf andere übermittelte Daten – wobei das Dokument nicht darauf eingeht, welche das sind. Eben so wenig tut dies die entsprechende FAQ. Aus letzterer lässt sich jedoch ein interessantes Detail entnehmen: The Amazon Mobile Ads API is designed to disable the geolocation feature when the device is detected as being physically located in the EU. Außerhalb der EU schaltet die API also von sich aus die Standort-Übermittlung ab. ↩︎

  10. Welche Daten AppBrain sammelt, beschreibt die integration policy. Erfasst werden phone model information, phone identifier (Google Advertiser ID), IP address of the phone, country and carrier of the connected mobile network and of the SIM card, and the AppBrain AppMetric™, a token that conveys information about which categories of apps a user is interested in in a privacy-conserving way. Demographic data (gender, age) is only collected when the developer receives this information and forwards it to the AppBrain SDK. When the app has permission to acquire geographic location, this is collected and deleted at most seven days after collection. ↩︎

  11. Sammelt folgende Daten: Standort, Netzbetreiber, Gerätehersteller und -modell, Betriebssystem, App Name, Spracheinstellungen, IP, AndroidID & mehr, um „targeted advertisements für unsere Business Partners auszuliefern“. Ein opt-out von targeted ads ist möglich – jedoch nicht von der Datensammlung. ↩︎

  12. um auf die Email-Adressen des Anwenders zuzugreifen ↩︎

  13. Details zu von AppNext gesammelten Daten finden sich in der Privacy Policy. Zusammengefasst sind das u. a.: Gerätetyp/Modell, Systemsprache, OS, SDK Version, Netzbetreiber, installierte Browser, App Verlauf und Nutzungsinformationen, Information bzgl. Downloads und Installation von Apps sowie Events in selbigen (z. B. iAP), IP-Adresse, Geräte-IDs, Android Advertising ID, Details zu Ads, Standortdaten (per IP, Netzwerk und GPS). Da in der Integrations-Anleitung lediglich die Permissions INTERNET sowie (optional) GET_ACCOUNTS genannt werden, dürften wir hier ein klares Beispiel für „wir nehmen auch andere der Host-App verfügbare Daten mit“ haben – denn mit den beiden genannten Permissions lässt sich auf die wenigsten der aufgeführten Daten zugreifen. ↩︎

  14. AppoDeal ist ein so genannter „Mediator“: der entwickler bindet lediglich ein SDK in die App ein, und wird über dieses von mehreren Werbenetzwerken (hier z. B. AdColony, AdMob, Amazon, AppLovin, Smaato, Unity) versorgt – weniger Aufwand, bessere eCPM, Impressions und somit Einnahmen. Unglücklicherweise differenziert AppoDeal’s privacy policy nicht zwischen ihrer Website und ihren anderen Services; daher lässt sich nicht klar entnehmen, welche Daten von diesem Werbemodul gesammelt werden. Auch fand ich keine andere eindeutige Quelle dazu. ↩︎

  15. Sammelt u. a. SIM operator ↩︎

  16. Avocarrot’s privacy policy beschreibt in Sektion 1, welche Daten gesammelt werden. Dies umfasst u. a.: Geräte-Information (Typ/Modell/Hersteller), OS, Netzbetreiber, IP-Adresse, IDs (Serial, GAID), Standort (GPS oder anderer), Information über angezeigte/angesehene/geklickte Ads. Informationen werden mit Werbetreibern geteilt, aggregierte Informationen auch mit anderen Kunden. Daten können im Ausland gespeichert werden – was explizit außerhalb der EU beinhaltet, wenn man sich in der EU aufhält. ↩︎

  17. siehe: Wikipedia; spezialisiert auf den Spiele-Sektor; Video Ads. Gemäß ihrer Privacy Policy werden u. a. gesammelt: Sprache, OS & SDK Version, Gerätemodel & ID (GAID/AndroidID), IP & MAC Adresse, Details zu Interaction mit Ads. Erfasste Daten werden explizit mit Daten anderer Werbeunternehmen verknüpft und mit selbigen geteilt. ↩︎

  18. Aus dem SDK Link, sinngemäß übersetzt: Unser SDK stellt uns keine PII über Anwender bereit. Wir sammeln jedoch Geräte-IDs (welche genau, hängt ab vom Typ der App, Google Play oder Amazon Appstore), grobe Standort-Daten (via IP), sowie Informationen über Impressions und Klicks. Wir erstellen auch Surveys welche es Anwendern erlauben, anonym Alter und Geschlecht anzugeben.
    Wer seine App mit Conversant oder einem anderen Netzwerk aktiviert ist selbst dafür verantwortlich, seine Nutzer über den Umgang mit den Informationen zu informieren. Deine Vereinbarung mit Conversant (speziell Sektionen 4.3, 4.4, 7.1) verlangen es von Dir offenzulegen, welche Informationen geteilt werden und mit wem.
     ↩︎

  19. Crashlytics scheint in Bezug auf Datensammlung sehr zurückhaltend zu sein. Einige Details lassen sich bei Quora finden. Ein Business-Partner schreibt (sinngemäß übersetzt): Niemand hatte je Bedenken bezüglich Data Leaks. Außerdem sollten auch jegliche andere Bedenken dadurch zerstreut werden, dass die gesammelten Metadaten recht rudimentär sind. Mit der minimalen gesammelten Datenmenge erreichen sie jedoch eine ganze Menge. Was diese „minimale Datenmenge“ ausmacht, schreibt ein früherer Angestellter: wenige Daten auf Anwendungsebene wie Paketname, Icon, Version/Build Number und Platform (um die App zu identifizieren), sowie auf Crash-Level ausschließlich die zur Analyse benötigten Details – für die er auf die Privacy Policy verweist, welche sich dort allerdings nicht mehr findet (die aktuelle Fassung von 1/2017 fand ich hier in einem PDF). PII wird dabei nur erfasst, wenn der jeweilige Entwickler sie explizit einschließt – in welchem Fall er das auch dem Anwender mitteilen muss. ↩︎

  20. Aus der display.io Privacy Policy: „The information we collect may include: geographic location, operating system versions, anonymous device identifiers for advertising, mobile app names, language settings, device type information, IP addresses, mobile network settings and internet browser types. […] We may disclose your personal information to our […] business partners.“ ↩︎

  21. mehrere Sicherheitsprobleme (zumindest 2012-2014), einschließlich „Account Hijacking“. Dafür bekannt, alles an privaten/persönlichen Daten zu sammeln, was es kriegen kann – was in diesem Kontext bedeuten kann: alles, worauf die Host-App Zugriff hat. ↩︎

  22. Sektion 1.2 in Fyber’s Privacy Policy (PDF) handelt von den via mobiler Apps erfassten Daten mit Begriffen wie „like”, „such as” etc. („etwa”, „unter anderem”, „z. B.”): Gerätetyp und ID, OS, Netzwerkanbieter, IP-Adresse, SDK Version, App, Standort, ausgelieferte Ads. Sektion 2.2 beschreibt, wofür gesammelte Daten benutzt werden, mit den üblichen Angaben (Werbung ausliefern, unseren Service verbessern etc.). Schließlich findet sich in Sektion 3, dass gesammelte persönliche Daten manchmal an Dritte weitergegeben werden können […] wenn es im Zusammenhang mit dem Verkauf und der Auslieferung von Werbung sinnvoll erscheint – und gibt mit den üblichen Marketing-Begriffen grobe Ideen dazu. ↩︎

  23. Interessant: Die HeyZap FAQ umfasst mehr als 100 Fragen, aber keine einzige beschäftigt sich mit Privatsphäre oder dem Schutz von PII. Alles dreht sich mehr oder weniger um wie und wann erhalte ich (das meiste) Geld. Die HeyZap Privacy Policy erklärt in Sektion 1, was gesammelt wird („This “automatically collected” information may include Internet Protocol address (“IP Address”), IDFA, Android ID, geolocation, country code, a unique device or advertiser ID, version of software installed, operating system type, the content and pages that you access on the Heyzap Application and/or Heyzap Network, and the dates and times that you visit the Heyzap Application and/or Heyzap Network.“) sowie in Sektion 2, wie die gesammelten Daten verwendet werden („to understand the usage trends and preferences of our Users, to improve the way the Heyzap Application and/or Heyzap Network works and looks, to create new features and functionality. […]“). ↩︎

  24. Siehe auch: Global Demo ↩︎

  25. Gemäß der Kochava Security and Privacy obliegt es dem Entwickler zu konfigurieren, welche Daten gesammelt und übermittelt werden. Es wird speziell darauf hingewiesen, dass PII abstrahiert wird: PII is not used in ongoing SDK transmission. In-App Events und Berechnungen werden getrackt, sowie „Install Notifications“ gegeben. Attribution Overview gibt darüber hinaus an, dass gesammelte Informationen auch Geräte-IDs und IP-Adressen umfassen. Das Dokument zur Android SDK integration enthält einen „sample payload”, welches weitere Details wie Land, Netzwerk-ID (Provider?), Gerätemodell enthält. Bei Kochava scheint es sich um einen „Mediator” zu handeln, der über 650 Werbenetzwerke, Publisher und Exchanges integriert. ↩︎

  26. LiveRail gehörte zu Facebook. AdExchanger zitiert die (derzeit nicht verfügbare) Privacy Policy. Demnach werden u. a. erfasst: Gerätetyp, Betriebssystem, eindeutige IDs, IP-Adresse, Standort. LiveRail wurde 12/2016 geschlossen↩︎

  27. Gemäß Localytic’s Privacy Policy bietet Localytics seinen Kunden und dritten Parteien Analysen anonymisierter, aggregierter End-User Informationen (“Analyzed Data”) – wobei es „kommerziell angemessene Anstrengungen“ unternimmt sicherzustellen, dass „Analyzed Data“ keinerlei PII enthält […] End-Users sollten sich jedoch bewusst sein, dass Kunden von Localytics’ derartige Informationen von Endanwendern anfordern können, um ihre mobilen Anwendungen zu nutzen, und daher PII in den an Localytics übermittelten Informationen enthalten sein kann. Endanwender sollten daher auch die Privacy Policies der jeweiligen mobilen Anwendungen daraufhin untersuchen, ob sie PII erfassen und weitergeben. In ihrem Analytics Dashboard finden sich weitere Hinweise auf erfasste Daten, z. B.: Standort (per Default IP-basiert, optional GPS) sowie Geräte-IDs. ↩︎

  28. MdotM sammelt u. a.: AndroidID, IMEI; weiterhin auch Geschlecht, Alter, Foto, Standort (Stadt), Mobilrufnummer, ausgelieferte/geklickte Ads, und weitere „click-stream” Daten. ↩︎

  29. Gemäß Metaps’ Privacy Policy werden u. a. gesammelt: Google Advertising ID (GAID), App-Verwendung, Interaktion mit Ads, IP-Adressen, sowie „freiwillig bereitgestellte Informationen“ ↩︎

  30. "a confederacy of ’privacy’ dunces": what we found under the hood of an ’anonymous’ chat app used by millions ist eine Analyse der Whisper App, welche einige Details zu Mixpanel sowie MobileAppTracking preis gibt. Nett formuliert: Furthermore they (Whisper) emphasize that THEY do not collect these metrics, and that much is true, they facilitate allowing third party vendors like Mixpanel and MobileAppTracking to do that work for them. (sinngemäß: „Whisper hebt hervor, dass SIE keine dieser Metriken erheben, und das ist wahr: dafür setzen sie Module von Drittanbietern wie Mixpanel und MobileAppTracking ein, die diese Arbeit für sie erledigen.“) Gemäß Lawsuit Fails Over Ridesharing Service’s Disclosures To Its Analytics Service (1/2015), werden bei Verwendung der Mixpanel-API wahrscheinlich die folgenden Daten preisgegeben: gender, age, zip code, metro region, travel plans, and link to the user’s Facebook profile. Mixpanel’s privacy policy gibt an: [we] collect your mobile carrier and the unique device id number […] information about the type of device you use as well as other details you provide us voluntarily – mit anderen Worten: Wir sind unschuldig, der App-Entwickler war’s. Wie üblich. Pöser Purche, zu Poden mit ihm! ↩︎

  31. Laut Mobfox’ Terms of Service werden u. a. folgende Details gesammelt, sofern verfügbar: Geschlecht, Alter, Standort, Gerätemodell und ID, Traffic/Session Information, IP-Adresse. Das Dokument gibt auch an, dass sowohl auf iOS als auch Android-Geräten per Geräteeinstellung ein Opt-Out von interessenbasierter Werbung möglich ist. ↩︎

  32. Gemäß ihrer Privacy Policy sammelt mobilCore u. a. Advertising ID, IP, MAC, OS+Version; ggf. auch Alter und Geschlecht; behauptet, die persönlichen Daten von Nutzern „nicht zu verleihen, verkaufen oder zu teilen“ (außer bei Rechtsfragen) ↩︎

  33. Gemäß Privacy Policy sammelt Pollfish auf Android-Geräten erheblich mehr Details als unter iOS. Erfasste Informationen beinhalten u. a. GAID, installierte Apps, Gerätebeschreibung, Netzwerkanbieter (MCC&MNC), Verbindungstyp, IP-Adresse, OS- und SDK-Version, ob NFC vorhanden/aktiv ist, Systemsprache, Standort. Sofern verfügbar und zugreifbar: IMEI, MAC, AndroidID, Serial, laufende Dienste, RAM/CPU/BT Informationen, verfügbare BLE Geräte. Für ein SDK, mit dem lediglich Umfragen durchgeführt werden sollen, ziemlich viel. ↩︎

  34. PubNative ist ein Mediator (integriert mehrere Werbenetzwerke in einer API) mit Sitz in Berlin. Aus ihrer TOS finden sich für deutsche Datenschutz-Verhältnisse recht spärliche Details zu erhobenen Daten: Laut Sektion 3.3 müssen IP-Adressen und Geräte-IDs erfasst sein, und Sektion 5.4 verpflichtet Publisher, PII nur bei Vorlage entsprechender Berechtigung zu übermitteln. Die Privacy-Policy bezieht sich lediglich auf die Webseite. Ein Blick in den Code der API gibt mehr Informationen preis, etwa OS-Version, Gerätemodell, Display-Auflösung, Android_ID, sowie einen „userIDKey”. ↩︎

  35. scheint sauber. Gemäß der Splunk FAQ, sammelt es selbst keine PII – d. h. der jeweilige Entwickler ist dafür verantwortlich, was übertragen wird (und könnte willentlich oder unwissentlich doch PII eingeschlossen haben). Weiter heißt es, dass lediglich Land, Zeitpunkt, Gerätemodell, SDK-Version, App-Version und Permissions gespeichert würden – sowie dass IMEI, UDID und jegliche andere PII von der Speicherung ausgeschlossen sind. ↩︎

  36. Jetzt Fyber ↩︎

  37. Gemäß der Supersonic Privacy Policy „können“ gesammelte Daten beinhalten: Gerätehersteller/Modell, Netzbetreiber, Verbindungstyp, auf dem Gerät verfügbarer freier Platz „und andere statistische und technische Informationen“. Ebenfalls möglich: Standort, Details zu angezeigten Ads sowie der Benutzer-Interaktion mit selbigen. Wenn der App-Entwickler es so entschieden hat, darüber hinaus: Geschlecht, Datum der Anmeldung (App-Installation?). ↩︎

  38. Tapjoy wird speziell im Zusammenhang mit Performance-Einbußen in Apps erwähnt. Sammelt u. a. AndroidID IMEI, Serial, MAC, SIM Operator/Netzwerk. Siehe auch: Tapjoy’s In-Game Ads Crush Mobile Industry Norms for Branding Metrics, comScore Finds (8/2016) sowie TapJoy – value creator or scam artist? (11/2012) ↩︎

  39. Unity 5 collects data from people playing your game?; Sammelt gemäß Privacy Policy u. a. AndroidID, IP, Gerätehersteller und -modell, OS + version, Sprache, App ID ↩︎

  40. Gemäß der Vungle Privacy Policy wird gesammelt: IP, AndroidID, MAC, „and other unique identifiers“, Aktivitäten in der App, andere installierte Apps, und mehr. Gesammelte Daten werden genutzt für targeted Ads, Performance-Tracking von Ads, um „Publishern und Advertisern Reports zu liefern […] und für weitere Forschungs- und Analyse-Gründe; und um unseren Kunden Marketing- sowie Promotion Informationen zu senen“. Daten werden geteilt – aber außer für „rechtliche Gründe“, ausschließlich in „aggregierter Form“. ↩︎

  41. Ich konnte keine expliziten Informationen darüber finden, welche Daten von Yandex Metrica erfasst werden. Anhand ihrer API Dokumentation lässt sich jedoch u. a. abstrahieren: installierte Apps (standardmäßig deaktiviert), Standort (optional), App-Version, Crash Details. Was ich nicht ermitteln konnte ist, auf welche Identifier oder PII die API zugreift. Überdies hat der Entwickler die Möglichkeit, beliebige Informationen mit einzuschließen, auf welche die App Zugriff hat. ↩︎

  42. Weitere wurden hinzugefügt, während ich zusätzliches Material für meine Studie ausgewertet habe, welches unter den Lese-Empfehlungen aufgeführt ist. ↩︎

  43. Eine persönliche Anmerkung zu „Anti-Virus für Android“: Eine vergleichbare Aktion wäre das Tragen des Helmes eines mittelalterlichen Ritters, um „Russisch Roulette“ zu spielen. Man würde diesen Helm gar nicht benötigen, wenn man sich nicht wissentlich und willentlich der Gefahr aussetzen würde (ein wenig „Gesunder Menschenverstand“ ist effektiver). Tut man es doch, werden einige Kugeln den Helm durchschlagen. Hinzu kommt, dass der Helm Spikes hat – und zwar innen. Man denke nur an die häufigen „false positives“, welche unnötige Panik auslösen (oder das System lahmlegen) – sowie an die zusätzlichen Schwachstellen, die nicht nur durch die oftmals übertriebenen Permission-Anforderungen entstehen, sondern auch durch die mitgebrachten riskanten Module (siehe den vorletzten Punkt bei Erkenntnisse). Bedenkt, wer Euch ständig den Einsatz derartiger Software nahelegt: deren Hersteller. Falls jetzt wieder jemand die Frage aufwirft, was die denn davon hätten, wenn sie ihre Software doch völlig gratis verteilen: Das tun sie gar nicht, Ihr bezahlt dafür. Mit Euren Daten, mit Eurer Privatsphäre. ↩︎

  44. McAfee schreibt To manage accounts so they can log in or authenticate to certain accounts („um Konten zu verwalten, damit sie sich bei selbigen anmelden bzw. authentifizieren können“) – doch dafür lässt die genannte Permission gar nicht verwenden. Wie der Name suggeriert, eignet sie sich lediglich für das Auflisten vorhandener Accounts; für die beschriebene Verwendung wäre zusätzlich USE_CREDENTIALS erforderlich. ↩︎

  45. Legitime Verwendung schließt Standort-bezogene Werbung ein: wer in Toronto lebt, interessiert sich sicher kaum für Sonderangebote in Santiago. Doch für diese Granularität wäre die IP-Adresse völlig ausreichend – maximal vielleicht noch der „netzwerkbezogene Standort“ (coarse location). Es gibt keine Rechtfertigung für ein Werbe- oder Analytics-Modul, auf den exakten (GPS) Standort zuzugreifen. ↩︎

  46. Siehe auch: Underestimated Privacy Implications of the ACCESS_WIFI_STATE Android Permission ↩︎

  47. Siehe auch: Characterising User Targeting For In-App Mobile Ads, eine Studie aus dem Jahr 2013, welche u. a. „targeted advertising“ mit einem kurzen Satz beschreibt: Targeted advertising is based on big data analytics, where user’s personal information is collected and processed for the purposes of profiling and targeting. ↩︎

  48. 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. This behavior is most common in more popular applications, suggesting that the promise of advertising dollars encourages application developers to violate users’ privacy. (Privacy Concerns in Android Advertising Libraries, page 2) While this may be information directly entered by the user into the application, it can also be information from social networking sites or other cloud data sources that the user authorizes the application to access. (page 41) ↩︎

  49. Tracking the Trackers: Towards Understanding the Mobile Advertising and Tracking Ecosystem (PDF, 2016), Seite 1 ↩︎

  50. Siehe auch: Reports Show Aggressive Mobile Apps Want Many Permissions They Don´t Need (11/2012) ↩︎

  51. Einige Firmen bieten „Bug Bounties“ als Belohnung für gefundene Bugs (siehe Wikipedia). Eine größere Liste solcher Programme findet sich u. a. bei Bugcrowd. Aber das ist nicht, was ich hier meine. Ich bezog mich vielmehr auf so etwas wie The Internet Bug Bounty und ähnliche Programme, wo man für Features eine Spende ausloben kann. Erfordert natürlich, dass der Entwickler da auch mitmacht … ↩︎

  52. Detecting Hidden Attacks through the Mobile App-Web Interfaces, Seite 8, Abbildung 4 ↩︎

2017-04-23 (2017-11-10)