Android Malware, Life Outside the Walled Garden


Android figure with malware critter embedded

Android malware is on the rise

There's a new instance of Android malware on the loose, targeting your SMS messages, intercepting them and attempting to use them for profit. It isn't the first instance of malware on the Android platform; there have been a number of apps posing as other innocuous, even useful, tools that harvested your data for less than honorable purposes. In fact, this latest incarnation of Android malware, named SpyEye, follows on the footsteps of Zeus, an Android version of desktop malware. TheRegister reports that Android malware exploits are set to rise precipitously over the next six months. In that same article, it is surmised that Google dare not "lock down" its applications for fear of developer reprisal, intimating that the problem won't be rectified with a "walled garden".

One Android Malware To Go Please

In contrast with Apple's "walled garden", Google has adopted what could be termed an "untamed jungle" approach. While there are multiple app stores with varying levels of vetting by the operator, there are ample methods for Android owners to download apps from any location fully on their own recognizance to determine the genuineness and safety of the app in question. This has several positive effects. First, the barrier to entry for developers is lowered as they can offer applications directly from their website without having to register and receive approval from a third party operator. Second, the user has a potentially larger pool of applications to draw from since apps that otherwise might have been rejected are now available (I'm looking at you PhoneStory).

There are downsides, too, though, as Android owners are finding out. When an app store operator vets an app, there is a much lower chance that it will be approved if it will adversely affect a user's device. There are quality checks made which wouldn't be outside of an app store environment. Of course, it helps if the app store operator has reasonable standards and a habit of enforcing them but any app store operator worth their salt is going to make the effort in order to preserve their reputation, else customers will bring their money to another app store that serves them better. Outside of these app stores though, anything goes. Without a formal vetting process in place, the bar is lowered for malware authors to infect users' devices.

Of course, not even Apple requires you to enter through their gates for all of their devices. End users can just as easily install apps from a developer's website on their iMac as any Windows user could on their PC. There is an App Store for OS X users, but it isn't required. It offers a degree of comfort, of safety, but isn't the only way. Users are left to fend for themselves. But the argument that Google would necessarily lose developers if they chose to lock down Android is without merit. Apple took some heat for what was perceived to be a strong handed approach in terms of what apps were allowed to do but seems to be doing quite well in spite of this. Even when Android first arrived and all of the comparisons of openness vs not-so-openness were cropping up, Apple has still done very well. Developers did not leave the platform in droves. Apple's world did not end. So it's not the openness, per se, that Google fears. Rather it's that they have hyped it so much they can't back down now. They've worked to convince everyone that they champion openness, and the free distribution of Android apps outside of an app store is a major part of that campaign, that any backing down now would seem like a retreat of sorts. And that, Google can't have.


Android Cut By The Splinters

So it seems Eric Schmidt, chairman of Google, accidentally gave notice that Android 4.0, the next release of the search giant's mobile OS, will be released in the October/November timeframe. Of course, that may change but regardless it appears to be coming soon. Whether it comes soon or not, without major uptake by a lot of handset vendors and service providers, it's simply going to add to the growing pileup of currently deployed Android revisions, increasing the fragmentation even more.

Android 4.0, code named Ice Cream Sandwich, is intended to, among other things, refine the APIs with an effort to reduce fragmentation. Android 2.0 (Eclair) was released in October 2009, 2.2 (Froyo) was released in May 2010, while 2.3 (Gingerbread) came out in December 2010. 3.0, aka Honeycomb, was a tablet only version first released in February 2011. 2.2 (Froyo) is currently deployed on roughly 50% of Android devices with 2.3 (Gingerbread) installed on another 30% or so. Honeycomb, the tablet version, is only deployed to about 1.5% of Android devices, a fact which leads to its own conclusions, but that's for another time. The fact is, the APIs were originally supposed to be forward compatible. Something written to target an older revision of the OS should work on newer revisions, until a major release comes along which might break API compatibility. The API, therefore, is intended to provide shelter to developers hoping to deploy against the largest possible number of devices. The problem, though, isn't developer application support for various OS's. The problem is the hardware.

The handsets are targeted at a given revision of the OS and a lot of time and money is put into making sure the handset works as intended with that version of the OS. Even between minor releases, as evidenced by the already existing fragmentation, it has been difficult to get the various parties involved to consider revisiting existing handsets, some of which might not even be marketed any longer and therefore unlikely to provide further revenue through additional sales, in order to incorporate a new Android revision.

Android 4.0 is supposed to address this, allowing one OS to target both handsets as well as tablets. That's great, but realistically is not going to reduce fragmentation very quickly. To begin with, Android tablet sales have been something just shy of anemic but even then it is doubtful that without some potent new features unlocked with 4.0 any Android tablet manufacturer will want to revise the OS on tablets currently in the sales channel, much less those no longer being sold. As for handset developers, they're in a worse boat since many deployed devices are much older than any tablet currently out there. And it's not like current handsets will suddenly drop dead of electronic heart attacks now that 4.0 is available. They will continue to perform as they always have. So Android 4.0 is really only expected to solve fragmentation moving forward.

And yet, even with the release of 4.0 imminent, major manufacturers who must have had access to beta versions of Ice Cream Sandwich, have still elected to roll their own with forked older versions of Android (vis-a-vis the upcoming Kindle). Sure, eventually Android 4.0 will become the mainstream version rolled out on new devices. But by then Google might have already been working on Android 5.0, aka Monster Truck Rally (who knows?). Meanwhile, the Android ecosystem will be falling to pieces.


Google, Red Handed and Red Faced

Now making the rounds are comments surrounding the internal Google documents revealed in the Oracle v Google case. The bits that seem to have everyone's interest aroused concern two things. The pertinent bullet points from the discovered document are as follows:

  • Do not develop in the open. Instead, make source code available after innovation is complete
  • Lead device concept: Give early access to the software to partners who build and distribute devices to our specification (ie, Motorola and Verizon). They get a non-contractual time to market advantage and in return they align to our standard.

A lot of time and attention is being given to these statements, making Google out to be hypocritical or as having less than savory business practices. The fact is that there is absolutely nothing wrong with either of these practices.

The first bullet point, concerning not developing in the open, is innocuous. There's nothing evil going on here. There's nothing about open source or openness in general that requires your code repository be visible 24x7 for all the world to see. If you want to stay in the coding cave and do your development (or innovate as Google puts it), only releasing the fruits of your labor when they are ripe and bursting with innovative goodness, that is your prerogative. I suspect it's the word choice that has folks up in arms here but conceptually this is the same thing as the guy working on a new device driver to tack onto the Linux kernel, not releasing it until it's feature complete. Really, it's just not a big deal.

The second bullet point, concerning early access to partners who abide by Google's standards, is a bit more interesting, but nonetheless does not rise to the level of being 'wrong'. Perhaps a bit embarrassing and maybe even damaging now that it's out in the open, but not wrong. If Google is developing a codebase and wants partners to adhere to their standards as a precondition of early access, isn't that their right? Is there anything indicating they absolutely must provide access to everyone, equally? Most open source licenses simply indicate what is involved in the relationship between the developer and the recipient of the code. It has nothing to do with any other relationships. Should Google have done this? Probably not from where they're sitting now, but at the time it was a calculated risk. Were they able to offer something in exchange for partners abiding by the vision Google had for the Android platform? What were the chances of it becoming public knowledge? How damaging would it be? Unfortunately for Google they may be about to find out. For my part? *meh*