Android security model is inadequate, and it needs a firewall(sswam.wordpress.com)
sswam.wordpress.com
Android security model is inadequate, and it needs a firewall
http://sswam.wordpress.com/2010/09/25/android-security-model-is-insufficient-and-it-needs-a-firewall/
11 comments
Yeah! Let's go and repeat all Windows flawed decisions!
First - the windows firewall which in no time involved into one button [ALLOW] because millions of stupid users were bombarded customer support.
Lets try to establish a privilege separation everywhere, so all users will work as administrators. Lets make code bloated and slow, only because it is a proper way of doing security.
btw, do you know, which is best security solution for Windows? The low-level full restore from a copy of just installed system form the second hard drive. Most of public PC providers are using this strategy.
So, the answer is fast, easy and idiot-prof re-flash procedure.
First - the windows firewall which in no time involved into one button [ALLOW] because millions of stupid users were bombarded customer support.
Lets try to establish a privilege separation everywhere, so all users will work as administrators. Lets make code bloated and slow, only because it is a proper way of doing security.
btw, do you know, which is best security solution for Windows? The low-level full restore from a copy of just installed system form the second hard drive. Most of public PC providers are using this strategy.
So, the answer is fast, easy and idiot-prof re-flash procedure.
that's not going to bring back the copies of my contacts, private photos, passwords and banking details which have been broadcast to the internet
Leaving banking account details on a public PC is called stupidity. ^_^
You can use something as a storage of critical data, or as a runner for some garbage. Even at Microsoft they don't browse porn-sites from their servers.
You can use something as a storage of critical data, or as a runner for some garbage. Even at Microsoft they don't browse porn-sites from their servers.
No, it already has security functions in place. If you don't want an app to use the internet, and it has stated it will do so, DO NOT INSTALL IT.
If you really want to play a game that requires that access, and you think it shouldn't, contact the developer and tell them so.
The firewall would only be used by a few people who both pretend to be security-conscious and also install any app that suits their fancy. Yes, it's work to install the firewall that requires root access. Suck it up and just do it, if you want that feature. Don't saddle the rest of us with it.
If you really want to play a game that requires that access, and you think it shouldn't, contact the developer and tell them so.
The firewall would only be used by a few people who both pretend to be security-conscious and also install any app that suits their fancy. Yes, it's work to install the firewall that requires root access. Suck it up and just do it, if you want that feature. Don't saddle the rest of us with it.
I think it's better to have the option, enabled by default, so that people see a warning pop-up the first time an app attempts internet access: "Freecell wants to access the internet. This could compromise your privacy or security. Press 'block' or 'allow' to continue." or whatever. Perhaps for the first time the message appears, the system could explain the risks in more detail, with a biohazard symbol or something. People could also choose 'block all' and allow an app only if it otherwise breaks. If you don't want a firewall, turn it off: simple. Otherwise, you are likely to be saddled with a large variety of malware. I'd rather have the firewall.
Isn't the real problem that people want a better curated market? Cut down on the spam, apply standards for permissions, make sure apps don't use the 1.4 security model (did that even ship on any phones?).
No.
I understand why Apple likes the App Store model and process, and the huge revenue they get from it. But I have never understood why any developer or consumer would consider it a benefit that outweighs its many negatives (higher costs, slower development, limits on application capabilities, extreme difficulty deploying custom apps, inability to develop applications that compete with Apple products, etc.).
It doesn't require a curated market to kill off 1.4 API features. A new version of the OS can do that, as can standards for permissions. Why would you believe having standards imposed by fallible humans with a limited view of the application could ever do a better job than the OS itself? Assuming the decision was made to correct these security risks, it's obvious, to me anyway, that doing it in software is the only reasonable way to do so.
I understand why Apple likes the App Store model and process, and the huge revenue they get from it. But I have never understood why any developer or consumer would consider it a benefit that outweighs its many negatives (higher costs, slower development, limits on application capabilities, extreme difficulty deploying custom apps, inability to develop applications that compete with Apple products, etc.).
It doesn't require a curated market to kill off 1.4 API features. A new version of the OS can do that, as can standards for permissions. Why would you believe having standards imposed by fallible humans with a limited view of the application could ever do a better job than the OS itself? Assuming the decision was made to correct these security risks, it's obvious, to me anyway, that doing it in software is the only reasonable way to do so.
Developers like it because if their software sits next to a bunch of other professional, polished looking apps their software looks better by comparison. If it's surrounded by "~~~FREE RINGTONES~~~", it doesn't look so great.
The objection to the app store, in my mind, was always not that it was highly curated by people, but that it was highly curated by people and there was _no_ other way to install software.
The objection to the app store, in my mind, was always not that it was highly curated by people, but that it was highly curated by people and there was _no_ other way to install software.
I've never seen ~~~FREE RINGTONES~~~ in the Android market.
Again, this is something with an obvious software solution. Google is the best in the world at providing good search results...so, why not provide the best search results in the market? (I don't think they currently do a good job, though. I'll be the first to admit that the Apple App Store is still a somewhat better experience than the App Market, despite App Market getting quite a bit better during its life...but it's not because App Store is curated. It's because Google hasn't put the resources into making App Market work really well.)
Generally, I think if you've got people involved in processes that could be handled by software, it's a failure. It's costing consumers more money, costing developers more time, and insuring that it is a fallible process and subject to the whims of sometimes capricious reviewers. Since this article is about security (and not "~~~FREE RINGTONES~~~"), that's clearly something that ought to be handled in software. The fact that Apple doesn't handle it in the OS, and instead relies on human reviewers, is Apple's failure. The fact that Google doesn't handle it in the OS, and relies on vendor trust and user intelligence and a better than average (but still weaker than ideal) security model, is Google's failure.
On the subject of security, you've suggested that Apple have the problem solved by having a curated market. I don't believe that's at all accurate.
Again, this is something with an obvious software solution. Google is the best in the world at providing good search results...so, why not provide the best search results in the market? (I don't think they currently do a good job, though. I'll be the first to admit that the Apple App Store is still a somewhat better experience than the App Market, despite App Market getting quite a bit better during its life...but it's not because App Store is curated. It's because Google hasn't put the resources into making App Market work really well.)
Generally, I think if you've got people involved in processes that could be handled by software, it's a failure. It's costing consumers more money, costing developers more time, and insuring that it is a fallible process and subject to the whims of sometimes capricious reviewers. Since this article is about security (and not "~~~FREE RINGTONES~~~"), that's clearly something that ought to be handled in software. The fact that Apple doesn't handle it in the OS, and instead relies on human reviewers, is Apple's failure. The fact that Google doesn't handle it in the OS, and relies on vendor trust and user intelligence and a better than average (but still weaker than ideal) security model, is Google's failure.
On the subject of security, you've suggested that Apple have the problem solved by having a curated market. I don't believe that's at all accurate.
On the Apple devices each app lives sand boxed in it's own directory, but apps can still access photos taken with the camera or saved from other apps. They don't ask for permission, but go through a standard image picker user interface provided by the system. I don't think apps can grab photos unless the user picks them through this widget. This way you know exactly what you are handing over. Direct access to the SD card is dicey at best.
It looks like compiled apps on Palm can also read the whole media directory. The neat thing with Palm though is any app can bring in scenes (a screen) from other apps, preserving the state of the application underneath, while passing back data. This way any app can selectively share with another app. On iPhone OS the only system wide widgets available are provided by Apple. I'm betting/hoping Palm will come back and give Apple a run for it's money, if the carriers don't cripple it somehow first.
It looks like compiled apps on Palm can also read the whole media directory. The neat thing with Palm though is any app can bring in scenes (a screen) from other apps, preserving the state of the application underneath, while passing back data. This way any app can selectively share with another app. On iPhone OS the only system wide widgets available are provided by Apple. I'm betting/hoping Palm will come back and give Apple a run for it's money, if the carriers don't cripple it somehow first.
I don't think apps can grab photos (on iPhone) unless the user picks them through this widget.
iPhone apps have been able to access camera roll images by direct file access. I think they are still able to, though I didn't verify that.
It wasn't even difficult at all, a path to the photo directory can be easily figured out either from the simulator's file system or by jailbreaking the phone. (Or nowadays by Googling)
Secure sandboxing is pretty difficult thing to do properly.
If the image picker UI widget has an access to your photos and it is running inside your applications process, then your process has access to those files. It doesn't matter if the actual path is hidden, a clever hacker could still figure out to get access to those files.
To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app. This is non-trivial to implement well, given that UI transitions are expected to be smooth and even support animations.
Due to the API design of UIImagePickerController, I think Apple has known this from the beginning and maybe planned to do it securely. But I assume they just haven't got time to implement it yet.
iPhone apps have been able to access camera roll images by direct file access. I think they are still able to, though I didn't verify that.
It wasn't even difficult at all, a path to the photo directory can be easily figured out either from the simulator's file system or by jailbreaking the phone. (Or nowadays by Googling)
Secure sandboxing is pretty difficult thing to do properly.
If the image picker UI widget has an access to your photos and it is running inside your applications process, then your process has access to those files. It doesn't matter if the actual path is hidden, a clever hacker could still figure out to get access to those files.
To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app. This is non-trivial to implement well, given that UI transitions are expected to be smooth and even support animations.
Due to the API design of UIImagePickerController, I think Apple has known this from the beginning and maybe planned to do it securely. But I assume they just haven't got time to implement it yet.
> To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app.
Android already does this using separate processes for distinct Activities and by using Intents for message-passing between those activities. Granted, Android doesn't prevent access to the SD card data, but assuming it did secure that access somehow, the existing Activity/Intents framework would make it trivial to keep that functionality separate. Except for the fact that all the system applications and activities are built on top of the same basic Android SDK/API as 3rd party applications, so anything they can do, your apps can do too if it requests the right permissions.
Android already does this using separate processes for distinct Activities and by using Intents for message-passing between those activities. Granted, Android doesn't prevent access to the SD card data, but assuming it did secure that access somehow, the existing Activity/Intents framework would make it trivial to keep that functionality separate. Except for the fact that all the system applications and activities are built on top of the same basic Android SDK/API as 3rd party applications, so anything they can do, your apps can do too if it requests the right permissions.
After doing some reading it looks like you can get a path to the image by poking around undocumented methods in the UIImagePicker class, but Apple does not allow those private API method calls past it's approval process. Just like you said, it is possible, but Apple curates it out.
I am surprised the images aren't accessed through another process that has directory access but enforces limits. Couldn't that process just allocate a buffer or take a pre-allocaed buffer for a UIImage and pass back a pointer to the requesting app? Is there some sort of technical limitation that forces it to send the image back via a slower method like IPC? Sending a message to the managing process to get the image and receiving a pointer back shouldn't have too much overhead should it?
I read on Ars that hardware virtualization support is coming to mobile at some point. The ability to trap the right instructions so an app can't break out should hopefully help secure these kinds data stores without having a curated app library, and without too much of a performance hit.
I thought we were there already there, so this is dissapointing. For some reason I am less comfortable with my phone apps having the sort of file system access than my desktop apps. Restricting internet access for apps in order to control data from leaking out is too far reaching, lots of apps need internet for things besides stealing data.
I am surprised the images aren't accessed through another process that has directory access but enforces limits. Couldn't that process just allocate a buffer or take a pre-allocaed buffer for a UIImage and pass back a pointer to the requesting app? Is there some sort of technical limitation that forces it to send the image back via a slower method like IPC? Sending a message to the managing process to get the image and receiving a pointer back shouldn't have too much overhead should it?
I read on Ars that hardware virtualization support is coming to mobile at some point. The ability to trap the right instructions so an app can't break out should hopefully help secure these kinds data stores without having a curated app library, and without too much of a performance hit.
I thought we were there already there, so this is dissapointing. For some reason I am less comfortable with my phone apps having the sort of file system access than my desktop apps. Restricting internet access for apps in order to control data from leaking out is too far reaching, lots of apps need internet for things besides stealing data.
http://developer.android.com/guide/topics/data/data-storage....
Context.MODE_PRIVATE
bam
Context.MODE_PRIVATE
bam
I just want a better market search. This is Google, for crying out loud! I want to be able to sort and filter by rating, date updated, price, alphabetically, permissions required, etc. Also, I'd prefer to display all prices in my local currency, so I don't have to look up how much a .99euro app costs based on today's exchange rate.
I always read the permissions requested by each app before installing. Some of the things I've seen are just obnoxious. My favorite are games that want full access to my contacts.
Also, there is a way to completely disable net access temporarily: APNdroid kills the wireless data over 3G/EDGE/GPRS and then disable wifi. This kills in-game ads but who knows what data the app stores up for future transfer.
Also, there is a way to completely disable net access temporarily: APNdroid kills the wireless data over 3G/EDGE/GPRS and then disable wifi. This kills in-game ads but who knows what data the app stores up for future transfer.
To disable net access temporarily couldn't you just put it in airplane mode?
Yes but that also kills the voice connection.
yes
you could, but this is not good enough. A malicious app can collect data to send, store it, and wait until you slip up and accidentally give it internet access. Again, this is trivial stuff, no elite hacking required.
I see a problem in the argument the author makes, specifically around the capabilities of users. He describes the method of installing DroidWall as being beyond the grasp of most users. I would go further and say expecting most (non technical) users to pay attention to, let alone understand, all the security permissions is a stretch.
Comparing Android to Windows in terms of it's security vulnerabilities? There are some fair comparisons, but the better comparison is how it is more likely to become a platform littered with unwanted apps from carriers and third parties. I wouldn't be surprised at some point to see Apps the "bundle" other apps.
People don't pay attention to all the words that flash on their screen before an app is installed. They just want the app.
Having a better managed app store would be a big step in the right direction.
As for disabling net access for "free" games that you want to play so that they don't display ads, the current focus on free and $0.99 apps really leaves the developers who put time in little other recourse to make money. (I'm not saying all free/cheap apps are of the same caliber, some are great and some are "not scottish").
Comparing Android to Windows in terms of it's security vulnerabilities? There are some fair comparisons, but the better comparison is how it is more likely to become a platform littered with unwanted apps from carriers and third parties. I wouldn't be surprised at some point to see Apps the "bundle" other apps.
People don't pay attention to all the words that flash on their screen before an app is installed. They just want the app.
Having a better managed app store would be a big step in the right direction.
As for disabling net access for "free" games that you want to play so that they don't display ads, the current focus on free and $0.99 apps really leaves the developers who put time in little other recourse to make money. (I'm not saying all free/cheap apps are of the same caliber, some are great and some are "not scottish").
I absolutely agree. The current warnings are inadequate because the average phone user does not bother to read them and cannot understand them.
The average user does not think up malware exploit-cases to convince himself that full internet access combined with the universal implicit 'read anything off the SD card' permission is not a good thing. He just clicks the funny rubber cow and listens to the moo sounds!
If games want to display ads, that would be okay, but they need a more limited permission which gives them internet access to their home server only (like java applets) and no access to local filesystems except a little space for their own settings and files. I think there should also be a declaration of ad-spamminess in the manifest so that people can avoid such games. I really don't trust random closed-source freeware games with my filesystems.
The average user does not think up malware exploit-cases to convince himself that full internet access combined with the universal implicit 'read anything off the SD card' permission is not a good thing. He just clicks the funny rubber cow and listens to the moo sounds!
If games want to display ads, that would be okay, but they need a more limited permission which gives them internet access to their home server only (like java applets) and no access to local filesystems except a little space for their own settings and files. I think there should also be a declaration of ad-spamminess in the manifest so that people can avoid such games. I really don't trust random closed-source freeware games with my filesystems.
Not saying it can't/shouldn't be improved...
...but I think it was unfair to single out Android which does have one of the more secure setups in terms of permissions for apps, for a flaw that exists in every major mobile OS.
Your title should have been "Mobile OS's security models are inadequate- and out line how Android, iOS etc could be improved upon.
The way you wrote it feels FUD-y :)
Your title should have been "Mobile OS's security models are inadequate- and out line how Android, iOS etc could be improved upon.
The way you wrote it feels FUD-y :)
Fair enough, but I only know about Android and Maemo! As for apple, I have different reasons for disliking Apple: http://sam.ai.ki/apple.html
I did mention that Maemo's practical security is much weaker than Android's, but it's actual security may be better - like Debian's - because most apps are open source.
"There is no way to deny internet access to a specific app that supposedly ‘needs’ it."
There is a way, which I employ to great success: don't install the app.
The SD card is a real worry, but I thought that apps are Sandboxed in a way - they might only see the files they created themselves? I would have to check - otherwise it would of course be completely broken.
There is a way, which I employ to great success: don't install the app.
The SD card is a real worry, but I thought that apps are Sandboxed in a way - they might only see the files they created themselves? I would have to check - otherwise it would of course be completely broken.
No, unless i am mistaken they are not sandboxed with respect to the SD card, and apps with write permission (comes for free with API 1.4) can also modify or delete any SD card content - to install a windows virus for example.
One thing I wish is that there was more granularity to some of the permissions.
I put together a streaming music player for a community radio station, and published it on the market. I want to be able to detect when the phone rings so I can kill the music. In order to do this, I need to request permission to "Read phone state and identity."
Once I've requested this permission, I can gather all this other data:
http://developer.android.com/reference/android/telephony/Tel...
I can request their IMEI/IMSI, their phone and voicemail numbers, the name of the cell network they're registered on, and the cell site they're talking to. This is too much! At the very least, the "read identity data about your phone service" should be separated from "find out if the phone ringing is or a call is in progress."
There are a large number of apps that request this particular permission. For example, why do Facebook, Amazon Kindle, Yahoo Fantasy Football, and OpenTable need access to this feature? These are all large brands that would suffer some hefty damage if they were found to be surreptitiously pulling user info, so I'm assuming they have a legitimate need for that permission that doesn't involve sniffing data. I want to know more clearly what business they have poking at the telephony manager.
I put together a streaming music player for a community radio station, and published it on the market. I want to be able to detect when the phone rings so I can kill the music. In order to do this, I need to request permission to "Read phone state and identity."
Once I've requested this permission, I can gather all this other data:
http://developer.android.com/reference/android/telephony/Tel...
I can request their IMEI/IMSI, their phone and voicemail numbers, the name of the cell network they're registered on, and the cell site they're talking to. This is too much! At the very least, the "read identity data about your phone service" should be separated from "find out if the phone ringing is or a call is in progress."
There are a large number of apps that request this particular permission. For example, why do Facebook, Amazon Kindle, Yahoo Fantasy Football, and OpenTable need access to this feature? These are all large brands that would suffer some hefty damage if they were found to be surreptitiously pulling user info, so I'm assuming they have a legitimate need for that permission that doesn't involve sniffing data. I want to know more clearly what business they have poking at the telephony manager.
The permissions are grouped under such broad categories to give the user a decent chance of understanding what they mean and getting through the permission dialog in a reasonable amount of time. The permission structure needs to strike a balance between granularity and usability.
It's certainly not ideal but I doubt that users are even paying attention to the permission dialog as it is.
A fun experiment would be to publish an innocuous free app that requests every single permission for no apparent reason. I wonder what percentage of users would actually decline to run it.
It's certainly not ideal but I doubt that users are even paying attention to the permission dialog as it is.
A fun experiment would be to publish an innocuous free app that requests every single permission for no apparent reason. I wonder what percentage of users would actually decline to run it.
I would add a brief textual description of why the application is requesting each permission. If on the permissions screen, I saw something like this:
Access personal data
- FooBarApp accesses your contacts to send and receive them
over Bluetooth when requested.
Allowing the app to affect the permission UI in any way will probably just end up as a vector for social attacks. You will see a lot of reasons like "You MUST click the Yes button below to complete the installation of ThingyWoo" or "DO YOU WANT FREE HOT SEXY BLAH BLAH? CLICK YES NOW!!!"
You only get a limited amount of space for description in the market, around 300 characters, which really doesn't allow for this and other useful information.
This wouldn't be in the market description, but rather on the permissions screen. Maybe something like 50 characters per permission.
OLPC's security model, called Bitfrost, is very interesting:
http://wiki.laptop.org/go/Bitfrost
http://wiki.laptop.org/go/Bitfrost
Architect of Bitfrost joined Apple a year and a half ago, it is interesting what is he cooking over there…
I think they should have separated permissions that could compromise privacy / security from less important permissions, and grouped them by potential impact. Also the user should me able to say "um, no I won't allow you to read the phone state". As it is, the apps are in control, not the user. It is extremely difficult to effectively change the range of permissions now, with such a large body of existing apps.
I don't think it would be extremely difficult; just phase in additional permissions with better granularity. Additionally, add an "ask me every time" permission that pauses the application and displays a confirmation dialog for each request, allowing the user to always accept or reject future requests made by that particular line of code.
"Ask me every time" would just lead to people click "Yes" every time just like on Windows.
Perhaps just "Ask me later" when installing, then a single prompt the first time the app uses a particular permission?
Just to play Devil's Advocate for a moment, from the perspective of the development process, and the conversion funnel, granular permissions are a total pain in the ass:
First off, if you've got a user who is trying to install the app, it's extra clicks and text that they're going to ignore anyhow. They trust you, they're installing your app, don't be an asshole.
Second, say you don't need GPS or something for your product's current state, but you'd really like to integrate with something that will need it. Handling all the states of old user without perms -> new user with perms ( asking for permission? refusing without? what about when they decline? ) is a huge headache of busy work code. Get them to add that permission while they're already clicking and ignoring the legalese, and everyone wins.
Yes, we read the permissions apps use, but we should all realize that our parents won't. As long as you're allowing people to execute arbitrary code, on your outsourced hardware, broadcast over a public network, there's some diminishing returns on security. You're putting really fancy padlocks on a screen door.
First off, if you've got a user who is trying to install the app, it's extra clicks and text that they're going to ignore anyhow. They trust you, they're installing your app, don't be an asshole.
Second, say you don't need GPS or something for your product's current state, but you'd really like to integrate with something that will need it. Handling all the states of old user without perms -> new user with perms ( asking for permission? refusing without? what about when they decline? ) is a huge headache of busy work code. Get them to add that permission while they're already clicking and ignoring the legalese, and everyone wins.
Yes, we read the permissions apps use, but we should all realize that our parents won't. As long as you're allowing people to execute arbitrary code, on your outsourced hardware, broadcast over a public network, there's some diminishing returns on security. You're putting really fancy padlocks on a screen door.
While there are some good points made here, I would like to point out that the average desktop computing environment has no protections of this sort.
If I write a Windows (or Mac OS X, or Linux, to a slightly lesser degree in each case) application, I can have that app do every bad thing proposed by the author, and much more. I can roam through their "Pictures" and "Movies" folders, send out stuff I find over the probably very high speed internet connection. I can run proxies or other malware. I can pretend to be other applications to sniff passwords, or for other nefarious purposes, etc.
That is, of course, a major failing of the security model in a desktop environment...and it's been responded to by lots of band-aid solutions, like anti-virus and malware detection tools.
In short, while I think it's sort of unfair to pick on Android (which has among the best security layers built into the OS, rather than into the application distribution process or based on vendor trust), I actually agree. The new mobile device OS is an opportunity to solve the major security issues we know about. It shouldn't be a situation where backward compatibility is allowed to stand in the way of mitigating serious security risks.
The SD card thing could be fixed by deprecating 1.4 behavior. I wouldn't think that'd be a major issue, since a large number of apps had to be updated for 2.x anyway.
If I write a Windows (or Mac OS X, or Linux, to a slightly lesser degree in each case) application, I can have that app do every bad thing proposed by the author, and much more. I can roam through their "Pictures" and "Movies" folders, send out stuff I find over the probably very high speed internet connection. I can run proxies or other malware. I can pretend to be other applications to sniff passwords, or for other nefarious purposes, etc.
That is, of course, a major failing of the security model in a desktop environment...and it's been responded to by lots of band-aid solutions, like anti-virus and malware detection tools.
In short, while I think it's sort of unfair to pick on Android (which has among the best security layers built into the OS, rather than into the application distribution process or based on vendor trust), I actually agree. The new mobile device OS is an opportunity to solve the major security issues we know about. It shouldn't be a situation where backward compatibility is allowed to stand in the way of mitigating serious security risks.
The SD card thing could be fixed by deprecating 1.4 behavior. I wouldn't think that'd be a major issue, since a large number of apps had to be updated for 2.x anyway.
I say it is psychology. Android tells you what the applications are able to do and by being rather explicite about it, it is scary.
It would be great if a user could sandbox those permissions or even outright block them, but I guess that would just lead to malconfiguration, confusion and blind bug reports. Maybe a custom mod will do it some day. I rooted yesterday and now have an iptables based firewall installed that lets me control what applications can access the internet (I guess there are loopholes around it but it is better than nothing).
It would be great if a user could sandbox those permissions or even outright block them, but I guess that would just lead to malconfiguration, confusion and blind bug reports. Maybe a custom mod will do it some day. I rooted yesterday and now have an iptables based firewall installed that lets me control what applications can access the internet (I guess there are loopholes around it but it is better than nothing).
Would that be possible for instance when enabling Mock locations? Or would this need some driver or kernel hacking?