The Quantified Coder and OpenYou Subprojects

Earlier this week, I spoke at Google I/O on OpenYou and The Quantified Coder Project, one of the first "things I can do with all of the hardware I'm working on for OpenYou" projects. The talk is now available on YouTube.

(if it doesn't happen automatically, wind above to 12:47 for the start of my talk, though the whole thing is a great watch if you've got the time, as there are lots of QSy topics in it)

For those interested in the talk content, the slides and notes are available as a zip file.

As I've been working on sensors for OpenYou, I've been coming up with different ideas about what to do with all of this data once I've got it. Having an end goal for these projects keeps me motivated while I'm in the bit mines. What's I've come up with so far:

  • Golden Gate Wall - Rock climbing is a big new hobby for me (only been at it about a year), and seems like a neat place to think about engineering. There's already some neat research papers, for instance. I figured I'd 3D scan a rock climbing wall in Berkeley, CA, and start mapping information about it. Looking to do things like automated route planning based on past traversal by climbers who are wearing sensors, maybe doing some infoviz on the biometrics, etc...
  • Quantified Coder - In looking at accessing all of this hardware, I have to think about where I'm gonna be most of the time, and what I can do with the data from that time. Mostly, it's gonna be spent in front of the computer. So, why not try and make it add value to what I'm doing, like programming? That's what quantified coder is about. For now, check out the talk above for a more in-depth explanation of where I see it going.

Right now, my main goal with OpenYou is to get the community moving, adding a wiki for protocol information, and getting a few of the driver projects to version 1. I've done information gathering/centralization projects like this before (for instance, with the Compaq IA-1 Internet Appliance, many years ago), but they tend to lose focus if there's not a goal outside of that. The projects above give this procedure some shape, which will hopefully means I can keep on-going interest and attention as everything progresses.

So, in conclusion, yes, OpenYou is a my very own meta-quantified-self project. Nice that things work out like that sometimes.

Fitbit and Security, or Lack Thereof

One of the libraries that I work on as part of OpenYou is libfitbit, an access library for the FitBit pedometer device.

It's basically a tiny accelerometer that clips to clothing to work as a pedometer. It can also communicate wirelessly with its base station, so that whenever a user walks by their computer and assuming they have the Fitbit server software running, it'll automatically sync. The data is stored on fitbit's website (shown above, lower right), where they give you a nicely designed interface to see it, compare to friends, and for a fee, have it analyzed by on staff trainers.

The hardware itself is very well designed. In 3 months of having the device, I have yet to lose it (which is a small miracle), and it stays clipped to clothing. The battery seems to last pretty much forever, and the display is nice and crisp. The wireless has quite a range too, picking up the device while I'm in other rooms.

The problems began when it didn't have drivers for syncing via linux. Doing what it is I do, I figured I'd whip some up real quick. This is where things when horribly, horribly wrong.

(For those that want to skip the story telling version of this and just read the hard technical details, the reverse engineering document is available on the repo, which has all of the gritty technical details.)

The first thing I normally do when looking at new hardware is to check out what I can about the software that ships with the device. There's usually some logs around to help out. In fitbit's case... Well, the logs are beyond helpful. They're scary. Here's a chunk from the beginning of one of them.

01/28 23:31:55 Sending 4357 bytes of HTML to UI...
01/28 23:31:55 Processing request...
01/28 23:31:55 Waiting for minimum display time to elapse [1000ms]...
01/28 23:31:56 Waiting for form input...
01/28 23:32:04 [POWER EVENT] POWER STATUS CHANGE 01/28 23:32:14 UI [\.\pipe\Fitbit|kyle]: F
01/28 23:32:14 Processing action 'form'...
01/28 23:32:14 Received form input: email=[USER UNENCRYPTED EMAIL HERE]&password=[USER UNENCRYPTED PASSWORD HERE]&[other stuff]
01/28 23:32:14 Connecting [2]: POST to with data: email=[USER UNENCRYPTED EMAIL HERE]&password=[USER UNENCRYPTED PASSWORD HERE]&[other stuff]
01/28 23:32:14 Processing action 'http'...
01/28 23:32:14 Received HTTP response:

Yes, that's a user's email and password, unchanged and in clear text, being flung over to their website via a pure http connection. This step is also logged to the user's hard drive in a clear text file, that is world readable.

This is bad.

The log goes on to verbosely record everything the fitbit says to the website and vice versa. Fitbit sends all commands from their website to the device, meaning they never have to upgrade their client software, though firmware does have to be updated on the device every so often. This policy is actually an interesting move. It made it way easier for me to replicate how their client works for libfitbit, but also keeps them from having to update their client when they make new firmware.

To continue the fun, we move onto the promiscuous base stations. As a convenience measure, any Fitbit tracker device (the thing you wear, lower left in the picture above) will sync with any base station (the part that connects to the computer, upper portion of picture above). This means that if you're at a friend's place who has a fitbit, the device will sync, without you having to do anything.

However, in order for the information to go from the user's fitbit that's attached to them, to their account on the website, there has to be some identifier on the device to let the website know who's who. The tracker serial number does this. The first thing the website asks for is the tracker number, and it then returns the user ID associated with the tracker number. The user ID is what's used to access a profile page, i.e.[user_id]

