Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Android Apple Your Rights Online

Study Finds iOS Apps Just As Intrusive As Android Apps 107

Posted by samzenpus from the more-of-the-same dept.
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."
This discussion has been archived. No new comments can be posted.

Study Finds iOS Apps Just As Intrusive As Android Apps More

Study Finds iOS Apps Just As Intrusive As Android Apps

Comments Filter:

  • But unlike Android apps (Score:1, Insightful)

    by Anonymous Coward

    they don't have to ask for permission.

    • Re:But unlike Android apps (Score:5, Informative)

      by kthreadd ( 1558445 ) on Friday July 19, 2013 @04:15AM (#44325187)

      iOS apps have to ask for permissions.

      • Re:But unlike Android apps (Score:5, Informative)

        by Sockatume ( 732728 ) on Friday July 19, 2013 @04:31AM (#44325245)

        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)

          by Krojack ( 575051 )

          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:But unlike Android apps (Score:5, Informative)

        by Anonymous Coward on Friday July 19, 2013 @04:43AM (#44325309)

        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)

          by ArsenneLupin ( 766289 ) on Friday July 19, 2013 @04:53AM (#44325359)

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

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

          • 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

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

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

          by Bogtha ( 906264 )

          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'

      • Now they do but it wasn't always this way. The damage has been done.
    • Or even inform you about what permissions they need or what they are actually going to access...

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

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

          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

          • On android, for example, when installing an app, it basically tells me which permissions that app is taking for itself.

            Unfortunately, it's not always clear what exactly these permissions mean.

            • Re: (Score:1)

              by Knuckles ( 8964 )

              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.

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

    • 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?

  • The basic problem (Score:5, Interesting)

    by ArsenneLupin ( 766289 ) on Friday July 19, 2013 @04:38AM (#44325281)
    ... 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...

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

      • 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

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

            by ArsenneLupin ( 766289 ) on Friday July 19, 2013 @05:34AM (#44325523)
            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.

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

              • 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

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

        by gnasher719 ( 869701 ) on Friday July 19, 2013 @07:23AM (#44325945)

        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.

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

    • Just learned from another post that this is actually what iOS is doing. Kudo's for Apple if this is the case, for once they are doing something right!

    • Re: (Score:2)

      by Bogtha ( 906264 )

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

      It's unlikely Apple would approve an application that did that.

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

    • Re: (Score:2)

      by dc29A ( 636871 ) *

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

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

    • (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.

      • The OS would only needs to fool some malware application, not to mislead a court... or what is actually your point? There are other malware out there than the Bundestrojaner...
        • My point is that governments can use this evidence to prove that you were in the "same location" as someone else also using the same faked data.

  • It's an issue of trust (Score:5, Interesting)

    by magic maverick ( 2615475 ) on Friday July 19, 2013 @04:43AM (#44325307) Homepage Journal

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

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

        by JaredOfEuropa ( 526365 ) on Friday July 19, 2013 @06:11AM (#44325683) Journal
        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.

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

            by tlhIngan ( 30335 )

            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.

            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

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

    • One general problem with app stores that carry only free software is that not everything can be free [pineight.com]. Repositories like F-Droid and Ubuntu main/universe don't have players for rented videos because the movie studios require compliance and robustness rules [wikipedia.org] that are fundamentally incompatible with free software licensing. And their selection of things like video games is anemic because creating games requires a lot of skills other than programming for which there isn't much of a counterpart to the free softwa

    • Not only that, the software isn't Free, and so even if I want to look at the code, I can't.

      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:

      • VLC for iOS 2.0.1 source code
      • MediaLibraryKit 2.0.0 source code
      • MobileVLCKit 2.1.0-pre1 source code

      Additionally, the latest code is always available on our git repositories.

      source: VLC for iOS 2.0 [videolan.org]

  • Is a way to change permissions on the android (Score:5, Interesting)

    by Trax3001BBS ( 2368736 ) on Friday July 19, 2013 @05:32AM (#44325513) Homepage Journal

    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.

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

      by AvitarX ( 172628 )

      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)

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

  • Anyone who believed at any point that this was not the case is a fool.

  • I want two bits of functionality. One is the ability to turn off fine grained access to my phone. With mac there is a great program Little Snitch. I can install an application and tell it that it can access the internet except I don't want it phoning home to stats.application.com. Or I can say no net access at all. I want the same thing for all my applications. Generally if the application (say a game) doesn't need net access I would like to cut it off. But at the same time some applications need some net a

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close