Warnungen vor Schnüffel-Modulen

Warnungen vor „Schnüffel-Modulen“

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.

Allgemeine Links

How—And Why—Apple, Google, And Facebook Follow You Around In Real Life (12/2017)

Analytics

Crashlytics

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.

Von Crashlytics verlangte Permissions:
INTERNET

Facebook

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.

Firebase

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.

Firebase speichert seine Daten außerhalb der EU (kurz zusammengefasst handelt es sich bei Firebase um Cloud Storage/Hosting plus Analytics, Ads (Admob-Integration), CloudMessaging (FCM) und mehr) und ist nicht einmal vom „Privacy Shield” gedeckt (siehe hier), der ohnehin bereits löcherig genug ist.
Firebase TOS verpflichtet Entwickler, keine personenbezogenen Daten zu übermitteln (Section 7: privacy; die use policy erfordert dafür die ausdrückliche Zustimmung des Anwenders). Es wird jedoch keineswegs vollständig offengelegt, welche Daten denn überhaupt gesammelt werden. Einiges erwähnt die Seite zum Thema Datenerfassung (z.B. die Android Werbe-ID – aber auch Geräteinformationen, Standort, App-Ausführungen, In-App Käufe, IP-Adresse, Mobilfunkanbieter, Sprache). Weitere finden sich unter Automatisch erfasste Nutzereigenschaften (etwa Alter, Geschlecht, Interessen). Schaut man sich diese Kategorien an, ist die Aussage „keine personenbezogenen Daten“ äußerst fragwürdig: mit Alter, Geschlecht, Interessen, Sprache und geografischem Standort ist schon eine recht genaue Eingrenzung möglich – und mit den entsprechenden Geräte-Daten sogar eine recht genaue Identifizierung. einige Dinge werden übrigens generell und standardmäßig getrackt.
Firebase kann mit Google Analytics verbunden sein (und ist dies wahrscheinlich meist auch, gewollt oder „versehentlich“).
Firebase kann verwendet werden, um Werbung in die Benachrichtigungen zu bringen – selbst wenn die entsprechende App nur im Hintergrund läuft.
Offene Firebase-Datenbanken: Tausende Apps leaken Passwörter, Nutzerdaten etc.

Flurry Analytics

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:

Flurry: An Affront to Privacy (4/2014)
Termsfeed: Privacy Policy for Flurry

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

Google Analytics

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.

Von Google Analytics verlangte/benutzte Permissions:
INTERNET ACCESS_NETWORK_STATE

Umeng

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

(„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:

erforderlich: INTERNET ACCESS_NETWORK_STATE WRITE_EXTERNAL_STORAGE
optional: ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION WRITE_CALENDAR RECORD_AUDIO

AdMob

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.“)

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:

erforderlich: INTERNET ACCESS_NETWORK_STATE
optional: ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION

AdsMogo

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

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

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).

Burstly

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:

erforderlich: ACCESS_WIFI_STATE ACCESS_NETWORK_STATE INTERNET READ_PHONE_STATE WRITE_EXTERNAL_STORAGE
optional: ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION CALL_PHONE

CallDorado

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

Chartboost

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:

erforderlich: INTERNET ACCESS_NETWORK_STATE
optional: WRITE_EXTERNAL_STORAGE ACCESS_WIFI_STATE READ_PHONE_STATE

DoubleClick

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.

DoubleClick ist Teil des Google Werbe-Frameworks.
Google identifiziert Nutzer Geräte-übergreifend (via Google Attribution) Search Engine Land
Google verbindet Daten mit „personally identifiable information“ ProPublica
Google Attribution integriert Informationen verschiedener Google Ad Services, einschließlich DoubleClick, um die Effizienz der Ads zu ermitteln – angefangen bei Suchen bis hin zu „store visits“
Aggregierte Daten werden mit Drittanbietern geteilt. Ebenso „anonyme Daten”, PII, und andere sensible Daten Ghostery
Die DoubleClick cookie ID — welche Benutzeraktivitäten auf Webseiten von Drittanbietern trackt — ist ein weiterer angeblich “anonymer” Identifier, den Google mit dem Google-Konto eines Anwenders assoziieren kann. Study

Siehe auch:

DoubleClick (Google): What is it and what does it do? at The Guardian.
Mehr Details zu DoubleClick bei Exodus Privacy

Von DoubleClick benötigte Permissions:
INTERNET ACCESS_NETWORK_STATE

inMobi

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:

Track or treat? InMobi’s location tracking ignored consumers’ privacy settings (6/2016)
follow-up: A deep dive into mobile app location privacy following the InMobi settlement (8/2016)
Firm pays 0,000 penalty for using Wi-Fi signals to secretly track phone users (6/2016)
A deep dive into mobile app location privacy following the InMobi settlement (8/2016)
The Gory Details of Mobile Ad Tracking (8/2016)

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:

erforderlich: INTERNET ACCESS_NETWORK_STATE
verwendet wenn verfügbar: 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

LeadBolt

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

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.

Millennia Media

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

Mobclix/Axonix

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

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

mobileCore

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

MobPartner

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

mOcean

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:

erforderlich: INTERNET ACCESS_NETWORK_STATE READ_PHONE_STATE
optional: CAMERA CALL_PHONE WRITE_EXTERNAL_STORAGE READ_CALENDAR WRITE_CALENDAR SEND_SMS READ_LOGS ACCESS_FINE_LOCATION

Moolah

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:

erforderlich: INTERNET ACCESS_NETWORK_STATE WRITE_EXTERNAL_STORAGE
optional: ACCESS_FINE_LOCATION ACCESS_COARSE_LOCATION READ_CALENDAR WRITE_CALENDAR

MoPub

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:

Leakage of Geolocation Data by Mobile Ad Networks (10/2016)
Mobile Advertiser MoPub Faces Privacy Class Action Lawsuit (11/2015)
Privacy Advocates Freak Out as MoPub Exchange Dips Into Verizon’s (Tracking) Cookie Jar (11/2014)
Here's How Twitter Can Track You on All of Your Devices (9/2013)
Mobile Advertising Insights from MoPub & Opera (11/2012)

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

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:

Google Play removed app due to Revmob (5/2016)
Lookout calls out shady Android ad networks (6/2013)

Von RevMob verlangte/benutzte Permissions:
ACCESS_NETWORK_STATE ACCESS_WIFI_STATE INTERNET READ_PHONE_STATE

sellAring

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.

Smaato

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

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

Tap for Tap

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

Tapjoy

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

Tencent Social Ads

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

Upsight

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:

mandatory: INTERNET ACCESS_NETWORK_STATE
optional (used if available): ACCESS_COARSE_LOCATION ACCESS_FINE_LOCATION GCM

VServ

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:

mandatory: INTERNET
optional: 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
used secretly when available: ACCESS_FINE_LOCATION

YouMi

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.