Fair questions, but how would you have designed it? Think carefully about the edge cases and user experience for both questions. I think it also helps to keep in mind lessons learned from incessant dialogs. Users are now desensitized and trained to click OK, despite not having read the message.

You know, I got that same feeling when the article said this was from "Russian security firm Doctor Web" and the malware dates back to October 2012.

They may be legit, but I did a double take on the name and country of the company, as well as the date.

Looks like it comes from TFA, which is next to useless for actual helpful information. No mention of what ad networks, or what apps theses were found in. They even blur the website name of where they encountered an ad. The Next Web article seems to be copy-pasta from the AV 'article' (probably better described as a press release). I clicked around their site and their links are broken and redirect to a scary 404 page that gives me instructions on how to recover Windows. Pot, kettle, anyone?

But sure enough, they sell Android antivirus software.

(Full disclosure: I sell an app meant to teach new users about Android permissions, but also give the text of the guide away -- still, take what I say with a grain of salt, like anyone else).

This is something I have been hoping to get time to write for awhile, more of a Wiki with statistics of how apps creep in their permission usage. Basically a community informational tool. Unfortunately I haven't had the time, nor much server coding experience. (If anyone is interested in contributing please feel free to contact me through my website).

And while your cynical take on the "developer first market" is not far off the mark, I think we should remember that there is a social contract between dev and user. I write a program and you pay me to buy it, or look at ads to use it. This part isn't really one sided at all. The problem is actually that permissions are granted before the user has a real chance to evaluate the application. This puts the users on the defensive.

I think if the social contract between dev and user was something agreed to at the time a feature was used, that would be better. It would put both dev and user on equal ground. If an app dev needs that permissions (for technical or business reasons), and they are denied it, they can shut down the app gracefully. If a user wants to deny some overreaching, they can also do so. With this case, either side can walk away at any time.

However, when the OS starts spoofing data (like the IMEI) in place of things (ala the rejected cyanogen patch), it breaks that contract both figuratively, and possibly literally. (For example if the user has agreed to TOS, and is now breaking them). I worry as a user that if we ever hope to have a system by which we retain control over permissions, we cannot break the contract, it will start a arms race (akin to ad blocking on websites).

What we need is to give users better tools to push back against permission creep, and for devs to have opportunities to cut back to what they really need.

It's not a contest -- the fact that iOS handles it well is a good thing. But it doesnt change the fact that what tepples said was also correct (though seems deprecated AFAICT). This was unfortunately the problem with that permission. It had very legitimate uses, and very nefarious ones too.

Nevertheless, you brought up the comparison to iOS. So kindly spare us the "only on slashdot" stuff when it was you who seemed to be spoiling for a brand fight.

Correction: I'm not sure media players even need it either as of API 8:

http://developer.android.com/training/managing-audio/audio-focus.html

Each app is run under a separate linux user process and is a separate instance of the dalvik VM.

I'd be curious your definition of sandboxing.

http://android.stackexchange.com/questions/42129/why-each-android-application-runs-on-a-different-dalvik-vm-process

Games should not need it. Any time the host activity is paused the games should pause any background processing. Media players, especially music players do play in the background, even with the screen off though. So for them, it is a must.

The permission is too coarse though. They need to separate state and identity. Unfortunately they've dug a backwards compatibility hole pretty deeply though at this point.

When I clicked your link I was hoping to find some delicious sirloin or ribeye steaks for sale. :(

"To pair with MindReadr (TM), just think the number 2643. To dismiss, don't think of those numbers"

Crap!

Screen calls? Eventually the app could answer and have the conversation we were going to have. Also there will be apps to make calls for us based on what we're thinking. If all goes well, these apps will call each other and have the entire conversation without us. I hope it is an interesting conversation!

I wonder if they will get their own facebook accounts....