Liminal Existence

I've done a fair bit of security work, and generally try to care about the finer details of privacy and security. However, one of the things that I've learned is that more often than not, no amount of digital security past a certain point is going to help, since usually the threat model isn't an advanced technological attack, it's a social one.

Thus far, Google has done a pretty good job of keeping private things private and public things public. I've spoken to people on the Google Reader team, and the main reason they haven't added support for private feeds is their acute concern for privacy.

Today Google announced a limited trial of storing health records online. This seems reasonable and doable in a secure way, but I'm sure they'll get lots of unwarranted flak for the long-awaited project.

However, there will and should be some warranted flak. It turns out that they're using your regular Google account to store this information, and will provide access to it using your regular password, no doubt through yet another Google login page. I've heard concerns that OAuth supports phishing (from Google people), but project infighting and power struggles at Google that result in tens of login pages, all slightly (or dramatically) different, all using the same credentials supports phishing much moreso.

I strongly support patients' rights to access their medical information, and Google is probably one of just a handful of organizations that can do the necessary coordination work and stand up to invasive organizations at scale. However, they need to stop thinking of this data as theirs, because it's not — it's your data. Using the same password as your email to access your health records is something that should be actively discouraged. If Google wants to present a unified interface, they should expose an API and use OAuth or AuthSub, just like any other third party that would consume the data.

Now, I may be over-reacting, but I had an interaction yesterday that suggests to me that I'm not. Someone using GTalk sent a chat request to blaine@twitter.com; this email address has an MX record that resolves to mail.twitter.com, and the corresponding JID resolves to jabber01.twitter.com. However, I have claimed my blaine@twitter.com address on GMail, and associated it with my primary GTalk ID (romeda@gmail.com). When I accepted the chat request, the response came from my GTalk account, romeda@gmail.com.

In effect, Google had done something clever, and in so doing broke the Jabber spec, ignored my own self-hosted Jabber server, and exposed my personal email address without asking my permission.

In this case, it wasn't a big deal, I don't care, etc. Others might, though, and I only knew that it was happening because the person on the other end of the chat was tech-savvy enough to realize what had happened. Also, email addresses and connections between them are hardly closely-guarded secrets. The thing I take away from this is that Google is being sloppy. There's a lot going on, and it's hard to keep track of it all. That your health records are being tied to your Google account just reeks of some power struggle where the Google account people want to bolster their product's internal importance (or have managed to do so that they get veto power where they shouldn't have it), and it's simply not a pragmatic choice. There's a reason your health records aren't stored at the DMV, and it's not out of convenience. Just sayin'.

Labels: email, google, health, jabber, privacy, security

Jabber::Simple [src, doc] is a simple (duh!) Ruby library that aims to make the implementation of basic Jabber functionality trivial. It is an extraction of the Jabber support that was added to Twitter, and is released under the GPL by Obvious. A line of code is worth a thousand words, so here is the complete code for sending a simple message to a Jabber user:

jabber = Jabber::Simple.new('rex@friendosaurus.com', 'password')
jabber.deliver("bront@friendosaurus.com", "Hey! I'm thinking of going Vegetarian - Any suggestions?")

Getting incoming messages is just as easy:

jabber.received_messages do |msg|
  puts "#{msg.body}" if msg.type == :chat
end

You can also set your status, and get information about your friends' statuses:

jabber.status(:away, "Eating at the Tree Cafe. I need a ladder.")

jabber.presence_updates do |update|
  friend = update[0]
  presence = update[2]
  puts "#{friend.jid} is #{presence.status}"
end

Installation

sudo gem install xmpp4r-simple

or download the package from RubyForge. Source code is also available, licensed under the GPLv2.

Yet Another Jabber Library?

There are a number of existing Jabber libraries for Ruby (jabber4r, xmpp4r, and Net::XMPP), so why Jabber::Simple? First off, Jabber::Simple does not aim to replicate any core XMPP protocol functionality present in these libraries — in fact, Jabber::Simple depends on xmpp4r and the Jabber::Simple#client and Jabber::Simple#roster methods expose all of xmpp4r's awesome functionality. When I started building in Jabber support for Twitter I'd used various Jabber clients, and even set up a simple Jabber server. Writing my own client, however, was a bit more complex. It turns out that the seamless experience of "adding a friend" and chatting with them is (unsurprisingly) comprised of a series of disjoint steps, and fraught with the peril of threads, XML streams, and arcane magic. The available libraries handle these tasks and many more admirably, but lack in elegance. My hope is that Jabber::Simple provides a sufficiently obvious interface with which to develop tools that use the Jabber protocol.

But Wait! There's More!

Now, you might shy away from writing that really cool chat-bot you've been meaning to write, saying "Wow, this is great, but setting up a Jabber server is a pain." --- but fear not! Go over to Google Talk and sign up for an account. Once you're done, use your Google Talk username and password, and start Jabbering. No really, it's that simple.

jabber = Jabber::Simple.new("you@gmail.com", "password")

Labels: code, jabber, ruby, xmpp