Das Inoffizielle Android-Handbuch
Das Inoffizielle Android Systemhandbuch
Die besten Android-Apps
What’s it all about those modules apps contain?
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
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:
- Most free apps have at least one ad module integrated. Many use more than one, some up to 10, and one app I found even using 15 – while a study even found one with 28 ad modules!
- Usually, you can get rid of those trackers buying the paid version. But the cases where those contained the very same ad modules were not rare; in one case the paid app even carried one additional tracker. A 2015 study confirms this: 85%-95% of the free apps were connected to at least one tracker; ~60% of the paid apps were connected to at least one tracker. Most of the trackers popular in free apps were present in paid apps. In many other cases, the „paid version“ is just a „license app“ to suppress the display of apps; as that means one needs to keep the „free“ version, it also means the module itself remains.
Dear developers, if you want to tell me „it’s just there but it´s not active“ I feel as safe as if you’d sell me a car with a bomb built-in telling me „it’s not armed“. I might believe you not having intentionally armed it – but as you haven’t built it, how can you be sure? - While most ad and analytic modules showed decent permissions, some seemed quite intrusive. A few even gave me goose bumps and let my hair stand on ends: I never thought they would be that open about information they access! Check for yourselves in above table, especially for Millennial and CallDorado. Developers using such modules in their apps IMHO cannot be trusted, and I’d avoid their other apps as well – who knows what easter-eggs await us in those.
- Checking the modules’ API descriptions and „privacy“ polices, I figured some of the data being collected. Of course those differ between the respective collectors. But my findings concerning these rawly confirm what MobileAppScrutinator reports on page 6: about a third of our candidates collects the AndroidID, about a fifth the IMEI. Less than a tenth also go for the WiFi MAC, serial, IMSI and phone number. Those graphs do not include other data picked up, like location, contacts, call history etc (part of which is covered in a separate graph on page 11: more than 10% collect network code or operator, about 5% collect location, less than 5% accounts or contacts); where found, I’ve listed those details along the module descriptions. The study further found those data is often sent unmodified (i.e. not hashed or encrypted), and not rarely even „in the clear“ (i.e. not via HTTPS/SSL), making it even easy for eaves-droppers (so called „men in the middle“) to pick them up, e.g. in public WiFi networks.
- Especially alarming I found (collections of) ATS in apps processing sensitive information. Whether it’s worth getting ads on tampons at the right day (to pick one example) is questionable at best – but when it comes to financial, health and similar details (and yes, this includes my calendar data), I’d prefer to not have any trackers snooping.
- During my „walk“ I was able to identify 15 modules42 with proof of being invasive to the users’ privacy. In above table, those are marked with a „monitoring icon“ – which also links to details on my resp. findings on them. If a module is not marked that doesn’t mean it’s not intrusive; in most cases it only means I was unable to find details (i.e. my „Google-Fu“ wasn’t strong enough: how do you search for impact of a module named „Adjust“, for example – or convince a search engine you in fact are looking for the term „MobileAppTracking“ and not just the fact of „mobile app tracking“?).
- On some modules I couldn’t find any information (e.g. Daum Ads, Cauly Ads). How did the developers find details to integrate them with their apps? Others required to first create an account to access that information at all (e.g. display.io). Do they want to keep us from knowing something about them?
- The term „free“ in the name of an app tells you with 95% accuracy that app contains ads (I encountered only few exceptions), which turns to 100% if it´s all-caps („FREE“). Couldn’t yet figure out what the term „best“ in the name of an app indicates, though.
- The terms „no ads“ or „ad free" do not necessarily mean the app doesn’t contain any ad module. Hopefully it at least means they don’t show any ads.
- Questionable at best: apps with the task to protect your privacy coming equipped with ATS. A clear No-Go to me – but there are several of them. I was waiting to find one of those candidates among the Ad Blockers, but luckily at least that was not the case
- Especially high concentration of intrusive modules I found in areas promising you to „get things cheap“: making cheap calls, finding cheap fuel. With relief I noted especially low concentrations in some sensitive areas like mobile banking, doctors/pharmacy. Marbled results in other sensitive areas like child protection. Some fun I had walking the so-called „Anti-Virus“ apps (see Anti-Malware): If you remove all candidates where I found „suspicious modules“, then walk the rest for those containing other ATS, the list (as expected) will be close to empty.43 Those left are the ones you could consider to possibly trust. But if you think even one of them is a „known solution“, you’re on the wrong track – the „big ones“ were all disqualified
- I’ve checked advices on how to integrate modules with „your app“ (needed that e.g. to find out permission requirements) and hints/discussions on what ad module to chose. The term „privacy“ wasn’t even mentioned, much less discussed. In some places there were FAQs on a module; same there. All that was discussed was how to make money, make more money, other money, get paid faster … Shocking: the CallDorado FAQ (yeah, still no HTTPS) answers on concerns that users might not like or even uninstall the app because of the module that the developer need not to be concerned: Caller ID services are very popular with users. Users will not uninstall you app. Well, one catches mice with bacon, foxes with meat – and users … continue for yourself, after having checked the details on CallDorado (e.g. here:
).
No-Gos and Ambivalence
In some areas, ATS are a clear No-Go. Examples (and yes, I found „violators“ in each of those areas):
- „Privacy Advisors“. How shall I expect an app to advise me about privacy if it obviously doesn’t respect it?
- Anti-Malware/Security suites. They should protect the user against vulnerabilities, not introduce additional ones. And both ad modules as well as some analytic modules pose additional risks, as studies show.
- Anti-Theft/Device-Finders. If I needed one of those I wanted them to track the thief, not me!
- Security Cams. Honestly? To whom do those report, and what?
- Encryption/Decryption of sensitive information (incl. mail, messaging etc.) I hopefully do not need to explain my reasons here. In case you need a hint: modules have access to everything their host app has access to. If I feel the need to encrypt such information I want to ensure that no third party has access to it. If I wanted to make it public, I had no need to encrypt it.
- Password safes. Very same reason.
- Apps that require root access (
ACCESS_SUPERUSER): High security risk, as ads then can run with the same power! And trackers as well. So e.g. a SuperUser app with such modules to me is an absolute No-Go – but yes, such candidates do exist. What’s more, you will have a hard time finding a Root Checker that comes without any suspicious module. - Apps for Kids: a double No here; one for tracking them, and another for the ads especially small children cannot be expected to competently deal with.
- Apps dealing with „very personal information“ like calendars, contacts, medication, finances. See „sensitive information“ above.
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:
- About every second app on the Google Play Store is „infected“ by at least one tracking module.
- Same must be said on about every forth paid app.
- Unsurprisingly, Google AdMob is the most used advertising module by far. Concerning analytics, Google Analytics and Flurry Analytics are spread almost evenly.
- Luckily, the most intrusive modules I found are not that widely used: less than every 80th app includes Millennial Media, and only about every 1000th app comes with CallDorado.
- Still: if you want a „tracker free app“ for a given task, you’ll have to search very hard – even if you don´t mind paying for it.
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:
GET_TASKS: Eavesdrop on your life, evade defensesGET_ACCOUNTS: find your accounts for „identity theft“44READ_PHONE_STATE: Track you through your device (usually by IMEI/DeviceID), know your carrierACCESS_COARSE_LOCATION/ACCESS_FINE_LOCATION: Pinpoint and track your travels.45READ_SMS/RECEIVE_SMS/RECEIVE_MMS/SEND_SMS: Commit fraud or steal from your bank (think e.g. of SMS TAN)
And now for what John missed:
ACCESS_NETWORK_STATE/ACCESS_WIFI_STATE46: Seeing whether the network can be reached (to load ads) – but also to capture network information (what networks are in reach?) and calculate your location (e.g. by IP and known WiFi networks)CHANGE_WIFI_STATE: To enable Internet access if youve disabled it (e.g. while in Airplane mode), so ads can be loaded (and your data sent)INTERNET: obvious, of course: to download ads and upload collected dataACTIVITY_RECOGNITION: identify the method of your movements. Are you a bicycler? Enjoy running? Drive a car?READ_CALENDAR/WRITE_CALENDAR: to place ads and know about your schedules. Keywords from your calendars are very interesting for your profile. Especially re-occuring events…READ_LOGS: Fish for sensitive data other apps might leakRECORD_AUDIO: listen in on your conversations?VIBRATE: to better annoy you, so you can’t miss an adWRITE_EXTERNAL_STORAGE: e.g. buffer video ads?
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 STATEpermission), 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 asREAD PHONE STATEandACCESS WIFI STATE, and in permissions that make ads more obtrusive, such asVIBRATE. 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?
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:
- Who’s watching you? McAfee Mobile Security Report (PDF, 2014)
Being issued by famous Anti-Virus expert McAfee, one can expect it exaggerates in direction to have their „protection“ installed. Nevertheless, with that filter in mind (and the fact the article is from 2014), a very interesting reading on some backgrounds. - Tracking the Trackers: Towards Understanding the Mobile Advertising and Tracking Ecosystem (PDF, 2016)
This study uses the Lumen Privacy Monitor app (previously known as ICSI Haystack) to understand how mobile apps handle private information, including data leaks and data sharing. - Investigations into Consumers Preferences Concerning Privacy: An Initial Step Towards the Development of Modern and Consistent Privacy Protections Around the Globe (PDF, 2014)
Provides alternative definitions of privacy and of invasions of privacy followed by a brief review of the regulatory gap in which most information services companies […] operate, then describes the “myth of anonymization” (and how easy it is today to de-anonymize „anonymized data“). After this comes a description and summary of the surveys themselves: consumers’ attitudes towards privacy, consumers’ attitudes towards protecting their children’s privacy. During this, it deals with privacy violations of search engines, ad networks, social networks, etc. - A Measurement Study of Tracking in Paid Mobile Applications (2015)
Powerpoint document with matrix of PII accessed by modules (slides 11-14). - MobileAppScrutinator: A Simple yet Efficient Dynamic Analysis Approach for Detecting Privacy Leaks across Mobile OSs (2016)
Focuses on tracking and data collection by advertisers and analytics companies across mobile platforms: We are first to provide detailed analysis and measurement data for both Android and iOS. Includes a matrix of which device identifiers are sent to which domains (page 7), as well as which PII is sent to which domains (page 10). - An In-Depth Analysis of Online Trackers’ Privacy (PDF, 2014)
Are They Worth Reading? We analyzed the privacy policies of 75 online tracking companies with the goal of assessing whether they contain information relevant for users to make privacy decisions […] From the conclusion: Only 75 out of these [2,750] companies had English-language privacy policies with content relevant for tracked users, which we analyzed thoroughly. We found that most of these companies are silent with regard to important consumer-relevant practices including the collection and use of sensitive information and linkage of tracking data with personally-identifiable information. - Mobile Privacy: Is There An App For That? (PDF, 2012; Master’s Thesis with 105 pages)
The goal of this thesis is to research to what extent third-party apps for smart mobile devices have to comply with relevant EU legislation concerning the processing of personal data. […] This will demonstrate what kind of data are available on smart mobile devices, to what extent developers of apps can access them with or without permission of users, and how these are processed by apps. - How mobile apps leak user data that’s supposedly off-limits (2/2016)
Gives some background on how those modules are able to access so much PII: Researchers at the School for Computer Science at the Georgia Institute of Technology recently delved into just how much data users are giving away to pay for free mobile apps. […] We have a permeable membrane between ad networks and mobile app developers to thank for all this dribbling. - Leakage of Geolocation Data by Mobile Ad Networks (10/2016)
This research demonstrates how mobile networks leak location data and other sensitive information from mobile phones by sending plaintext, unencrypted transmissions. It is therefore possible that geolocation information, associated with a user, could be captured by government and private sector entities, as well as by nefarious actors.
Though focused on iPhones, same can be applied to other platforms and holds true also on Android. Read online, or download PDF from the site. - What Mobile Ads Know About Mobile Users (PDF, 2016, 15 pages)
We then demonstrate how malicious ads can infer sensitive information about users by accessing external storage, which is essential for media-rich ads in order to cache video and images. […] We conclude with our recommendations for redesigning mobile advertising software to better protect users from malicious advertising.
This is less about the modules themselves accessing data, but rather about how the ads themselves are isolated to not access PII and other data. For that, it studied four AdSDKs: AdMob, MoPub, AirPush and AdMarvel, and investigated what a fully confined, privilege-separated mobile ad can learn about the user of the device on which it is displayed. So it´s about the dangers ads themselves present. - IntelliAd Understanding In-APP Ad Costs From Users Perspective (7/2016)
we aim at understanding the ad costs from users perspective. We utilize app reviews, which are widely recognized as expressions of user perceptions, to identify the ad costs concerned by users. […] Our experimental results provide the developers with suggestions on better incorporating ads into apps and, meanwhile, ensuring the user experience.
This is a reading for developers who care to take the „UX“ (aka „user experience“ – or: one essential but easily ignored component, end users, as the study puts it) in mind when chosing to embed some ad SDK - Privacy Concerns in Android Advertising Libraries (PDF, 8/2013, 64 pages)
Master thesis:
This work investigates privacy characteristics of Android advertising libraries. Taking a sample of 114,000 apps, we extract and classify their ad libraries. We then seek to understand how they make use of sensitive user data. […] We find that the use of most permissions has increased over the last several years, and that more libraries are able to use permissions that pose particular risks to user privacy and security. [… We] consider information passed directly from the application to the ad library. […] We find that many applications pass personal information directly to their ad libraries, without any need for the library to query the operating system directly.
Especially see table 3.2 on page 46, which lists privacy related API calls per ad library for some of the most common ad libraries. - Characterising User Targeting For In-App Mobile Ads (PDF, 2013, 6 pages)
In this work, we present a novel analysis of targeted advertising in the Google AdMob advertising network and show insights about the relevance of Google user profiles, and the categories of apps used, on the in-app ads served on smartphones. […] Our analysis reveals that, for all comparable experiments, the proportion of targeted ads is in all cases higher than the proportion of contextual ads. Moreover, blocking the targeting (disabling targeting in an AdMob user profile settings) results in a significant drop in the number of received ads with some experimental instances receiving no ads at all. Overall, the number of targeted ads is comparatively lower than the number of generic ads. - WifiLeaks: Underestimated Privacy Implications of the ACCESS_WIFI_STATE Android Permission (2014, PDF, 8 pages)
Our analyses reveal that this permission is already used by some companies to collect user Personally Identifiable Information (PII). We also conducted an online survey to study users’ perception of the privacy risks associated with this permission. This survey shows that users largely underestimate the privacy implications of this permission.
[…] PII can be derived from the data related to Wi-Fi interface (Section 3), namely unique identifiers (useful for tracking purposes), device geolocation, travel history and social links between users. […] This raw data may look innocuous, but it is actually possible to either directly access or infer several user PII.
Page 4 has a table of information accessible via this permission. Page 5 has another interesting table showing top-5 networks (which easily can be assigned to ad modules) accessing those sensitive data. From this article, it e.g. includes inMobi and Google (i.e. AdMob or GA) – but also others I didn´t find any „suspicious reports“ on up to know (Tapjoy, Vungle), and several I didn´t even notice yet. - Unsafe exposure analysis of mobile in-app advertisements (PDF, 2011, 12 pages; requires Google Account; without login here)
In this paper, we focus on potential privacy and security risks posed by these embedded or in-app advertisement libraries […] In particular, we first decouple the embedded ad libraries from their host apps and then apply our system to statically examine the ad libraries for risks, ranging from uploading sensitive information to remote (ad) servers to executing untrusted code from Internet sources. Our results show that most existing ad libraries collect private information […] call logs, phone number, browser bookmarks, or even the list of apps installed on the phone. Moreover, some libraries make use of an unsafe mechanism to directly fetch and run code from the Internet, which immediately leads to serious security risks.
A matrix on information accessed per ad module can be found on page 7. The study a.o. finds ATS invasively collecting PII, disclosing smartphone data to running ads (allowing them to collect data without the user’s permission; example given: Mobclix), unsafely fetching and loading dynamic code (makes malvertising possible and easy). The study finally concludes hat even among some of the most widely-deployed ad libraries, there exist threats to security and privacy. Such threats range from collecting unnecessarily intrusive user information to allowing third-party code of unknown provenance to execute within the hosting app. - Longitudinal Analysis of Android Ad Library Permissions (4/2013, PDF, 9 pages)
This paper investigates changes over time in the behavior of Android ad libraries. […] We find that the use of most permissions has increased over the last several years, and that more libraries are able to use permissions that pose particular risks to user privacy and security.
Especially interesting: table 7 at page 7, listing libraries found in apps removed from Google Play (read the surrounding paragraph for context). In short, apps containing any of those libraries are more likely to be removed from the Playstore. From the set in this article, the table contains Airpush and RevMob. - Privacy Policy for Advertising SDKs
Sums up privacy policies/implications from some selected networks.
Also related
- Leaky Apps Far Riskier Than Mobile Malware (2/2016)
Some of the data leak behaviors include sending out or broadcasting unique device identifiers, address book, calendar, location or SMS messages, attempting to root a device or capabilities for recording calls, or other user-initiated activity. Privacy invasive activity includes tracking locations, accessing address book, calendar, SMS archives, microphone and other functions, and sending data to ad networks.
In examining over 315,000 unique iOS and Android apps from the respective platform´s app stores, Appthority found that just over 48% of iOS apps and nearly 87% of Android apps displayed data leakage behaviors.
Meanwhile over 62% of iOS and 86% of Android apps engage in privacy invasive behavior.
The full report is available for download here. - Security and Privacy of Users’ Personal Information on Smartphones (2015, PDF, 202 pages; Doctoral thesis)
In my study, I examined the causes and impact of information leaks by clean applications in order to identify the motivation behind accessing users’ personal information without their knowledge. The empirical results indicate that third-party advertising libraries are responsible for privacy breaches. I further extended my research by investigating the built-in tracking settings made available to users by the smartphone operating system. (emphasis mine)
This doctoral thesis doesn’t focus on ad modules, but deals with them in the general context. - Who Is Spying On Android Users, Why Do They Do It And What Are They Doing With The Data? (12/2016)
Mainly deals with data collected by Google, Facebook and Amazon. - List of Quality of Experience (QoE) applications (2016)
List of domains with short descriptions and risk ratings – so you can check your logs and adjust your devices’hostsfiles. - Cross-Device Tracking: Measurement and Disclosures (PDF, 2/2017) Our study only looked at the possibility of linking two browsers on two virtual computers. We did not study the ability of companies to track users across mobile applications or other devices leveraging static identifiers such as IDFAs or Android IDs.
- Are these Ads Safe: Detecting Hidden Attacks through the Mobile App-Web Interfaces (2016, PDF, 15 pages)
Focuses on the ads themselves rather than on specific ad networks or ad modules, and explains some patterns of how malvertizing works:
Mobile users are increasingly becoming targets of malware infections and scams. Some platforms, such as Android, are more open than others and are therefore easier to exploit than other platforms. In order to curb such attacks it is important to know how these attacks originate. We take a previously unexplored step in this direction and look for the answer at the interface between mobile apps and the Web […] - Shining the Floodlights on Mobile Web Tracking — A Privacy Survey (PDF, 2013, 9 pages)
We compare tracking across five physical and emulated mobile devices with one desktop device as a benchmark. […] We confirm many intuitive predictions and report a few surprises. - Mining Apps for Abnormal Usage of Sensitive Data (PDF, 2015, 11 pages)
[…] we mined 2,866 benign Android applications for their data flow from sensitive sources, and compare these flows against those found in malicious apps. […] malicious apps can be identified by their abnormal data flow alone, without requiring known malware samples. - Privacy Concerns: Analysis of music applications on Android (PDF, 2014, 11 pages)
In this article, I will use mitmproxy […]. I will leverage its ability to conduct a man-in-the-middle attack in order to analyze HTTP/S traffic to some of the most popular music applications that are available today on android mobile devices. What results may surprise you.
In context of this article, it e.g. points out that zip code, year of birth (yob), gender and other id values being sent to third party advertisement companies (in this case, a company called Ando Media – but quotes another study confirming the same for e.g. AdMarvel, AdMob, comScore, GoogleAds and Medialets). The author comes to the conclusion that Spotify and Pandora collect those PII mainly for the purpose to pass it on to those advertisement companies. Seems that’s how you pay for their music. - Eye on Privacy - January 2014 (PDF, 1/2014, 12 pages; HTML)
[… this] mobile application, violated Section 5(a) of the FTC Act prohibiting unfair or deceptive acts and practices affecting commerce by failing to disclose that the app transmitted user data, including precise geolocation information and persistent identifiers, to third parties such as advertising networks. This flashlight app certainly is not the only one having done so, but this one was „publically caught int the act“ because it made it to the top apps with millions of downloads. The linked document gives some background on the FTC rulings in this case – but also goes on to implications for other apps/companies. Following that, two more cases are discussed. - On Ad Library Updates in Android Apps (PDF, 2017, 16 pages)
Discusses the various expenses involved in updating ad libraries and a.o. finds that in some (13.75%) cases, updates of apps have no chances in the apps’ own code but just in those ad libraries – which developers seem to be forced to update to not lose revenue.
-
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. ↩︎
-
See e.g.: Truth in Advertising: The Hidden Cost of Mobile Ads for Software Developers (PDF) ↩︎
-
I do that at least once a year systematically, to keep them useful for you ↩︎
-
Permissions in curly braces are „optional“ – but most times marked for developers as „highly recommended for better performance“ (in terms of money, of course). ↩︎
-
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. ↩︎
-
Aquired by AdMob in 2009, integrated into the latter, and shut down in 2013 ↩︎
-
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. ↩︎ -
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. ↩︎
-
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. ↩︎
-
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. ↩︎
-
to access the users’ email addresses ↩︎
-
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
INTERNETand, optionally,GET_ACCOUNTSpermissions, 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. ↩︎ -
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. ↩︎
-
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. ↩︎
-
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. ↩︎
-
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. ↩︎ -
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. ↩︎
-
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.“ ↩︎
-
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. ↩︎
-
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). ↩︎
-
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. […]“). ↩︎
-
Also see: Global Demo ↩︎
-
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. ↩︎
-
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. ↩︎
-
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. ↩︎
-
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. ↩︎
-
According to Metaps privacy policy, a.o. collects: Google Advertising ID (GAID), App usage, interaction with ads (click), IP addresses, plus „voluntarily provided information“ ↩︎
-
"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. ↩︎
-
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. ↩︎
-
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) ↩︎
-
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”. ↩︎
-
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”. ↩︎
-
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. ↩︎
-
Now Fyber ↩︎
-
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?). ↩︎
-
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) ↩︎
-
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 ↩︎
-
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. ↩︎
-
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. ↩︎
-
Some more were added when I studied additional material collected on the topic, as listed under Further readings. ↩︎
-
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. ↩︎
-
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). ↩︎ -
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. ↩︎
-
Also see: Underestimated Privacy Implications of the ACCESS_WIFI_STATE Android Permission ↩︎
-
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. ↩︎
-
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) ↩︎
-
Tracking the Trackers: Towards Understanding the Mobile Advertising and Tracking Ecosystem (PDF, 2016), page 1 ↩︎
-
Also see: Reports Show Aggressive Mobile Apps Want Many Permissions They Don´t Need (11/2012) ↩︎
-
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. ↩︎
-
Detecting Hidden Attacks through the Mobile App-Web Interfaces, page 8, figure 4 ↩︎