Werbung ist in Android-Apps ja nahezu allgegenwärtig. Auch Analytics sind nicht unbedingt eine Seltenheit. Wirklich harmlos sind nur wenige dieser Kandidaten, aber einige sind besonders dreist.
Die folgende Liste ist keinesfalls vollständig; dies sind lediglich Module, die mir besonders aufgefallen sind. Einzelne Apps enthalten teilweise zehn oder mehr solcher Werbe- und Analytics-Module. Welche dies jeweils im Detail sind, findet sich (sofern die App im Playstore verfügbar ist), mittels eines Klicks auf das Appbrain Icon neben dem App-Namen. Siehe auch: Werbemodule und Privacy-Checker in den App-Übersichten.
Entwickler: Die Ausrede „das war mir nicht bewusst“ kann allenfalls bei Modulen gelten, deren Permissions die Implikationen nicht so offensichtlich darstellten. Doch spätestens sobald entsprechende Berechtigungen zum Zugriff auf PII explizit eingebunden werden muss man davon ausgehen, dass Euch die Privatsphäre Eurer Nutzer egal ist. Denjenigen, die auf ihre Privatsphäre wert legen, muss man dann empfehlen, alle Eure Apps zu meiden – da Ihr dort sicherlich ähnliche Maßstäbe angelegt habt. Den Entwicklern, denen die Problematik tatsächlich nicht bewusst ist, lege ich diesen kurzen Artikel wärmstens ans Herz: zwar auf Englisch, aber neutral und gut erklärt – nicht so „aufgebracht“ wie bei mir :)
Besonderes Risiko: So ein Modul hat Zugriff auf alles, auf das auch die App selbst Zugriff hat – denn sie ist Teil derselben. Es findet keine Isolation statt. Darüber hinaus sind diese Module in der Regel „proprietär“, d. h. es lässt sich nicht wirklich prüfen, was sie noch so treiben und welche Daten sie abgreifen: ihr Quellcode ist nicht offen.
Auf den ersten Blick scheint AppsFlyer sensibel zu sein. In ihrem Blog ermutigen sie Entwickler, eine gute Balance zu finden und nichts zu sammeln, was sie nicht benötigen – und weisen dabei explizit sowie detailliert auf die Gefahren bezüglich des Sammelns von PII hin.
Ihre Privacy Policy informiert darüber, welche Daten „zum Beispiel“ gesammelt werden: IP Adresse, UserAgent, Platform, SDK Version, anonyme User ID, Zeitstempel, Entwickler Schlüssel, App Version, Geräte-IDs wie: IDFA (Identifier For Advertisers), Android ID, Google Advertiser ID, Gerätemodell, Hersteller, Betriebssystem-Version, In-App Events und Netzwerkstatus (WiFi/3G).
Bliebe es darauf beschränkt, wäre es fast „normal“. Die Datenweitergabe scheint auf interne Verwendung und das Dashboard des jeweiligen Entwicklers beschränkt (mit Ausnahme von „lawful demand“ – also etwa „Verlangen von Behörden“). Auch seien die Daten zur Sicherheit verschlüsselt gespeichert. Man behält sich jedoch das Recht vor, „aggregierte Daten“ mit Geschäftspartnern zu teilen.
Und jetzt darf man raten, wer das wohl sei. Exodus Privacy hat da eine Liste, die recht lang ist (und selbst dabei nur eine gekürzte Fassung darstellt). Prominente Namen umfassen (sind jedoch nicht beschränkt auf) Google, Facebook, Flurry, Tapjoy, Tencent…
Desweiteren berichtet etwa Tarnkappe: Das AppsFlyer Framework "ermöglicht es den Apps, einen Hintergrund-Benachrichtigungsdienst zu umgehen, mit dem die Ausführung von Schadcode beim Ausschalten eines Telefons eigentlich verhindert werden soll" – was von Cyberganoven genutzt wurde, um Schadsoftware auf den Geräten der Anwender zu installieren.
The Intercept weist darauf hin, dass AppsFlyer Geräte auch mir ihrer ID „fingerprinted“ und Anwender so über Datasets hinweg verfolgt, um die durch Nutzung verschiedener Geräte (sowie wahrscheinlich auch das Zurücksetzen der Werbe-ID) verursachte Fragmentierung zu umgehen – und aufzeichnet, welche Anwender welche Apps installieren.
Von AppsFlyer verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
READ_PHONE_STATE
Der Name suggeriert eine Kombination aus zwei Worten – und so ist dieses Modul auch dazu gedacht, Crashes von Apps zu analysieren. Nur warum sendet es dann auch Informationen, wenn gar nichts abgestützt ist – wie beispielsweise direkt nach dem Start einer App? Und wofür werden dabei Identifier wie Android_ID und GAID benötigt? Das ist zumindest fragwürdig.
Gesammelte Informationen beinhalten u. a.: Developer-Token, API-Key, OS version, client version, an Installation-ID, Android_ID and GAID. The Intercept weist darauf hin, dass Crashlytics Anwender auch geräteübergreifend verknüpft.
Von Crashlytics verlangte Permissions:
INTERNET
Nach Exodus Privacy:
Ein Doppel-Whopper, der sowohl in die Kategorie „Analytics“ als auch „Werbung“ gehört.
Hierzu möchte ich den Sicherheits-Experten Mike Kuketz zitieren:
… fällt mir auf, dass beinahe jede App eine »Facebook-Wanze« integriert hat. Ganz gleich ob man einen Facebook-Account besitzt oder nicht, wird bei jedem Start der App und während der Laufzeit eine Verbindung zu »graph.facebook.com« hergestellt. Dabei wird unter anderem übermittelt:
Google Advertising ID, Ob Ad-Tracking aktiviert / erlaubt ist, Paketname & Versionsnummer der App, Android-Versionsnummer, Gerätemodell, Länderkennung, Zeitzone, Displayauflösung …
Die oben dargestellten Infos genügen Facebook bereits, um festzustellen, dass ihr die jeweilige App […] benutzt. Glaubt ihr nicht? Dann schaut mal hier: Leserfrage: Warum weiß Facebook welche Apps ich nutze?
Und das ist nur die berüchtigte „Spitze des Eisbergs“. So kann Facebook daraus beispielsweise nicht nur ermitteln, dass ihr die jeweilige App benutzt – sondern auch wie oft, zu welchen Zeiten, und mehr …
Bedenkt dabei auch, dass Facebook eine der größten Datenkraken ist. Daher muss man obiges definitiv als tiefen Eingriff in die Privatsphäre werten.
Damit ich nicht alle Datenschutz-Skandale einzeln aufzählen muss (da käme ich mit dem Aktualisieren nicht nach): hier gibt es eine Liste. Ebenfalls lesenswert ist die Zusammenfassung bei MobilSicher: Besonderer Drittanbieter: Facebook.
Dies ist ein (zu) häufig genutztes Modul, da es bequemes „Cloud Processing“ bietet. Die Hauptaufgaben scheinen jedoch Analytics und Werbung zu sein: Firebase Analytics ist eine Kernkomponente, und auch Admob ist Teil von Firebase.
Analytics-Module sollen dem Entwickler helfen zu verstehen, wie seine App im Alltag benutzt wird. Flurry bietet da einen sehr tiefen Einblick – auf Kosten der Privatsphäre. Und über den Rand der jeweiligen App hinaus. Der Anwender wird davon in der Regel nicht informiert.
Erschwerend kommt hinzu, dass Flurry auch im Werbemarkt aktiv ist (Hinweis: Flurry gehört zu Yahoo). Hier besteht also nicht nur theoretisch die Gefahr einer App-übergreifenden „Verfolgung“ sowie Profilbildung. Details lassen sich unter folgenden Links nachlesen:
Von Flurry gesammelte Daten:
Diese beinhalten u. a. alle „screen views“ und Klicks in der App, plus OS-Version, eindeutige Geräte-IDs, Standort. Außerdem wird offensichtlich erfasst, wann immer eine App auf dem Gerät gestartet wird – unabhängig davon, ob diese ebenfalls Flurry enthält. Flurry teilt aggregierte Informationen über das Verhalten der Nutzer (App-übergreifend) mit all seinen Kunden – nicht nur mit denen, von denen der Anwender Apps nutzt und somit implizit „zugestimmt“ hat.
Für ein Opt-Out muss man offensichtlich zunächst einen Account anlegen (die Seite verlangt nach einem Login), und sodann die Geräte-ID dort eintragen. Was letztendlich bedeutet, dass Flurry von nun an das Gerät einer Person zuordnen kann (mit den bei der Registrierung angegebenen Daten). Ich bin nicht sicher, welche Auswirkungen ein Opt-Out hier überhaupt hätte (abgesehen davon, dass man diese Prozedur für jedes Gerät wiederholen müsste – und somit eine weitere Verknüpfung herstellt): Die Anleitung beinhaltet diese Informationen nicht, und einen Account habe ich natürlich nicht erstellt.
Von Flurry verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
WRITE_EXTERNAL_STORAGE
ACCESS_FINE_LOCATION
Auf zahlreichen Webseiten wird es eingesetzt, und in zahlreichen Android-Apps ebenfalls. Erlaubt dem Entwickler tiefe Einblicke, wie seine Anwendung „performt“ – was natürlich eine gute Sache ist. Sammelt aber auch eine Menge persönlicher Daten, was uns weniger zusagt. Letztere ergeben insbesondere bei Android-Usern, welche zumeist ja auch über ein (aktives) Google-Konto verfügen, aussagekräftige Profile. LunaMetrics beschreibt wie Daten gesammelt, aber auch „Advanced Tracking“ und Targeting mit Google Analytics eingesetzt werden.
Google Analytics verwendet beispielsweise „persistente Cookies“, um User quer durch das Web zu verfolgen (für Details, siehe beispielsweise Google Analytics EU Cookie Law). Während sich Cookies auf Browser beziehen, kommen unter Android andere Strategien zum Einsatz. Da das Modul nicht die Permission zum Zugriff auf die Geräte-ID verlangt, dürfte die „Advertizing ID“ verwendet werden (siehe Android Identifiers: Wie Android-Geräte und ihre Nutzer identifiziert werden) – welche man zumindest ab und an zurücksetzen kann. Der Missbrauch von Privacy durch Google Analytics resultierte in der EU schließlich in einem Gerichtsprozess (siehe: Investigations into Consumers Preferences Concerning Privacy: An Initial Step Towards the Development of Modern and Consistent Privacy Protections Around the Globe, 2014, Seite 6).
Wer sich für die Schnüffelei erkenntlich zeigen möchte, mag vielleicht einen Blick auf den Artikel How to Sanction Google for their Aggressive Behavior werfen. Nicht alle Anregungen dort lassen sich von jedem umsetzen – geben aber sicher die eine oder andere Idee.
Ebenfalls von besonderem Interesse ist Google Analytics offensichtlich für
Hacker – die es beispielsweise nutzen können, um auch Firewalls zu überwinden.
Dank der enormen Verbreitung und Beliebtheit dieses Analyse-Tools ist nämlich
die Domain google-analytics.com
für Datentransfers oft freigeschaltet. Details:
Google Analytics als effektives Hilfsmittel für Cybercrime Datenklau.
Von Google Analytics verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
Huq Industries Ltd. mit Sitz in London, UK, bietet sogenannte Footfall-Daten zum Verkauf an. Damit sind Daten gemeint, die abbilden, wie sich Personen in einem bestimmten Gebiet bewegen. Nach eigenen Angaben verfügt Huq über Standortdaten von Mobiltelefonen, die mehrere Jahre in die Vergangenheit reichen. Die Rohdaten dafür erhält die Firma von kooperierenden App-Betreibern, die einen Software-Baustein (SDK) von Huq in ihre App integrieren.
(Quelle: Mobilsicher)
Das Versprechen (oder eher Märchen) der „anonymisierten Daten“ wird dabei keinesfalls verwirklicht, wie Mobilsicher aufzeigt:
Der dänische Fernsehsender TV2 wollte es wissen: Kann man die Standortdaten von Personen, die mit einem Smartphone in der Tasche herumlaufen, einfach so kaufen? Und kann man darin einzelne Personen identifizieren? Die Antwort aus dem eindrücklichen Bericht, der im Juli erschienen ist, lautet: Ja, man kann.
Für 36.000 dänische Kronen (etwa 4.850 Euro) erhielt der Sender 129 Millionen Datensätze, jeweils das zweite Halbjahr 2019 und 2020. Entgegen der Versicherung „Daten, die mit Huq geteilt werden, enthalten keine Informationen, mit deren Hilfe Nutzer*innen namentlich identifiziert werden können und wir liefern keine zusätzlichen Informationen, mit denen Sie identifiziert werden könnten“ war dies durchaus möglich:
Anhand der Huq-Daten konnten die Journalist*innen die Aktivitäten von Jensen exakt nachverfolgen: Wann er verreiste, wo er tankte, in welchen Hotels er übernachtete und wann er sich im Krankenhaus aufhielt. Im Fall von Otto Jensen war das eine sehr unangenehme Überraschung, hatte aber keine schlimmen Konsequenzen. Das ist nicht immer so. Längst werden kommerziell verfügbare Daten auch gezielt gegen einzelne Personen eingesetzt.
Hinzu kommt, dass Huq sämtliche Privacy-Einstellungen, inklusive Opt-Out, einfach ignoriert – wie eine ausführliche Analyse vom Oktober 2021 zeigt: What the Huq?. Es wird einfach weiter gesammelt, bis der Arzt kommt. Um Apps, die mit dieser Bibliothek daher kommen, sollte daher ein großer Bogen gemacht werden.
Neben „anonymen Metadaten“ sammeln Mixpanel's Module fast immer auch eine ganze Reihe persönlicher Daten – beispielsweise Email-Adressen, vollständige Namen, Gesundheitsdetails (etwa in einer Diabetes App. Obwohl mittlerweile behoben, schloss das zwischen 3/2017 und 2/2018 sogar Passwörter ein (siehe auch hier. Schuld daran ist zwar nicht Mixpanel allein, sondern auch die jeweiligen Entwickler in der Art, wie sie die Module einbinden. Wobei sie aber sicher kaum absichtlich Passwörter in die Datensammlung aufgenommen haben; das weist m.E. eher darauf hin, dass das SDK von sich aus zu viel aufgreift. Es ist also schwer zu sagen, was noch alles auf den Servern in den US of A landet, sobald ein Mixpanel Modul eingebunden ist.
Mixpanel's Privacy Policy ist noch schwammiger als die Google's in der Erklärung, welche Daten denn nun gesammelt werden. Es handelt sich hier eher um einen langen Text mit wenigen konreten Details.
Weitere Informationen:
Von MixPanel verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
BLUETOOTH
und natürlich alles, worauf die Host-App selbst Zugriff hat.
Was soll man von einer Firma erwarten, in der sowohl Peter Thiel als auch noch Karl-Theodor zu Guttenberg ihre Finger haben? Gewinnmaximierung. Aber auf keinen Fall privatsphärefreundliches Verhalten. Und so berichtet Netzpolitik am 13.08.2021:
SafeGraph verkauft Standortdaten an fast alle, die sich dafür interessieren. Mit solchen Ortsdaten lassen sich Nutzer:innen de-anonymisieren und Rückschlüsse über deren Leben ziehen. Die Firma, in die unter anderem Peter Thiel und Karl-Theodor zu Guttenberg investiert haben, wurde deswegen von Google gesperrt.
Nun hat Google dies sicher nicht aus reinem Altruismus getan – ist es doch selbst für aggressives Sammeln von Standortdaten bekannt. Motherboard führt dazu aus, dass die von SafeGraph gesammelten und feingranularen Daten quasi jedem verkauft werden, der eine Kreditkarte hat.
… uses the mobile sensors built into smartphones to understand a user’s location and activity. We have trained our algorithms with millions of real-world consumer examples from GPS, accelerometer, gyroscope, barometer, wifi, ambient light, and many other sensors. This provides us with an anonymous, but highly accurate understanding of where, how, and when people interact with physical locations and businesses.
Our sensor-technology is on nearly one hundred apps and millions of mobile devices in the US. Our panel generates more than a terabyte of sensor data every single day and provides a detailed view of more than 100 million anonymous visits a month. We carefully curate our panel to ensure that it is highly reflective of the general population across geography, gender, ethnicity, age, and household income.
(source)
Kurz zusammengefasst: Benutzt alle möglichen im Gerät verbauten Sensoren, um Aktivitäten und Standort des Nutzers zu „verstehen“. Dabei werden täglich mehr als ein Terabyte Daten erfasst – völlig „anonym“ natürlich, einschließlich Geschlecht, ethnische Zugehörigkeit, Alter und Einkommen.
Die Behauptung der (sicheren) Anonymität darf insbesondere bei dieser Detailiertheit angezweifelt werden. Auch wenn es zunächst anonym erscheint, sollte eine Deanonymisierung durch „Quervergleiche“ nicht all zu schwierig sein. Und natürlich wäre ein solcher Detailgrad für Forschungszwecke notwendig – aber selbst dann sollte die Erfassung erst nach ausdrücklichem, informiertem Opt-In des Anwenders erfolgen. Was mitnichten der Fall ist: die Analytic-Firmen forcieren dies nicht sondern überlassen es den jeweiligen Entwicklern, die es oft genug ignorieren (absichtlich oder fahrlässig). Ein verstecktes Opt-Out, wie es auch bei Sense360 existiert, ist verantwortungslos – insbesondere da die meisten Anwender sich nicht einmal der Tatsache bewusst sind, getrackt zu werden.
Das Fettgedruckte nochmals auf Deutsch: „Keines dieser Unternehmen scheint für seine Behauptungen und Praktiken gesetzlich haftbar zu sein; stattdessen gibt es eine Art von Selbstregulierung, die sie zu forcieren behaupten.“
Bei derart brisanten Daten, die hier erfasst werden, muss dieser Tracker hier bei den Schnüffelmodulen erwähnt werden – unabhängig davon, ob mit den erfassten Daten bewusst Schindluder getrieben wird oder nicht.
Laut Exodus Privacy sammelt Tealium sowohl PII (personable identifying information) als auch non-PII von Besuchern seiner Webseite und Nutzern seiner Services (also auch Nutzern von Apps, in denen ihr Modul verbaut ist). Sie schreiben, dass sie diese Daten nutzen und auch an Dritte weitergeben – ganz nach ihren eigenen Wünschen („may make use of, or make such Aggregated Data available to, third parties, in any manner in our sole discretion“). Tealium teilt Daten mit Serviceanbietern, Schwesterunternehmen, Partnern und nicht von Tealium kontrollierten „affiliated businesses“, Abrechnungsfirmen und „Autoritäten“. Daten werden so lange aufgehoben, wie man es für notwendig erachtet („for as long as needed to provide our Services, comply with our legal obligations, resolve disputes, establish legal defenses, conduct audits, pursue legitimate business purposes, and enforce our agreements“) – was durchaus als „dauerhaft“ interpretiert werden kann (böse Zungen könnten jetzt fragen, warum „provide our Services“ und „pursue legitimate business purposes“ getrennt genannt werden – wohl weil der Nutzer wieder einmal nicht explizit nach seinem Einverständnis gefragt wird).
Eine Studie (4/2018) fand heraus, dass Tealium Nutzerdaten von Facebook abgriff – auch wenn ihr CMO dies bestritt.
Um ehrlich zu sein fand ich auch einige Seiten, die Tealium's „enhanced privacy“ anpriesen – aber wer glaubt so etwas, wenn selbige Seiten entweder von der Werbe- und Trackingindustrie selbst betrieben werden, oder aber mit zahlreichen Trackern verseucht sind? Ein solcher Artikel behauptete sogar, dass Tealium gar keine Daten sammeln würde. Das behauptet nicht einmal Tealium selbst.
Die zur Alibaba Gruppe gehörende leading mobile app analytical platform in China ist auch als Flurry of China sowie rival of Tapjoy bekannt.
I couldn’t exactly figure out which data it collects, but I guess that updates a remote “application log” via the company’s API at
alog.umeng.co/app_log
.In its headers the request contained a
X-Umeng-Sdk
field with operating system version, app version and smartphone model.
(„Ich konnte nicht genau herausfinden, welche Daten es sammelt – jedoch denke
ich, es aktualisiert ein remote “application log” über die API der Firma unter
alog.umeng.co/app_log
. In den (HTTP) Headern fand sich u. a. ein
X-Umeng-Sdk
Feld mit der Betriebssystem-Version, App-Version und dem Smartphone-Modell“.)
(Manuel D'Orso: Some MiFit app analysis)
There is also an entry in VirusTotal on this domain as a malicious URL. See: h–ps://www.virustotal.com/en/domain/www.umeng.com/information/ Thus we can confirm that the app posts encrypted personal data to a malicious url.
(„Bei VirusTotal findet sich ein Eintrag für diese Domain als „bösartige URL“, siehe h–ps://www.virustotal.com/en/domain/www.umeng.com/information/. Somit können wir bestätigen, dass die App persönliche Daten an eine „bösartige URL" übermittelt.“)
(Analysis: Android SMS Malware (PhotoViewer))
Nebenbei stuft Symantec dieses Modul als „hoch riskant“ ein.
Obwohl Umeng in erster Linie ein mobiler Analytics Anbieter ist, wird es mehr und mehr komplex. Neben dem Analytics-Sektor bietet es mittlerweile auch Statistiken, Reports, SingleSignOn, ein soziales Netzwerk, Push Notifications, Werbung und weitere Funktionalitäten – und scheint so vielmehr das „Facebook of China“ zu werden.
Von Umeng verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
READ_PHONE_STATE
AdMarvel gehört Opera. Eine Cornelly Untersuchung fand zu diesem Ad-Modul u. a.:
We found that the AdMarvel AdSDK satisfies the WebView-related conditions even on post-4.1 Android, i.e., it allows files loaded by ads to access any file on the device. This enables any ad shown in an AdMarvel-supported app to steal local files from external storage.
(„Wir fanden, dass das AdMarvel AdSDK die WebView-bezogenen Voraussetzungen sogar auf Android-Version nach 4.1 erfüllt – d. h. es erlaubt den Ads Zugriff auf jede beliebige Datei auf dem Gerät (auf die die Host-App Zugriff hat). Dies erlaubt jedem Ad, das in einer mit AdMarvel versehenen App angezeigt wird, lokale Dateien vom externen Speichersystem (interne und externe SD-Karte) zu stehlen.“)
Bei Apps, welche mit sensiblen Inhalten umgehen (Banking, Gesundheit etc.) kann dies vertrauliche Informationen der App selbst beinhalten, die man keinem Drittanbieter zur Verfügung stellen möchte. Beispiele dafür finden sich in der gerade zitierten Cornelly Studie (ab Seite 9).
Dieses Ad-Modul setzt Anwender also bewusst Angriffen bösartiger Werbung aus. In aktuellen Versionen der AdMob und AdMarvel SDKs ist diese Lücke bereits geschlossen (d. h. Apps, die 2017 oder später kompiliert wurden, sollten nicht mehr betroffen sein) – dürfte aber bei Airpush und MoPub nach wie vor bestehen.
von AdMarvel verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
WRITE_EXTERNAL_STORAGE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
WRITE_CALENDAR
RECORD_AUDIO
2013 lehnte ein Gericht eine Klage im Google Mobile App Spyware Case ab, aufgrund mangelnden Schadens: Die Kläger konnten „nicht angemessen darlegen, dass die Aktionen des Unternehmens ihnen Schaden zugefügt hätten“. Also nicht, weil der vorgeworfene Tatbestand nicht nachgewiesen werden konnte – sondern weil das Gericht der Meinung war, es sei dadurch ja kein Schaden entstanden.
The plaintiffs alleged that Google and mobile advertising companies AdMob Inc. and AdWhirl Inc. used code hidden in mobile apps to secretly collect their names, gender, ZIP codes, app activity information, geolocation data, and the universally unique device identifiers of their phones. They also alleged that Google misrepresented that their PII would be anonymized.
(„Die Kläger behaupteten, dass Google und die mobilen Werbe-Firmen AdMob sowie AdWhirl in Apps versteckten Code nutzten, um heimlich ihre Namen, Geschlecht, Postleitzahlen, App Aktivitäten, Standortdaten sowie die universell eindeutigen Geräte-Identifikatoren ihrer Phones zu sammeln. Weiterhin behaupteten sie, dass Google falsche Angaben hinsichtlich der Anonymisierung ihrer PII machte.“)
Was, wie das Gericht befand, heutzutage völlig normal sei, gemäß gewisser „sozialer Normen“:
The court said the plaintiffs' allegations that the defendants violated their constitutional right to privacy “are not sufficient to allege that the Google Defendants' conduct constitutes an egregious breach of social norms.“
(„Das Gericht befand, die Behauptungen der Kläger bezüglich der Verletzung ihrer verfassungsmäßigen Rechte auf Privatsphäre seitens der Beklagten seien ´nicht ausreichend zu behaupten, dass Google's Aktionen einen unerhörten Bruch sozialer Normen darstelle´.“)
Zwei Jahre zuvor war Google bereits zum selben Thema unter Beschuss: Android Faces Lawsuit For Knowing Too Much About The Users (6/2011; Admob):
Google’s Android smartphone has become a Big Brother and knows more about the users, than their family and friends does. A federal class-action lawsuit filed by a Charleston attorney, has alleged Google and Android phone apps of keeping track of user’s personal information and selling them to advertising companies. According to the lawsuit, Android apps keep track of customer’s personal information ranging from his physical location, to his sexual orientation and monthly income.
(„Google’s Android Smartphone ist zu einem Big Brother geworden und weiß mehr über seine Anwender, als es ihre Familien und Freunde tun. In einer Sammelklage vor einem Bundesgericht, eingebracht von einem Anwalt aus Charleston, beschuldigt Google und Android Phone Apps, persönliche Informationen über seine Nutzer zu sammeln – von ihrem Standort über seine sexuelle Ausrichtung bis hin zum monatlichen Einkommen.“)
Teilt Daten mit anderen Ad-Companies wie Mobfox, Smaato und weiteren, siehe Google Says It Doesn’t 'Sell' Your Data. Here’s How the Company Shares, Monetizes, and Exploits It. (4/2020).
Für ein paar Einsichten in die Funktionalität siehe auch Characterising User Targeting For In-App Mobile Ads (PDF, 2013).
Von AdMob verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
Wie Leadbolt und AirPush, verwendet AdsMogo „package name obfuscation“ und generiert zufällige Package Namen für unterschiedliche Entwickler, um eine Entdeckung zu vermeiden (siehe hier. In Malware-Apps kommt es etwa doppelt so häufig vor wie in legitimen Apps. So schreibt beispielsweise McAfee:
We found that adsmogo and leadbolt are two ad libraries that we found seldom appear without malware.
(„Wir fanden, dass AdsMogo und LeadBolt zwei Bibliotheken sind, die selten ohne Malware auftauchen.“)
AdsMogo scheint es auch anderen Bibliotheken zu erlauben, sich zu „verstecken“ („stealthily hide themselves“), wie z. B. hier berichtet wird. Derartige Apps nehmen dann im Geheimen Audio und Video auf, überwachen und uploaden Standortdaten, extrahieren Daten, die sie zu „remote servers“ hochladen, und mehr.
Airpush war besonders dreist: der durchschnittliche Android-Anwender konnte in der Regel nicht ohne weiteres feststellen, welche App die Werbung auslöste, die plötzlich an unerwarteten Stellen auftauchte – etwa getarnt als Benachrichtigung, oder als App-Icon auf dem Homescreen. Um den Spuk wieder los zu werden, muss man sich explizit von diesem „Dienst“ abmelden: entweder durch Installation einer entsprechenden „Opt-Out-App“, oder durch Eingabe der IDs der betroffenen Geräte auf der entsprechenden Website.
Die vom Werbemodul angeforderten Berechtigungen legen nahe, dass Airpush die Geräte-IDs ausliest (natürlich, um dem Opt-Out Wunsch des Anwenders nachkommen zu können), aber auch den aktuellen Standort nutzt. Letzteres sicher nur, um auch relevante, auf den Standort bezogene Werbung auszuliefern – wobei der Standort dafür sehr genau sein muss (oder warum braucht es den Zugriff auf GPS?). Gemäß dieser Analyse sended Airpush u. a. die AndroidID, Telefonnummer, den Standort und den SIM-Operator an seine Server.
Siehe auch bei AdMarvel in Bezug auf „erlaubt bösartigen Ads das Stehlen von Daten“.
Weiterführende Links:
Von Airpush verlangte/benutzte Permissions:
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
INTERNET
READ_PHONE_STATE
WRITE_EXTERNAL_STORAGE
Avocarrot ist ein Mediator. Gemäß ihrer Privacy Policy sammeln sie:
Informationen über das Gerät, wie Typ und Modell, Hersteller, Betriebssystem, Netzbetreiber, IP Adresse, Browser bzw. App inkl. Version, Geräte-Ids (z. B. iOS Identifier for Advertising (IDFA), Android Advertising ID, oder eindeutige Geräte-Id (IMEI).
Darüber hinaus: Log Information, einschließlich der benutzten App oder besuchten Website, Start- und Endzeitpunkt der Sitzung, Zeitzone, Sprache, Typ der Netzwerk-Verbindung, Standort (GPS oder netzbasiert), sofern für die App/Website verfügbar.
Daten werden geteilt mit Advertisern und Kunden. Gespeichert und verarbeitet werden sie auf Amazon Servern. Ein Blick auf die Server von Avocarrot selbst offenbart: Sie erhalten lediglich ein F-Rating (8/2018) aufgrund von Sicherheitsmängeln.
Weitere Lektüre: Mobile Applications and Access to Private Data 11/2017
Von Avocarrot verlangte Permissions:
INTERNET
[ACCESS_NETWORK_PERMISSIONS]
Zusätzlich verwendet Avocarrot auch den Standort, wenn die Host-App über die entsprechende Berechtigung verfügt (siehe oben).
Der Fireye Report security reimagined nennt Burstly (welches mittlerweile zu Apple gehört) eines der aggressivsten Werbe-Module. Nach dem Report sammelt Burstly u. a. Alter, Zahl der Kinder, Ausbildung, ethnische Zugehörigkeit, Geschlecht, Größe, Einkommen, Interessen, Standort, Beziehungsstatus, sexuelle Orientierung, politische Einstellung, Postleitzahl.
Den geforderten Permissions nach zu urteilen, dürfte das jedoch nur ein Bruchteil sein – hinzu kommen zumindest noch eindeutige Geräte-IDs und mehr. Symantec bezeichnet es als „potentially unwanted app“, und füllt die Lücken mit IMEI, Kernel-Version, Gerätehersteller und -Modell, sowie Netzwerkbetreiber.
Von Burstly verlangte Permissions:
ACCESS_WIFI_STATE
ACCESS_NETWORK_STATE
INTERNET
READ_PHONE_STATE
WRITE_EXTERNAL_STORAGE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
CALL_PHONE
CallDorado implementiert als „Lock-Feature“ CallerID, um in die entsprechende Anzeige Werbung einzubauen. Agiert als Mediator für Admob, Facebook, Smaato, inMobi, MoPub, Flurry … Gemäß der so genannten „privacy policy“ sammelt CallDorado u. a. IP, DeviceID, IMEI, MAC, Telefonnummern ein- und ausgehender Anrufe (inkl. Anruf-Statistiken), Standort, Kontaktlisten, Interaktionen der Anwender mit den Ads. Die gesammelten Daten werden mit „sub-suppliers“ (d. h. den anderen Werbe-Netzwerken) – und auch weiteren, nicht genauer bestimmten „third parties“ geteilt. Der Anwender hat dem automatisch durch die „Nutzung der Dienste“ zugestimmt.
Von CallDorado verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
READ_PHONE_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
WRITE_EXTERNAL_STORAGE
RECEIVE_BOOT_COMPLETED
READ_CONTACTS
WRITE_CONTACTS
PROCESS_OUTGOING_CALLS
SYSTEM_ALERT_WINDOW
Zitiert und frei übersetzt aus der Chartboost Privacy Policy:
Wenn ein Ad über unsere Online Services ausgeliefert wird, können wir die folgenden Daten vom Gerät des Anwenders auslesen: bundle ID, Sprach-ID, Version des Betriebssystems, Gerätemodell, SDK-Version, eindeutige Geräte-ID, IP-Adresse und MAC-Adresse. Greift der Anwender auf ein Video-Ad zu, sammeln wir außerdem: Start/Boot-Up Informationen, wie viel vom Video abgespielt wurde, auf dem Gerät für unsere Videos verwendeter Cache-Speicher, welche Videos dort abgelegt sind, sowie das komplette Abspiel-Ereignis. Wir identifizieren das Gerät über Chartboost's interne Geräte-ID, welche mit der Apple IDFA bzw. Android-ID / GAID des Anwenders verknüpft ist.
[…] Wir erhalten fernerhin Informationen über Anwender von anderen Advertisern bzw. Werbe-Firmen, wie etwa Geräte-IDs, IP-Adressen, Details aus Cookies sowie Nutzungsdaten. Diese Informationen kombinieren wir zusätzlich mit weiteren demographischen, geografischen und interessenbasierten Daten, ebenfalls von weiteren Drittanbietern.
[…] Die so gesammelte und mit anderen Drittanbietern geteilten Daten werden unter anderem genutzt für industrielle Analysen, zum Tracken von Ad Conversions, oder zum Erstellen demografischer Profile. […] Schließlich können wir auch aggregierte bzw. anonymisierte Daten über unsere Endanwender mit Werbefirmen, Publishern, Geschäftspartnern, Sponsoren und anderen Drittanbietern teilen.
Von Chartboost verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
WRITE_EXTERNAL_STORAGE
ACCESS_WIFI_STATE
READ_PHONE_STATE
Zitiert aus Wikipedia:
DoubleClick wird oft in Verbindung mit Spyware gebracht, da HTTP-Cookies im Browser so gesetzt sind, dass eine Rückverfolgung des Benutzers von Webseite zu Webseite möglich ist. Eine Aufzeichnung darüber, welche Werbung angezeigt und angeklickt wird, ist ebenso möglich.
[…] Allein die Speicherung und Analyse von personenbezogenen Suchanfragen erlaubt weitreichende Möglichkeiten für die Erstellung von individuellen Nutzerprofilen. […] Das Unternehmen erklärt, dass „die gespeicherten persönlichen Daten nur zu dem Zweck benutzt werden, zu dem sie gefragt sind“, was praktisch nichts anderes heißt, als dass die Daten uneingeschränkt für jeden erdenklichen Zweck verwendet werden können. Einer IT-Consulting-Gruppe aus San Francisco zufolge bietet DoubleClick eine Opt-Out-Seite an, die sich auf Cookies auswirkt, allerdings nicht auf die Rückverfolgung per IP-Adresse.
DoubleClick sowie einige weitere Werbefirmen wurde auch dafür bekannt, die Privatsphäre-Einstellungen von Nutzern zu ignorieren – wie etwa MediaPost in einem Artikel in 8/2016 berichtet.
Siehe auch:
Von DoubleClick benötigte Permissions:
INTERNET
ACCESS_NETWORK_STATE
inMobi hat bereits Erfahrung mit Verletzungen der Privatsphäre – seien es nervige Popup-Ads, oder das Tracking des Standorts. Definitiv die Finger lassen sollte man von Apps, welche inMobi einsetzen und Zugriff auf Mikrofon und/oder Kalender haben. Ein wenig Hintergrund:
Gemäß A Measurement Study of Tracking in Paid Mobile Applications ist inMobi eines der beiden Ad-Netzwerke, welche die meisten User-Daten sammeln. Außerdem berichtet Underestimated Privacy Implications of the ACCESS_WIFI_STATE Android Permission (2014, PDF), dass inMobi Daten zu verfügbaren WLAN-Hotspots sammelt und nach Hause schickt.
Außerdem hebt Is Smartphone App Privacy Groundhog Day for Regulators? hervor (frei übersetzt):
mOcean und Inmobi waren in der Lage, Anrufe ohne Wissen des Anwedners zu starten. Inmobi konnte ebenso SMS verschicken, ohne den Anwender zu benachrichtigen.
Investigating User Privacy in Android Ad Libraries schreibt weiterhin (frei übersetzt):
Die Bibliotheken von mOcean und Inmobi enthalten Funktionalität, um Anrufe zu starten sowie Kalender-Einträge hinzuzufügen – ohne Benutzer-Interaktion.
Von inMobi verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
ACCESS_WIFI_STATE
CHANGE_WIFI_STATE
READ_LOGS
VIBRATE
RECORD_AUDIO
WRITE_EXTERNAL_STORAGE
ACTIVITY_RECOGNITION
READ_CALENDAR
WRITE_CALENDAR
Wie bereits Flurry, ist auch dieses Modul bekannt für Werbung außerhalb der Host-App – wie z. B. Popups, Anzeigen im Nachrichtenbereich, Icons auf dem Homescreen. Zur gleichen Zeit tut der Chef der Firma kund, „seine Firma nimmt die Privatsphäre wichtig“ (sieht danach aus, als fehle da ein Komma: „nimmt die Privatsphäre, wichtig“, also „weg, aufpassen“). Weiterhin bestätigt Hyphenet (Hervorhebungen von mir):
AirPush and Leadbolt have gained quite a poor reputation for their “aggressive marketing practices,” which include placing ads to the notification/status bar, placing ad-enabled search icons on your mobile desk, and collecting user information.
Zu gut Deutsch:
Airpush und Leadbolt haben sich mit ihren “aggressiven Vermarktungs-Praktiken“ eine wirklich schlechte Reputation erworben. Diese beinhalten das Platzieren von Ads im Nachrichtenbereich, der Statusbar, als Icons auf dem Homescreen, und das Sammeln von Benutzerdaten.
Was meinen Verdacht bestätigt. McAfee merkt an:
We found that Adsmogo and LeadBolt are two ad libraries that we found seldom appear without malware.
Übersetzt:
Wir fanden, dass Adsmogo und LeadBolt zwei Werbe-Bibliotheken sind, die selten ohne Malware auftreten.
Auch wenn es Ausnahmen gibt, ist dies ein besonderer Grund zur Vorsicht. LeadBolt is the worst offender when it comes to invading your privacy. Im selben Report: 50% of the time, LeadBolt is associated with Malware.
Von LeadBolt verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
Zusätzlich zu den über diese Permissions verfügbaren Informationen ermuntert LeadBolt Entwickler, weitere Daten ihrer Nutzer zu übermitteln – wie etwa Alter und Geschlecht. Ob darüber hinaus zusätzliche, der „Host-App“ zugängliche Informationen übertragen werden, ist mir nicht bekannt – steht aber zu vermuten.
LiveRail gehörte zu Facebook, und konzentrierte sich auf Video Ads. Q3 2014 Internet & Digital Media Market Snapshot stellt fest: LiveRail kombiniert Facebooks Datensammlung mit seiner Targeting-Technologie.
Wie eine Study on future trends and business models in communication services hervorhebt, scheint Facebook hier zu kombinieren:
We do note that Facebook uses three types of advertising platforms: LiveRail specialises in video ads, Atlas focuses on cross-device advertising, and Audience Network allows advertisers to run Facebook ads on other mobile apps.
Gemäß dieses Berichtes wurde LiveRail 2016 geschlossen. Auch wenn es in einigen Artikeln bis 11/2017 noch lebendig erscheint, lassen sich die entsprechenden Hostnamen nicht mehr auflösen.
Data Mining Mobile Devices, page 71:
Millenia Media´s MYDAS technology engine leverages unrefined user data and aggregates it into actionable audience profiles based on key behavior, location and content trends. These profiles, when coupled with multiple layers of mobiles data, create specific and targetable audiences for advertisers via app.
Übersetzt: Millenia Media´s „MYDAS technology engine“ verwendet User-Rohdaten, und aggregiert sie zu handelbaren Profilen. Diese basieren auf Schlüssel-Verhalten, Standort und Inhalten sowie deren Trends. Verbindet man diese Profile mit verschiedenen Layern mobiler Daten, erhält man spezifische, vermarktbare Zielgruppen für die App-Werbe-Industrie.
Gemäß A Measurement Study of Tracking in Paid Mobile Applications erfasst Millennia Media u. a. den Standort, die AndroidID, IMEI, OS-Details, Netzwerk-Verbindungs-Informationen sowie Details zum verwendeten Mobilfunkanbieter.
Von Millennia Media verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
ACCESS_FINE_LOCATION
WRITE_EXTERNAL_STORAGE
NFC
BLUETOOTH
WRITE_CALENDAR
VIBRATE
RECORD_AUDIO
MWR Security revealed that a one-off app it built sent text messages from the user's phone, their call log and contacts' details to an advertising company called MobClix, which has not responded to comment requests.
(Android app permissions silently duplicated to advertisers)
Also kurz: SMS, Anruflisten und Kontakt-Details werden mal eben abgegriffen, sofern die Host-App darauf Zugriff hat. Das Addon selbst verlangt laut Anleitung keine derartigen Permissions. Von Mobclix wurde darüber hinaus berichtet, dass es laufenden Ads Zugriff auf Smartphone Informationen/APIs gibt.
Mobclix wurde ca. 2014 in Axonix überführt.
Von Mobclix verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
MobFox gehört zu Matomy, und hat auch mAdserver übernommen. MobFox's Terms of Service lässt sich entnehmen, was gesammelt wird. Frei übersetzt:
Matomy sammelt persönliche Informationen von mobilen Applikationen und Geräten, je nach Berechtigung, wie Geschlecht, Alter, Standort und andere Attribute. Weitere gesammelte Daten umfassen Geräte-Attribute (wie Modell, Hersteller, Geräte-ID) und Traffic/Session Informationen, einschließlich Sessionlänge, IP-Adresse und weitere Aktivitäts-Informationen. Matomy kann zusätzliche statistische Analysis-driven Data nutzen, wie etwa Altersgruppe, Interessen-Bereiche und den generellen Standort.
Matomy verwendet diese Informationen, um Trends zu analysieren, die Benutzer-Aktivitäten zu verstehen und demografische Informationen zu sammeln, damit es seine interessenbasierten Ad-Services entwickeln und Daten mit seinen Geschäftspartnern teilen kann.
Matomy speichert diese Informationen in Übereinstimmung mit Matomy’s rechtmäßigen Geschäftszwecken für die Informationsverarbeitung. Anschließend werden die Daten entfernt, für eingeschränkte rechtmäßige Interessen archiviert, oder anonymisiert. Informationen, die sich nicht für Identifikation nutzen lassen, können ohne zeitliche oder Nutzungsbeschränkungen aufgehoben werden.
Zwar bietet MobFox ein Opt-Out und spricht vom „Anonymisieren“ personenbezogener Daten – doch wie immer wäre es aus Sicht der Privatsphäre eher wünschenswert, PII gar nicht erst zu erfassen und ein Opt-In zu verwenden.
Von MobFox geforderte Permissions:
INTERNET
ACCESS_NETWORK_STATE
MobileAppScrutinator führt aus, dass mobileCore die AndroidID, IMEI and WiFi-MAC erfasst und im Klartext an ihre Server schickt. mobileCore's Privacy Policy beschreibt, dass gesammelte Daten außerdem umfassen (frei übersetzt):
SDK-Version, Geräte-Informationen, Android Advertising ID, IP-Adresse, OS Details, MAC-Adresse sowie weitere statistische und technische Informationen […], installierte Apps, Alter und Geschlecht des Anwenders
Weiter führt sie aus:
Wir können diese Informationen mit Drittanbietern teilen, mit denen wir eine strategische Partnerschaft haben, wie z. B. Advertisern. Wir nutzen derzeit die Server von Amazon Web Services, Inc., um die Informationen zu verarbeiten.
Es ist davon die Rede, dass die Informationen „password-protected/encrypted“ gespeichert werden – und der Anwender die Löschung der eigenen Daten verlangen kann, was dann innerhalb von 30 Tagen ausgeführt werden soll.
Von mobileCore verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
READ_PHONE_STATE
WRITE_EXTERNAL_STORAGE
WAKE_LOCK
Dieses Werbe-Netzwerk gehört seit 2015 Cheetah Mobile – schon das allein macht es suspekt. Die zuständige RTB Privacy gibt an, dass u. a. Namen, Adressen, Email-Adressen, Telefonnummern, auf dem Gerät gespeicherte Informationen, sowie weitere übermittelte Daten gesammelt werden – behauptet aber auch, personenbezogene Daten nicht weiterzugeben (Wer's glaubt).
As with other mobile optimising businesses like Onavo (which Facebook acquired), products like Clean Master, CM Browser (a light internet browser) and Battery Doctor (a smartphone battery life extending app for iOS and Android) give Cheetah a large trove of data about mobile usage.
Matching this up with MobPartner’s business will give the latter product far greater reach and potential. While Cheetah has already been trying to do this, MobPartner will provide a more effective front end suite of services to utilize this data.
(Cheetah Mobile Buys MobPartner For M As Ad Tech Consolidates, 03/2015)
(Grob übersetzt: „Vergleichbar mit anderen Unternehmen in der mobilen Optimierung, wie etwa Onavo (von Facebook übernommen), liefern Produkte wie Clean Master, CM Browser oder Battery Doctor Cheetah einen großen Fundus an Daten zu mobiler Nutzung. Gepaart mit dem Geschäft von MobPartner gibt dies letzterem Produkt große Reichweite und Potential. Obwohl Cheeta dies bereits zuvor versucht hat, erhält es durch MobPartner ein weitaus effektiveres Front-End von Diensten, um diese Daten auszunutzen.“)
Cheetah Mobile spielt nicht fair. Viele ihrer Apps sind Bogus. So behauptet Cheetah beispielsweise, ihre App Clean Master würde die Performance von Smartphones drastisch verbessern. Den Beweis oder auch nur eine plausible Erklärung blieben sie jedoch in zwei Interviews schuldig. Auf der anderen Seite sind sie schnell damit, die Konkurrenz zu diskreditieren:
Apus said in July it was taking legal action in China against the company for unfair competition. It claimed that two of Cheetah Mobile's utility apps were misleading users into uninstalling the Apus launcher app by portraying it as more resource-consuming and battery draining than it in fact is. […]
(Chinese app developer Cheetah Mobile throws down gauntlet to mobile advertising platforms, 8/2015)
(Wieder kurz übersetzt: „Apus sagte im Juli, aufgrund unfairen Wettbewerbs in China legale Aktionen gegen die Firma zu unternehmen. Sie behaupten, dass zwei von Cheetah's Utility-Apps Anwender dazu verleiteten, Apus Launcher zu deinstallieren – indem Apus ein höherer Ressourcen-Verbrauch unterstellt wurde, als es den Tatsachen entsprach.“)
Es sollte also niemand faire Ads erwarten – oder gar faire Behandlung für die gesammelten Daten.
Von MobPartner verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
READ_PHONE_STATE
WRITE_EXTERNAL_STORAGE
Is Smartphone App Privacy Groundhog Day for Regulators? hebt hervor (frei übersetzt):
mOcean und Inmobi waren in der Lage, Anrufe ohne Wissen des Anwedners zu starten. Inmobi konnte ebenso SMS verschicken, ohne den Anwender zu benachrichtigen.
Investigating User Privacy in Android Ad Libraries schreibt weiterhin (frei übersetzt):
Die Bibliotheken von mOcean und Inmobi enthalten Funktionalität, um Anrufe zu starten sowie Kalender-Einträge hinzuzufügen – ohne Benutzer-Interaktion. mOcean kann ferner auf die gleiche Weise auch SMS versenden.
Aus dem mOcean Ad-Modul waren wir in der Lage, ohne jegliche Benutzer-Interaktion einen Anruf an eine beliebige Nummer zu initiieren. Ein Angreifer könnte dies nutzen, um Anrufe bei teuren 0900er Rufnummern zu tätigen. Ebenso konnten wir den Standort des Gerätes ermitteln, und die EMail-Anwendung mit vorbelegtem Empfänger, Betreff sowie Nachrichtentext zu öffnen.
Von mOcean verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
READ_PHONE_STATE
CAMERA
CALL_PHONE
WRITE_EXTERNAL_STORAGE
READ_CALENDAR
WRITE_CALENDAR
SEND_SMS
READ_LOGS
ACCESS_FINE_LOCATION
Moolah gehört offensichtlich in die gleiche Kategorie wie Airpush und LeadBolt, wie beispielsweise Mobile ads can hijack your phone and steal your contacts anmerkt (frei übersetzt):
Weitere Werbenetzwerke, welche Lookout als aggressiv einstuft, umfassen Moolah Media und Leadbolt.
Attack of the covert commercials ergänzt dies mit den entsprechenden Details aus gleicher Quelle:
[…] Moolah Media (die auf unsere Anfrage nicht einmal reagierten) und LeadBolt verwenden Strategien, die wir als “aggressive” erachten. Das beinhaltet die Anzeige von Ads außerhalb der entsprechenden App (beispielsweise in der Notification Bar), das Verändern von Desktop- und Browsereinstellungen sodass, unter anderem, neue Icons auftauchen und Werbung anzeigen, wenn man sie antippt – sowie Zugriff auf persönliche Daten ohne entsprechende Warnung.
Von Moolah verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
WRITE_EXTERNAL_STORAGE
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
READ_CALENDAR
WRITE_CALENDAR
MoPub ist ein „Mediator“, d. h. es fungiert als Gateway zu mehreren anderen Werbenetzwerken. Wie beispielsweise RevMob, welches bereits auf dieser Seite erwähnt wurde. MoPub gehört Twitter – und interagiert natürlich auch kräftig mit dem Dienst. Es wird sicherlich niemanden überraschen, dabei geräteübergreifend verfolgt („getrackt“) zu werden. Wie das funktioniert? Einige der folgenden Links beschreiben dies:
Welche Daten MoPub sammelt, zeigt das erst genannte Dokument u. a. anhand einer Beispiel-URL. Um es klarer erkennbar zu machen, habe ich die URL aufgesplittet:
http://ads.mopub.com/m/ad?v=8
: Unverschlüsselte Übertragung (http://
)
&udid=ifa:90E*****CC9-4**C-B7B8-6D24*****B54
: Device ID (vom Autoren sanitized)
&id=agltb3B1Yi1pbmNyDAsSBFNpdGUYorkhDA&nv=1.17.2.0
:
&q=m_gender:m,m_age:21
: Geschlecht und Alter
&o=p&sc=2.0&z=0400
&ll=40.69770885046903,-73.99321115040379
: Standort (Longitude und Latitude)
&lla=65&mr=1&ct=2&av=2.2.2
&cn=Verizon&iso=us&mnc=480&mcc=311
: Daten zum Mobilfunk-Provider
&dn=iPhone7%2C2
: Modell des verwendeten Geräts
Siehe auch bei AdMarvel in Bezug auf „erlaubt bösartigen Ads das Stehlen von Daten“. Erschwerend hinzu kommt, dass MoPub zur Übertragung auch häufig auf unsichere Verbindungen zurückgreift.
Von MoPub verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
WRITE_EXTERNAL_STORAGE
RevMob wurde dabei erwischt, PII (Personal Identifying Information) ohne die explizite Einwilligung des Anwenders „abzufischen“. Dummerweise von Google selbst – sodass Apps, welche dieses Werbemodul nutzten, kurzerhand aus dem Play Store flogen. Was wahrscheinlich auch der einzige Grund war, warum diese wohl doch zu offensichtliche „Fishing Aktion“ recht schnell aus dem Modul entfernt wurde.
Um auf der Website von RevMob relevante Informationen zu finden, muss man sich dort zunächst mit seinen persönlichen Daten registrieren. Das gilt auch für Details dazu, wie man das Modul in die eigene App einbindet, und welche Berechtigungen es benötigt. Aus diesem Grund hat jemand zumindest diese Kernspezifikationen in einem Gist zur Verfügung gestellt.
Da das Modul u. a. die Berechtigung READ_PHONE_STATE
verlangt darf man davon ausgehen, dass ein Zugriff auf die Geräte-IDs (IMEI,
Serial etc.) stattfindet. Und so bestätigt diese Analyse, dass AndroidID, IMEI und
Serial an die Server der Firma geschickt werden.
Weiterführende Links:
Von RevMob verlangte/benutzte Permissions:
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
INTERNET
READ_PHONE_STATE
Der Name ist Programm: Diese AdWare ersetzt das Freizeichen durch Audi-Ads. Ein Softpedia Artikel beschreibt (frei übersetzt):
Außerdem sollten sich diese Ads beenden, sobald die angerufene Person antwortet – doch das passiert nicht immer. In einigen Fällen lief die Wiedergabe während des gesamten Telefonats, was eine Kommunikation nahezu unmöglich macht.
Lästig ist auch, dass die „Post-Call“ Werbung für über eine Minute den Bildschirm blockiert, was „schnelle Anrufe“ erschwert.
Obwohl sellAring behauptet, keinerlei Benutzerinformationen zu sammeln, sieht die Realität anders aus: Untersuchungen ergaben, dass u. a. IMEI und MEID gesammelt wurden. Zu guter Letzt verbrauchen mit sellAring versehene Android Apps auch noch jede Menge Resourcen.
Die genaue Liste verlangter Permissions konnte ich nicht herausfinden (lediglich
CALL_PHONE
und PROCESS_OUTGOING_CALLS
wurden in diversen Artikeln erwähnt), doch ein Post bei XDA
lässt hier schlimmes erahnen:
Sellaring is annoying for users and requieres alot of permission which leads to the thing that some users title apps with sellaring as spyware / malware.
Zwar konnte ich keine „Skandal-Meldungen“ im Netz finden, jedoch sprechen die verlangten Permissions für sich:
Von Smaato verlangte/benutzte Permissions:
INTERNET
ACCESS_NETWORK_STATE
READ_PHONE_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
READ_CALENDAR
WRITE_CALENDAR
WRITE_EXTERNAL_STORAGE
StartApp kann sehr aufdringlich werden: Popups, Such-Icon auf dem Homescreen, Beeinträchtigung der App-Performance… Und so ganz nebenbei sendet es auch so manche persönlichen Details an die Werbe-Firma: IP, AndroidID, Netzbetreiber, App-Details, Gerätehersteller, Standort, IMEI. Also besser Finger weg.
Von StartApp verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
Optional (aber „highly recommended for better performance“ – sofern die Host-App sie nicht ohnehin bereits verwendet):
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
BLUETOOTH
RECEIVE_BOOT_COMPLETED
Ein weiterer relativ unbekannter Werbetreiber, über den sich kaum etwas finden lässt. Die Berechtigungen, welche dieser sich automatisch beim Einbauen des Moduls zuteilt bzw. zuteilen möchte, sind allerdings alarmierend:
Von Tap for Tap verlangte Permissions:
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
Wired schreibt (frei übersetzt):
Netzwerke wie Tapjoy und Flurry’s AppCircle bezahlen App-Entwickler dafür, dass diese Traffic, Registrierungen und in einigen Fällen App-Installationen für andere App-Entwickler erzeugen.
Was bedeutet, dass die genannten Bibliotheken zusätzlichen Daten-Traffic erzeugen, der Euer Kontingent belastet. Außerdem wurde 1/2017 Klage gegen TapJoy, AdColony, Chartboost, Vungle, IronSource, InMobi, und weitere eingereicht, da sie persönliche Daten ohne vorherige Zustimmung abgegriffen haben sollen.
Andere Nutzer mussten feststellen, dass plötzlich Bilder in ihrer Galerie auftauchten – und andere böse Überraschungen.
Erst kürzlich (11/2017) hat Tapjoy aufgehört, auf die IMEI zuzugreifen (und die
Permission READ_PHONE_STATE
aus dem SDK entfernt) – obwohl sie
bereits 3 Jahre zuvor (11/2014)
angaben, auf die GAID
umgestellt zu haben.
Permissions required by Tapjoy:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
Natürlich geht es auch hier um vast amounts of user data, was ja auch offen zugegeben wird. Wie man an diese gelangt sein mag, ist anhand der geforderten Permissions unschwer zu erraten. Was damit gemacht wird? Ein Beispiel, aus verlinktem Artikel zitiert:
Wenn Tencent weiß, dass ein User in etwa einem Monat die USA besuchen will, kann ein Advertizer diese Information beispielsweise für Kampagnen in den Wochen unmittelbar zuvor nutzen.
Na, das klingt doch danach, dass die Privatsphäre dort gut geschützt ist, oder?
von Tencent Social Ads verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_WIFI_STATE
READ_PHONE_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
WRITE_EXTERNAL_STORAGE
RECORD_AUDIO
Wie u. a. Threadpost und Heise berichten, stehen Disney, Upsight sowie weitere Werbenetzwerke in Kalifornien vor Gericht, weil sie gegen COPPA verstoßen haben – und PII von Kindern gesammelt haben sollen.
Von Upsight verlangte Permissions:
INTERNET
ACCESS_NETWORK_STATE
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
GCM
Nicht nur ist die Liste offiziell genutzter Permissions exzessiv – auch fand eine Studie heraus, dass VServ weitere Permissions nutzt, sofern die App Zugriff hat. Anhand der Liste lässt sich unschwer erraten, dass der Eingriff in die Privatsphäre hier enorm zu sein scheint:
Von VServ verlangte Permissions:
INTERNET
ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE
WRITE_EXTERNAL_STORAGE
READ_PHONE_STATE
WRITE_CALENDAR
READ_CALENDAR
CALL_PHONE
[USE_CREDENTIALS]
WRITE_CONTACTS
READ_CONTACTS
SEND_SMS
ACCESS_FINE_LOCATION
Von der chinesischen Werbefirma YouMi wird berichtet, dass es heimlich Benutzerdaten an seine Server übermittelte – nicht nur ohne Wissen der Anwender, sondern auch ohne das der Entwickler, welche das SDK in ihre Apps integriert hatten. Die Daten umfassten Benutzerinformationen, Geräte-IDs, installierte Apps, und mehr.
Computer Science & Information Technology zeigt in einer mit dem „malware vetting system“ DMIA durchgeführten Studie auf (frei übersetzt):
Bei Apps, welche das YouMi SDK verwenden, ist der Anteil an Malware wesentlich höher als bei anderen. Die meisten dieser Apps wurden von DMIA automatisch als „abnormal“ eingestuft. Die Ursache hierfür vermuten wir im Youmi SDK selbst. Wir haben es daher heruntergeladen, und gemäß der Anweisungen eine Demo-App erstellt. Diese haben wir sodann mit DMIA untersucht. Wir erhielten 3221 Zeilen mit Informationen, von denen 153 Zeilen sich auf private APIs bezogen. Unauthorisierter Netzwerkverkehr konnte direkt beim Start der App beobachtet werden; den Rest der Zeit waren die Zugriffe im normalen Bereich.
Das iRiS Projekt kam zu ähnlichen Ergebnissen:
Um unsere Bedenken zu verifizieren haben wir die Bibliothek heruntergeladen, eine Dummy-App erstellt, und diese mit iRiS analysiert. Wie erwartet, zeigte der Dummy ähnliches Verhalten wie die zuvor untersuchten Apps und verschickte Benutzerinformationen an den Ad-Server. Es sollte ebenfalls erwähnt werden, dass die Klassen- und Methodennamen in der Bibliothek sämtlich obfuscated und zu zufälligen Zeichenfolgen umgewandelt waren – wahrscheinlich um manuelle Analyse zu vereiteln.
Obwohl obiges für die iOS-Plattform ermittelt wurde, ist es nicht auf diese beschränkt. So fragt MalwareTips:
Was kann ein Werbe-SDK tun um Deine Privatsphäre zu stehlen? – und beantwortet das auch gleich mit 10 Punkten, basierend auf dem YouMi SDK für Android. Darin enthalten: Eine Liste aller installierten Apps sowie aller laufenden Prozesse erstellen, welche Apps werden gerade benutzt, welche wurden vor kurzem verwendet, Standort ermitteln, IMEI, Android-ID und MAC-Adresse einsammeln – und das Ganze natürlich zum Anbieter hochladen. Mit den IDs lässt sich der Anwender dann auch bequem App- und Session-übergreifend Tracken, um die gesammelten Information mit der Zeit möglichst zu vervollständigen.