Looks like apple is not perfect either. http://bgr.com/2012/07/05/iphone-malware-spam-app-store/ But in their case the app was pulled. A quick search on play.google.com reveals that the brightest flashlight is still available for download.
Try Vultr using this link and get us both some credit:
Shhh guys, Mauricio's coming, pretend to be keeping it on topic.
For what it's worth I use the xprivacy xposed module to manage permissions. It does require root of course but will be useful for some. Apparently the App ops settings aren't fully polished yet, but will probably be better (than xprivacy) if it ends up getting fully integrated.
rphenix: Well acording to this article App Ops is still alive in android 4.4 afterall just need to install this app. Note I haven't tried this myself.
Hmm interesting ... Is app ops part of android or is it an app?
App ops is part of Android, it's integrated with the OS but it is not available for end user access. The app you download just enables the hidden menu.
Depending on whether or not Google decide to keep it in (they have said similar things about other features in the past so it's possible it will stay), it will probably end up accessible through the development settings menu.
Edit - when I say it's part of Android, what I mean is it's been added to the source code - just appears to not be fully implemented on any current builds.
Since nobody has chimed in with a developer perspective, here's my $0.02 from working in a mobile dev shop - Android permissions drive us nuts as well. Google requires you to list all things your app could possibly do - not what it will actually do for the user using it. Great from a security/paranoia perspective, sucky from the perspective of an actual user who just runs screaming from the list, which at the time of download is mostly meaningless to them since they haven't yet used the app and understood what the permissions are needed for.
Apple (as much as it pains me to admit it as an Android fan...) has a better way - the OS asks the user for permission to access something sensitive (eg contacts, camera access) at the time the app actually needs it. It does this just once as well to minimise the nuisance factor. That way the user has a strong association between the thing being requested (eg contact list access) and the action being performed (say selecting a contact from the device to populate a form). I would argue this is much better from the user perspective than Google's approach - if an app while sitting there idle suddenly requests SMS access them it is obvious something dodgy is going on, vs the Google approach of the user accepting it at download time and then forgetting about it.
Also some of the Android permissions are horribly coarse - for example from memory if the app needs access to the contact list (say as per my example above) on Jelly Bean and later devices adding this permission into the app also adds permission to read call logs which is called out separately in the permissions list the user has to accept. Totally unnecessary - the developer in this scenario neither wants nor needs this access, but because the contact access permission is so coarse it comes along for the ride, and scares the bejezus out of paranoid users.
And then there is the example of optional features - say the app has a mode available to only some users for which the camera is required. But all users must accept the camera permission at download time, just because code is there to access the camera. An Apple device would only prompt the user for permission when the mode is being used (and the camera code is executed).
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
ID Verified
