Predictions of Play Store Fallout

The recent changes to the Play Store terms of service, requiring physical addresses and imposing a service-level agreement (SLA) on support questions are not terribly surprising moves. Google is basically trying to get developers of paid/in-app purchasing (IAP) apps to “raise their game” and provide better support to buyers.

That being said, I’m not sure that Google thought this all the way through. This has the whole “frog/boiling water” trope written all over it: while developers had been putting up with more and more hassle from Google, this particular change appears to be enough to get some developers to jump.

Tactically, the Play Store might well shrink in size over the next 60 days, as developers pull apps from the store, or Google kicks them out for failing to abide by the revised terms. If I’m Apple, I’m hoping that some independent service reports such an event, then using my press contacts to make sure the tech media trumpets how Android developers are leaving in droves.

Strategically, though, I expect to see several things arise in the coming years:

  • More emphasis on agents: There should be a rise in firms that will serve as agents for app developers. These agents would license apps from developers and sell those apps on the Play Store and elsewhere, in exchange for a cut of the proceeds. These agents, in turn, would provide the physical point-of-presence and front-line SLA handling, delegating any “real” support questions to the developers.

  • Formation of developer cooperatives: Some agents will likely be scum, if for no other reason than middlemen tend to run the gamut from sensational to scum in other places. Hence, I expect one or more developer cooperatives to form, to help ensure that there is at least one non-scum middleman. These would be registered as businesses or non-profits and would serve as an agent for their members, filling the middleman role while being a bit more transparent and friendly to the membership. Cooperatives with significant traction in specific countries might offer additional member benefits akin to what you might get from other forms of associations, such as group health insurance in the US, with an eye towards helping individual and small business developers. It is possible that existing groups, like the App Developers Alliance, might morph into this role.

  • Rise in interest in other distribution channels: Individual developers frequently skip other distribution channels (Amazon AppStore for Android, BlackBerry World, direct distribution, etc.) as they are a bit of a headache. Agents will be more interested in those channels, as they are “force multipliers” for their catalog of licensed apps. This in turn should spur development of Play Services replacement frameworks, better instructions for writing apps that can be deployed in multiple channels at once, and so on.

  • Greater consolidation of developer power: Agents, whether they are independent firms or are developer cooperatives, will wield more power than will the individual developers they represent, just due to sheer mass. Whether that concentration of power will be sufficient to cause Google to start behaving more transparently will depend largely upon…

  • Legal action: From the EU competition commission to class action suits, I expect Google’s legal team to be busy. Other markets may sue to break the “most-favored-nation” status that the Play Store has on Android devices, attempting to drive Google to create an “app installer” API that developers could support and users could opt into to allow apps to have Play Store-like ability to install and upgrade apps. Greater transparency around apps being kicked out of the Play Store, better support channels from Google to developers, and the like will also be part and parcel of what legal action might try to improve.

Now, my skills at predicting the future are modest at best, which is why I write Android books and do not tell fortunes. However, these seem like probable responses to the recent Play Store moves.

Sep 29, 2014

Upcoming Conference Presentations: Samsung Developer Conference

I have one more event scheduled for this fall: the Samsung Developer Conference. I will be delivering a couple of presentations there, on optimizing memory and power usage within your apps. These presentations should be on November 14th, though the exact schedule has not yet been announced.

I don’t speak at many vendor-specific events. Where I do, I make sure that I speak on general Android development topics (albeit ones of relevance to developers targeting that vendor’s specific environment). My presentations at the Samsung DevCon are valid for all Android devices, not just the Samsung line.

Also note that I don’t accept speaker fees or other significant compensation for speaking at events. At most, I might ask for the event to pick up the cost of a hotel or flight, but not always, and in particular I am not receiving any expense reimbursement from Samsung for speaking at their event. I am simply serving as a freelance Android developer evangelist, to help Android developers be efficient and effective in their app development.

Sep 25, 2014

The Busy Coder's Guide to Android Development Version 6.0 Released

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 6.0, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!

This largely completes the Big Book Pivot of 2014, adding Android Studio coverage to all of the core chapters (including the tutorials) and some of the trails.

Along the way, this includes:

  • Adding build.gradle files for all projects

  • De-Sherlocking all projects, except those that are specifically demonstrating ActionBarSherlock

  • Removing the chapter on IntelliJ IDEA and replacing it with material more specific to Android Studio

This book update also:

  • Adds a chapter on the manifest merger process, with particular emphasis on Gradle for Android and how manifests from different sourcesets plus libraries combine to create the generated manifest for the app itself

  • Adds a number of small improvements to the core chapters, as part of a more thorough review of that material

  • Tweaks the tutorials, partly to deal with Android Studio issues, and other minor changes to improve the instructions

  • Various errata fixes

Updates should now return to their normal every-four-to-six-weeks cycle, emphasizing new APIs, tools, and the like. I am planning on three updates yet in 2014, with Version 6.1 due out in early October.

If you are not a subscriber, you may wish to learn what the Warescription has to offer. The book, plus a year’s updates and other Warescription benefits, costs $45 (credit card/debit card/PayPal) or its equivalent in Bitcoin.

Sep 03, 2014

Defending Against "Camera Peeking" Attacks

Yesterday, I blogged about a research paper describing various attacks. In yesterday’s post, I covered defending against another activity popping up and masquerading one of your critical activities.

Another attack outlined by the paper is easier for an attacker to use… but is also easier to defend against. The paper’s authors refer to it as the “camera peeking” attack.

