Study Finds iOS Apps Just As Intrusive As Android Apps 107
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."
But unlike Android apps (Score:1, Insightful)
they don't have to ask for permission.
Re:But unlike Android apps (Score:5, Informative)
iOS apps have to ask for permissions.
Re:But unlike Android apps (Score:5, Informative)
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.
Re: (Score:2)
It takes less time to write an app that assumes it has a set of permissions, rather than an app that checks to see whether it has a certain set of permissions, and if not, does something sensible.
What really needs to happen is the App stores need to start allowing the customers to filter their searches on which permissions apps require.
Re: (Score:2)
I'm confused. I don't see this and never have on my iPad. Is it only in iOS versions > 5.1.1? I have the first gen iPad so I got one of those "fragmented" versions of the iOS.
Re: (Score:2)
iOS 6 I'm afraid. You get location permissions and that's it.
Re: (Score:2)
How?
Re:But unlike Android apps (Score:5, Informative)
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:But unlike Android apps (Score:5, Interesting)
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...).
Re: (Score:3)
I think Android will do the same, it's just an engineering challenge. Apple only got around to it with iOS6 last year.
Re: (Score:3)
Very sensible choice. Why can't Android do the same?
It can [liliputing.com], 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 (Score:2)
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: (Score:2)
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.
My old school PC did not have an always-on internet connection, it did not have a GPS chip installed in it, it did not have all of my contacts packaged behind a convenient API (my contacts were handwritten in a little book) When I didn't want a program to have access to the internet, I didn't grant it access to the internet via the firewall, or I didn't even run it while the modem was connected.
Re: (Score:3)
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'
Re: (Score:2)
Apple reject applications that do things like that.
Re: (Score:2)
Also, applications cannot pester the user in this way. After two rejections, the requests for user location data is automatically denied.
Re: (Score:2)
What if it's an app with a legitimate function the user simply declines to use? I don't want my Twitter posts geotagged with my position, but I don't want them all geotagged with randomly chosen locations in central Borneo either.
Re: (Score:2)
There is an API to know whether the app has a permission or not. If a twitter app is saying you posted from central Borneo when you didn't, that would be the apps fault. But it probably wouldn't get past an app store review anyway.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Part of the problem here is that clueless users don't understand permissions. They will assume that they have to grant the app all the permissions, or it won't work.
Re: (Score:2)
The fact that you can't just pick and choose permissions when installing the app is also a problem.
On android, for example, when installing an app, it basically tells me which permissions that app is taking for itself. There's no reason why those permissions couldn't be selectable right at that point, instead of having to dig for a setting late
Re: (Score:2)
Unfortunately, it's not always clear what exactly these permissions mean.
Re: (Score:1)
Exactly. If app x has the option to let me send something to users in my address book (and which app hasn't), I understand that it will need access to the address book. That still does not tell me whether it will use that access to send all my contacts to its server.
Re: (Score:3)
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.
Legit offline use (Score:2)
Re: (Score:2)
If it's got ads you were only ever renting it in the first place. If the dev lets you keep playing without ads, or shuts down the app automatically, is their perogative.
Re: (Score:2)
Or turn on airplane mode.
Re: (Score:2)
they don't have to ask for permission.
Now let's assume for a moment that's true - what does the fact tell us that despite what your claim implies "iOS apps are just as invasive and curious about user data as Android apps are" and not more?
Re: (Score:3)
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 act
Re: (Score:2)
Can you do this with Android? I can't seem to find a way. It looks like I have to accept everything or nothing. Maybe I'm just not trained.
Re: (Score:2)
Cannot. Unless you root it and install 3rd party stuff.
No idea why Android users think the ability to revoke a permission is not important.
Re: (Score:2)
No idea why Android users think the ability to revoke a permission is not important.
Really? You pretty much call it right there - they're users, not devs, so their knowledge of the technology is limited. Nobody's told them why it's important, so they don't know or care.
Which is completely understandable, and not a reason to be jerks to them or treat them like idiots (not saying that's what you've done, but you have to admit it's a common behavior among the technologically experienced). After all, no one expects you to be an expert on hydraulics and internal combustion just because you use
Re: (Score:2)
Man. What a way to twist what I wrote around. You do realize that it my stance, right? Read what AC said.
Re: (Score:2)
You do realize that it my stance, right?
What your stance? Mongo not understand poorly formatted sentence structure.
Lol, sorry, can't help but bust your balls.
Read what AC said.
Did - your response doesn't seem to have anything to do with their comment. Are you sure you didn't mean the parent (DKlineburg's) post? Or can you expound a bit and give some context?
Re: (Score:1)
It's amusing to me that for the longest time, Apple fanbois mocked Android users for having the permissions list which "nobody reads anyway," while having *no* information or control over what iOS apps used.
Apple finally gets something that is clearly superior to what Android has out-of-the-box (though it would still be nice to know an app's permissions list before downloading) and suddenly they have no idea why Android doesn't also do it this way. In another 6-12 months when this feature is rolled into st
Re: (Score:2)
Apple did this as a result of Path and the various state AGs telling them they need to do a better job. So Apple came up with a pretty damned decent way of doing it.
The same issues and state AGs were involved with Android too. Since Android already had a model to start with, why didn't they improve on it, instead of sitting on their ass for so damned long?
*THAT* is the question.
Re: (Score:2)
No, but you can see before you install what permissions it is going to need.
The basic problem (Score:5, Interesting)
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: (Score:3)
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: (Score:3)
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 javascrip
Re: (Score:2)
I mean it's trivial for the programmer to handle. iOS 6 returns "null"; if you get that instead of the contact database, handle it right.
Re:The basic problem (Score:5, Insightful)
Re: (Score:3)
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: (Score:2)
Does it matter whether a bad app uses crashing or uses nagging to force its users to acquiesce?
Both would be bad, especially if the crashing is done deliberately (nagging is always deliberate, I presume...). But nobody advocates either of them (well, except malware authors...)...
It's a bad app trying to strong-arm the user.
Exactly my point...
The benefit is that good apps have an opportunity to behave reliably when the user wants privacy.
True enough, pretending to grant permission may lead to a less reliable operation, but that may be the price to pay in an ecosystem where most apps couldn't be trusted to respect the user's privacy otherwise. It's a sad world, and those that "stand by watching" (while they still have a choice) are as guilty
Re: (Score:2)
Such a tactic won't work on iOS. Firstly once it gets told no twice, the user doesn't even get the option again, the app will always receive a no from the OS.
Secondly, any unreasonable demands such as you outline would probably result in a rejection by the app reviewers. iOS apps are expected to continue to be able to do things that can reasonably be done without the requested permission.
Re:The basic problem (Score:5, Insightful)
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: (Score:2)
Indeed. I think the current version of iOS returns "null" if there's no permission, and a valid but empty dataset if no data is available.
Re: (Score:2)
Re: (Score:2)
It's unlikely Apple would approve an application that did that.
Re: (Score:2)
... 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).
Custom ROM users on Android no longer have those issues. They can pry CM 10.1 and Privacy Guard out of my cold dead hands.
Re: (Score:2)
That is basically what iOS does. If you don't grant it permission, it still returns the expected types of data, but the data is essentially empty.
Re: (Score:3)
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 [arstechnica.com]
Re: (Score:2)
(return plausible but fake location data, plausible but fake adresses, etc.).
Then there will be a record (admissible as evidence) connecting you with other users whose devices used the same plausible but fake information.
Re: (Score:2)
Re: (Score:2)
It's an issue of trust (Score:5, Interesting)
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: (Score:2)
I do get the impression that the tide's starting to turn a bit of late and that people are starting to realise the drawbacks of the Apple/Android app-store model.
Yes, the applications might be cheap or free, but when they're coming from obscure and opaque closed-source developers with no public track record, there's generally a price to be paid somewhere along the line, either in the form of IAPs or privacy/security problems (or both).
About 2 years ago, I replaced my laptop with an iPad, as it seemed to be
Re:It's an issue of trust (Score:4, Insightful)
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: (Score:2)
Not trustworthy by default - absolutely. I think I failed to make that point clear.
But there are certainly projects and products that have become trustworthy over time - both open and closed source.
By contrast, the trend on the Apple/Android app store seems to be towards studios that pop up out of nowhere, based in obscure parts of the world, with no kind of track record and no means of recourse when things go wrong.
Re: (Score:2)
Is this a good thing or bad thing? I mean, if you're a software developer in Russia, Romania, or other "obscure part of the world", how do you earn a living? Move?
Or how about a small time developer in middle of nowhere USA? Last time we deal with them, we usually called them "indie develo
Re: (Score:2)
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?
And if you are using a binary, then checking the source code is mute. Unless you compile it yourself, who's to say what you are using. Of course, can you trust your compiler... :-)
Free application repositories lack a few things (Score:2)
Re: (Score:2)
VLC for iOS can play all your movies and shows in most formats directly without conversion.
: :
You can find the source code for the last release here:
Additionally, the latest code is always available on our git repositories.
source: VLC for iOS 2.0 [videolan.org]
Re: (Score:2)
Is a way to change permissions on the android (Score:5, Interesting)
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/ [google.com]
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/ [google.com] 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: (Score:2)
If there's no consistent way of handling an app's permissions, then those permissions-fudging apps make other developers' lives very difficult. I can imagine that's why Google wouldn't want them on the store.
Re: (Score:2)
But you have to be rooted.
After it became illegal to root a device in the United States of America,(...)
FTFY
Re: (Score:2)
There are, but it isn't illegal to root a device here in Europe. Once you own it, it's yours, you do whatever the f*** you want with it.
Is a way to change countries more easily (Score:2)
Re: (Score:1)
Re: (Score:2)
On Android you can use the XPrivacy module for the Xposed framework to spoof permissions to apps - i.e. fake location data, fake phone number, fake contacts, etc.
Very nice program.
XPrivacy Android 4.0+
http://forum.xda-developers.com/showthread.php?t=2320783 [xda-developers.com]
https://play.google.com/store/apps/details?id=biz.bokhorst.xprivacy [google.com]
Requires Xposed to be installed first.
http://forum.xda-developers.com/showthread.php?t=1574401 [xda-developers.com]
I'll see (how / if) this works on my U.S. Motorola Xoom
Re: (Score:2)
Where did that happen? It is perfectly legal for me to gain root on any device I own, never mind what any EULA might state.
Re: (Score:2)
Where did that happen? It is perfectly legal for me to gain root on any device I own, never mind what any EULA might state.
Looks like Jan 26th 2013 - http://yro.slashdot.org/story/13/01/25/144204/unlocking-new-mobile-phones-becomes-illegal-in-the-us-tomorrow [slashdot.org] The /. article summery says "While this doesn't apply to phones purchased before the window closes, this means that after 1/26/13, for any new mobile phone you purchase, you'll have to fulfill your contract, or break the law to unlock it."
I feel the same way you do, if and when I get a new phone I'll be rooting it, it's a security thing. One of the sites I use is still goin
Android permissions (Score:2)
I've never understood why, when you get an Android app update and the permissions are changed, it goes ahead and lists ALL the app's permissions again rather than just the new ones. And they are so vague as well, like "access to the network" or something. In practice, I just ignore the permission requirements, rendering the system totally worthless.
Re: (Score:1)
unfortunately most free apps require access to networks too, as they are ad supported. If it has an invite mechanism it needs access to your contacts too, basically meaning every app could very well be a spam harvester and that the system is useless.
Re: (Score:3)
Wait, this was something people believed? (Score:1)
Anyone who believed at any point that this was not the case is a fool.
Turning bits off should not stop app (Score:2)
Re: (Score:2)
iOS does exactly what you want, except for web access (I think iOS7 adds a toggle for that).