Mastodon IzzyOnDroid


Say thanks!
↓ Your product here? ↓
Das Inoffizielle Android-HandbuchAndroid kennenlernen, Tipps & TricksDas Inoffizielle Android-Handbuch
Android kennenlernen, Tipps & Tricks
Buy at Amazon for EUR 16,99
Das Inoffizielle Android SystemhandbuchTiefer ins System einsteigenDas Inoffizielle Android Systemhandbuch
Tiefer ins System einsteigen
Buy at Amazon for EUR 7,00
Die besten Android-AppsDen Androiden austattenDie besten Android-Apps
Den Androiden austatten
Buy at Amazon for EUR 5,00
 
dehelp

What’s it all about those modules apps contain?

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

Using modules in app development is a great concept: no one has to re-invent the wheel, bug fixes and implementation of improvements can be performed at a central place with multiple apps profiting from – and each developer can focus on what (s)he’s best at. That´s the idea behind many useful modules contributing to the apps’ functionalities – and so there are plenty of them: to deal with databases, GUI-elements, file handling, and so on. To the profit of developers and users alike.

Then there’s a second category of modules, which does not directly contribute to the functionality of an app – but nevertheless has a justified purpose: analytics. Their intention is to make bugs and misbehaviors reproducible, so devs get crash logs they can easier identify culprits, and behavior patterns to improve their apps. And there are ad modules – as developers spent a lot of time writing good apps understandably want some benefit of that (and honestly, far too few users are willing to spend even a little money on apps, even as little as a cup of coffee – which is one of the main reasons developers have to look for alternative fundings). According to a study made in 2016, over 41% of apps in the Google Play Store include at least one mobile advertising library, and it is common for a single app to include several libraries from multiple advertising providers. But this second category of modules comes at a price.

General impact, regardless of module

First, of course each module occupies additional space – increasing the app’s size. This also means nibbling at your device’s storage. Second, analytics as well as ad modules cause additional network traffic (upload statistics and other information, download ads), which has some impact on your data plan.1 As soon as they are running, they will also use your device’s CPU, RAM – and battery. Last but not least: if there´s a bug or data leak in a module, the host app is affected by that as well.2

For development modules contributing to the functionality of an app (the first category mentioned above), all that can probably be neglected. Quite the opposite to be assumed: if a bug exists in a popular module, it’s probably much faster fixed there (and then for all apps using it – as soon as their developers update). And as the functionality is needed either way, there is no additional use of anything – whether local resources or network traffic.

The second group is a little different, as some of those third party helpers are quite a bit greedy. If the developer didn’t chose wisely, they might do more than intended. Some of those analytics and ad modules are known to be intrusive to your privacy – and/or annoying in their „local behavior“ (popups, ads camouflaging as notifications or warnings, and other nasty things). If encountered, I’ve marked those in my app lists with a special icon, linked to details on their behavior.

Detailed information on those „snooping modules“ is not easy to find. Especially not a compiled list with hints. If you do a search, almost all hits are from the perspective of developers, dealing with „how to get the most money for the least effort.“ On their own pages explaining the frameworks, privacy is rarely a topic. A classical example is e.g. the HeyZap FAQ: More than 100 questions and answers, but not a single one deals with data protection, privacy or anything even close – all is more about how to get money, how to get more money, when to get money … Obviously neither advertisers nor developers do care about you as a person, but only as a target. If data is the currency of the future, it seems we’re just getting robbed massively.

So when I walked my lists this spring3, I’ve tried to find information on those I encountered most frequently – and want to share my findings with you.

The study

As I wrote, I walked the app listings and cross-checked apps for their modules – mainly against their listings at AppBrain. AppBrain uses their AppBrain Ad Detector, which users can install on their devices, to analyze .apk files of apps installed on the very same device for modules they contain – and aggregate results on their site.

On a first run, I’ve built up a list of modules used by apps, focusing on ad and analytics modules, together with the permissions their integration in apps required, plus whether they were already noted for suspicious behavior in any reports. The latter proved a bit tricky (with questions as e.g. what search terms to use); often I found reportings only later on as by-catch of another search, when analysing a report or study I turned up. The names of some modules together with how search engines work made it especially difficult, as it seems impossible to force a „literal search“: when I e.g. tried to find where „MobileAppTracking“ was mentioned, search engines simply split up the term into three words and showed me wherever they found something on „mobile app tracking“, „tracking mobile apps“ and so on – regardless of me "quoting" the term or even +"enforcing" its occurrence in search hits. Thus I´m sure I’ve missed some reports (not only in the mentioned example).

