Android’s App Permissions Were Simplified – Now They’re Less Secure | Hacker News Reader

Android’s App Permissions Were Simplified – Now They’re Less Secure

howtogeek.com

104 pointsedoloughlin69 comments

I never understood why the permissions are so generic. When I see what permissions apps require, I shiver. It would be much better if it just demanded the developers to describe what they need the permissions for. What would be even better is that I could choose to enable some permissions on a case-by-case basis. That way I'd feel more secure and less frightened.

Android has some big app security issues to address, and they just... seem to be moving in the opposite direction. I've seen this update and it simply doesn't make sense to me. It didn't make the permissions more clear, it made me more scared of what might be hiding underneath all that.

I don't remember ever stopping an app installation when I saw suspicious permissions—I just assumed they were used for something, and I guess that's what 90% of the people would do. It would make all of them more secure if they could choose a small "ask me every time" option next to permissions that don't seem quite right, but may be legit.

Or overhaul the whole API. It's really a mess at times. Not just security. I have a beef with the horrible ways to address ridiculous hardware and software fragmentation, right from the ways you specify design and looks to using API features not available everywhere, or falling back to reasonable defaults if there isn't a hardware component you need.

I haven't developed for iOS, but I imagine it's much better than Android as a platform to develop on.

you can choose to enable permissions on a case by case basis if you install XPrivacy. You can either enable/disable permissions upfront, or have XPrivacy prompt you as an application attempts to access various functionality.

The downside is it requires root, but it works very very well.

http://forum.xda-developers.com/xposed/modules/test-xprivacy...

What happens when you deny? That's the problem I have: I need intelligent denials. Like 'fake GPS location' or 'fake contacts'.

XPrivacy provides fake information for a several permissions, including location when an app is denied that permission. You can manually set or auto-randomize the fake information. People often ask me why I'm sending them Facebook messages from Pyongyang.

That's exactly what it does. It feeds the application with fake or no data. There's no other way to do it due to Android's (in my opinion fundamentally flawed) security model.

xprivacy provides graceful denial of permission by providing false (potentially randomized) information. For example, rather than deny internet permission it will trick an app into thinking the internet is disconnected. Instead of denying GPS access it will tell the app that you're in a user-defined or random location (based on your settings).

I'm using xprivacy. It is a pain in the ass but does give me the functionality you mentioned. Root required. Asks with popup on requested permission. Tracks app permission request history. Fresh installed apps restricted by default. I paid for the pro/donation version which fetches community curated restriction lists. Honestly I don't know if its worth the bother but seems like the least I can do. I do get some comfort finding many apps I install actually use less permissions than they ask for at install.

Developer-supplied descriptions don't help: If you're worried that an app might use its permissions inappropriately, you should also be worried that the developer will leave inappropriate uses out of whatever explanation they supply.

"Contacts required so we can highlight their names in incoming messages. [And spam them, but we're not telling you that...]"

Are you familiar with Cyanogenmod? http://www.cyanogenmod.org/

Not available for my phone, sadly.

Here's how Android could fix its permission system:

Take contact lists as an example.

Many programs request access to your contact list. Usually, this is so that they can display back to you a contact picker that lets you choose some set of contents which you want to share with, or otherwise invite to use the app. A few bad apps will just spam your contacts without your approval.

How could we make this more secure? Well, imagine that Android itself implemented a contact picker API. Instead of requesting access to contacts upfront, a program would call an API to say "Please ask the user to select some contacts for purpose X". The platform itself would then render a contact picker UI, and the user would pick some contacts. Only the chosen contacts would be returned to the app.

As far as the user is concerned, for legitimate apps, the UX I described is exactly the same as what they get now, except that the app doesn't have to request general access to the user's contact list upfront, and thus the whole thing is more secure. It's strictly superior! And this approach -- of inferring security from decisions the user is making anyway, by making those decisions happen in privileged UIs rendered by the platform -- turns out to extend to far more than just contacts.

This is the model I'm currently implementing in https://sandstorm.io (a platform that can be summarized as "Android for your personal server").

Android was in fact meant to work this way, with apps providing such functionality through intent filters that match the PICK or GET_CONTENT actions.

But Android is also supposed to work through ContentProvider components that enable access to databases. Sometimes you need more than a PICK action performed by an external app. As in the case when you want to make an alternate implementation of a contact picker.

