On the back of NetworkWorld’s recent announcement, and other harbingers of doom, that Android’s KitKat (4.x) LolliPop (5.x) & Marshmallow (6.x) releases have known security issues, I decided to seriously revisit taking up being a code monkey again. This time though it’s (more?) serious with 100+ issues including several chipset code vulnerabilities being reported by our good friends at Google. Easy, I’ll have this fixed in a jiffy: whip out VirtualBox currently enjoying a cushy life as a Xamarin Android Player for a virtualised Nexus 7 LolliPop plaything (what, you don’t have virtual playthings?) and that old copy of Ubuntu LTS 14.04 which has been taking up precious NAS space and use up some of that extraneous SSD space on my i7 laptop. For those in the know you’ll laugh or maybe smile or at the very least I trust you’ll have a wry smile, for the rest of the mortals in cyberspace let me break it to you that building a kernel isn’t a trivial operation and building a complete copy of all the software needed to allow a modern smart phone to work is no small undertaking. The mountaineer’s excuse “because it’s there” doesn’t wash, ignorant bliss is a good way of looking at it but perhaps a better way is it’s an obstacle that needs to be overcome. Don’t over think it, or see the full enormity of the undertaking or you’ll run away screaming with your hair on fire. I don’t think Linus knew his creation would end up where it has, sure he had aspirations and I remember him saying at one point that he would know that he’d “won” when Linux was running people’s washing machines and fridges: transparent and ubiquitous (I’m sure that’s a terrible misquote but you get the idea).

So, how do you eat an elephant? One bite at a time. Break the task down into small pieces and start at the beginning and before you know it you’ve eaten the whole elephant. That’s probably the IT consultant in me speaking though. It doesn’t matter how big, complex or imprecise the engagement is you start somewhere (usually the beginning, which in itself is typically a misnomer because the beginning can be such a nefarious and often imprecise concept) and develop a plan of attack (the tactics) to arrive at your destination (the end state, the objective). Strategy? Sorry? I thought this was a blog about digital disruption, let’s not complicate matters with an air of professionalism. But this is a fun task, because it’s there. Yes, just like the mountaineer. Ok, I missed the strategy, no wait. Did I get that right? Step back. First principles, Consulting 101: strategy is the “what”, tactics are the “how”. Good, now that’s out the way and we’re all on the same page back to insanity. Talking of which I’ll never forget seeing Geoffrey Rush play Poprishchin in an adaptation of Gogol’s Diary of a Madman by the Melbourne Theatre Company in 1989. I remember recognising at the time that he ripped his mind out of his head trampling it onstage for onlookers (the audience) to regale at. One of the most powerful performances I’ve ever seen, beat that corporate leaders of today!

Right. Strategy. Build my own kernel. Did I discuss why? No. Good. Well, not good, and let me elaborate. We’re mostly familiar with our commodity desktop operating systems and how they (usually) get updates (hopefully). It’s a standard security mantra:

1. patch/update your applications and operating system;
2. run antivirus/malware detection software;
3. make backups: and
4. when in doubt see points one to three, rinse, repeat.

And that would be good if our smartphones kept up with the vulnerabilities being discovered but they don’t (the iFruit crowd are probably laughing now). There’s a lag between when an exploit/vulnerability becomes public knowledge and when a patch/correction/fix is made available. And let’s not attack Google here. They do an admirable job frequently alerting manufacturers many weeks ahead of their own announcement. So why the hold up? The manufacturers have a _lot_ of device models, each with their own customisations to take account of the underlying hardware such as the processor, the graphics chip, the modem (which is the actual “phone” component) the PDA (or user interface) and associated hardware like speakers, microphones and cameras. So it’s not that straightforward. There’s a lag. And sometimes that lag can be months, a year and sometimes your device is obsolete and there’s no support anymore. In fact “we” seem to be moving (allowing/accepting?) planned obsolescence of smart phone hardware: often anything over a couple of years old and you’re on your own. Good luck finding updates. So why as consumers do we allow this to happen? For the hardware manufacturer there’s no incentive to update: it takes time, it’s complex and it costs real money to regression test a complete update to a device and put their name behind it. There’s one exception though. Google. Sorry? What? I thought they were the problem. No. Let me explain. They do have an incentive. They want you to use your device as much as possible, they are incentivise by your device usage. And they have a simple fix. The Nexus line of hardware. What? I’ve never heard of that brand. These are the Google flagship phones built by an array of manufacturers and frequently receive almost immediate security fixes and updates.

So, why not just bite the bullet and buy a Nexus? I’m really, really happy with my Samsung Galaxy Note 4. Sure it’s got a big screen and that’s a positive to me, it’s my eyes into the digital world. Some see that as a negative but ask anyone who’s had a large screen “phablet” and I think you’ll find they’ll never go back to a “small” screen again. Sure, I’m talking about people who use these devices as much, much more than just a telephone. So what do you do? You wait for the manufacturer to release an update, but it’s not that simple either. In this wonderful world of universal standards we have different standards in different countries for mobile phones. Say what? Yes, they are actually different and sometimes completely different hardware under the hood on the same “model” device. Different countries use different spectrums, and that means that the manufacturers need to make different versions of their update available, then the actual carriers in each country need to validate that build against their actual network. We’re not talking about fast, agile organisations here sadly. The incumbent carriers have a lot of devices to juggle, a lot of updates and a lot of complexity and if they get it wrong the prospect of a lot of potentially irate customers.

OTA. Over The Air. That’s how most people get their updates. The local carrier pushes out an update to their customers over their network and presto your device updates. This isn’t always seamless nor pain-free. There’s a vast amount of complexity in building the software and it’s a huge job to regression test everything to make sure that Sally and Johnny don’t ever lose their photos or contacts. OK, it’s getting better, we’ve been moving most of the configuration and data, photos etc., out into the cloud, into vast global data centers housing our precious data but not everything is there yet and may never be, it’s likely that there will always be a requirement to have some localised componentry.

So where does that leave us? If you want a “secure” phone, wait, patiently or buy a new device which may very well be insecure and require updates on day one, and FTR the current listed price of a Nexus 6 is AU$947. But it’s not all bad. There is a lot of work going on under the hood of your average (currently supported) Android phone and there’s a lot of work which Google has undertaken to mitigate potential exploits.

Here’s an excerpt from the latest Google security bulletin:

  • The Android Security team actively monitors for abuse with Verify Apps and SafetyNet, which are designed to warn users about Potentially Harmful Applications. Verify Apps is enabled by default on devices with Google Mobile Services, and is especially important for users who install applications from outside of Google Play. Device rooting tools are prohibited within Google Play, but Verify Apps warns users when they attempt to install a detected rooting application—no matter where it comes from. Additionally, Verify Apps attempts to identify and block installation of known malicious applications that exploit a privilege escalation vulnerability. If such an application has already been installed, Verify Apps will notify the user and attempt to remove the detected application.

So, why the desire to be a code monkey again? Because you can, because it’s possible, because this software platform is open, it allows you and encourages you to do this. You can see the source code, you can build it yourself. That’s what open source is all about. Sure, it’s not for everyone, it requires a degree of skill, experience, specialised knowledge and often a lot of patience. But *you* can build it yourself and to a technologist that’s really appealing. It’s like a puzzle, a challenge, something to be overcome and you can also learn how all the parts fit together to make an incredibly complex and sophisticated tool. Sometimes the knowledge gained during the journey is as or more important than reaching the destination itself.

Just how many monkeys will it take to build an Android source tree? One. It’s been a few years since I last did this and I’m looking forward to it.

To be continued (in later posts) 🙂

%d bloggers like this: