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.

Smartphone Sales Grew 20%

gartner136.gifGartner has some new research that shows smartphone sales grew by 20% for Q3 2014. However, the respective OS market shares stayed roughly the same…  

gartnetq314.png

What’s more interesting is that three of the top five smartphone vendors are Chinese: Huawei, Xiaomi and Lenovo. Samsung continues to see a double digit decline in percentage market share. I suspect we might eventually end up in a situation of Apple vs Chinese Android.

State of Mobile Commerce

criteo.pngCriteo has some new analysis "State of Mobile Commerce Q4 2014", covering over $130 billion of annual sales across more than 3,000 online retailers globally. There are lots of insights and the research upends many assumptions.

Consumers are buying on mobile. Smartphones have overtaken tablets and the average order value is reaching desktop level. Criteo say "It’s now important to reach Android shoppers"

androidtransactions.png
If you are using apps to sell something real then you can’t ignore mobile and you can’t ignore Android.

Beacons Need Content

prismatic.pngThere’s a thought-provoking story at prismatic that explains Why the beacon revolution has been postponed. I worked on an iBeacon client project (on Android) this past year and some of the observations are similar to mine.

If you don’t know what beacons are, at their simplest, they are just Bluetooth Low Energy (BLE) devices that don’t need conventional Bluetooth pairing. This means iOS and Android devices can easily detect them and apps can perform actions when they are detected. The (i) in iBeacon is mainly only a Bluetooth custom packet (data) format defined by Apple, an extra interpretation of the signal strength as a range of intermediate, near and far and the ability of iPhones themselves to become beacons. Hence, (later) Android devices can also see iBeacons and the signal strength can be used to determine range.

Back to the story, Tim Dunn says that beacons need a lot more than installing small beacon devices into stores or venues. The system requires "wholesale changes in data management, user identification, merchandizing, messaging and the build of a new set of CRM rules". It "requires commitment in CRM and content generation".

I agree with Tim. It’s not just about installing beacons and creating the iOS and Android apps which can be (human) resource intensive in themselves – although 3rd parties now offer SDKs and backend systems to ease integration. The clever and innovative parts are in associating the right business objects (Stores, venues, rooms, products, even people) with beacons and continually creating appropriate and timely content. The last part, "continually creating appropriate and timely content" can be hugely (human) resource intensive and I think there are many opportunities in this area to automate content generation for specific industry areas.

IDC Smartphone Predictions for 2018

idc.gifIDC has new research into Smartphone shipments and predictions for 2018. 1.3 billion smartphones will ship this year representing an increase of 26.3% compared to 2013. However, this growth is set to decline to about 9.8% compound annual growth between 2014 and 2018. The respective Android and iOS market shares are expected to stay at about the same order of magnitude over this period.

idcsmartphonedec2014.png 

If IDC are right, this means we will be entering a relatively stable period for mobile developers with no major differences in market share likely to cause developers to switch between platforms.

Generally speaking, if you are selling something then iOS will continue to be your most important platform as it’s a self-selecting group of users who have higher disposable income. If you are providing a service and need reach, then Android is your most important platform as it represents 82.3% of devices in use. However, my usual advice applies – survey your intended users and see what devices they own. Depending on your industry, you might be surprised.

Web Access From Devices

scientiamobile.pngScientiamobile has a new free MOVR report (PDF) for Q3 2014 showing device usage trends, particularly related to web access from mobiles. There’s lots of data on form factors, top smartphones, top tablets, top OSs for browsing across different continents. A chart that caught my attention was one that showed the use of WebViews within apps to view web pages…

appwebviewsbyos.png 

Why does Android have a much higher proportion of web page views from WebViews? I’ll be contentious and guess it’s because developers put in less effort on Android. WebViews are the quick and easy route to getting an Android app with the compromise of poorer usability. I guess it’s because companies/developers tend put less effort into Android apps than iOS apps.

On a recent project, I argued (unsuccessfully as they are still there) that WebViews make a very poor substitute for real screens (Android Activities). Without a lot of effort creating a responsive server-side, the web pages don’t look like app screens, the app vs web navigation breaks down, you get links rather than buttons/list items, you open up many complex security vulnerabilities and content authors end up thinking it’s ok to add arbitrary server-side content. For example, I saw content being included that had sharing buttons and feedback forms that looked alien in the app and didn’t work well. It made me uncomfortable that the app I had written had become something I wasn’t proud of.

Meanwhile, Google are trying their best to make Chrome and by implication, WebViews feel more like the platform you are running on. This started with Material Design which they hope will unify the look and feel cross platform. Google are pushing to reduce the distinction between app screens and web screens. The Lollipop Launcher (Home screen) includes cards that can be web pages. Chrome Developers Tweeted from the Chrome dev summit yesterday…

chromedevelopers.png

Google are also working on Chrome rendering performance, push messaging, Bluetooth, notifications, access to camera, geofencing and background sync as well as corresponding web site permissions to control access to these new features. All these things will eventually help the web become more like an app.

However, all this is very Chrome centric. Consistent design and available functionality will only work if you use Chrome and implement Material Design cross platform and even if you did, Material Design web pages aren’t going to look good on iOS. Even the example in the above tweet shows a Navigation Drawer (hamburger menu) on the right hand side in the wrong place. In reality, Android Chrome users are more likely encounter iOS idiom-based web pages with disclosures than Material Design web pages. I anticipate the web and WebView content/functionality will continue to be an idiomatic mess.