This is why the issue has to be addressed directly, by making many if not all permissions optional, and settable per app. Handling a SecurityException is not burdensome. Much of the permission overreach is due to crappy "behavioral targeting" data collection that doesn't really work. Nobody will miss it.

Android does have an API to do that, and as far as I know it's always had this ability. The problem is that developers aren't interested in using it. The stock contact picker can mess with an app's "flow" and it might not match the overall design of the app. Developers would rather implement their own contact picker than use the one the OS provides, and that requires permission to read all contact data.

In that case, I'd suggest the following:

1) The Android UI designers need to get on it and figure out how to make the contact picker more acceptable to developers. This could involve adding some flags that adjust the look and feel. But keep in mind that Android apps are all supposed to be following common design guidelines anyway, so apps shouldn't be excessively customizing common elements.

2) Don't let apps request access to all contacts in the first place. Don't give them any choice except to use the picker. Obviously it's far too late for this now, but if it had been done this way in the beginning, then there would actually be pressure to make the system picker work acceptably.

Argh, no. The problem with Android is the lack of granularity! For example, the permission a music player needs to know when to pause if you're taking a call also lets that music player see who you're calling.

I suspect this is why people on Android (including myself) get honestly scared when they see the permissions most apps need. They're way, way too broad for what the apps need to do, but the app developers have no choice as there's nothing more fine-grained.

> For example, the permission a music player needs to know when to pause if you're taking a call also lets that music player see who you're calling.

Why does that take a permission? Can't Android just tell an app "your sound is being paused", cut sound, and display the dialog?

It sounds crazy to me that apps actually have to cooperate on this kind of thing, why do they even get a choice?

Yeah, it's also one of the permissions that makes you wonder why the app needs it.

Right. Android permissions are a kludge to work around an insecure OS API design.

How do you mean? How do you tell a user that an app can be expected to use the camera or send SMS messages? Permissions make sense; you can't abstract away the fact that people want to know what an app can do.

>Can't Android just tell an app "your sound is being paused", cut sound, and display the dialog?

