Apple Implements Annoying Fake Security

On my way home this evening I read about the Battery Health app for giving information about my MacBook battery.  Sounded like a handy thing to have so I fired up the App Store when I got home and tried to install it.  I say “tried” as no sooner had I entered my Apple ID password as I was faced with this window.

Security Info Window

“Bloody hell”, thought I, “more stupid question/answer pairs to remember.  Well at least they haven’t …. oh no.”  Yes, not only have Apple gone in for the security question theatre but they’ve also gone and implemented a fixed set of questions rather than allowing them to be personalised.  Beyond that they’ve gone for the “trendy” approach of asking non-standard questions.  No “what’s your mother’s maiden name” type questions here.  No, it has to be about your favourite teacher, car, and other such guff.  I’ve copied the options you’re allowed to select from below.

The Fixed Security Questions

Well, this is just bloody brilliant.  Possibly these questions do mean something to you and you can always pick the same answer from your mind, in which case these could be secured more easily than any password by using some social engineering or looking at Facebook.  If, on the other hand, the questions mean nothing to you (and, as I’ve mentioned before, it’s amazing how many idiots implement lists of questions that don’t apply universally) then you’re either going to get stuck every time you have to answer them or you’ll end up writing them down somewhere.  How very very secure.  Maybe you think I’m being a bit over the top in accusing Apple of providing a useless set of questions, so let me ask a simple question.  Given that one fifth of the available questions depend on car ownership, how many people in the world have never owner a car?  Now, as an alternative, how many people don’t know their mother’s maiden name?  While the standard questions one finds in these types of forms have no benefits (or indeed detriments) in terms of security level, at least they do tend to cover a wider range of people.  Better yet, why not offer completely customisable options?  Oh yes, because it’s Apple and Apple knows best.

Unfortunately Apple’s technical support have not been particularly helpful so far, only suggesting I raise a ticket for iTunes feedback.  Well, that doesn’t exactly help me install new software on my Mac or update (say to improve security) existing apps.  Oh well, once again I realise why I absolutely loathe Apple as a software maker.  Love their hardware, hate their systems, hate their policies.

For a good explanation of where this sort of authentication came from and why it’s utterly daft, head over to The Daily WTF to read about Wish-It-Was Two-Factor authentication.

 

Yet Again OS X Pokes Me In The Eye (or OS X Environment Variables)

I bought myself a Macbook Air last year to replace my ageing laptop. The theory was that I’d be using cross platform apps so the underlying system didn’t matter. Or rather it didn’t matter enough to outweigh the pretty 🙂

Anyway, not all of the niggles I have are down to OS X (Apple’s “we must have our own way” GB keyboard is bloody awful and seems designed to piss off developers), but many are and I’ve just come across another. Trying to set consistent environment variables across all apps, regardless of whether terminal based or launched from an icon is an absolute mess. Worse still, Apple doesn’t seem to offer any standard friendly configuration methods for environment variables. Pricks. Anyway, the best resource for troubleshooting these that I’ve found recently is this post on stackoverflow. I’ve reproduced it below in order to ensure it is captured and kept!

There are several places where you can set environment variables.

  • ~/.profile: use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in Terminal.app are login shells).
  • ~/.bashrc: this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
  • /etc/profile: this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
  • ~/.MacOSX/environment.plist: this is read by loginwindow on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. There is no reason to use this one any more.
  • ~/.launchd.conf: this is read by launchd when the user logs in. It applies to all programs launched by the user, GUI and CLI, on 10.5 and 10.6. Additionally, you can apply changes at any time by piping this file into launchctl (maybe grep ^setenv first if you have other commands you don’t want to run). Then the new variables apply to any application launched by launchd from that point on. This means you should restart Terminal.app for the new variables to cascade down into the shells it launches.
  • /etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. Again, to apply changes to the running root launchd you can pipe the commands into sudo launchctl.

The fundamental things to understand are:

  • environment variables are inherited by a process’s children at the time they are forked.
  • the root process is a launchd instance, and there is also a separate launchd instance per user session.
  • launchd allows you to change its current environment variables using launchctl; the updated variables are then inherited by all new processes it forks from then on.

Sample setting an environment variable with launchd and storing it into your personal config so it works for your login even after your reboot:

echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE >> ~/.launchd.conf
echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE | launchctl

Now, launch your GUI app that uses the variable, and voila!

 

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. …