Latest revision as of 13:19, 23 September 2013

Add OTR support to KDE-Telepathy

Summary

On our roadmap. Will happen when it happens.

If you want to help code it, we will be happy to get you started.

What is OTR

OTR is short for "off the record" and is an encryption scheme that sits _on top_ of all messaging layers providing point-to-point encryption/auth. It is not an official part of any communication protocol but a layer on top written by some cryptographers.

Wikipedia, as always, says it best: Off-the-Record_Messaging

History

When we started KTp OTR was being considered for implementation at the Telepathy level, up from us. As such we were waiting on it to be implemented in the library we used, and we would add the UI on top. There was a GSOC project on this, but this was never merged into Telepathy (https://gitorious.org/jprvita-repos/telepathy-gabble/commits/otr), and as such we have nothing to build upon. We could implement it ourselves, on top of the Telepathy layer. This is a slightly less "clean" solution, but the most realistic.

Personal Thoughts

Encrypting messages is at the wrong level, encrypting the entire stream (i.e XEP-0188 which is lower in the stack) is so much simpler, provides greater security and is "right".

libOTR isn't an ideal solution.

Conclusion

If someone wants to implement it in KTp we will be happy to help. We have a message filtering plugin which could be adapted to work with this, and the plugin from Kopete could be ported with medium changes. We will happily adapt our plugin system to try and support it and anyone stepping up to the coding challenge.

It's something that's now on our roadmap, and we've got some precursor refactoring underway at the moment. Then it will be mostly a copy and paste job from Kopete.

Angry comments on blog posts/mailing lists/social networks will not make it happen faster. Please do not do that.

Misc

GTalk also has an implementation of something called "OTR" which is Off the Record which turns off server logging, This is completely different and is a documented XMPP extension. This is something I would like to add.

@@ Line 4: / Line 4: @@
 ===Summary===
-No. Unless you want to code it, in which case we will be happy to help.
+On our roadmap. Will happen when it happens.
+If you want to help code it, we will be happy to get you started.
 ===What is OTR===
@@ Line 16: / Line 18: @@
 When we started KTp OTR was being considered for implementation at the Telepathy level, up from us. As such we were waiting on it to be implemented in the library we used, and we would add the UI on top. There was a GSOC project on this, but this was never merged into Telepathy (https://gitorious.org/jprvita-repos/telepathy-gabble/commits/otr), and as such we have nothing to build upon. We could implement it ourselves, on top of the Telepathy layer. This is a slightly less "clean" solution, but the most realistic.
-===Do I need OTR to be safe?===
-Not really. OTR was designed in yesteryears when IM networks were over unsecure connections, nowadays almost all of them Facebook, GTalk most other services are all over an SSL layer. This means you have security from you to the server and there's no interception between you and the server. In the case of GTalk you can't be sure Google isn't listening, but random hackers on the same network can't.
 ===Personal Thoughts===
@@ Line 25: / Line 23: @@
 Encrypting messages is at the wrong level, encrypting the entire stream (i.e XEP-0188 which is lower in the stack) is so much simpler, provides greater security and is "right".
-OTR is only for geek users and the paranoid, and no-one discusses anything that secret over IM! It doesn't have a large userbase, just a vocal one.
+libOTR isn't an ideal solution.
 ===Conclusion===
@@ Line 31: / Line 29: @@
 If someone wants to implement it in KTp we will be happy to help. We have a message filtering plugin which could be adapted to work with this, and the plugin from Kopete could be ported with medium changes. We will happily adapt our plugin system to try and support it and anyone stepping up to the coding challenge.
-However, it's not something I consider a worthwhile use of my team's time, and angry comments on blog posts/mailing lists/social networks will not change that.
+It's something that's now on our roadmap, and we've got some precursor refactoring underway at the moment. Then it will be mostly a copy and paste job from Kopete.
+Angry comments on blog posts/mailing lists/social networks will not make it happen faster. Please do not do that.
 ===Misc===
 GTalk also has an implementation of something called "OTR" which is Off the Record which turns off server logging, This is completely different and is a documented XMPP extension. This is something I would like to add.