Android and the Unexplained Permissions

I’m currently on holiday so was quite excited when I saw a post about the release of TETRIS® free on the Android Market by EA.  I’ve was mentioning to someone the other day that I love Tetris so this seemed perfect to while away some time by the pool.  How wrong I was.  As if I wasn’t already pissed off enough with the way EA have been approaching the distribution of BattledField 3, with this app release they’ve managed to join the ranks of developers requesting permissions far beyond what one would expect with no explanation.  I’ve written previously about the Facebook 1.6 update adding SMS permissions with no justification listed up front.  The TETRIS release is even odder, requesting permissions to make phone calls.

We all know that there is a constant problem with permission creep in Android.  Arguably, this is one of the reasons that a perception has grown of the Android Market as a home of malware without the protection afforded by Apple’s review process.  One could suggest that this is partly due to customers becoming desensitised to reviewing application permissions because they are so used to such large, unexplained requests.  Now, app developers broadly fall into two camps: those who will ensure they request the minimum set of permissions possible and those who go for everything left right and centre.  It’s particularly saddening to see the latter camp being joined by those larger houses who should know better.  Do they not have some sort of basic audit control to prevent such requests, and if not, why not?

Ultimately, I believe the responsibility to sort this situation out falls on the head of Google.  They need to put in some effort to work with some of the larger / higher profile publishers to set a good example to other developers.  Over dinner I pondered three possible solutions.

The simplest thing would be to educate developers in their use of permissions.  I had a quick skim of the Android development guide sections on permissions (going on the top Google results here) and was shocked that there wasn’t a simple statement to encourage developers to limit what they request.  Surely this is a good starting point.

The next change would be to give users a voice to alert publishers that they are displeased with what is being requested.  I can’t review TETRIS® free to make my opinion clear on the market or warn others as I haven’t (and won’t be) installing the app.  Being able to express why one doesn’t want to install an app would give publishers a demonstrable metric of potential lost sales and/or user base.  Surely this would make them sit up and listen.

The last, and possibly most extensive, overhaul would be to enforce a mandatory explanation for every permission requested.  Whether this is implemented in the Android manifest or when one publishes an app I don’t really care.  The latter could be used to add an additional warning to developers when they have requested additional permissions in an update and push the message further.  There is, without a doubt, no good reason that any developer should not be able to explain what they are using a permission for.  The only reasons could be because the permissions are malicious in nature or the developer does not fully understand what they are requesting, an equally dangerous prospect.

Obviously this latter option would require some policing to ensure that rubbish isn’t entered into the explanation, but that’s what the wonderful community is for.  Allow market users to flag up poor explanations and then Google can review these and come down these publishers with the force they would normally reserve for someone with an unusual name on Google+.

I know this blog isn’t read heavily, so I’d love a way to push this message out further.  I’m sure others have tried to suggest similar approaches in the past and I am disappointed with our Googly overlords.  THEY CAN DO BETTER.  I’ll throw a link up to this on Google+ and see if it gets any notice.

 

Problematic Permissioning

Ah Facebook.  You and I have had an on-off love affair for many years now.  First you were a simple but useful tool for organising parties at university.  Then you allowed a bunch of random American teenagers to spam friend requests around and you broke my heart.  I remember the arguments most of all: you would constantly ask what I wanted to do with my life, did I want to be a vampire or a werewolf?  I just ignored you …  But then the reconciliation came.  Mobile platforms sprung up and suddenly I wanted Facebook again.  Mobile versions of Facebook condensed down the simple parts that I appreciated all those years ago.  When I finally got to the Android version of Facebook, I knew it wasn’t perfect, but I accepted it.  It was passable.

Where am I going with this preamble (or ramble …)?  Well, first off I wanted to make it clear that I don’t have anything against Facebook.  It’s become fashionable over the years to knock and dismiss Facebook and I don’t really get this – I think it’s one of the best of its genre of service.  Having said this, over the years there have been some spectacular mistakes made with Facebook.  This week they seem to have triumphed again with the 1.6 update to the Android app. … 

 

Setting a target

I’ve begun work on my first app. It’s called Homogeneity and it’s a game built with libgdx.  The aim is to make it a new take on an old theme of turn based puzzle game.

I’m going to set myself a release target for the end of the month so I need to work out what has to be in the first build.  Off the top of my head I think I’ll need the following:

  • Extensible game engine.  As I have an idea where the design is going I should plan to support future features from the go.
  • Score recording but not score evaluation.  As I said, this game is turn based.  Now, I have some ideas about how to evaluate scoring (i.e. what’s a “good” number of turns, what’s a “medium” number of turns, etc.), but it’s going to require either a dedicated bit of work to create, or a complete abandonment of my plans and I’ll just fudge it …  If I at least capture and record the best score so far I can map this back to evaluations later.
  • Two sets of levels to give an idea of what I plan to expand in future releases.
  • All permissions I’ll need.  Now, this won’t be quite right.  In the future I may require SD card access for a planned feature, but this can be made obvious at the time I request them.  The last thing I want to do is keep adding little extra permissions with each release.  It annoys me as a users and I can’t believe I’m alone with that.  I want to have my minimum permission set in place up front.
  • AdMob support.  This’ll be a LITE release so I should start as I mean to go on.
  • Tablet support.  My flatmate owns a Xoom and I’m eyeing up a Thrive.  ‘Nuff said really.
  • Basic rendering.  I just want it to work for now.  I can improve things later.

Anything else is a bonus.