Thoughts on Google’s Android Security 2014 Year in Review

androidI have finally got round to reading Google’s ‘Android Security 2014 Year in Review’ (pdf). I believe it’s mainly a public relations exercise to assure everyone that Android is safe and that Google is being proactive in improving security. However, having read the report it’s easy to come away with the impression that everything’s ok. There are few places in the report I thought “Yes, but…”.

First an obvious one. Google say they “provided device manufacturers with ongoing support for fixing security vulnerabilities in devices, including development of 79 security patches”. However, what they don’t say is that very few of them made their way onto consumers devices.

Google say “Fewer than 0.15% of devices that download only from Google Play had a Potentially Harmful Application (PHA) installed”. This doesn’t sound many. As an end user you will probably be comforted by such a statistic. However, what if you are a company with say 1000 employees? Statistically, at least one of them might be leaking company information. What if you are a bank with millions of customers using a banking app? If your app doesn’t adequately secure data then a very large number of people could be affected. I think what this means for developers is that just because there’s a low chance of infection, apps should still take exceptional steps to protect their own sensitive data and not solely rely on the fact the platform is secure most of the time. The fact that Android is “secure most of the time” is only of significance for end users.

androidphas

There’s lots of emphasis on Google’s Verify Apps that checks apps at time of install. This won’t catch everything. Attackers are getting good at installing skeleton apps and later downloading extra functionality after Verify Apps has stopped looking.

Also remember, security isn’t only about PHAs being installed. It’s also about the ability to easily obtain information from stolen devices, reverse engineer apps and other such activities that can cause nefarious deeds without even installing an app under Google’s Verify Apps.

Connection Quality Specific Downloading

Thinking about app download speeds, have you worked on a project where, having completed an app, a few people with what I call ‘intermediate quality’ connections, neither good nor bad, complain it downloads data slowly? The problem with intermediate quality connections is that they don’t complete fast and also don’t fail quickly due to not hitting timeouts. If you are downloading lots of things, slowly, the consequence of ‘only just’ not hitting http timeouts can result in the user perceiving downloads as slow.

The question then often becomes can we download different quantities or types of data for different users? Users on high end phones and good connections might be served richer data or more data at once while those with poorer connections might be served minimal or indeed no data. The problem is that it’s very hard to quantify all this and base your functionality on quantitative data.

Facebook has just made this problem a lot easier on Android because they have open sourced their Year and Connection classes. These can provide insights on how use varies with network performance and can allow you to vary functionality based on that performance.

Incidentally, Facebook have also just open sourced Fresco, a new image library for Android. Interestingly, it uses NDK (c native) memory techniques to store bitmaps, a technique I also happen to have used on a past project. I used this technique on a ‘kiosk’ single use device where it wouldn’t affect the memory available to other apps (because there weren’t any others). I am not so sure whether it’s right to use it on a general purpose device unless you carefully limit how much native memory you actually use. Jumping back to quality of connections, Fresco also provides for lazy loading of images from the network in a fast and smooth way.

Android for Embedded Projects

linuxdotcom.pngThe use of Android as an embedded platform interests me as I have worked on three such projects and those projects seem to have the most potential. Embedded projects are those that use Android to power a single-purpose device where the user interacts with just one app. According to VDC Research

“Embedded products running Android will gain share over the next few years. Over the last three years, Android shipments that did not include smartphones, tablets, and E-readers grew at a CAGR of 149.2 percent, culminating in about 15 million units shipped in 2014.”

VDC say that Android is currently eating into the share of Windows Embedded rather than Linux in areas such as automotive infotainment, medical devices, military handhelds, retail and signage. However, Android isn’t currently being used in areas more typically labeled IoT such as connected home and industrial automation.

Google’s Android for Work is Insecure

androidsecuritylogo.pngThere’s a very interesting article on "Android for Work: Demystified" that dissects Android for Work and concludes it isn’t that secure. The repercussions provide some important learnings for all apps that need to handle sensitive data.

Android for Work and Android disk encryption in general, suffer from a similar expectation and affliction. The expectation is that encrypted drives protect data which isn’t fully true. The affliction is that they only protect data ‘at rest’ while the phone isn’t running. Once the phone is running the drives are seen decrypted from software and can be accessed via root or via exploits that provide access as root.

The solution to the problem is, as the article hints, to encrypt the data itself and not just rely on the drive encryption. This is the crux of the message on my Android security web site. You need to define what data needs to be kept secure and protect it appropriately. Assume your app can and will be attacked and do your best to secure only the data that has to be secured. Don’t solely rely on mobile device management (MDM), drive encryption, apk re-packaging or any other higher level wrapper.

Tablet Growth Has Flatlined

idc.gifIDC has new research into tablet shipments and as a result has now reduced the forecast up to 2019. Android currently remains the leader with an expected 67.4% share this year while iOS is expected to have 25.6% share. Windows trails at 7%. The following chart shows how growth has flatlined…

idctabletshipmentsgrowth.png 

App Security Requirements

androidsecuritylogo.pngI believe that many Android (and iOS) developers have a blind spot for app security. Clients, product owners, product managers or whoever is responsible for the app rarely have security requirements and time-starved developers tend to ignore the problem.

