Way last fall, I took my old LifeSaver app and re-wrote it to store histories in Google App Engine back-end as opposed to the SD card, mostly because lots of modern phones don’t have SD cards. Then I had an attack of fear about deploying it, then I went on a world tour and got sick and took vacation and got distracted. I just published LifeSaver 2.0.

No Fear · The fear, of course, was of being the proprietor of a cloud database containing highly personal information. Lots of people had ideas on how to solve this, so I eventually picked the easiest: The data gets erased after an hour or so; see the Retention and Privacy write-up.

I am keeping records of how many personal histories were uploaded and downloaded, by how many unique users, but I’m irreversibly hashing the user IDs, so I think people are safe from prying eyes.

More Fear · I’m still a little worried. I’ve never actually run a production app on App Engine before. And I have to say, if there’s an Idiot’s Guide to How GAE Billing Works, I haven’t found it; there is scope for some more tutorial material.

I took the precaution of signing up for a paid account and authorizing a few bucks a day worth of spending. I honestly haven’t the faintest idea how this is going to work out; if anything interesting crops up, I’ll report back.

Conclusions · Still preliminary of course, but then all conclusions are.

  • I like writing Ruby code so much more than Java code.

  • Sinatra rocks.

  • I’m not sure of how applicable Google App Engine is in the wider universe of Web apps, but its RESTful API surface and key/value datastore are pretty well a perfect match for this one.

  • This will have been worth doing if only because I got AERC out of it.


Comment feed for ongoing:Comments feed

From: John Cowan (Feb 14 2012, at 09:02)

In your second vulnerability, you should really say "I and other Google employees". "Do no evil" is all very well, but "Hire no evildoers" is a counsel of perfection.

And what happened with the chorus of commenters shouting "Client-side encryption!"


From: Kevin Reid (Feb 14 2012, at 09:58)

When I visit Retention and Privacy on my phone (Nexus One, 2.3.6), as soon as I zoom in or scroll right, the lifesaver decoration is underneath the white text, making it unreadable. Also, the title of the page is "LifeSaver: Saved Life for timbray".

[A similar problem occurs on this very comment-entry form: the sidebar overlaps the header if the viewport is narrower than (header + 2·sidebar).]


From: Amy! (Feb 14 2012, at 10:41)

Is there any possibility that the server side of this might be released? Storage of this information anywhere outside of my control makes me nervous (so I won't use this, though the only thing I've found nearly-comparable simply backs up and restores SMS, not call logs). If I could set it up on my own server (heck, even on a non-server where it could be started and stopped as needed), I'd find it more compelling.


From: PJ (Feb 14 2012, at 10:48)

Isn't http://android-developers.blogspot.com/2012/02/share-with-intents.html another way to save your data? Then import could be something like 'hey look at this URL'


From: Martin Probst (Feb 14 2012, at 12:20)

Front end:

Your application is probably trivial for the server side work. I have no idea what it might or should cost you, good luck ;-)

It would be great if Google could provide case studies of applications and how much frontend hours they consume.

Data retrieval:

You can get everything you need with a simple get by key from datastore, and delete old records with a simple query every hour. A datastore read costs 0.07 $ per 100k operations, a write or delete if you only index the 'updated' time about 0.40 $, so storing the data for 100k users should cost you a dollar. If you put everything into memcached on top of it, you should even be good for most repeated read requests.

Data storage:

Assuming a payload of 1kb, you can store 100k user's data for some 0.24 $ per month, which would mean 100k active users per hour, which is rather unlikely, I'd guess.

So even if your application is ludicrously successful, data storage and retrieval shouldn't cost you much. No idea about the processing.

Regarding client side encryption, AppEngine currently doesn't have a way to encrypt user data such that the application cannot access it without the user later (e.g. a cryptographic secret available from the UserService).

So you wouldn't just need client side cryptography, you'd also have to worry about how to transport keys from A to B. That seems quite hard to do in a user friendly way, and cryptography is way too easy to get wrong anyway, I guess.


From: John Gill (Feb 15 2012, at 01:32)

"Hear, hear" regarding appengine billing.

I wrote a couple of appengine apps. Both small. One was a soccer prediction league for me and my friends, the other an experimental service to help Ottawa bus users find out where the buses actually are.

appengine used to be excellent for this sort of thing, no worries about running up a bill. It gave me a chance to learn how it all worked (thanks Google) and so I was likely to use appengine for any other tool I might write.

With the billing changes the attraction is gone completely. I prefer to just write django apps and not be tied to appengine.


From: Anton McConville (Feb 15 2012, at 07:05)

Very cool, Tim.

I especially liked your one hour solution - I think mostly because I learned from it - it would not have occurred to me to do that, right away.

Wonder if you thought about saving the data in the user's Google Spreadsheet account? You can ask for permission to do that when they log in, then write the data to a new spreadsheet for them using the data api.

It could help save $ in storage, and it also delegates the lifespan of the data to the user and their own use of Google Docs.

As for:

'if there’s an Idiot’s Guide to How GAE Billing Works, I haven’t found it; there is scope for some more tutorial material.'

Shouldn't there be an app for that? Maybe a 20% project for someone? - I'm thinking something visual like a mortgage calculator, or/and interactive where you could give it an appspot url to analyze for you.



author · Dad · software · colophon · rights
picture of the day
February 13, 2012
· Technology (87 fragments)
· · Android (62 more)
· · Web (393 more)
· The World (126 fragments)
· · Life Online (268 more)

By .

The opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.