User:WillWare/Google Gadget Home Controller

You've got a burglar alarm or lab automation system running on some random PC somewhere, but your ISP blocks port 80 and doesn't offer a static IP address. How are you going to monitor and control it from within a Wave? HomeController is a Google Gadget that permits secure access to those remote clients within a Wave or elsewhere on the web. Example remote clients include: This idea evolved from an earlier incarnation.
 * Smart-home systems that report home security status or accept commands for X10-controlled appliances ("Clipper, I'm coming home, turn on the driveway light")
 * Laboratory automation systems that are controlling and monitoring experiments running overnight or over the weekend
 * Software build systems running overnight
 * Test automation systems that run a roomful of embedded devices through a test suite
 * Shell access to some remote Linux box somewhere

Architecture
HomeController is made up of two pieces.
 * A Google Gadget, which can be embedded in a blogspot page, iGoogle front page, or on a Wave.
 * The Reflector is a server that relays information between the Gadget and the remote client. It's a web app running on App Engine, using the Datastore to maintain client information between pings from the two clients.

The gadget and the remote client are both clients, the reflector is a server. The remote client makes HTTP POSTs including status to the reflector. Status takes the form of an HTML snippet. The reflector is an App Engine web app. Pretty much everything is JSON.

User prefs for the gadget
I am having trouble getting the user prefs to work
 * the URL for the reflector, which doesn't really change, but theoretically could
 * the name of the remote client; the reflector should be able to handle many clients as long as they all have unique names

Stuff left to do

 * Registering and de-registering clients is still a kludge.
 * User-friendliness -- look for ways to make it really clean.
 * Provide several examples of what client code could/should look like. Clients can be written in any language, it's just a web protocol.
 * Handle 99% of clients with a single piece of client code that has nearly zero configuration.

The Reflector really needs a nice GWT app for administration. It can continue to use the client protocol, as long as I don't mess up the security.

It would be good to put together something like a mathematical proof that the whole security model is solid. A language for discussing software security, and expressing such proofs, would be a valuable thing itself. There's a lot of research literature on software correctness proofs, although practicing software engineers almost never use that stuff. Something similar should work for proving that a security model is bullet-proof.

Another half-baked idea, unrelated: somebody should do an ad-supported web app that lets you design a business card, and download the business card in PDF or whatever other format that printers like. Maybe I should do that.

Security
I'm pretty sure the security is fairly bullet-proof. That means that a hacker should not be able to send commands to your remote client.

When you set up your remote client, you set up a password. Assume that password is strong enough not to be guessed.

Communications between the client and the reflector are via HTTPS, so the only communications to worry about are those between the Gadget and the reflector. (Note to self: any reason not to HTTPS those communications as well?)

For every command it receives, the remote client will create a long random string called a "salt", a term from the cryptography literature, and transmits it to the Gadget. When you type a command into the Gadget, you also type in a password, and the Gadget computes a cryptographic hash of the salt, the password, and the command concatenated. The salt, the hash, and the command are all sent back to the remote client.

The hash function prevents the listener figuring out the password. Because the salt changes on each command, the listener can't listen to a session and then play it back later.

Google Gadgets Editor and the development cycle
A huge thing was the development cycle. A Gadget is an XML file with HTML and Javascript in it, and I chose to use GGE, an editor which lets you publish the Gadget directly onto your iGoogle front page.

GGE is great but Look Out for Browser Caching! Your browser will want to cache the Gadget, and you need to work around that every time you edit and re-publish. The way I did that was to make each save to sequential filenames: foo001.xml, foo002.xml, foo003.xml, etc. This also gives you a free cheesy form of version control.

App Engine Logs
I am running the reflector on App Engine, and I found the logging on App Engine to be incredibly useful. The code is running on some remote environment that I can't see, so the log is invaluable. I bookmarked it in my browser.

My wish list
I'd love it if Google would produce a simulated Gadget environment that runs on my machine and plays nice with the simulated App Engine they already supply.

I also wish they would provide a simulated Wave environment for Robot development, but that's a topic for another venue. A Robot is written as a web app, and you can run it just fine on simulated App Engine, but I had to write a bunch of Python code to test the Robot, and realized I was part-way to building a Wave simulator. They should just go ahead and do that.