Cloud Lifesaving and Fear

Last year I built (and of course blogged) this nifty little Android app called LifeSaver, which would copy your telephone-call and SMS logs onto an SD card, so you could move the SD card to another phone, run LifeSaver again, and get ’em all back. Calls and texts aren’t migrated by the excellent Android backup system.

A few thousand people used it (I sure did, since I change phones all the time), and reviews are good. But it’s becoming less useful, because lots of phones these days don’t have SD cards.

A smart Googler suggested I put an App Engine back-end on it, so it wouldn’t need anything but a network connection. I did, and it works. But I don’t think I can publish it.

Quiz · Can you see why this idea turned out to be flawed? I’ll tell all in a few paragraphs, extra points if you’ve already said “That’s a horrible idea!”

Mechanics · With one exception, the change was almost stupidly easy to make. The app already knew how to translate the Android log data back and forth into JSON, just fine for pumping back and forth over the Web.

Then I had to write the App Engine back-end; I’d never done one of those before. The main options for that are Python, Java, and Go. I do Java all the time and don’t particularly like it. I already learned Python once, partly. Learning Go would be a Personal Growth Experience, and what with App Engine and Android Authentication, this project already had two of those.

So I didn’t do any of those things. I used Sinatra on Jruby on Java on App Engine. Because I miss doing Ruby at work.

That stack isn’t an official day-job project for anyone, and the pieces don’t always fit together 100%; you’ll need to use rvm, and then I had to downgrade gem to get Bundler running. But once things were in place, it all Just Worked.

App Engine · I’m no App Engine expert so I don’t have a useful opinion on what kinds of apps you should and shouldn’t use it for. But I can report that for this project, it was just the ticket. I want to do basic CRUD operations on tuples, my latency requirements aren’t very demanding (the saves and restores run in background on the phone), and I sure don’t want to invest any time or money in sysadmin-ing a server.

App Engine’s DataStore thingie met my needs exactly; the semantic gap between a JSON object and its notion of an Entity is pretty well zero. I have to say, the whole thing was a treat to write. Here’s the core code that handles the call log being uploaded from the phone:

post '/calls/' do
  begin
    if !check_user(request)
      redirect @auth
    else
      request.body.rewind  # in case someone already read it
      data = JSON request.body.read
      count = 0
      data['calls'].each do |row|
        count += Call.incoming(row, @auth).store
      end
      "Stored #{count} calls"
    end
  rescue => e
    croaked e.message + e.backtrace.inspect
  end
end

The Java code on the phone wasn’t nearly as pretty, but that’s just the way Java code isn’t. There was nothing taxing about the data fetching or pushing or pulling of course. So, slam-dunk, right?

Except For... · Identity and authentication. My thinking was, on an Android device there’s going to be a Google Account for sure, right? And those work with App Engine, right? So connect A to B and you’re done.

I was half right. On the App Engine side, it really is just that easy. In that little code snippet above, see that if !check_user(request) thingie?

def check_user(request)
  if AppEngine::Users.logged_in?
      @auth = AppEngine::Users.current_user
      true
  else
      @auth = AppEngine::Users.create_login_url(request.url)
      false
  end
end

This Just Works and does the right thing, whether you’re coming in from a phone app or an actual browser with a human behind it.

On the Android-client side, I found the authentication libraries to be a little on the twitchy and subtle side, and the specifics of using them to get at App Engine were thinly documented.

But I figured that out and decided it was worth encapsulating the solution in a little library and writing about it, so stand by for that.

Free Web Sites! · Then it occurred to me that since I had this data there on App Engine, all I had to do was make an HTML version of it and I’d have a site for each user containing the history of their calls and texts.

Since the data was just a bunch of tuples and I could code it up in Ruby, it took approximately 15 minutes to get it on the air; then I invested extra time in making it look like the LifeSaver screens in the Android app. Here’s a screenshot; phone logs in the cloud!

By the way, have you figured out the Big Problem yet?

Know Fear · I got a few friends to dogfood the app, and as soon as the first one said “Hey, it works. That’s... weird”, I saw it.

If I put this sucker on the air, I would become the proprietor of a shared database containing not just “Personally Identifying Information”, but people’s whole bloody lives. A programming error could ruin those lives, because there are quite a few people who’ve made phone calls and sent texts that they’d really rather not share with the world.

And I suppose it’d be only a matter of time before I got a subpoena from some law-enforcement official tracking down Anonymous hacktivists or maybe even real criminals.

Having said that, I showed a draft of this to a smart Googler and she said “I wonder how bad/how much worse it is given that law enforcement can pretty much go to carriers today to get all the info anyway.” Maybe I’m overthinking this.

What Next? · I’m not sure, actually. If all else fails, I’ll open-source the code and then if someone else wants to run such a service it’s their funeral.

One possibility would be to encrypt the data using some info from the Google Account which would only be available to someone who’s actually logged in. Then the information would still be in the cloud, but not accessible to the database operator.

Another possibility would be to use the cloud just as a temporary staging service; you can upload your history but it only persists for 60 minutes or until you download it, whichever comes first.

Which means you wouldn’t have the nifty online website of your history; but I’m increasingly conflicted as to whether that’s a feature or a bug.

What do you think?

---

---

Contributions

---