A camera, as identified by an instance of android.hardware.Camera, can only be used by one app at a time. The attack is simple:

  • monitor for when an app that might use the camera for something important comes to the foreground

  • at that point, start watching for the Camera object to become unavailable

  • once the Camera is unavailable, then available again, grab the Camera and take a picture, in hopes that the camera is still pointing at the confidential information

The example cited by the paper’s authors is to watch for a banking app taking a photo of a check, to try to take another photo of the check to send to those who might use the information for various types of fraud.

Polling for camera availability is slow, simply because the primary way to see if the camera is available is to open() it, and that takes hundreds of milliseconds. The paper’s specific technique helped to minimize the polling, by knowing when the right activity was in the foreground and therefore the camera was probably already in use. Then, it would be a matter of polling until the camera is available again and taking a picture. Even without the paper’s specific attack techniques, this general attack is possible, and it would not surprise me if there are more efficient ways to see if the camera is in use.

On the other hand, the defense is simple: if your app is taking pictures, and those pictures may be of sensitive documents, ask the user to point the camera somewhere else before you release the Camera object. So long as you have exclusive control over the camera, nothing else can use it, including any attackers.

A sophisticated implementation of this might use image-recognition techniques to see, based upon preview frames plus the taken picture, if the camera is pointing somewhere else. For example, a banking app offering check-scanning might determine if the dominant color in the camera field significantly changes, as that would suggest that the camera is no longer pointed at a check, since checks are typically fairly monochromatic.

Or, just ask the user to point the camera somewhere else, then release the Camera object after some random number of seconds.

General-purpose camera apps might offer an “enhanced security” mode that does this sort of thing, but having that on by default might annoy the user trying to take pictures at the zoo, or at a sporting event. However, document-scanning apps might want to have this mode on by default, and check-scanning apps might simply always use this mode.

Aug 26, 2014

Defending Against Activityjack Attacks

A number of media outlets reported on a research paper and USENIX conference presentation describing a way by which your users could be tricked into providing confidential information — passwords, credit card information, and such — to a piece of malware, rather than to your app.

The paper points out that there are ways of writing malware such that:

  • the malware can pop an activity in front of yours, and

  • do so at just the right time, to mimic one of your activities, such that the user thinks that the malware’s activity is actually yours and enters the confidential data into the malware activity

For the purposes of this blog post, I’ll refer to this as an “activityjack” attack. Just as a clickjacking attack tricks Web users into clicking on the wrong things, and just as a tapjacking attack steals Android touch events via a transparent layer on top of the screen, an activityjack attack steals input destined for your activity by interposing another activity on top of yours.

The particular means of implementing the activityjack attack outlined in the paper is a bit esoteric. What it does do, though, is illustrate that such an attack is possible. Half the battle with security is knowing what you need to defend against.

The paper outlines solutions to their particular flavor of activityjack attack that require OS modifications. That’s fine, and perhaps the Android project will implement that stuff. But it will take years for such changes to percolate through the Android device ecosystem. For example, tapjacking was “solved” in Android 4.0, but there are millions of people using devices older than that, even today. Hence, we need to think as much, if not more, about application-level solutions.

Let’s ignore the details of the particular approach from the paper. Let’s merely assume that an attacker can get their activity in front of ours at the right time, as there are less-esoteric ways of doing the same thing (e.g., via an AccessibilityService). How do we defend against that for critical activities, such as “login” activities that require the user enter a passphrase?

An activityjack attack has two key weaknesses:

  1. The attacker cannot see the screen, because on non-buggy devices, the attacker has no means of capturing a screenshot of our activity as it comes into the foreground. Hence, while the attacker can create an activity that tries to mimic ours, they can only do so statically, analyzing our activity’s UI on their development machine and creating their own lookalike.

  2. We know that our activity has left the foreground, as we are called with onPause() (and perhaps other lifecycle methods, depending upon the nature of the attacker).

Hence, one defense can be to include in our activity a secure element that cannot be mimicked ahead of time, then hide that element (or our whole UI) when we are no longer in the foreground.

This concept of a secure element is not new. Some financial services Web sites have taken this approach. As part of the user setting up their online banking account, the user chooses an image from a collection of clipart. On the Web page that collects the user’s passphrase, the page also shows this secure element. The user is taught that if they do not see their chosen image, then the Web page they are looking at is not really from their bank, and therefore they should not type in their passphrase.

This is not that hard to implement in Android. You too would allow the user to choose a piece of clipart, displaying that in an ImageView on your secure activity in onResume(). In onPause() you would hide that ImageView via setVisibility(View.INVISIBLE). That way:

  • Since the image is chosen by the user, the attacker is unlikely to mimic the same image

  • Since you are hiding the image when you are not in the foreground, the attacker cannot use a transparent region in their activity to have your image “peek through” their attacking activity

As a result, if the user is paying attention, the user should see either the wrong image or no image at all, and the user should realize that they are being activityjacked and therefore fail to proceed.

You might be tempted to do something else in response to your secure activity being replaced in the foreground by another app’s activity, such as pop up a warning dialog. However, there are plenty of valid scenarios when this would occur, such as an incoming phone call, and you have no reliable means of whitelisting all possible valid scenarios. There will be a high incidence of false positives, and that may not help the user. Having this as an user-selectable option is fine, but I would not go this route by default.

With luck, somebody will come up with a better defense, one that makes it more likely that the user will not provide confidential information to the attacker, yet not be so onerous that they get fed up with your app and uninstall you. However, this approach should be reasonably easy to implement and help defend your users from activityjacking attacks in critical activities.

Aug 25, 2014

Older Posts