I don't know if it can, but it doesn't. To respond to external audio changes, an app has to use AudioManager.OnAudioFocusChangeListener [1]. You can then define behavior for various cases, like AUDIOFOCUS_LOSS (another app has started playing audio, don't expect it to stop), AUDIOFOCUS_LOSS_TRANSIENT (another app has started playing audio, but it might stop soon so be ready to regain focus) and AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK (another app has started playing audio but it's temporary, so you can just lower your app's volume until you regain focus).

This is all voluntary. By default, an app playing audio won't respond to these signals at all. And how you respond to them is voluntary too - if you decide to just lower your app's volume instead of pausing the audio, even though you didn't hear CAN_DUCK, there's nothing to stop you.

If you want to pause audio when the headset is unplugged, you have register a receiver for the ACTION_AUDIO_BECOMING_NOISY intent. By default audio will continue playing.

>It sounds crazy to me that apps actually have to cooperate on this kind of thing, why do they even get a choice?

Some people might not want their music player to pause every time they get a new text message or email alert.

[1] https://developer.android.com/reference/android/media/AudioM...

> Some people might not want their music player to pause every time they get a new text message or email alert.

Yes, but that shouldn't be the apps choice.

Why not?

The phone state/identity permission is so moronic that it must be intentional on Google's part. There's no need for a permission to determine if the "phone" part is active. And certainly not to tie it into your phone ID and call info.

I usually hate assumptions of malice, but I can't see any engineering reason here. Yet training users to accept tracking is in Android's favor.

The problem with permissions on Android is that it is an all or nothing choice. You either grant all the permissions an app asks for or you decline, in which you can't use the app.

Is it really that difficult to have a list of fine grained permissions presented to the user with on/off selections? They can all be on by default but it at least gives the user the option to have an app NOT to access your contacts if it clearly has no business doing so in the first place (some dumb game or something).

If an app is not granted a permission it's up to the app to deal with that.

The likely result though is that the app will simply refuse to run if not granted the permission.

If so, it clearly illustrates the nature of the app. I.e. it's a bunch of fluff designed to harvest peoples contacts or whatever. Or maybe just lazy developers.

At least it gives me as a user a choice (which I guess I already had with the blanket permissions scheme) but it also gives me as an app developer the opportunity to create a better app that's more trust worthy.

The app doesn't need to know that it hasn't been granted permission.

(I.e. stub the api, have it return mock data.)

Exactly. I do this with XPrivacy for every single application I download: deny access to contacts, Google/Facebook Account, Phone Serial Number, deny access to network if the application doesn't need it.

I've never had an application refuse to run because of it, and I'll never use a phone without XPrivacy again (it's scary what some apps request).

That could have negative consequences. Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear.

Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures?

If you fake GPS data than if the user accidentally turns off location access on an application that needs it the app has no way to inform the user that it won't work well. As far as your run logging software knows you are now just running on the same treadmill for the rest of your life.

Just seems like you're likely to create situations that are confusing/suboptimal for users. Let the app know what's going on. If the app doesn't behave well in that circumstance it should be removed from the store or punished by users with poor reviews.

The best is the enemy of the good.

True, it could have negative consequences. But aren't the negative consequences of the current system even worse?

Let's say it takes a permission to play sound. If you don't tell the app they can't play sound they may spend a lot of CPU and battery generating music that no one will ever hear.

So the phone uses more CPU and battery. It's not that big of a deal.

Or if you stub in the photo APIs, what does an app do when it tries to find a photo to show and the user said "no". Should Android pretend there are no pictures? Return some fake stock pictures?

Yes, Android can tell the app that there are no photos.

We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?

"Give apps everything" and "lie to apps" is not a binary choice. There is a third option, the one iOS takes. Inform the program they don't have access to that information.

> So the phone uses more CPU and battery. It's not that big of a deal.

Battery life is very important in a phone.

> Yes, Android can tell the app that there are no photos.

It could also tell the app "You have been denied the GPS permission."

> We are all accustomed to using GPS-related apps when we have no GPS signal. How is this any different?

Really? I'm not. And what if turning off GPS was accidental? I'm used to apps telling me "X won't work because GPS access has been disabled." Just breaking the experience with no way of notifying the user why their run logger stopped logging runs is not acceptable design.

It's not an all-or-nothing choice. You could easily have a 3-way toggle between "Allow - Refuse Permission - Send Mock Permission". By default you refuse any permissions you don't want the app to have. If it starts behaving badly, you send the mock permission.

Plus, as others have said, there's nothing wrong with giving users the option.

In web development there is this notion of Progressive Enhancement [1]. It basically means that if certain functionality is not available you either disable the features that make use of it or you implement an alternative means of making the functionality work.

I understand that permissions are a little bit different but I believe that a similar approach would work with permissions as well assuming that Android would supply a new advanced permissions sub system. With this, if an app isn't granted a specific permission it can either disable the feature (maybe making clear to the user that this is the case) or implement some other alternative functionality.

E.g. an app hasn't been given the permission to read a user's current geo-location. In that scenario the app could ask the user to manually enter a location (e.g. by selecting a position on a map).

Within the current permissions system you could only doing with mocking, as you stated, which I personally find a bit of a hack and probably very confusion to the user.

http://en.wikipedia.org/wiki/Progressive_enhancement

That depends on your model for the developer. If the developer is trying to exploit the user, then he may make the app refuse to run. Or if the developer is to lazy to handle not having the permission, he may allow the app to crash.

However, there are also cases where the developer wants to add a useful, but not necessary, feature which requires additional permissions.

> Is it really that difficult to have a list of fine grained permissions presented to the user with on/off selections?

Difficult to do at all? No.

Difficult to do without horrible UX? Yes. Fine grained permissions means apps that do useful things need lots of them, and presenting all of them with "on/off selections" is likely to be both ugly and confusing for most users.

You'd think, but the Blackphone's Security Center manages to do that very easily, with great UX. I use XPrivacy on my HTC One and the UX is a mess of mystery buttons and weird, technical options. Blackphone has a on/off switches for things like "Camera & Audio", "Record audio", "Read contacts", etc.

There's also a tab for non-privacy-related permissions, e.g. vibrate, notification, keep awake, etc, which are on by default, to make sure the app isn't unnecessarily limited by default. It's miles better than the default Android permissions system, and one of the features I like best about the phone.

Android could very easily implement something like that, with a dialog asking if the user wants to grant the permission, with perfect backwards compatibility (since there are devices/software that does it now), and I hope they do.

With a hierarchical UI, the permissions can be controlled easily as finely or coarsely as desired. Something like this:

     - [*] Phone
     |  |--[ ] Make outgoing calls
     |  |--[ ] Answer incoming calls
     |  \--[X] Read call log
     |
     + [X] Access Location Services
     |
     - [ ] Network
     |  |--[ ] Outgoing connections
     |  \--[ ] Incoming connections (listen)
      ...

I think that presenting a list of toggleable permissions isn't the problem. The problem is that all the apps out there right now depend on having all the permissions that they ask for, and you'll end up with random crashes all the time when users deny permissions.

I think that eventually app coders would change their code to degrade gracefully when denied access to something, but in the short-term, people would think that Android was unstable.

I've been using App Ops for a few months now on a rooted phone and I've turned off a good deal of permissions for various apps. I haven't had any force crashes from that so far. I expected it to be a bigger problem than it is.

That's good to hear, but how representative of a sample are your apps? I think more tech-oriented people gravitate towards well-coded apps that deal with exceptions well. There's lots of poorly-coded apps that don't.

You may certainly be right on that front. I have no idea how well-coded most of the apps are, but my most heavily-used apps tend to be stable ones just by virtue of the fact that when apps become unstable, I find replacements. My guess is that many people have the same workflow. That said, I don't use any social networks, I don't play very many games on my phone, and I don't have any children, so I don't have any of these apps where you interact with a cartoon cat, or that show you arbitrary colors and play noise or otherwise distracts children, so there are certainly large subsets of the app ecosystem that I really am not taking advantage of.

I think this would only work with a new "advance" permissions sub-system. Introducing a new permissions sub-system has three benefits; 1) old apps will continue to work 2) the old system can be deprecated at some point in time giving developers ample time to upgrade their apps 3) new apps can start to use the new system creating more trust between the developer and the user.

