I’m willing to accept that XMPP ESessions are dead; as far as I can tell there’s no interest in other implementations, and some form of client-to-client TLS is looking promising (though I’m a bit worried about requiring Jingle).

Implementing ESessions hasn’t been a total loss, though. I think we’ve built a good casual crypto UI model for Gajim, and I would like to see something similar to it in other clients.

Here’s an overview. Please ignore the specific text used in the screenshots, I know it sucks. Suggestions would be appreciated.

UI Flow

If the other client supports end-to-end encryption, an encrypted session is negotiated in the background as soon as you start typing.

The shield icon is from Tango. It’s not a great metaphor, but I think that it’s better than a padlock. The question mark is our own addition. We use a different icon when the contact has been authenticated.

When you click the shield icon, you get this dialog. The idea is to provide the basic information about the session; something like Firefox’s Page Info Security dialog. If we were using public keys for authentication, that info would appear here.

When you click “Verify” on the session info dialog, you get this dialog. Clicking “Yes” marks the session (and all future sessions using the same shared retained secret) as authenticated. Clicking “No” just closes the dialog.

I think the core idea is to encrypt by default without requiring the user’s intervention (even for authentication), but to make it clear what that means and make it easy to authenticate at any time.

(inspired by the big thread about XMPP end-to-end security over at security@xmpp.org)

Authentication sucks. Without it, crypto is automatic and decentralized, but insecure; doing it introduces a dependency on human intervention or a trusted third party.

I don’t like trusting “authoritative” third parties, so I’m most interested in making the human intervention required as simple as possible.

Aiming for an authentication system that Aunt Tillie will use is unrealistic; there’s no reason for her to care.

But we should aim higher than Uncle Peter, who always checks SSH fingerprints and is willing to do whatever he needs to when privacy is important.

A better target is Cousin Dave, who works in IT or took a CompSci course at business school. He doesn’t know the difference between Diffie-Hellman and Blum Blum Shub, but he’s aware of crypto, he’s competent, and he’s willing to expend minimal_amount_of_effort for privacy.

This is not to say that Uncle Peter’s use cases should be neglected, just that a system doesn’t need to be 100% usable by everybody to be better than what we’ve got.

Support for short authentication strings lowers the barrier to entry nicely, without making any significant compromises.

atom-tools’ bin directory has several UNIXy tools that I’ve never really mentioned before.

These tools operate on “collections”. I’m using the term in a broader sense than RFC 5023; a “collection” can be an AtomPub Collection, a directory containing Atom Entries, or a feed on stdin or stdout.

atom-cp

atom-cp copies the contents of a source collection to a destination collection.

atom-grep

atom-grep prints a feed to stdout containing all the entries in the source feed that match a given regexp.

atom-purge

atom-purge DELETEs every entry in the given collection.

atom-post

atom-post POSTs the contents of a file or stdin to a given URL.

It doesn’t do anything fancy, it’s just a convenient way of getting media or an Entry created by some other tool onto the web. Eventually this will construct Entries too, but not yet.

Use Cases

Back up your blog:

atom-cp http://example.org/coll ./backup/

Restore a backup, or post several pre-created entries:

atom-cp ./backup/ http://example.org/coll

Delete spam:

atom-grep poker http://example.org/comments | atom-purge -

Plagiarise somebody else’s blog:

atom-grep "popular content" http://example.org/coll | atom-cp - http://example.com/seo

Post a picture to your media collection:

atom-post -m image/png http://example.org/media icon.png

(Disclaimer: XML is a terrible format to pass down a pipe. It’s awfully convenient though, and my pipes and my collections haven’t been long enough for it to be a problem.)

This is the blog of Brendan Taylor. I try to stick to things of a technical nature here.

This exists as a record for myself. Anything you get out of it is a bonus.

It runs on custom software that I would be happy to share.

A word to describe the warmest part of the year is useful to everyone who ever goes outside.

A word to describe the period of time between a solstice and an equinox is only useful to astronomers, calendographers and people desperate for small talk.

Happy first day of summersolstice.

Google just released some statistics for GSoC 2008, which reminded me of something I’d noticed in last year’s Student/Mentor map:

• lots of people in and around Vancouver
• a couple of people scattered throughout BC
• two people in Calgary
• two people in Edmonton

And then a huge gap until Toronto.

Western Canada isn’t exactly a centre of exciting software activity. :(

Ruby now has 3 Atom Publishing Protocol libraries: atom-tools, atomutil and ratom. They all use the Atom namespace, and they’re all incompatible. Not a great situation.

ratom uses libxml-ruby rather than REXML. It’s embarassingly faster than atom-tools. ratom can parse the 1100 Atom Entries in my Venus cache in 0.25s; atom-tools takes 6s.

I haven’t been able to get atomutil to work. I expect it is faster than atom-tools, too (though not nearly so dramatically); atom-tools parses an XML tree into a tree of Ruby objects (instead of just wrapping the XML tree). This may have been a mistake.

Published atom-tools 2.0 a few days ago.

The XML parsing and building has been completely reworked. This should make handling extensions much easier.

A big feature for people writing clients is HTTP caching support (ported from Joe Gregorio’s httplib2). I actually commited this to the darcs repository the same day I published 1.0 but never released a 1.1 version (oops!).

It’s got some new UNIX-y tools that I’ll write about later.

I’ve gotten rid of the YAML mapping entirely; it wasn’t as human-read/writeable as I had hoped. I think there’s promise in doing something with Maruku for that.

I’m slowly moving from Test::Unit to rspec (thanks to a lot of grunt work by Simon Rozet). I think the result is a lot cleaner.

I’ve tried to keep things as backwards-compatible as possible, but some things have changed since the 1.0 release. The main difference is that Atom::Collection now represents an app:collection element, instead of just being a fancy Atom::Feed.