Random Musings on the M Developer Preview: the Ugly (Part Two)

This post wraps up the series that I started on Monday (“the Good”) and continued Tuesday (“the Moderately Disconcerting”, or “the Bad” for short) and Wednesday (“the Ugly (Part One)”), reviewing what is in the M Developer Preview.

IOW, as with popular movie franchises like “The Hunger Games” and “Avengers”, this trilogy goes up to 4.

Today’s focus is on “auto backup for apps”.

As with yesterday’s rant on M’s aims to reduce background processing to improve battery life, railing against backups would seem to be being against “motherhood and apple pie”, to use the American euphemism.

I love backups. I have a fairly extensive backup regimen for my office. I even blog about how developers need to do backups.

However, it has non-trivial privacy and security issues.

Suppose that Microsoft, a decade ago, made this announcement:

As part of Windows 7, we are going to automatically make a copy of all the files on your hard drive (or whatever subset we choose) to our servers. In accordance with our terms of service, we have a worldwide right to do pretty much whatever we want with that data. In exchange, we agree to restore that data, if your PC suffers some fatal calamity and you elect to replace it with another Windows 7 PC and the same software in a timely fashion.

I would expect there to be Congressional and EU commission inquiries about this, and for privacy advocates to be railing against the practice.

In essence, though, this is what Google has been doing all along, and is simply re-emphasizing now in M. Though, with luck, some of the problems with their approach are merely documentation errors.

Automatic backups are enabled for all apps installed on devices running the Android M Preview. No additional app code is required. The system provides users with the ability to opt out of automatic data backups.

Here, it indicates that the user has to opt out to avoid the backups, meaning that the user presumably was automatically opted-in. The current M Developer Preview does not work that way, in that backups are an opt-in process via the Settings app. However, that backup process is device-wide — either all apps are backed up or none are.

The automatic backup feature preserves the data your app creates on a user device by uploading it to the user’s Google Drive account and encrypting it.

Google is going to emphasize that the backups are encrypted. However, this is only going to work, from a privacy and security standpoint, if the user is supplying the passphrase or other key information. There is no evidence that this is part of the flow. Then again, since the backup system seems to have issues, it’s possible that there is somewhere for a user to supply a backup key that is just not obvious (or not available) in MNC.

However, my guess is that there is no plan for the user to supply the key. In that case, Google has the encryption algorithm and key, and so they can decrypt the data whenever they want. Keeping it encrypted on Google Drive might help in the case of a breach of network security, but it will not prevent Google from decrypting it of their own volition and using that data, including sharing it with third parties (whether by design or under duress). The only real defense that users and developers have are the terms of service agreements, and I leave it up to qualified legal counsel to determine whether or not those are adequate. In my decidedly non-legal-expert opinion, they are not.

All of this leads to two issues:

1. What if the app is being used for data that cannot just be backed up wherever/whenever? Using a US-centric example, what about apps that hold medical data governed by HIPAA?

2. What is the legal exposure to app developers for allowing Google to have access to app data like this? In the case of Google playing around with the app data, people will certainly sue Google. But might they come after the app developer as well? And what happens for other ecosystems (Amazon, BlackBerry, etc.) that use Android but not Play Services? If they adopt this same auto-backup stuff and route it to their servers, what are the risks?

This auto-backup capability needs to be more granular and support user-supplied pluggable backup transports. In other words, businesses should be able to say that the backup data goes to their servers, not Google’s, particularly for their own business apps. And if individuals would prefer that their data be backed up somewhere other than Google’s servers, that should be their right.

Also, please note that while this is advertised as “backup”, it is really “disaster recovery”. It appears that the only time these backups will be restored is if the user replaces their device with another one. There are plenty of other possible problems (human data entry error, unexpected data corruption, etc.) for which backups will be useful, but you will need to implement that sort of stuff yourself in your app, for any data that is uniquely stored on the app and is not automatically being reflected in some server somewhere.

So, what should developers do?

First, opt out in the short term, by adding android:allowBackup="false" to the <application> element in the manifest.

Then, work out a longer-term plan, perhaps in concert with your legal adviser, who can give you feedback about your risk exposure.

From there, I see four major implementation flavors emerging:

1. Simply remain opted out, so your app’s data will not be backed up.

2. Opt in (android:allowBackup="true") and rely on the fact that your app just doesn’t have any significant data that might represent any sort of privacy or security risk if Google ships it to their servers. For example, perhaps all of the data is actually on a server somewhere, with the device merely holding a cache (and note that caches, by default, are not backed up).

3. Opt in, but configure the backups to only back up one file, one that contains “bootstrap” data to help you connect the user to real backups that you are maintaining separately. This will allow you to compete on the basis of sophistication of backups, and you can still take advantage of “auto backup for apps” for disaster recovery scenarios. Just make sure that the “bootstrap” data is not itself going to lead to security issues — for example, using a URL to a backup is fine, so long as access to that URL is defended separately.

4. Opt in, but encrypt your app’s data at rest in the app itself, as part of normal work. For example, you could be using SQLCipher for Android as your database container. Now it does not matter if Google (or anyone) backs up the data, as the data is useless to them without the encryption key (or perhaps a $5 wrench).

Again, backups are good. Disaster recovery is good. Google’s stock implementation has risks for developers and is incomplete (in that it only deals with disaster recovery). Developers need to think through how backups work and what is appropriate for their app and their users.