This is a solvable problem - the trouble is that the various platforms are competing for developers and for app-ecosystem size.

It's extra work for a developer to handle a "permission denied" exception for each external call, but they can do it. A changeover could be done by grandfathering old apps, but requiring all new apps and updated apps to accommodate fine-grained permissions.

If customers had fine-grained control, many apps could no longer be monetized without direct payment from the consumer. An example: The free 2048 app surely doesn't need internet access to run, but it needs it to serve ads.

Extra work and loss of revenue --> grumpy developers switching to other platforms.

It's solvable but it would lead to a lot of short-term pain that Google's not willing to put up with. Who do you think would get blamed when all the apps stopped working correctly?

Another example of why this trend of "simplification" in software is really disturbing.

core idea here — making Android app permissions comprehensible to normal users — is good.

What sort of "normal users" didn't understand the previous system!? What sort of "normal users" wouldn't know the difference between e.g. sending and receiving SMS, or the camera and microphone?

Instead of making software for idiot users, how about expecting them to have a little knowledge and be able to find more? It's even funnier when you realise this change is coming from Google, who runs services that almost everyone uses to find information. In general the big effect this change has is people will know less about what the software on their device is doing, and also be less inclined to ask questions about it --- because details are replaced with vagueness, they won't know what to ask. This also gives power to Google and the app developers to make privacy-disrupting changes without the users knowing. Taking away control and detailed information is the perfect way to minimise dissent in your userbase and have them think and do what you want them to.

Under this sugar-coated guise of "simplification", "convenience", "minimalism", etc., users are gradually being converted from individuals with the power to make their own decisions, to consumers who are complacent followers not knowledgable enough to revolt. The simplest life, where others in power make all your decisions for you, is one of complete submissiveness. My reaction to this can be summed up in 3 words: Do not want.

On the one hand, I have nearly written this exact thing before. On the other hand, I've heard many people whine about the relative complexity of Android, on many levels.

What's funny is that I'm completely at loss at the new system. All of the permission are either so broad that they could mean anything, or so intrusive that all available apps now basically spy on my entire life.

If I can't understand their scope, I have no idea how the metaphorical average user will.

Android permissions are entirely useless. They aren't permissions since you can't actually turn them off. All they are is a bit of warning as to what the app does. When you install a flashlight app that says it need to read your contacts, it would be MUCH BETTER for Google just to present a warning screen: "This app will upload your entire list of contacts, everyone you know or have ever communicated with, to its own servers. Do you wish to proceed [Y/N]?"

That would actually be an effective warning.

But really, Google doesn't want effective warnings.

