But, then, some companies are really upset about spoofing. For example, Swype had serious issues with that to the extent they cried they won't even be able to release their famous keyboard if they weren't be able to get personal data for their analytics.  So, CM team decided to not built any spoofing (the only practically working solution to the problem) in.
Dancing bunnies 1 : Security 0
Swype is operating in a marketplace that is full of apps crying wolf and asking for way more permissions than they need, usually for unknown purposes. For example, I like to read The Verge and use its app, but it has "read phone status and identity" and "modify or delete the contents of your USB storage" in its manifest, which I'm not comfortable with. There is nothing that explains what they use this information for, how long they store it, and who they share it with. Heck, my desktop browser doesn't give theverge.com this permission and yet the site functions just fine.
Why should I bare my personal data to the whole world just because one developer is too lazy to implement checks on his inputs?
If app doesn't handle exceptions, it's the consumers who are at loss. They either lose their privacy or service. Former is worse (in my viewpoint), but still...
(Obviously, losing some dubious malware-ridden "night vision" app is not real loss to begin with, but there are more high-quality apps that are quite disastrous from privacy viewpoint.)
Unless Google will start actively penalizing requesting more permissions than absolutely necessary, nothing will change. And, considering all top market players (including Google themselves) are actually interested in analytics and whatever and not interested in end-user's privacy, it's very unlikely scenario.
That post has some really wishy washy handwavy explanations for how IMEI spoofing etc supposedly ruins Swype analytics. I don't buy it.
1. Your device manufacturer paid to include Swype in their default keyboard (no IMEIs requested or desired, AFAIK). That was where they made their money, at the time.
2. You signed up for Swype's beta program, to get a free version of Swype directly from them (which you sideloaded, possibly on multiple devices and/or ROMs). To me, whether or not they "really" needed IMEIs for their statistics is beside the point. Gathering those statistics was the only thing they were getting out of their beta program, so if you didn't like that deal you should just not participate - not spoil it for other people by giving false information.
Accessing the address book is another area where permissions could be made much better. No app really needs access to my entire address book. They just need to launch the built in address book and only get the information they need for the one or more contacts you choose from your address book.
I think one solution is having the prompts integrate with the sort of crowdsourcing algorithm that XPrivacy has (e.g., if >90% of users have granted the app permissions on the address book, then don't show the prompt.)
Another important feature is that the app should not know if the user has granted it the permissions it asked for. If the user doesn't want to, the system should just feed the app bogus data and let the user continue interacting with other parts of the app (as we see today, most apps don't really need the data they collect in order to work.)
Android permissions, on the other hand, are reasonably fine-grained and allow the user to deduce what the app is going to do. If the app wants to send a SMS, how hard is it to popup a modal dialog that shows the target number and asks for the permission right there? That is obviously much better than showing it in one big list along with "internet access" in some nag-screen on the store.
Of course the app should know I didn't grant the permission. The only reason you revert to bogus data is because apps currently crash in horrible ways instead of handling it gracefully, as would be the case if this kind of at-the-spot permissions handling was the default.
Re: your second point, you're right, if the on-demand permissions handler were the default, more apps would handle it gracefully. However, it's not, and most apps today crash because they don't handle SecurityException when they call the android APIs. Also, you're assuming developers will act in good faith and will do whatever the users want. I would not be surprised at all if companies like Zynga, if they knew the user didn't give them the permissions, implement all sorts of dark UIs to trick/force the user to give them their data.
Should we not protect users just because they're too trusting with computers to realize what's going on?
Counterpoint, iOS appears to have a very successful permissions model in doing exactly this.
* Permissions are asked for one at a time
* Apps are expected to handle rejected permissions, but they're sent dummy data anyway (address book has no contacts, GPS coords is 0,0 etc)
* Permissions can be revoked in Settings.app
Android only asks for those permissions when installing the app, which is not too burdensome. Iirc Vista did UAC popups for almost every user action, which people rightfully rose hell about.
A better way would be to come up with a smart grouping profile for apps that want reasonable common combinations. For example, "Standard application that can access your INTERNET". Give it a nice screen. "Standard application application that can USE YOUR CAMERA and access your INTERNET" would get a big question mark icon.
For any app that wants any weird combination outside the standards, make it opt in like you say - one permission at a time. With each requiring a screaming skull and crossbones.
If you did that, you could integrate more fine-grained permissions into a small number of supported profiles, and developers would be strongly discouraged from choosing anything outside that combination.
So you can unlock your device when you buy it and not root it till you are ready.
eg. Say you notice you suddenly owe $100 on your phone bill due to a phone app causing charges to your bill (or even just because you gullibly fell for a social engineering attack), you should be able to just refuse to pay with no repercussions other than that the premium provider will be sent a notification that you refused to pay and then may block you via caller id from future use of the service.
I doubt this will ever happen since politicians generally don't give a rat's ass about consumers anymore, but it would be nice.
> Require mobile carriers to provide the option of barring premium SMS and MMS services on all plans from 1 July 2010. This gives consumers a choice to block such services;
My SIM came pre-blocked which was nice.
If the worst they can report on is an obscure and rather obviously dodgy looking App no longer on Google Play then there isn't much for us to worry about.
This is a nasty piece of malware, but premium SMS scam apps are nothing new to Android. So the article playing up the danger of this random, seemingly single-market focused malware (Hispanophone vs. global) isn't particularly scary.
From the analysis posted, it's trying to bypass that by not sending an SMS to a premium number. It's sending the phone number to a website, and whatever it is that is running on that website is subscribing the user to a premium service.
The original idea with reverse-billing was that users could subscribe to services such as weather updates, which would automatically send a message once a day/week, and the user be charged upon receipt. The problem with reverse billing is that it's clearly open to substantial abuse.
I guess this app is going through SMS opt-in, sending the reply behind the scenes.
I wonder why the app requires SMS write permissions though.
App stores like Google Play should reward apps which require the least amount of permissions by pushing them higher in the search results (and publicize that fact).
or openpdroid , or both. the cool thing about openpdroid is that you can spoof location requests too. also, i don't think any other privacy app allows you to block requests to sim and imei info
And the things I really fancy about XPrivacy is that current versions have learning mode (like `su` GUI prompts, configurable to automatically deny or allow after a timeout) and yet-underdeveloped but very promising argument-level permission controls (i.e. allows WebView's loadUrl for one URI, but not another).
Is it equivalent to a "goto label217" ? (shock and horror !!!)