On a subsequent run, I’ve walked the entire app listings here at IzzyOnDroid (over 14.000 apps currently) to check which apps are using „intrusive modules“ identified in the first step, and marked them accordingly. Note that only about 13.000 apps of those lists are available on Google Play (and thus on AppBrain), and that further library information was not available for all of those: about every 6th to 8th app missed those details as the AppBrain website relies on the resp. apps being installed on a device reporting its finding back via above mentioned Ad Detector app.

Finally, I gathered statistics of my findings from the database where I had recorded them.

Modules I checked

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

If there´s an icon in the „OK“ column, click it for detailed information: that module then was already included with the warnings in my app listings. Others of the above might follow. As my information is incomplete at best, feedback is welcome: if you find an article reporting „privacy issues“ with some ad or analytics module, please let me know!

Findings

A few things I´ve noticed on my way were:

No-Gos and Ambivalence

In some areas, ATS are a clear No-Go. Examples (and yes, I found „violators“ in each of those areas):

Statistics

For this study I performed multiple steps – which (after several weeks of hard work) as results produced above module listing, markings on apps in my app lists – and the following statistics on the distribution of selected ATS within apps. As I already pointed out, for about every 6th to 8th app AppBrain had no data on modules contained. As I unfortunately forgot to keep track of differenciating between „no data available“ and „no modules detected“ (and didn´t want to spend another three weeks for precise numbers on it), for statistics I took off 10% of the absolute number – so the following stats mark a „lower margin“. This is especially true as I usually do not include apps in my listings if they are too obviously suspicious, so real numbers are again higher as they would include those candidates.

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

Those statistics only cover the modules named there – so when speaking of „All with trackers“ or „All with ads“, this only relates to the modules named. Numbers covering really all hence are even higher. Still, above table clearly shows some interesting facts:

What are some uses for those permissions?

There might be obvious uses for controlling the ads/statistics/analytics. But there’s definitely potential for abuse. On that, we can find some details in McAfee’s 2014 mobile security report:

And now for what John missed:

A further note on READ_PHONE_STATE: Ad networks usually want this to get hold of your devices’ identifiers. If used in multiple apps on the same device, data can be correlated and used for profiling: what apps do you use then is easy to tell, as they can all be combined using the device ID. And by that of course your interests, together with other data collected. PII collected by one app then also can be combined with PII collected by another. And if only one of those apps has e.g. access to your accounts, and the ad module makes use of that, they can even pull in your email address – thus making the profile a personal one instead of just a „device profile“.

Quite unsurprisingly, Longitudinal Analysis of Android Ad Library Permissions (on page 6) comes to the conclusion:

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

Aren’t targeted ads a win-win?

It’s often argued that targeted ads47 are a typical win-win situation: the advertiser is saved from paying for putting ads in the wrong places – and the user is saved from seeing ads (s)he´s not interested in. But that´s a nice theory, assuming all play fair – which isn´t always the case. Sure, if an advertiser knows you might be interested in spending your holidays in Ireland, he can send you specific offers for that to chose from – and you can pick the best deal. But, with all the aggregated information on you, he might know you need to go to Dublin urgently tomorrow (not having time to check all offers) – and send you offers with higher fares. The insurance company getting to know you engage in „risky hobbies“ might not be interested in selling you a police cheap. Or at all. Additionally, as a Cornelly study points out, mobile ads must be treated as potentially malicious – targeted or not. The same study notes that many AdSDK providers, including AdMob, MoPub, and AdMarvel, serve ads over HTTP. Therefore, a man-in-the-middle attacker can inject malicious code into ads as they travel over the network.

Apart from that, sending ads is not the only thing done by the collectors. They often also offer the data for sale. Also consider data breaches. With your personal and private data stored on several servers across the Internet (resulting of the data collection done by those snooping modules), what happens if it gets into the wrong hands? Identity theft is one thing. Blackmailing might be another. A turn of politics might cause what´s right today to become punishable tomorrow. Just to name a few points. And besides the data collections, the more obvious (and visible) part of aggressive marketing are annoying pop-ups and other „unwanted interruptions“. Not to forget „malvertising“, where harmful ads loaded with malware reach your devices as the company running the ad network didn´t check its customers „input“ carefully enough.