I'm a coder, when I see a warning I ignore it, I think most people see the warning text will ignore it just like me. Warning is a good way to notify users of potential threats, but it's not the fundamental way to solve the problem.

> I'm a coder, when I see a warning I ignore it

You shouldn't.

Thank you for your reply. Next time I try to solve the warning message.

Having more fine grained permission controls for power users would be good, but it wouldn't be enough to fix Android's current security model. Most people don't read the permission list (even the simplified one) when installing a new app. Most people aren't power users who would take the time to understand and fiddle with Privacy Guard-like controls.

Granting all-or-nothing permissions at install time is not a viable security model for a consumer-oriented operating system. It could work in an enterprise environment where each new app has to be approved by management and go through a lengthy 'certification' process. However, unlike enterprise apps, Android has otherwise decent security based on the Linux kernel and proven, rock-solid app sandboxing.

Android needs to split the current permission list into two categories. Basic ones (like Internet access) that could be granted at install time and privacy-oriented ones (Camera, Location, etc.) that the user gets prompted for, just like on iOS.

Breaking existing apps could be avoided by feeding them empty or fake data (Location not available, Camera in use by another app, etc.) and providing new APIs to detect rejected permission prompts for developers who decide to update their apps.

Users have a right to privacy and the operating system shouldn't require sysadmin-level knowledge to let them protect their data.

The problem I have with this is that breaking down by category is not how I think about security. I break it down by severity. I don't think "can this app access my microphone?" I think, "Can it access my microphone while the app is not in the foreground? Can it do it while the screen is off? Can it run at startup and do this without me knowing? Same for location access, various other things. Google's change makes all those the same, because they come in the same "category". It might be a simple way to think about security, but it is not a secure way.

What I really want is a tier of permissions that I can totally trust. I want to be able to install any random app from any random developer and know it's not got ability to harm me. This change seems to ruin that. They can install it with lite permissions and then upgrade them later and I won't be notified. Most especially I want this for my wife, mother and children. They need simple instructions: only ever install apps with permissions like X. But again, this change ruins that. Permissions like X get escalated to permissions like Y without notification. I'm really not sure what you can tell anybody to keep them safe now other than "don't install apps. Which is probably what I will start doing.

What if each <permission> could have a tag android:mandatory="true" for necessary permissions, and for those without the flag, on the install screen, it could allow the user to switch the permission on/off ?

If an app just needs permission to my contacts for its optional import contact feature, it is certainly not mandatory. There could even be an API call to ask the user to reconsider the permission (same as Google maps asking the user to enable location reporting).

Why not use the way this article[1] says?

[1] http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-...

Apps can ask for permissions only when it really needs them, and explain why need them.

The iOS system works pretty well, but does have a few downsides.

There are apps that spam permissions requests. Let's take some kind of Foursquare thing that needs see your photo library, GPS location, and contacts because of how it works. Poorly written apps will often just spam all three requests when you first open the app instead of asking for your contacts now, your photos when you try to select one, and GPS when you try to tag somewhere.

Notifications are also a problem. At this point nearly every single app I download has the first run experience of asking to send me push notification (answer is basically always "No") which is a poor experience and just trains people to smash "yes" or "no".

By the way, if you hit the wrong one how do you fix that? I bet 90% of users don't know, and would just delete and reinstall the app.

However on iOS apps are NOT allowed to explain WHY they need a permission. The dialog boxes are generated by the system to prevent gaming. Well designed apps will set the user up, showing you a little screen saying "We're about to ask for access to your camera roll so you can select a picture", poorly designed ones just pop-up the dialog.

It works fine for me. The only thing I'd like from Apple is an additional permission for non-push notifications. I don't want every app I install to automatically get access to send non-push notifications. I have to go turn that permission off far too much.

iOS apps are starting to realise this and get smart about how they ask for permissions. See http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-...

The common model I'm seeing is the app will ask the user beforehand, giving the proper explanation. If the user agrees, then they are prompted with the OS level permissions dialog.

Cause that can be annoying.

What if when installing, you could be presented with all the permissions, and a on/off switch for the optional ones, where you could be even prompted for them later (similar to the article)?

It'd be an improvement.

But I suspect too many applications would deliberately be set up to either have no optional permissions or would be set up to pop up a screen saying "please enable permissions" and close if you turned any of them off.

