| |||||||||||||
GUADEC: Danny O'Brien on privacy, encryption, and the desktopGUADEC: Danny O'Brien on privacy, encryption, and the desktopPosted Aug 5, 2010 19:12 UTC (Thu) by BenHutchings (subscriber, #37955)In reply to: GUADEC: Danny O'Brien on privacy, encryption, and the desktop by gmaxwell Parent article: GUADEC: Danny O'Brien on privacy, encryption, and the desktop
Mocking people that ask for it as paranoids... Check the date on that entry. I really don't think it was intended as mocking anyone.
(Log in to post comments)
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 5, 2010 19:43 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
In the context of the long standing argument a lot of people perceived it that way.
I probably should have mentioned that this dispute regarding OTR in Telepathy vs the decision to promote certificate based XMPP-only security had been going on for a year prior to that "joke" post across several mailing lists and bug trackers.
To see the dramaz for yourself, google around or start at http://bugs.freedesktop.org/show_bug.cgi?id=16891
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 6, 2010 0:49 UTC (Fri) by pabs (subscriber, #43278) [Link]
Thankfully they finally relented and are no longer opposed to adding it.
GUADEC: Danny O'Brien on privacy, encryption, and the desktop Posted Aug 19, 2010 10:18 UTC (Thu) by robot101 (subscriber, #3479) [Link]
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)
|
|||||||||||||