You cannot even tell where your data goes to regularly (i.e. „as planned“) by those collectors, so you can’t even start to have an idea on how savely it is stored there. Apart from the „benefits“ initially mentioned, the dangers connected to „targeted advertising“ relating to your personal and private „life details“ are rather high. To me, the risks clearly outweigh the „benefits“. Especially with so many companies involved, and hardly any of them looking as if they take my privacy serious in any way.

How do those modules obtain my data?

For one, the modules do so directly. As pointed out, the developer integrating them with his app has to request the permissions demanded in order to have the module working – so it should be clear what to expect from that end. But theres more to it. One fact I´ve often pointed out when asked concerning the implementation of modules in apps. Quoting How mobile apps leak user data that’s supposedly off-limits:

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

In other words: whatever the app itself has access to, is also accessible to each and every module it uses.48 So if a harmless-looking ad modules only demands the INTERNET permission, it might not crash if there´s no other permission is granted to the app using it. But still, it would be able to access, say, your addressbook and calendars if the app itself uses the corresponding permissions. And of course could upload them to any server it likes – due to the one innocent-looking permission it demands for itself. There is no isolation between module and app, though it would be strongly needed. Which is why I’d not use an app loaded with any of those modules if it comes to personal data – think e.g. of SMS (messages, contacts), dialer (contacts), calendar & tasks, password safes, finance, health – just to name a few. Your mileage might vary; I’ve even seen budget managers with Facebook and Twitter modules …

What can I do do protect myself?

McAfee writes:

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

Often this is no easy task. Would you have guessed a torch app might require the CAMERA permission in order to use the flash light? Luckily, at least some developers started to explain the permissions their apps use, right in the app description. When in doubt, contact them to ask for explanations (and suggest to include them with their app descriptions, if missing). Or ask experienced users at your Android forum if they have an explanation. You can also always consult the permission list here at IzzyOnDroid to find some explanation on them. In context of the modules discussed in this article, also be aware that multiple apps might contain the very same ATS module, thus generating „potentially rich data (spanning a super-set of permissions across apps)“49 – a fact also confirmed by another study, which finds that Trackers can collect more information when they are present in more than one app among the apps user has installed (see graph on slide 17). On average a user shares data with ~25 trackers when both free apps and paid apps are concerned.

One more thing is that, even if you know what the permissions mean, you cannot tell what they might be used for.50 You can guess – but who tells you you’ve guessed right? Or that an app uses a permission for multiple purposes, including some you would not agree to? From Mobile Privacy: Is There An App For That?, page 69:

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

Another reason to consult those who might know (in a forum) when in doubt. Also, some of the Ad-Modules and Privacy Checkers could prove helpful – at least for the apps you already have installed. One of them, Lumen Privacy Monitor, was used in the study Tracking the Trackers mentioned in below reading list.

If you want to play it as safe as possible, only use apps from the F-Droid main repository. Their staff compiles the apps from their resp. sources which were checked before. Any proprietary stuff was either removed before compile, or the app marked accordingly in its description as „tracking you“ or having „unfree dependencies“.

Contact the developer. (S)he might not be aware of the risks the relevant module introduces to her/his app. Explain your concerns (optionally link to this or similar articles), and recommend to have the risky module replaced by something less intrusive. The dev should follow suit if (s)he takes users’ privacy serious. Also suggest a „paid version“ completely free of ATS (or if such one already exists: buy it, use it). Offer a donation, set up a „bug bounty“51.

Consider using an ad blocker. Though most of them require your device being rooted, there are also some candidates for non-rooted devices. And before the discussion starts: No, this is not about „cheating“ or „taking the benefit from developers“. Writing apps mostly is hard work, and many developers spent not hours but months or years on their apps, which we should honor. But this is pure self protection: As e.g. a 2016 study shows, ads may contain malicious files52. As this article shows, ad networks are intrusive to our privacy. So I consider this a legit step. But to compensate, consider buying the paid versions of the apps you use regularly – or seek contact with the resp. developers to find another way to „make up“.

