…and if only Google can read your IMs…

Like every sane person I know, I’m tremendously excited about Google Talk. I haven’t tried their client (and I don’t really intend to), and that’s the biggest reason I’m excited about it: I don’t have to try their client to use it. And they require TLS, thank goodness. The upshot is that you can use any client and assume that your boss/co-worker/BOFH isn’t reading your IMs. Google has reserved that right for themselves, but they’ve set the expectation of privacy with everyone else. More on that in a minute.

There’s a lot of good in Google Talk. The smart folks in Mt. View picked an open protocol, for starters. They would have had to do a ground-up (re)write on the server software for whatever protocol they choose (or developed), so an open protocol was likely neither easier nor faster to deploy. Regardless, the choice of XMPP might simply have been a cost/benefit calculation, but it’s the kind of calculation that every other giant that has entered the IM market totally screwed up in their meetings-before-meetings: closed protocols are the first thing that a smart competitor can (and should!) commoditize out from underneath an entrenched rival. Why google has so-far missed this on the social-network front is vexing, but it’s nice to see some sane competitive thought on IM. Users are going to win as a result. Google just set the value of closed IM protocols for their rivals at zero for anyone with a GMail account. And that’s a lot of people.

But here’s where I get less generous: Google has set themselves up in a singular position of power over their user’s privacy. Your messages over Google’s IM servers are encrypted up to the point where they hit their machines, decrypted, shunted around Google’s messaging infrastructure, and then re-encyrpted when they are sent down the wire to your ex-roomate who’s living in Belize. So the only person who can snoop on your messages is Google. Or whatever governments or institutions can coerce or force Google to monitor, censor, or block your conversations.

Calculated or not (my money’s on “not”), there’s now a point of failure in the “don’t be evil” plan; at least when it comes to IM. But let me be explicit: Google’s insistence on TLS by the client is a HUGE step forward for IM privacy. Using Google’s IM networks, you can now expect that no one but you, the other person, and Google can read what you write. The only problem is that this expectation can be broken in some pretty non-obvious and non-evident ways.

So how can it get fixed?

By baking something like OTR into the client. Since it can be easily layered on top of any IM protocol and because it provides forward secrecy and plausible deniability, it allows users an evident and workable way of knowing when something is amiss. Just letting users see that they can expect a level of privacy instead of implicitly promising and then silently eroding it will provide a built-in hedge. By deploying it in the default client, there’s an implicit expectation that people that want to inter-operate with their client will support it, and by making the choice to turn it off for a user that can’t support it explicit, it gives users a way to know what the game really looks like.

By choosing XMPP for IM transport, Google has lost it’s fabled claim to technology agnosticism. It is setting the rules, and it’s a great chance to prove that it intends not be evil; now or in the future. I for one hope it’s a chance that’s not wasted and that if it is, a competitor (Yahoo? anyone? Beuler?) figures it out and treats privacy as an explicit, visible feature.

Crypto isn’t the answer, but setting expectations and getting users used to being in control certainly is a first step to toward an answer that’s longer lasting.


  1. Posted September 13, 2005 at 1:15 am | Permalink

    You should have done your homework on OTR and end-to-end encryption over XMPP a bit more. :-)

    Here’s what’s on the XMPP/Jabber menu:
    RFC 3923: http://www.xmpp.org/specs/rfc3923.html
    PGP: http://www.jabber.org/jeps/jep-0027.html
    Encrypted Sessions: http://www.jabber.org/jeps/jep-0116.html

    It’s currently a sloppy mess. Pretty much only PGP is deployed and supported by clients at the moment. The use of S/MIME in the above RFC is ugly, and everyone on the standards-jig mailing list has gotten distracted with spim.

    Perhaps by time I get to the point where I have to have it, things will be settled.

  2. Posted September 13, 2005 at 9:17 am | Permalink

    Hey Nolan,

    So I actually tried to get a handle on XMPP privacy before I wrote this post, and most of what I turned up was related to PGP or cert-based schemes. The parts of XMPP that have seen IETF work only seem to talk about them, anyway. As much as I love (and use!) pgp/gpg, I don’t consider it even the beginning of a viable approach, and cert-based schemes are a complete non-starter, which is why I wrote this post. Plausible deniability and forward secrecy are massively important and PGP/cert based schemes aren’t likely to provide either without essentially re-inventing OTR.

    I was unaware of JEP-0116, which appears to provide everything I want out of Google Talk, but it’s marked “experimental” and it’ll be some time after software is deployed based on it that i’ll feel confident basing my privacy on it. Which leaves us back at square one: Google has the ability to *set expectations*, and today, there’s running code in OTR that (with a required protocol change) can provide most of what I’d like to see.

    I guess at the end of the day I see a lot of room for pragmatism on this: whether or not it’s done within the context of XMPP or layered on top, I don’t so much care. I just care that whatever wins is done in a widespread, by-default kind of way so that users come to expect it.

    If users are the “weak link” in these systems, then *they* need to be turned into the enforcement mechanism for their own privacy. Either OTR or JEP-0116 seem to be promising in that direction, with the right UI attached (I can’t stress that enough).


  3. Posted September 16, 2005 at 10:09 pm | Permalink

    Yes! I get so frustrated when people propose exactly the wrong solutions to IM security. I think OTR is a bit too complicated for people to understand — but what seems even more hard for them to understand is that IM is a unique security situation and needs a special solution (like OTR).