What’s the problem? Well, on Android (see later for iOS) there are so many ways attackers can attack your app. Whether it’s re-packaging your app with malware, repackaging to circumvent functionality, stealing ip or stealing secure data an attacker has many choices of ways to attack. Methods include:

  • Unzipping, decompilation, recompilation and re-packaging of your code
  • Patching Android OS calls at runtime to intercept data
  • Examining runtime memory to see data
  • Taking a backup of app data and reading it offline

Some of these things are possible on unrooted devices and all these things are possible via a rooted device or, more seriously, via exploits that allow temporary access as root. Determined attackers can also create custom ROMs or emulator images that can intercept your app at given points in its lifecycle.

I encourage all Android developers to do some background reading. The droidsec Wiki is a great place to start to see the scale of the problem and the tools available. Unfortunately, there’s a lot more information on how to hack than there is on how to prevent hacking presumably because it’s more fun to break things than fix them. My Android Security site offers a ‘coding first’, guideline-based approach to prevent, as opposed to detect, security problems.

If you are a product owner or product manager I suggest you also research this area, define your secure data and, if necessary, uncover security requirements for your app.

For those iOS developers thinking, "Oh that’s Android, we are safe on iOS", you might like to take a look at Lookout’s latest assessment of iOS security and my previous post on Android vs iOS security.

CSS Tablet Forecasts

cssinsight.pngCSS Insight have some interesting forecasts for tablet shipments. They claim that tablet sales will double over the next four years as more first-time users appear and existing owners replace older models.

csssalesoftablets.png 

They also say Windows will claim a larger market share. I think this might even happen. People in our ‘IT world’, most of which now use Macs and Macbooks,  under-estimate the reach of Windows. However, in the ‘real world’ many people still use PCs. Take a look at NetMarketShare browser stats that cover 40,000 sites across the world. A very large number of people are still using Windows.

Allied to this are Microsoft’s new strategies. They already give away Windows free to OEMs on low end devices. They have also promised to upgrade Windows 7/8 free of charge when Windows 10 ships. The start menu will also make a comeback. In the longer term, these changes might help consolidate and retain existing users onto Windows 10 and sell more tablets. However, I still believe Windows on phones is probably a lost cause.

Thoughts on Android Studio

androidstudio.png

If you follow Android you will probably already know Google deprecated Eclipse and Android Studio is now the recommended IDE for Android development. I migrated all of my current clients’ projects last December. I hadn’t previously migrated them as I have a policy of not using beta tools on client projects – more to conserve development time as opposed to avoid introducing problems. I had used Android Studio, as a learning exercise, for some simple personal projects but had held back writing about the problems until v1.0 shipped and I had more experience of using Android Studio across several client projects. I am at that point now so here are my latest impressions.

The Good

  • First of all and importantly, it’s very easy to import Eclipse based projects.
  • IntelliJ IDEA has far superior code completion. It’s a lot quicker to code when you don’t have to go to other files/places to determine APIs and constants. It also seems to be very intelligent at offering a sorted list of the most likely code completions with the most likely first.
  • It’s good to now be able to easily create custom variants of apps via Gradle.
The Bad
  • It has poor NDK support for non-trivial NDK builds. You end up having to not use the built in Android Studio support for the NDK and instead configure Gradle to do a separate NDK build. This makes using NDK code less integrated and less visible in the IDE than it was with Eclipse. One of my client projects makes extensive use of the NDK so this issue is a larger problem for me.
  • Unlike Eclipse, you can’t have more than one project (that generates an apk) open at once thus making switching between projects inconvenient. To be fair, there’s less need to switch between projects now that it’s easier to have build variants.
  • Some run configuration parameters aren’t persistent between successive Android Studio sessions. Specifically, if a particular device is selected for debugging this isn’t saved between Android Studio invocations. You will be asked again next time.
  • There are still some bugs in frequently used features. For example, on loading an existing project, some projects refuse to see the ‘app’ part of the project until there has been a Gradle sync.
  • Unlike Eclipse, Android Studio doesn’t ‘compile as you go’ to produce issues in the ‘problems’ tab. Instead you have to build to see problems. This is a backward step. There’s a 3rd party plugin that enables auto-compilation if you dare (it hasn’t been updated for a long long while).

The integration with ADB is poorer than with Eclipse…

  • The logcat Window seems to periodically stop working and ends up in another logcat Window somewhere deep in the Android DDMS Window hierarchy. If you have multiple monitors and are used to dragging the logcat window out to a separate screen you will soon be frustrated when the logcat stops and ends up coming out in some other window. I’d say this is the most annoying problem of all.
  • There’s no ADB file explorer. You can now use the separate ‘Android Monitor’ application that gives essentially what you had under Eclipse. However, using this cuts off the ADB connection in Android Studio as only one thing can have a debug connection at any one time.
  • Selecting Stop doesn’t kill the app being debugged. You have to manually do this via the device Android task manager (or use ‘adb shell am force-stop <packagename>’ for Honeycomb and above).

Unfortunately, there’s more bad than good. As ex-Googler Jean-Baptiste Queru said yesterday "Working with Google tools: there’s the one that’s deprecated (Eclipse ADT) and the one that’s not ready yet (Android Studio)."

If you are interested in the ‘Present and the Future of Developer Tools for Android’ you might also like to read a very recent interview with Tor Norbye.