Dave Cridland Application 2018

Hello

My name is Dave Cridland, sometimes "dwd", and very very occasionally David. I work for Surevine Ltd, I'm also on the Board of the Ignite Realtime Foundation, and I'm nominally Project Lead for Openfire, although in practise Daryl and Guus do all the hard work. Finally, I'm currently serving as XMPP Council Chair.

I may be contacted on dave@cridland.net or dwd@dave.cridland.net, and I also lurk in a number of chatrooms as dwd.

With the XEP-0345 stuff covered, here's a short essay on Agency, and one on Threat Models.

Agency

It's nice to take the train, sometimes. I can read a book, watch a film, or simply sleep. There's a small matter of the price of the ticket, of course, but that's usually covered by my employer. So you'd think that I would always travel by train, even if the same journey by car might be a little faster sometimes.

But no, normally I use my car to travel. I'm frequently whizzing up and down the M4, particularly the portion that runs along the south coast of Wales. I can't read a book (though audiobooks are great), certainly can't watch a film, and my occasional experiments with sleep are fairly terrifying.

The difference is that when I'm driving, I'm in control. I could, if I wanted, choose to drop off the M4, and travel through the Brecon Beacons instead (I sometimes even have). I can choose when to leave. I can choose when to arrive.

Sometimes, the train is more convenient, though - usually when I travel to London, I use the train, for instance. And I love to kick back and bury myself in a book, or catch up on my backlog of films, or whatever. But as much as I love the journey once I'm on it, I hate rushing to the train, and then waiting for it. You can call it impatience if you like. I call it lack of agency.

I play games on Windows. I do work on Linux.

I idly post rubbish on Twitter. I do serious discussion mostly on XMPP.

I generally prefer Open Source, but the vast - vast - majority of software projects I use I've never even looked at the source code. I looked at the Linux kernel code once. I've mostly stopped having nightmares. That stuff is way beyond me.

I generally prefer Open Standards, but my focus on active participation is extremely narrow. I'm dimly aware about SYN and ACK flags, and even that you can use them both together. But it's all a dim haze.

It's not that I want to use XMPP because I do work on the standards, or the clients, or the servers. It's that I could. I have, as the kids say these days, agency.

I'm always conscious, when using Twitter, that as much fun as it is, I do not have a horse in that game, and never could. I cannot write a Twitter. I cannot host my own Twitter. It doesn't put me off using it totally, of course - but it leaves me feeling unsatisfied.

In my work within the XMPP Standards Foundation, on the other hand, I do satisfy my need for agency. I might not be the expert in audio/video chat I perhaps should be - but I'm confident that all the information I'd need to become one is out there. I haven't ever written a (proper) client - but I could do so, if the need (or simply curiosity) arose. And if I didn't want to put in the effort yet still wanted the result, I could convince someone else - and if they said no, find someone else again.

XMPP, and Open Standards, and Open Source, is for me about keeping options open, about flexibility, and above all about agency.

The XMPP Threat Model Agency

While we have, in principle, a number of Threat Models on our books, for some reason the flash bulbs really go off for The State Actor. When she steps out on the catwalk, all eyes are on her, and nobody really pays much attention to The Rogue Access Point, or The Compromised Server, for example. Poor Insider Threat is almost ignored, and sulks in the corner wondering why.

I worry about this, because if one assumes the only Threat Model worth considering is The State Actor, then we have a tendency to focus too narrowly on a single problem. We can, of course, protect against The State Actor with some effort, but it has two key effects:

1. We compromise on usability rather than security. As a for-example, we have a tendency to prioritise Perfect Forward Secrecy over Archive Access. This isn't just a convenience for users, either - having a strong audit trail is important for other security issues, like the Insider Threat mentioned before.
2. We compromise security by enforcing an incompatible model. You cannot, to state the obvious, talk to the State if the entire focus of your security is in preventing the State seeing your messages. (The reason why is that the State might have strict audit and escrow requirements).

This is all made more awkward because we have countless XEPs on end-to-end encryption, but literally not one of them mentions a Threat Model. We are, it seems, to take it on faith that PFS is unequivocally good. The State is unequivocally evil.

But the reality is contradictory, and fluid. We need to ensure that end-users can talk both to, and about, the State, and in both cases have some clear assurances about how they are protected - and just as important, how they are not.

A product or service can (and perhaps should) stick to a single Threat Model. We do not have that luxury, and in restricting our Threat Models are restricting our own utility.