Study Finds iOS Apps Just As Intrusive As Android Apps

wiredmikey writes "Despite fevered arguments that iOS is more secure than Android, and that Android offers developers more options than iOS, a study has found that both platforms are equally as invasive and curious when it comes to collecting user data. Security firm BitDefender analyzed more than 522,000 apps over the past year and focused on the 'intrusive behaviors' the app developer may have included in the product, such as tracking location, reading contact lists, and leaking your email address or device ID. According to Catalin Cosi, iOS applications appear to be more focused on harvesting private data than the ones designed for Android. Cosi did acknowledge that Android apps state all the permissions needed at installation time and there is no way to change the settings afterwards, while iOS permissions are requested at run-time, as the specific resource is used, making iOS a little bit more secure in practice."

Comments

Re:But unlike Android apps

[kthreadd]

iOS apps have to ask for permissions.

Re:But unlike Android apps

[Sockatume]

Furthermore you can pick and choose what permissions you give, and double check or revoke them later from one convenient "Privacy" pane. I'm switching permissions off and on for my own amusement right now.

Also the device UDID is no longer available; apps that look for it are rejected and I think the current version of iOS refuses to hand it over.

The basic problem

[ArsenneLupin]

... is that if apps are denied permission, they may refuse to work (even though the permission requested might not actually needed for the app's official purpose).

So, what we would need is a change in how permission refusal is communicated (or not communicated) to the app. The OS should always tell the app "yes you got permission", but then just fake the action (return plausible but fake location data, plausible but fake adresses, etc.). Or fail with a code not linked to permission (pretend that there is no cellular network available if user refused permission to use it)

That way, it will be much more difficult to pressure users into granting apps each and every right they ask for...

Re:The basic problem

[Sockatume]

An app which refuses to acknowledge the possibility that it might be denied permission, is an app you should not use. It's really trivial to handle, especially for a non-critical app feature.

Re:The basic problem

[ArsenneLupin]

An app which refuses to acknowledge the possibility that it might be denied permission, is an app you should not use.

The problem is, most users cave for such pressure.

Which means that suddenly you might be in a situation where all apps for a given purpose might do this. Then even the reasonable users have to either cave in or just accept that they have to do without any kind of app to fulfil this purpose.

I was in such a situation recently, when needing a replacement filter basket for my espresso machine... and had to notice that all online shops selling such spare parts would force me to accept their intrusive javascript. Eventually I caved...

It's really trivial to handle, especially for a non-critical app feature.

Problem is, if rather than just disabling a single feature, the app stops to work altogether...

Re:The basic problem

[ArsenneLupin]

We want the app programmer not to know.... The problem are not innocently bug apps, but deliberately intrusive apps. If they get back "null", they may refuse to work until the user finally caves in and grants them access (to contact database, location data, ...), that's the whole point.

Re:The basic problem

[Sockatume]

Does it matter whether a bad app uses crashing or uses nagging to force its users to acquiesce? It's a bad app trying to strong-arm the user. The benefit is that good apps have an opportunity to behave reliably when the user wants privacy.

Re:The basic problem

[gnasher719]

An app which refuses to acknowledge the possibility that it might be denied permission, is an app you should not use. It's really trivial to handle, especially for a non-critical app feature.

For example, an app that wants to read my address book must expect and handle the case that my address book is absolutely empty. Or an app wanting my location must handle the case that the iPhone doesn't know its location, because WiFi is turned off and GPS has no reception.

On the other hand, as a developer I should be told the reason why there is no data. I might want display an error message if the phone can't give me its location because the GPS doesn't work, but no error message if the user refused to allow me access to the location.

Re:The basic problem

[robmv]

CyamogenMod Privacy Guard>/a>, it gives the applications you configure that way empty data for your contacts and other privacy important data. It works like Incognito/private mode on browsers

It's an issue of trust

[magic maverick]

I like Ubuntu and Debian. They have "app stores" (apt-get install freeciv), and they work well. (I don't use the Ubuntu software center, mainly 'cause I don't want to see ads.) And, the stuff I can install from the main repositories is trustworthy. It's Free Software, and the source is available if I want to look at it. I also trust the organizations behind Debian and Ubuntu to pull software that is found to be unworthy of trust.

But, Apple? Google? I don't trust them. Not only don't I trust them, I don't trust their app stores. I don't trust the software in them. There isn't sufficient review to prevent malicious software getting in. Not only that, the software isn't Free, and so even if I want to look at the code, I can't.

And studies like this show that my lack of trust is probably a good thing. Because the software available is potentially malicious and intrusive (and I get to define what is malicious for me, and invading my privacy is malicious).

Re:It's an issue of trust

[JaredOfEuropa]

Open source is not trustworthy by default. If you download and use a somewhat obscure bit of FOSS, do you really check the code yourself for bad behaviour, or do you assume that others have? That's a dangerous assumption. In contrast, Apple and Google add a layer of trust to closed software. They're saying "If you trust us, then you can trust that the apps you download do not mess around with private APIs and therefore cannot steal your contact list or other private data without your consent.". They take care of checking code for you (on a basic level). I don't trust Apple in every matter, but I do trust that they perform decent checks on the software in the App store, and I trust their OS enough to not worry about apps bypassing privacy controls using trivial exploits.

That works for developers as well: by passing Apple's QA, I gain a modicum of trust with potential customers while keeping the source code to myself. The App store model allows honest small time developers to make some money off their work.

Re:But unlike Android apps

[Anonymous Coward]

iOS apps don't ask for permission.

Accessing the framework APIs will prompt the system to ask for permission, on behalf of the application. Basically, most APIs will work irregardless of what the user chooses. What those APIs return is directly related to the users choice- for example, if the user says "no" when the application attempts to determine your location via Core Location, then the CL APIs will still work- they'll just return useless information (basically hardcoded to nothing). The other APIs work in the same way.

This was done for backwards compatibility (so applications don't break just because the privacy stuff decided you can't get access to XYZ- the APIs for XYZ still work as expected, they just don't return any usable information) and so that applications can't side step the process of asking for permission but attempting to access the APIs anyways.

It is possible to circumvent all of this by going around the system frameworks, but that is not trivial in the least- and Apple will smack you down hard for even attempting to access the private APIs you need to do so. You either go through their public APIs and get on the app store, or find some other way onto user devices (in which case the user is responsible for whatever stupidity they're going to run as root on their handheld).

Re:More secure? Hardly.

[Sockatume]

If you don't give permission, a good app will pop up a message explaining why it wanted to use that feature, while a bad one will usually just die or act upon null data (e.g. show your contacts as empty).

FWIW I find that I only give apps permissions they actually need with the runtime system. If I never use a feature in an app, it never gets permission to use it, so I know exactly what it can access from the moment I install it. If it makes an unreasonable request, it's rejected and I get on with what I actually want the app to do. Facebook can see my photos because I use it to post photos, but it doesn't know about my location or my contacts.

Re:But unlike Android apps

[ArsenneLupin]

Accessing the framework APIs will prompt the system to ask for permission, on behalf of the application. Basically, most APIs will work irregardless of what the user chooses. What those APIs return is directly related to the users choice- for example, if the user says "no" when the application attempts to determine your location via Core Location, then the CL APIs will still work- they'll just return useless information (basically hardcoded to nothing). The other APIs work in the same way.

This was done for backwards compatibility (so applications don't break just because the privacy stuff decided you can't get access to XYZ- the APIs for XYZ still work as expected, they just don't return any usable information) and so that applications can't side step the process of asking for permission but attempting to access the APIs anyways.

Very sensible choice. Why can't Android do the same? Or for that matter, Javascript on desktop browsers?

It is possible to circumvent all of this by going around the system frameworks, but that is not trivial in the least- and Apple will smack you down hard for even attempting to access the private APIs you need to do so. You either go through their public APIs and get on the app store, or find some other way onto user devices (in which case the user is responsible for whatever stupidity they're going to run as root on their handheld).

Now, this is less optimal. The OS or runtime should enforce well behavedness, not the app-store. There might be many reason why a user might bypass the app-store (such as getting apps that compete with Apple's built-in functionality, or are not up to Apple's morality standards), he should not be punished for this choice by having the app bypass system security...

In java, applets have to respect the sandbox rules no matter where you got it from. There is just no way to use "private APIs" that give extra rights. It's enforced by the run-time (well, unless there are security holes in that runtime, but that is a different discussion...).

Is a way to change permissions on the android

[Trax3001BBS]

But you have to be rooted.

After it became illegal to root a device, Google store remove anything that interfered
with another programs ability to do what it does, firewalls, adblockers, HOSTS files, permission changers...

From the AdAway site:
AdAway is not available on Google Play! It was removed by Google due to Violation of section 4.4 of the Developer Distribution Agreement.
Please install it from F-Droid. https://code.google.com/p/ad-away/

My XOOM tablet is rooted (jailbroken / mine) I have the old "permissions" from Google play
that does change permissions of a program, as well as having a firewall and a HOSTS file installed.

Can't vouch for it as it's a very quick search but http://code.google.com/p/android-permissions/ claims to be able to do this as well.

To see what information an Android program can send, goto www.Rovio.com and read the Tos and Privacy Policy
it's a fav site of mine showing what's collected. Rovio.com is Angry Birds for one, ASTRO file manager reads
the same way both very popular programs.

Re:But unlike Android apps

[Sockatume]

I think Android will do the same, it's just an engineering challenge. Apple only got around to it with iOS6 last year.

Re:Android permissions

[k_187]

I think its just a feature of 4.1+ but it does tell you what the new/changed permissions are when you install.

Re: But unlike Android apps

[AReilly]

Old school apps, the programs we used to run on PCs automatically had access to everything that the user who ran it had access to. And that didn't seem to be a problem. People would report "spyware" and programs that did badness would be shunned.

It seems that the fine grain permission protections of the mobile platforms have the inverse effect to the seeming intention: permission explicitly granted is exploited ruthlessly. And that seems to still be OK.

Re:But unlike Android apps

[Bogtha]

What those APIs return is directly related to the users choice- for example, if the user says "no" when the application attempts to determine your location via Core Location, then the CL APIs will still work- they'll just return useless information (basically hardcoded to nothing). The other APIs work in the same way.

No, that's not true. iOS tells the application when something is unauthorised. For example, you can call [CLLocationManager authorizationStatus] at any point, and if you ask for the user's location and get denied, it sends your delegate a locationManager:didFailWithError: message saying that the user denied the request. The same is true for other APIs. You don't get fed bad data.

Re:But unlike Android apps

[geminidomino]

Very sensible choice. Why can't Android do the same?

It can, and has been able to do so for awhile. Modifications for it to do so were refused by the CyanogenMod devs, on the grounds of "Not wanting to piss off google and/or devs." I presume they're not in the main system rather than a 3rd party mod for the same reason.

I've been using Android devices for a few years, and whether or not I can get PDroid on them is one of my suitability criteria now. If iOS really has that function baked-in, then it's an example of something Apple did right that Google whiffed.

Re:But unlike Android apps

[jkflying]

The thing is, ad-supported apps need network access, and if you could disable the network access permission then you'd essentially be pirating the app. Of course, nothing stops you from using DroidWall to block it manually, but that requires you to root the device, which means that Google isn't *enabling* it, and as such they don't have to endure the wrath of angry app-developers.

Which is why Google doesn't allow you to pick and choose at install, even if they *do* tell you what permissions are needed.