Infrequently Noted

As has been repeated ad-infinitum elsewhere, there new MS Dev Toolbar for IE has made it much easier to get to a lot of the things that were previously buried under endless tabs and dialogs. It's almost at parity with the Mozilla equivalent (which is good, since its feature set seems to be a direct rip). But there's one place where I wish MS's slaving copying hadn't succeeded so well: the clear cache option.

On Mozilla/FF, the web developer extension pops up a dialog to tell you that it actually did what you asked it to. This dialog needs to be dismissed by hand in some way (enter, click on "ok", etc.). The "sheet" that this shows up as on Mac is noticably slow to appear, needlessly drawing out the process even further. IE now does something equally useless by prompting you to confirm that the action you just explicitly requested is actually what you want to do. Gratefully its asinine "look! I did it!" dialog auto-dismissed. Small comfort when your workflow has been completely destroyed by the previous dialog.

Why are these tools putting all of this in our face? Who cares enough that it actually cleared the cache to want to "confirm" it? Just freaking clear the cache already and let me get back to doing real work.

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.

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

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.