×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Study Finds iOS Apps Just As Intrusive As Android Apps

samzenpus posted about a year ago | from the more-of-the-same dept.

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

Sorry! There are no comments related to the filter you selected.

But unlike Android apps (1, Insightful)

Anonymous Coward | about a year ago | (#44325181)

they don't have to ask for permission.

Re:But unlike Android apps (4, Informative)

kthreadd (1558445) | about a year ago | (#44325187)

iOS apps have to ask for permissions.

Re:But unlike Android apps (5, Informative)

Sockatume (732728) | about a year ago | (#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:But unlike Android apps (0)

Anonymous Coward | about a year ago | (#44325333)

I really am puzzled its not a standard feature in android, I got a android version on my N900 and the first thing I installed is LBE guard(you need a routed phone though) so that I would be able to deny/allow anything at will.

Re:But unlike Android apps (1)

skids (119237) | about a year ago | (#44330447)

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:But unlike Android apps (0)

Anonymous Coward | about a year ago | (#44336031)

It surely doesn't take much more work if you build that checking of available permissions in at the start. I see retrofitting that as potentially painful though.

Re:But unlike Android apps (0)

Anonymous Coward | about a year ago | (#44331745)

You've been able to do exactly that for years on Android. You just need something like Gemini App Manager.

Re: But unlike Android apps (0)

Anonymous Coward | about a year ago | (#44325603)

I'm switching permissions off and on for my own amusement right now.

Dude, the first rule about switching permissions is you don't talk about switching permissions - especially while you're doing it.

Re:But unlike Android apps (1)

Krojack (575051) | about a year ago | (#44327513)

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 (1)

Sockatume (732728) | about a year ago | (#44327631)

iOS 6 I'm afraid. You get location permissions and that's it.

Re:But unlike Android apps (0)

Anonymous Coward | about a year ago | (#44334085)

I (and everyone I know) does this with Android. Once you're rooted you can install an app that will force remove permissions from apps. Of course, many apps will refuse to work without their unnecessary permissions, but then you have an easy way to filter the wheat from the chaff. This is not possible on iOS.

Re:But unlike Android apps (5, Informative)

Anonymous Coward | about a year ago | (#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 (4, Interesting)

ArsenneLupin (766289) | about a year ago | (#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...).

Re:But unlike Android apps (2)

Sockatume (732728) | about a year ago | (#44325553)

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

Re:But unlike Android apps (2)

geminidomino (614729) | about a year ago | (#44326123)

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 (0)

Anonymous Coward | about a year ago | (#44326749)

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

Because Android (just like iOS) was deliberately designed to "leak" personal information. Personal information and targeted advertising is the new gold rush.

Google's motto: "Don't be evil (unless we can make a buck)".
Apple's motto: "Exploit people differently."

Re: But unlike Android apps (2)

AReilly (9339) | about a year ago | (#44326021)

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 (1)

IndustrialComplex (975015) | about a year ago | (#44327875)

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:But unlike Android apps (2)

Bogtha (906264) | about a year ago | (#44326045)

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 (0)

Anonymous Coward | about a year ago | (#44326309)

So, we're back to "You have disabled access to tracking your position. You need to enable this to continue playing".

The advantage of replying with bogus data is that the app cannot pester the user until he gets fed up and enables access.

Re:But unlike Android apps (1)

Bogtha (906264) | about a year ago | (#44326413)

So, we're back to "You have disabled access to tracking your position. You need to enable this to continue playing".

Apple reject applications that do things like that.

Re:But unlike Android apps (1)

Bogtha (906264) | about a year ago | (#44326419)

The advantage of replying with bogus data is that the app cannot pester the user until he gets fed up and enables access.

Also, applications cannot pester the user in this way. After two rejections, the requests for user location data is automatically denied.

Re:But unlike Android apps (1)

Sockatume (732728) | about a year ago | (#44327793)

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:But unlike Android apps (1)

BasilBrush (643681) | about a year ago | (#44328273)

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:But unlike Android apps (1)

atlasdropperofworlds (888683) | about a year ago | (#44331001)

Now they do but it wasn't always this way. The damage has been done.

Re:But unlike Android apps (1)

GeekWithAKnife (2717871) | about a year ago | (#44325357)

Or even inform you about what permissions they need or what they are actually going to access...

Re:But unlike Android apps (1)

Stormthirst (66538) | about a year ago | (#44325955)

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:But unlike Android apps (1)

PopeRatzo (965947) | about a year ago | (#44326193)

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 later. Except of course, that the intrusion is exactly what the developers intended.

Re:But unlike Android apps (1)

N0Man74 (1620447) | about a year ago | (#44326793)

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:But unlike Android apps (1)

Knuckles (8964) | about a year ago | (#44330227)

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:But unlike Android apps (2)

jkflying (2190798) | about a year ago | (#44326831)

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 (1)

tepples (727027) | about a year ago | (#44327071)

So am I pirating when I scoot out of range of the WLAN signal?

Re:Legit offline use (1)

Sockatume (732728) | about a year ago | (#44327811)

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:Legit offline use (1)

CanHasDIY (1672858) | about a year ago | (#44328587)

Or turn on airplane mode.

More secure? Hardly. (0)

Anonymous Coward | about a year ago | (#44325259)

I believe that iOS apps are generally more secure for various reasons, but not for the one mentioned in the article. When the user installs an app he will be looking at the requested permissions and have a bit time to think about them (at least that's what I do) and you can see all at once. When people are asked at runtime while actually using the app, they will just grant the permission. (BTW, what happens if the permission is not given at RT? The app just quits?)

Re:More secure? Hardly. (2)

Sockatume (732728) | about a year ago | (#44325335)

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:More secure? Hardly. (1)

DKlineburg (1074921) | about a year ago | (#44326181)

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:More secure? Hardly. (1)

the_B0fh (208483) | about a year ago | (#44326249)

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:More secure? Hardly. (0)

Anonymous Coward | about a year ago | (#44327827)

Most people who defend Android's design decisions are engineers who think that reading the list of requested permissions at install time is adequate protection. The assumption is that if you don't want the app to do something you'll choose not to install it.

Most people who are not engineers don't know what the frack those permissions even mean and need the context of "what was I doing when this app asked for permission" in order to know if they want their app to be able to make calls/share photos/etc.

Re:More secure? Hardly. (1)

CanHasDIY (1672858) | about a year ago | (#44328645)

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 a car, do they?

Re:More secure? Hardly. (1)

the_B0fh (208483) | about a year ago | (#44330717)

Man. What a way to twist what I wrote around. You do realize that it my stance, right? Read what AC said.

Re:More secure? Hardly. (1)

CanHasDIY (1672858) | about a year ago | (#44331209)

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:More secure? Hardly. (1)

scot4875 (542869) | about a year ago | (#44329221)

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 stock Android, the Apple fanbois will then claim that Google stole the idea and that iOS has *always* had better handling of app permissions (while also ignoring the fact that this feature has been available for years to pretty much any Android user who wanted it enough to get it).

--Jeremy

Re:More secure? Hardly. (1)

the_B0fh (208483) | about a year ago | (#44330737)

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:More secure? Hardly. (1)

jkflying (2190798) | about a year ago | (#44326843)

No, but you can see before you install what permissions it is going to need.

Re: More secure? Hardly. (0)

Anonymous Coward | about a year ago | (#44325629)

Lol, we're talking about the same users who responded to Windows' "omg, ur about to be pwned" warnings with "yes" always?

The basic problem (5, Interesting)

ArsenneLupin (766289) | about a year ago | (#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...

Re:The basic problem (2)

Sockatume (732728) | about a year ago | (#44325361)

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 (2)

ArsenneLupin (766289) | about a year ago | (#44325405)

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 (1)

Sockatume (732728) | about a year ago | (#44325487)

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 (4, Insightful)

ArsenneLupin (766289) | about a year ago | (#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.

Re:The basic problem (2)

Sockatume (732728) | about a year ago | (#44325567)

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 (1)

ArsenneLupin (766289) | about a year ago | (#44325635)

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 here as the actual perpetuators.

It's a critical mass thing. If 80% of the users don't object to the 10% of bad apps that don't respect privacy, then those 10% grow into 99.99% for lack of incentive, and the other 20% of users are now deprived of making that choice.

Re:The basic problem (0)

Anonymous Coward | about a year ago | (#44327887)

Apple rejects those apps in their review process, negating the need for the OS to misrepresent the reason for the rejection.

Re:The basic problem (1)

BasilBrush (643681) | about a year ago | (#44328377)

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 (0)

Anonymous Coward | about a year ago | (#44331733)

The issue here is - and to the point of the parent -
1. Programmers should be held to a higher standard in terms of the gracefulness of handling errors (and security) of their creations.
2. If you are exposed to an app that doesn't hold those standards, don't use it!

Your argument about the app programmer not knowing is a nonsequitor - as it all depends on what the application is built to do; hence the programmer has to be involved. An example would be an application designed to display stock market ticker information. It would have to have access to the network to do that. Now, let's say we use your model -- and the OS blocks the network due to user turning it off or denying access. The correct response is to have the application either die/fail to load, or to present a message to the effect that it is inoperative for its purpose. That can't be done by the OS.

Re:The basic problem (0)

Anonymous Coward | about a year ago | (#44336073)

I don't mind the apps knowing. There are plenty of apps I use where I can see why they requested certain permissions, but I'd still rather block them because I'm not interested in the features that require those permissions. If the devs don't handle it gracefully then I simply won't use that app and I might bitch to the devs about their shitty attitude. I don't want to use apps by devs that take a shitty attitude to their users, and seeing if they handle permissions being blocked gracefully is one way of assessing an apps quality. For me it is a rare enough case where I might want to deceive the app that I'm not really bothered about that option.

Re:The basic problem (4, Insightful)

gnasher719 (869701) | about a year ago | (#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.

Re:The basic problem (1)

Sockatume (732728) | about a year ago | (#44327657)

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:The basic problem (1)

ArsenneLupin (766289) | about a year ago | (#44325367)

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:The basic problem (1)

Bogtha (906264) | about a year ago | (#44325691)

... 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.). 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 sounds like a recipe for an incredibly confusing user experience.

The way iOS works at the moment is that if an application tries to access something like your contacts, a system prompt pops up asking the user whether to allow it or not. If they don't allow it, the application is told this and has to handle it as well as it can. If it fails to do this well, it won't be approved by Apple. Once the user has allowed an app to access something twice or refused it twice, this preference is remembered and the user isn't prompted again.

Re:The basic problem (1)

dc29A (636871) | about a year ago | (#44326083)

... 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:The basic problem (1)

MachineShedFred (621896) | about a year ago | (#44326097)

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:The basic problem (1)

Beorytis (1014777) | about a year ago | (#44326935)

(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:The basic problem (1)

ArsenneLupin (766289) | about a year ago | (#44327083)

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

Re:The basic problem (1)

Beorytis (1014777) | about a year ago | (#44330241)

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.

Re:The basic problem (0)

Anonymous Coward | about a year ago | (#44332797)

Jailbroken iOS devices can do just this...Protect My Privacy from the Cydia store will let you pick a fake location from a map, and you can then choose to Allow, Deny, or Fake a location on a per-app basis.

This is my #1 reason for NEEDING my iPhone jailbroken. Added bonus: it's fun giving Facebook checkins from Guantanamo Bay and Area 51.

It's an issue of trust (4, Interesting)

magic maverick (2615475) | about a year ago | (#44325307)

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 (1)

RogueyWon (735973) | about a year ago | (#44325417)

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 just as good for the tasks I need when "on the move" (and I do keep a proper desktop at home). I'm seriously considering moving back to a laptop PC now, because it's increasingly clear that the cheap and dirty "apps" model is no substitute for a proper combination of trusted open-source software and high quality (if more expensive) closed-source products from reputable developers.

Re: It's an issue of trust (0)

Anonymous Coward | about a year ago | (#44325495)

I am sorry but you seem to contradict yourself. the only truth to your comment is that a closed source free or paid app has to come from a reputable developer.

Re:It's an issue of trust (3, Insightful)

JaredOfEuropa (526365) | about a year ago | (#44325683)

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:It's an issue of trust (1)

RogueyWon (735973) | about a year ago | (#44326219)

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:It's an issue of trust (0)

Anonymous Coward | about a year ago | (#44327997)

Apple at least adds a layer of trust because anything on the iTunes store has been approved by Apple (if you trust Apple which you must if you bought a device that runs their OS).

Additionally the iTunes app store has user ratings and allows you to see all the other apps (and their ratings) developed by a particular developer. This ads much more transparency that just finding a website which only shows the latest couple products (and hides the several that are now infamous as trojans).

And on top of that you still have the ability to choose to only download apps that come from developers that have been vetted by whatever third party method you consider reliable for desktop apps.

So the iTunes app store adds two additional levels of security and still lets you do what you would have done anyway when vetting applications. It's by definition more secure.

Re:It's an issue of trust (1)

tlhIngan (30335) | about a year ago | (#44328373)

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 developers". It's just the App Stores make it so easy for indie devs to set up shop (selling software isn't easy - between setting up the necessary infrastructure to handle payments and all that) that we're seeing more and more of them pop up.

Of course, the fact that they're gathered all in one place also helps. And 90% of stuff is pretty much crap - just instead of dying in obscurity, they die on the app store shelf. (Yes, you may say "everything indie is good! Indie music rocks! indie games rock!" etc., but the real truth is you're only seeing the cream of the crop - the rest out there really is crap).

Re:It's an issue of trust (1)

Princeofcups (150855) | about a year ago | (#44327973)

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

Re: It's an issue of trust (0)

Anonymous Coward | about a year ago | (#44328691)

OMG, I can't hear the source code!

Free application repositories lack a few things (1)

tepples (727027) | about a year ago | (#44327363)

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 software movement. Without video games, users end up driven to consoles, whose policies tend to be even worse for free software [slashdot.org] .

Re:It's an issue of trust (1)

John Bokma (834313) | about a year ago | (#44332249)

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]

Did someone get a FUD dictionary for X-mas? (0)

Anonymous Coward | about a year ago | (#44325371)

Intrusive, fevered, invasive, curious, leaking, harvesting... Wow... That post was like a "post"er child for FUD.

Is a way to change permissions on the android (4, Interesting)

Trax3001BBS (2368736) | about a year ago | (#44325513)

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:Is a way to change permissions on the android (1)

Sockatume (732728) | about a year ago | (#44325585)

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:Is a way to change permissions on the android (1)

alex67500 (1609333) | about a year ago | (#44325599)

But you have to be rooted.

After it became illegal to root a device in the United States of America,(...)

FTFY

Re:Is a way to change permissions on the android (0)

Anonymous Coward | about a year ago | (#44325857)

What, you mean there aren't actually other countries out there? Everyone knows only murricans have internet.

Is a way to change countries more easily (1)

tepples (727027) | about a year ago | (#44327143)

For one thing, Dice is headquartered in the United States. For another, most people born in the United States lack an opportunity to choose a country other than the United States.

Re:Is a way to change permissions on the android (1)

Anonymous Coward | about a year ago | (#44325909)

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.

Re:Is a way to change permissions on the android (1)

knarf (34928) | about a year ago | (#44335445)

After it became illegal to root a device,

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.

Android permissions (1)

jez9999 (618189) | about a year ago | (#44325527)

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:Android permissions (0)

Anonymous Coward | about a year ago | (#44325615)

It does say which ones have changed.

Re:Android permissions (1)

AvitarX (172628) | about a year ago | (#44325751)

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:Android permissions (0)

Anonymous Coward | about a year ago | (#44327135)

Most paid apps do as well I suspect. Case in point realcalc+ a not too shabby calculator app. If you buy the paid app with extra functionality, the extra functionality will stop working if the device can no longer connect to the Google app store.

Re:Android permissions (2)

k_187 (61692) | about a year ago | (#44325869)

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

Analyzed 1500 apps per day? (0)

Anonymous Coward | about a year ago | (#44325793)

I'm sure they did a fine job.

Re:Analyzed 1500 apps per day? (0)

Anonymous Coward | about a year ago | (#44326067)

I'm sure they did a fine job.

They had an app do it ... or a bunch of monkeys.

It is more secure. (0)

Anonymous Coward | about a year ago | (#44325843)

Apple devices are more secure for certain threat scenarios. Fore full disk encryption iOS uses a PBKDF and a hsm to generate the key. That means that you can't really brute force the key except on the device. Android uses the pin to generate the key directly, which is much weaker.

That said, I have public key cryptography for email, and textsecure for SMS on the android device I'm typing this with. I wish Google, or just a hardware company would step up their game, because this is where it's needed.

Duh. (0)

Anonymous Coward | about a year ago | (#44326401)

Only the brainwashed believe otherwise.

Wait, this was something people believed? (1)

intermodal (534361) | about a year ago | (#44326563)

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

Turning bits off should not stop app (1)

EmperorOfCanada (1332175) | about a year ago | (#44326849)

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 access to be useful but I don't want them calling anyone I don't trust.

Then there are bits that I really don't want applications accessing such as my contacts, messages, photos, etc. And lastly there are bits that I don't want some applications wasting energy with such as a colorwheel application accessing my GPS.

The key functionality is that I don't want an application to be able to not run when I cut it off from non core functionality. It is obvious that my video camera app should give up if I cut off from the camera but it shouldn't be approved if it won't run without net access or GPS. This access restriction would also apply to applications built into the phone itself. No exceptions for google or apple.

A great example of this would be the large number of Facebook logins that want access to my friends. I can't turn that off so I don't use them. I know the second that I say yes they will spam all my friends.

But I am fairly sure that I can hold my breath before either Apple or Google allow this because it would cut off access to the sleazier aspects of both companies.

Re:Turning bits off should not stop app (1)

Sockatume (732728) | about a year ago | (#44327687)

iOS does exactly what you want, except for web access (I think iOS7 adds a toggle for that).

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?