It's not clear to me from the article how apps are able to gain permissions just from updating. Is it because future updates run under the 'new' system while the current version still runs under the 'old' system?

I'm not sure I think this is so bad. Granular permissions can be annoying and confusing. If you surveyed the Android owning populace how many really care about rough/accurate location? "I want this app to know where I am" doesn't seem that bad. Read vs send SMS? I can sort-of see why you might want an app to only send, but I can't think of a case where you'd only want it to receive.

I may be colored by living in the world of iOS. There are very few permissions. Apps have access to your location or they don't. They can see your phonebook or they can't. They can access your photos or nothing. The fact that Android has more 'dangerous' abilities (sending SMS, phone calls, etc) makes it more difficult.

Some of this may just be poor categorization. I would expect most phone related stuff (phonebook, dialing, call log) to be under a single permission, but the ability to re-route calls should be under a different one (or only setup through settings).

I'm also surprised that there is a permission for using internet access. How many apps really don't need that? It seems like most everything people would want to use (games that show ads or scores, social media, browsers, etc) would need it, so you're just training people to say 'yes'. The keyboard example is a good one, but that sounds like certain things should just be a special type of app with different restrictions.

Sounds to me like Google is trying to fix the 'every app requiring every permission' problem by reducing the choices to be more understandable.

> It's not clear to me from the article how apps are able to gain permissions just from updating. Is it because future updates run under the 'new' system while the current version still runs under the 'old' system?

The permissions required by an application can change from one version to another. Previously, if an update demanded more permissions than the version it replaced, the user would be asked to confirm the change. Now, this permission "upgrade" will sometimes be allowed silently.

Is that only in category (read phonebook -> read phonebook & make calls) or across category (read phonebook -> read phonebook & setup a VPN)?

I can understand the first given what they're trying to do, the second would be outrageous.

Within a category. However, as explained by the article, even that can involve some pretty serious escalations (e.g, "read SD card" to "format SD card"!).

The fact that Android has more 'dangerous' abilities (sending SMS, phone calls, etc) makes it more difficult.

I'm also surprised that there is a permission for using internet access.

A few months back I had to deal with this on my home network: https://adblockplus.org/forum/viewtopic.php?t=11849 My brother had Adblock Plus on his Android tablet and it was continuously sucking down data to do nothing, presumably in a background process.

It makes sense that if you want to give devs lots of power when making apps, you need to give users finer grained permissions. Maybe you can group things or whatever, but you probably shouldn't be making permissions coarser grained or forcing users to install 3rd party apps to get control of their phone again.

This is one of the reasons I use iOS. I don't really have to worry too much about apps doing dodgy things because they are severely hamstrung to begin with.

Android's permissions system is useless anyway so it really doesn't matter what they do with it.

Most people don't read the permissions and wouldn't know what some of them mean even if they did (let alone that sometimes the same heading appears multiple times, requiring you to read the fine-print to look at exactly what the app wants to do).

Worse, their experiences train them to ignore the prompts just like EULAs or IE's infamous ActiveX prompts... "Wanna punch the monkey? Click here to install SpywareInstallerActiveX". Many if not most users clicked OK. Similarly, all the big name apps and games ask for a huge long list of permissions and users are trained to just click OK.

iOS is better (though still imperfect). You want to see who I'm calling? Nope, the privacy invasion isn't worth the risk of ever exposing that. Want access to contacts? Then the user will get prompted at that point in time, not at app install (though some crappy apps try to ask at startup). All apps are required to work even if the user says no, and be functional unless the permission is required for the app to work at all.

Users are much more likely to be aware of what is happening if the permission request happens at time of use. If I install a game then during the first level I get a popup asking for permission to access my contacts, I'm much more likely to treat that as a red flag because nothing about the context would indicate the app should be looking at my contacts, versus being buried in a huge list of permissions that I usually ignore anyway.

Sigh... I've been using especially the internet permission as a way to choose between apps. According to the article this permission is on by default. What gives? Most apps might need it, but many don't. Now each app I install can send information across and I have no way to find out. Makes me not want to install anything.

That's why I use use cyanogenmod with privacy guard.

First I read that security is improved on Android L http://www.xda-developers.com/android/exclusive-android-l-lo... and now I read this. Google wake up! Privacy and Security is the biggest weakness in Android! FIX this!

Reply on news.ycombinator.com