If you are a developer, note that a study pointed out that integrating certain ad libraries can negatively impact an app’s rating. While today far too many users are ignorant toward privacy intrusions (and often don´t even notice them), some do – and will blame you, maybe wrongly to a degree, for that if you „overdo“ it. To end-users, integrating too many or too aggressive ad modules looks greedy. And those who take their privacy serious feel you sell them out – as it’s us users who pay with their privacy. This counts even harder if there’s no option to buy an ad free version; either because there is no paid version, or even that is not ad free. Don’t be lazy saying you´ve disabled the modules in the paid version: even if we trust you, we don’t trust the „sellers“ of those modules; but what is not there can do no harm. So leave them out in paid versions, and use less intrusive candidates for the „free trials“. If users see you care for their privacy, you raise in their esteem – and your apps are more trusted and recommended in the „privacy-aware community“ (which will affect the general community as well).


Recommended readings

The following is a selection of documents I turned up during my study, which I found interesting enough to recommend them to you for deeper investigation:

appsprivacysecurity


  1. Tracking the Trackers (on page 5) finds that 70% of the analyzed apps dedicate at least 10% of their traffic to tracking and advertising activities, while more than 7% of mobile apps have at least 90% of their traffic associated with ATS activities. If it were not for ATS-related activities, many mobile apps would operate mostly offline. ↩︎

  2. See e.g.: Truth in Advertising: The Hidden Cost of Mobile Ads for Software Developers (PDF) ↩︎

  3. I do that at least once a year systematically, to keep them useful for you ↩︎

  4. Permissions in curly braces are „optional“ – but most times marked for developers as „highly recommended for better performance“ (in terms of money, of course). ↩︎

  5. Collects a.o. the following data: AndroidID, IMEI ↩︎

  6. Adlantis (a Japanese ad provider) is considered an exemplary aggressive ad module e.g. by Analysis of Code Heterogeneity for High-Precision Classification of Repackaged Malware, which also states it tries to read user private information but unfortunately doesn’t specify which. Besides: the Adlantis Privacy Policy you cannot even read without Javascript enabled – which means you are already tracked before you can inform yourself on details of the tracking. ↩︎

  7. Aquired by AdMob in 2009, integrated into the latter, and shut down in 2013 ↩︎

  8. The AerServ Terms and Conditions states it a.o. collects (precise) geo-location data, and urges developers to have their users explicitly opt-in to that. That document also mentions that AerServ does not wish to receive any PII, and thus the developer agrees to not send such (if the developer still does so, he’s held responsible having obtained the users’ explicit consent („User Volunteered Data“)). Their Privacy Policy says collected data includes (but is not limited to): * information about your device, such as the type and model, manufacturer, operating system, carrier name, Internet Protocol (IP) address, mobile browser, applications using the Services and the version of such applications, and identifiers assigned to your device […] time zone, and network connection type […] geo-location of your device, when location services have been enabled […] information about ads served, viewed, or clicked on.* Also: We receive information about consumers from third parties to enable targeted advertising on the website(s) and application(s) that we support.
    On the other hand, what they write about ad blockers is impressive for an ad company – especially the fact that they blame the ad industry for that. Also see: AerServ Partners With The Media Trust to Ensure Ad Security for Publishers↩︎

  9. On data collected from the end user, Amazon’s Mobile Ad Network Publisher Agreement in section 8d obliges the developer not to provide them with any PII. Geo-location data is limited to users outside the EU who explicitly agreed to providing that. For other data provided, the users’ explicit consent is required as well. The document however does not reveal what other data might be collected, neither does the corresponding FAQ. But the latter reveals: The Amazon Mobile Ads API is designed to disable the geolocation feature when the device is detected as being physically located in the EU. ↩︎

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

  11. Collects user data: Generic location, carrier, device manufacturer/model, OS, app name, language settings, IP, AndroidID & more, in order to „Deliver targeted advertisements on behalf of our Business Partners“. One can opt-out of targeted ads, but not of data collection. ↩︎

  12. to access the users’ email addresses ↩︎

  13. Details on data collected by AppNext can be found in their privacy policy. Summed up, they include: device type and model, system language, operating system, SDK version, mobile carrier name, mobile browsers installed on the device, app history and usage information, information regarding downloads and installations of mobile applications and any information regarding in-app events, IP address, identifiers assigned to your device, Android Advertising ID, or other types of unique device identifiers, details on ads served, location information (by IP, network and GPS). As the integration instructions only name the INTERNET and, optionally, GET_ACCOUNTS permissions, this would be a classical example of „we also take everything else the host app has access to“ – as many of the mentioned details are not available by means of those two permissions. ↩︎

  14. AppoDeal is a so-called „mediator“: the dev integrates one SDK, and feeds on multiple ad networks (here e.g. AdColony, AdMob, Amazon, AppLovin, Smaato, Unity) – less effort in implementation, better eCPM, impressions and thus income. Unfortunately, their privacy policy doesn’t distinguish between their website and their other services, so it does not become clear what data is collected by their SDK. Neither did I find another clear source on that. ↩︎

  15. Collects a.o. the following data: SIM operator ↩︎

  16. The Avocarrot privacy policy describes in section 1 what data is collected. This includes a.o.: device info (type/model/manufacturer), OS, carrier name, IP address, identifiers (serial, GAID), geolocation (GPS or other), information about ads served/viewed/clicked. Information is shared with advertisers. Aggregated information is shared with customers. Data can be stored abroad, which explicitly includes outside the EU if you’re located inside. ↩︎

  17. see: Wikipedia; focuses the game sector; video ads. According to their privacy policy, collected data include language, OS & SDK version, device model, unique device identifier (GAID/AndroidID), IP & MAC address, details on ad interaction. Data explicitly is connected with data from other ad companies, and also shared with them. ↩︎

  18. Quoting from their SDK link: Our SDK does not provide personally identifiable information about users to us. However, we do collect device identifiers (specific device identifier depends on type of app, Google Play or Amazon Appstore), gross location data (via IP), as well as information about impressions and clicks. We also run surveys which allow users the option to anonymously report age, range, and gender.
    If you’re ad-enabling your application with Conversant or any other network, it is your responsibility to let users know how information is handled. Your agreement with Conversant (particularly Sections 4.3, 4.4, 7.1) require you to disclose what information is being shared with any third party.
     ↩︎

  19. Crashlytics seems to be pretty benign when it comes to data collection. Some details can be found in a Quora question. A business partner writes: Nobody has ever had any concerns regarding data leaks. Plus, since the metdata that is collected is fairly basic, it should quiet any concerns you may have. They do a lot with the minimal amount of data they collect. What basic data that is is stated by a former employee: some data on app level like package name, icon, version/build number and platform (to identify the app), plus on crash level only the necessary details to analyse the crash – for which he points at their privacy statement, which unfortunately is no longer available (the recent version as of 1/2017 can be found here in a PDF). PII is only included if the developer explicitly does so, in which case the developer must disclose the fact to the users. ↩︎

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

  21. several security issues (at least 2012-2014), incl. „account hijacking“. Known to collect whatever they can get of your personal data – which in this context might mean everything the host app has access to. ↩︎

  22. Section 1.2 of Fyber’s privacy policy (PDF) explains about data collected via mobile applications with terms „like”, „such as” etc: device type and ID, OS, network provider, IP address, SDK version, app, geo-location, ads served. Section 2.2 shows how collected data is used, by the usual terms (serving ads, improving our service etc.), and finally section 3 says that personal data collected may sometimes be relayed to external third parties […] where it makes sense in the business of selling and delivering advertising, and gives some raw ideas (again the usual marketing-speech). ↩︎

  23. Interesting: The HeyZap FAQ has about 100 questions, but not a single one is about privacy or protecting PII. All is more or less about how and when to get paid (most). Their privacy policy explains in section 1 what is collected („This “automatically collected” information may include Internet Protocol address (“IP Address”), IDFA, Android ID, geolocation, country code, a unique device or advertiser ID, version of software installed, operating system type, the content and pages that you access on the Heyzap Application and/or Heyzap Network, and the dates and times that you visit the Heyzap Application and/or Heyzap Network.“) and in section 2 how that data is used („to understand the usage trends and preferences of our Users, to improve the way the Heyzap Application and/or Heyzap Network works and looks, to create new features and functionality. […]“). ↩︎

  24. Also see: Global Demo ↩︎

  25. According to Kochava Security and Privacy, it’s up to the developer to configure which data is accessed and collected. They especially point out: Personally-Identifiable Information (PII) is abstracted. PII is not used in ongoing SDK transmission. In-app events and calculations are tracked, and install notifications are given. Attribution Overview further details collected device information ranges from unique device identifiers to the IP address of the device at the time of click or impression, that Kochava tracks every engagement with every ad served. Android SDK integration lists a „sample payload” revealing additional details, such as country, network ID, device model are also included. It seems to be a mediation provider, integrating with over 650 mobile ad networks, publishers, and exchanges↩︎

  26. LiveRail is owned by Facebook. AdExchanger quotes from its (currently unavailable) privacy policy: Information we collect includes, among other things, device type, operating system, unique identifiers, IP address, location, browser type and language, and header information such as URLs and date/time stamps. LiveRail was shut down in 12/2016↩︎

  27. According to Localytic´s privacy policy, „Localytics provides analyses of anonymized, aggregate End User Information to its Customers and to other third parties (“Analyzed Data”). Localytics takes commercially reasonable efforts to ensure that Analyzed Data does not include any PII […] End Users should be aware, however, that Localytics’ Customers may request such information from End Users in order to use their mobile applications and such PII may be included in the End User Information provided to Localytics. End Users should therefore review the privacy policies of the mobile applications they use to assess the security of any PII they disclose.“ In their Analytics Dashboard we can find further hints on what’s collected: e.g. geo-location (IP based by default, GPS optionally) and device identifiers. ↩︎

  28. MdotM collects a.o.: AndroidID, IMEI; further also gender, age, photo, city location, mobile number, other Network App IDs you communicate with as part of your interaction with the Network Application, advertisements that were delivered to you and that you clicked on, and other click-stream data. ↩︎

  29. According to Metaps privacy policy, a.o. collects: Google Advertising ID (GAID), App usage, interaction with ads (click), IP addresses, plus „voluntarily provided information“ ↩︎

  30. "a confederacy of ’privacy’ dunces": what we found under the hood of an ’anonymous’ chat app used by millions is an analysis of Whisper app which reveals details on Mixpanel and MobileAppTracking. Nice catch here: Furthermore they (Whisper) emphasize that THEY do not collect these metrics, and that much is true, they facilitate allowing third party vendors like Mixpanel and MobileAppTracking to do that work for them. According to Lawsuit Fails Over Ridesharing Service’s Disclosures To Its Analytics Service (1/2015), the following data are possibly shared to Mixpanel by use of its API: gender, age, zip code, metro region, travel plans, and link to the user’s Facebook profile. Mixpanel’s privacy policy states to collect your mobile carrier and the unique device id number […] information about the type of device you use as well as other details you provide us voluntarily – i.e. which the developer of the resp. app decides to be shared. ↩︎

  31. Mobfox’ Terms of Service lists it a.o. collects informatcion such as your gender, age, location and other attributes. Further collected data includes your device attributes (such as model, make, device agent details, device ID) and traffic/session information, including session durations, IP address and additional activity information. Matomy may use additional users’ statistical analysis-driven data, such as your age group, areas of interest and general location. The document also states: In both iOS and Android devices you may signal your wish to opt out of receiving interest-base ads via your device settings. ↩︎

  32. According to their privacy policy, mobilCore collects a.o. Advertising ID, IP, MAC, OS+version; may include age & gender; claims to „not rent, sell, or share your and/or the user’s Personal Information“ (except for legal issues) ↩︎

  33. According to their privacy policy, Pollfish collects significantly more details from Android devices than it does on iOS. This includes GAID, apps installed, device description, network provider (MCC&MNC), connection type, IP address, OS version, SDK version, NFC available/active, device language, geolocation. If available/accessible: IMEI, MAC, AndroidID, serial, installed apps, running services, RAM/CPU/BT information, available BLE devices. Quite a lot of details for an SDK with the only purpose of „participating in surveys”. ↩︎

  34. PubNative is a mediator, i.e. it integrates multiple ad networks via its API, located in Berlin, Germany. Details on what data are collected from users can only partially be abstracted from their TOS (pretty minor disclosure for a German company). According to section 3.3 it includes IP addresses and device IDs. 5.4 says publisher must ensure no PII is transmitted unless all required permissions are obtained. A look at the API reveals slightly more details, such as OS version, device model, screen resolution, Android_ID, some „userIDKey”. ↩︎

  35. seems clean. According to its FAQ, it does not collect any PII by itself – i.e. the dev could of course have done so willingly or accidentally. According to the FAQ, Splunk MINT only stores country, timestamp, device model, SDK version, app version, and permissions – and explicitly not the IMEI, UDID or any personally identifiable information. ↩︎

  36. Now Fyber ↩︎

  37. According to the Supersonic Privacy Policy, collected data „may include“: device manufacturer/model, carrier, connection type, free space available on device „and other statistical and technical information“. Also possibly geo-location, details on the viewed ad and your interaction with it. If the app developer included it: gender, date of sign-up (app install?). ↩︎

  38. especially mentioned to affect performance in apps. Collects a.o. the following data: AndroidID IMEI, serial, MAC, SIM operator/network. Also see: Tapjoy’s In-Game Ads Crush Mobile Industry Norms for Branding Metrics, comScore Finds (8/2016) and TapJoy – value creator or scam artist? (11/2012) ↩︎

  39. Unity 5 collects data from people playing your game?; according to its privacy policy, collects e.g. AndroidID, IP, device manufacturer/model, OS + version, language, app ID ↩︎

  40. According to its privacy policy, Vungle collects: IP, AndroidID, MAC, „and other unique identifiers“, activities within the app, other apps installed, and much more. Collected information is used for targeted ads, performance tracking of ads, to „provide aggregate reports to Publishers and Advertisers […] and for other research and analytical purposes; and to send our customers marketing and promotional information“. Data is shared – but except for legal purposes, always in „aggregated“ form. ↩︎

  41. I could not find a page listing up information collected by Yandex Metrica. However, some can be abstracted from their API description: installed apps (disabled by default), location (optional), app version, crash details. It however doesn’t reveal which identifiers or PII is included by default. Plus, the developer can include everything the app has access to. ↩︎

  42. Some more were added when I studied additional material collected on the topic, as listed under Further readings↩︎

  43. A personal remark on „Anti-Virus for Android“: That´s like wearing the helmet of a medieval knight to play „Russian Roulette“. You wouldn’t need that helmet if you wouldn’t willingly put yourself at risk (using some common sense is more effective). As you do both, some bullets still penetrate the helmet. And what’s more, the helmet has spikes. Inside. Think of all those „false positives“ causing unnecessary panic, plus vulnerabilities introduced by their often massively high demand on powerful permissions, as well as the again risky modules they usually contain. Remember who wants to tell you that you need that kind of software: its makers. And if you now ask the common question what good it does them if they give it away for free: they don’t. You pay with your data, with your privacy. ↩︎

  44. McAfee writes To manage accounts so they can log in or authenticate to certain accounts – but for that, this permission is far from being sufficient. As the name suggests, it is for finding accounts, not using them (which would be USE_CREDENTIALS). ↩︎

  45. Legit uses include geo-targeted ads: if you live in Toronto, you probably don’t care about special offers in Santiago. But for that granularity, your IP address should be sufficient – at maximum your coarse (network) location. There´s no justification for an ad or analytics module to access your precise (GPS) position. ↩︎

  46. Also see: Underestimated Privacy Implications of the ACCESS_WIFI_STATE Android Permission ↩︎

  47. Also see: Characterising User Targeting For In-App Mobile Ads, a study from 2013, which a.o. defines „targeted advertising“ with a short sentence: Targeted advertising is based on big data analytics, where user’s personal information is collected and processed for the purposes of profiling and targeting. ↩︎

  48. We find that many applications pass personal information directly to their ad libraries, without any need for the library to query the operating system directly. This behavior is most common in more popular applications, suggesting that the promise of advertising dollars encourages application developers to violate users’ privacy. (Privacy Concerns in Android Advertising Libraries, page 2) While this may be information directly entered by the user into the application, it can also be information from social networking sites or other cloud data sources that the user authorizes the application to access. (page 41) ↩︎

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

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

  51. Some companies offer „bug bounties“ as rewards for reporting bugs (see Wikipedia). A larger number of such programs can be found at Bugcrowd. But that´s not what I meant here. I was rather referring to The Internet Bug Bounty and similar programs. If the dev in question participates in one of them, that is. ↩︎

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

2017-04-22 (2017-11-10)