Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

...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.

Safari 2.0.1

After much discussion recently with Erik, we decided that Safari was a lost cause when it came to coercing XML documents out of serialized strings. Fortunately, Safari 2.0.1 seems to now include both the DOMParser and XMLSerializer classes that Mozilla implements. Looks like some of the last chinks in Safari's Ajax armor are finally fixed.

Dojo 0.1 is out!

Dojo 0.1 is now available.

An amazing team put this thing together, and shows. While we've got a long way to go toward one-dot-oh, this first release of Dojo is something everyone involved with its creation can be proud of. So go download it, check out the post-download help page and API outlines, and let us help you build something amazing.

It may not be perfect yet, but we're on the case. Until then, enjoy the best darned Open Source JavaScript toolkit around. We think you'll like it.

new box

This blog has been moved to new hardware in a new NOC which should be significantly faster all around. If you experience any problems reaching this blog in the coming days, please send me mail.


I love my Mac. I really can't imagine going back to windows or even Linux for my desktop at this point. But I've got a beef w/ the speed of this sleek little box that I spend the majority of my waking hours in front of. It's kind of a dog.

I recently put another gig of ram into it, which has kept it from the infernal swapping, but for straight-up development work, it's just not enough any more. I'd drop the cash on a new laptop today if Apple was selling something half-again as fast, but they aren't. The clock speed increases aren't fooling anyone. I need something that feels as fast as the thinkpads my friends are starting to tote around in lieu of their PowerBooks.

So c'mon Apple. Get it together so I can spend money with you again.

Older Posts

Newer Posts