GUADEC: Danny O'Brien on privacy, encryption, and the desktop

We were never opposed to adding support for end to end encryption, and we completely understand the reasons for wanting it. We were just reluctant to embrace a technology like OTR which was not integrated into the protocol but instead dropped on top of only the messaging part. With an XMPP connection in Telepathy we build many different forms of communication - including presence, geolocation, voice and video calls, file transfers, collaborative applications - and with OTR all of these would go unencrypted, and only the messages are protected. Given our involvement in the XMPP standards process, we preferred to support an end-to-end encryption mechanism which was implemented in the protocol itself and would handle all of these use cases.

(And, let's be clear: The exact details of the XMPP encryption are fairly irrelevant to this discussion - although "certificate based" - this is just a technical convenience to allow us to use existing TLS libraries. A certificate is just a key in a certain format - it does not impose any requirement on how those certificates are signed or verified. So they don't need CAs or governments to sign them or whatever, you can still do SSH / OTR style "leap-of-faith" and manually verification of fingerprints/identities if you wish, which is how we always planned to present it in the UI.)

However, we had a discussion with some EFF members who explained to us the problem with our approach, which is nothing to do with any technical details or any type of encryption being "more bettar" than another - it's simply that by not supporting the use of OTR in Telepathy, we were reducing the existing privacy of the currently deployed OTR users in the cases they were talking to Telepathy users. This reasoning was explained to us clearly and in a level-headed manner, and we were inclined to agree.

We therefore adjusted our plans to allow both the XMPP and OTR style encryption to be presented through a similar Telepathy API (and also therefore, a similar UI in the client application, presenting a hopefully better-integrated and smoother experience for the user whichever technology is in use). We currently do not have many spare resources to work on an OTR implementation of this API, although we would be very happy to support somebody who was interested in working on it, and would be happy to add support in the Empathy UI if this API was implemented.

(speaking as a co-founder of the Telepathy project, although I contribute in more of a hand-wavy direction-setting way now :D)