After knowing the combination of user id and tracker serial, anyone can be basically authenticated and can send data to the site under the account the tracker is bonded to.

This is an incredibly easy system to spoof. I could walk around with a netbook and a fitbit base station in my backpack, gather serial numbers at a public meetup, then have all the account information I wanted.

Which brings us to the crux of the problem, and the reason I believe the software is the way it is currently: Why would I do that?

It's just steps, after all. Who cares?

This is one of the things I'm seeing more and more when reverse engineering medical hardware. It's not financial information, it's not important health information, so why should it be locked down?

While this may seem like a rather light issue (other than the password in the clear thing, which is 100% inexcusable), with common thought being 'woo, someone stole my steps!', the implications can get pretty staggering depending on how far out we want to cast the timeline, especially in relation to device popularity.

First off, one of the major marketing points of QS hardware right now seems to be synergy between information stores. Fitbit can now instantly upload a user's data to DailyBurn, Google Health, and other sites that the user links to it. This is considered a value-add for health hardware, since users may have been keeping information elsewhere before whatever device they're using existed. This also means that if I have write access to one account via the methods described above, I have write access to many accounts via account bonding across sites, assume the user has created those bonds.

To crank the paranoia level another notch, the amount of device companies I've talked to that are also looking at linking to health insurance companies really makes this a horror story. If someone maliciously gets into a user's health device account that then links into health insurance/health care, who knows what havoc could be wreaked.

Finally, there's lots of metadata that can be lifted from these devices as more and more of them go wireless. If you're wearing something that uniquely identifies you, that means all someone needs is a base station to tell who the user was, where they were, and when. In the days of geolocative apps and constant check-ins, there comes the question of whether people might want that implicitly, but this seems like it should be opt-in versus opt-out (or in this case, no opting at all).

So, yeah. Fitbit is a great design, and completely insecure, though not unfixably so. Everything I've talked about above could be easily fixed. Flip on https for transfers (but please don't encrypt everything, as I'd like my drivers to keep working), don't log everything ever to disk, allow users to set whether they want base sync promiscuity or not. It's not that bad. However, the fact that this was even seemed like a good idea in the first place is a bad precedent for health hardware to come.

And all I wanted was a pepsi some linux drivers.

OpenYou at the Quantified Self Conference

After making it to the San Francisco Quantified Self meetup last week, it became obvious how silly it would be to not show up to the Quantified Self conference in May. So, we'll be there with whatever hardware we can drag along. Looking forward to meeting people and talking about what can be done with new hardware!

Project Updates - Liblightstone and libomron

Time for what I do best, more project updates!

First off, after 3 years of brokenness, liblightstone may see full stability for multiple devices in upcoming v1.5.

The lightstone is a USB device that comes with the "Journey to Wild Divine" video game. The point of the game is to teach users to relax and breath deeply. However, with the game itself working sporatically thanks to being based on a very old version of Director, actually finding peace with WD rarely happens.

liblightstone was established in 2006 to help owners of the lightstone access data from the device in an open source, cross platform way. However, it has been plagued with bugs when trying to use multiple devices on the same machine, and the release of an updated lightstone with different USB VID/PID pairs caused problems. After finally obtaining one of the newer lightstones last week, I've fixed the aforementioned problems and hope to release v1.5 soon. I hope these will make the driver stable enough to call the hardware access project done for the foreseeable future.

v1.5 will hopefully be released in the next couple of days, after I do some testing across windows machines. I've been getting odd differences in device enumeration between machines with the WDK installed versus without.

The USB access code from liblightstone is also used in projects like libomron and emokit, so these bugfixes will be finding their way to other projects soon.

libomron is also going to be seeing some work soon as we try to continue it toward v1.0.

libomron is a driver for Omron based USB devices, such as the

  • HJ-720ITC Pedometer
  • HEM-790-IT Blood Pressure Monitor

It currently only covers those two pieces of hardware, as well as their foreign counterparts (like the M10-IT blood pressure monitor). However, it looks like most of Omron's equipment uses the same protocol, so the base of the library is extensible to new equipment as it comes out.

While the omron equipment isn't as flashy as, say, the fitbit, it's far cheaper ($20 for omron's USB pedometer if you find it on sale, versus $99 for a fitbit).

libomron is currently approaching v1.0, with a few things left to be done in order to get multiple devices working (same issue as liblightstone had), as well as getting device clearing working. Finally, we're hoping to have a simple XML/JSON/CSV data exporter available so it can be easily run by other programs with no need for interfacing at the source level, unless you want neat progress bars or something. Everyone loves neat progress bars.

np_epoc v0.2 released

v0.2 of the np_epoc external for Max/MSP and Pd has been released.

VID/PID and key are now selectable by users. Users can also get a device count to make sure the VID/PID pair is set up correctly.

Hopefully key and ID detection will be done by emokit soon, but that's going to take a little more work since we're not yet sure how the key is deduced on connection.

Binaries are available on the sourceforge NP Labs release site.