Telegram Bot Platform(telegram.org) |
Telegram Bot Platform(telegram.org) |
I think Telegram is succeeding in what TextSecure is failing: attracting a widespread community of developers. This is only a confirmation, in my opinion.
EDIT: and, by the way, while Telegram security is no good, I wonder why we cannot have both (security & developer-friendliness)
We have a few bots in production that use libtextsecure and have been running fine for almost a year without any maintenance.
I was a bit at loss about where to begin, as I couldn't find documentation about getting the extension setup for dev/testing. Specifically I couldn't get past the QR-code auth screen as I seemed to be missing some special configuration to connect with the servers.
I just assumed it wasn't really ready for outside devs yet.
But I just checked back in on the repo and it looks like a new CONTRIBUTING doc has been added, which is great: https://github.com/WhisperSystems/TextSecure-Browser/blob/ma... This is the type of stuff I was looking for.
I'm happy to see WhisperSystems making contributing more accessible. I probably could have learned this stuff by asking the devs, but I didn't want to bother them, I much prefer reading docs and playing with it myself first.
My language of choice for the bot was Clojure. I was interfacing with libaxolotl-java and basically rebuilding libtextsecure in Clojure (that was months ago).
Yesterday, when I discovered libtextsecure-java (while exploring Github repositories, by the way, I didn't notice your website had been updated in the meantime), I started a rewrite, using README as my primary source of documentation (the only piece of doc I could find, actually).
Ok, so what's this `KeyHelper`? Ok, I'll search on Github. Fine, it's actually `org.whispersystems.libaxolotl.util.KeyHelper` - luckily I knew it was in a completely different project. The same goes for `AxolotlStore`, which is actually `org.whispersystems.libaxolotl.state.AxolotlStore`, and it's not even mentioned on libaxolotl-java README because the latter is outdated.
Then: what is `TrustStore`? Good luck finding out that! Basically it is a wrapper around a binary file - which I had to download from TextSecure source repo without knowing what there was inside, and which by the way is encrypted with the password whisper (documentation: nowhere - thank you @AsamK for your textsecure-cli sources on github).
Ok, and finally figuring out - turning to TextSecure-Server docs - what is a signaling key, what are the specifics for the client-generated password (which by the way is sent over SSL via Basic authentication - probably not the most secure method ever, but probably there are many reason for that) and what is an install ID, I finally had the opportunity to debug obscure security problems on Java and to meet in person a Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1167153). Not to mention the fact that apparently libtextsecure-java doesn't work over websockets but only over GCM (https://github.com/WhisperSystems/libtextsecure-java/pull/5) - however I won't be surprised if it did.
A really nightmarish experience. Maybe this summer I'll try to reimplement libtextsecure in another language and then document thoroughly my efforts. Who knows.
Also, does this library work on other systems besides android? I've noticed `android` appearing multiple places and google specific api (`GoogleCloudMessaging`).
I don't have any Google Services installed.
So I tried finding it on F-Droid, but it wasn't there. I found out there has been a lot of discussion about this. [0][1]
I decided to compile it on my own. That requires to use use Google Libraries, oh well. I managed to get that done and was disappointed when I tried to use it. It also requires to have Google Services installed on your phone for push notifications. I don't have that.
I tried finding a solution, and other people complained about this and there was the idea to use websockets instead of google push notifications [3]. Someone forked TextSecure and started working on it [4].
Unfortunately that fork isn't stable yet, and it doesn't communicate with 'producion' users of TextSecure [5].
This is where I gave up. It shouldn't be so hard to install a free app on a free system.
Also, the websocket fork is somewhat dead [6].
0: https://f-droid.org/posts/security-notice-textsecure/
1: https://github.com/WhisperSystems/TextSecure/issues/127
3: https://github.com/WhisperSystems/TextSecure/issues/1000
4: https://github.com/JavaJens/TextSecure
Anyway, google play apparently tried to auto-update and bricked itself; now it just says "no connection" when I launch the play store.
Last week I tried to install TestSecure but it would not run. It just gave an error message about needing to update play services.
I ended up installing the Telegram app in F-Droid.
Telegram's message format uses ambiguous padding, so they have to try all padding lengths when validating a message: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
That loop leaks timing information, as does the "Utilities.arraysEquals" method it uses. I'm not sure if it opens up a timing attack, but it's suspect: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
There is another spot where they pad with zero bytes without any authentication. This may leave room to mess with the protocol: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
There are also some weird things throughout the code, like using SecureRandom.nextDouble() all over: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...
Now it's deprecated and I'm really sad about that.
telegram-bot and tg are great projects. Rest assured, many people (including myself) appreciate all your hard work.
Awesome, great, APIs are good.
Know what's better? Open specifications and federated services. It's called XMPP and if it's not enough, then something better should be developed.
Is this the replacement of SMS? Not sure what people would have thought at the time if they could not send SMS to other mobile carriers. It saddens me even more to see public institutions moving their SMS infrastructure to the new 'carriers'.
Protocols are not a new thing. Let's not go back to the time were computers could not talk to each other.
Probably because features are more important than security, sigh.
Scanning a QR code or creating a secure connection between the clients to exchange the keys isn't that hard.
Open for usage I guess. It's a pity that the API (and server) source is still closed. The Bot Platform is a cool initiative anyways, so good luck!
https://github.com/DrKLO/Telegram/tree/master/TMessagesProj/...
They would like to have you believe otherwise through their PR efforts, but I wouldn't trust them simply on the fact that they claim they are open source when they are not, and it's not clear what's going on in that binary lib. If they never claimed to be open source in the first place, it would be a different story.
Whatsapp should take the hint and open up their platform for developers... Curiously I was thinking about building bot-based services on their platform (largest user base in my country), but basically gave up after seing how closed they are to any initiative like this. Felt even worse after reading things like this: https://twitter.com/gcmartinelli/status/605776036358291456
More interestingly, the WhatsApp text box then effectively becomes a REPL shell to a remote API : you could ask for stopping updates, updates only once a day, etc; If the remote server implements a DSL, you could do a LOT.
The possibilities were endless and exciting.
But I have a feeling WhatsApp / their new owner are going to just let the opportunity pass by. If anyone at FB is reading this : guys, Business integration with WhatsApp is where the next $250 billion is. That's how FB will get a permanent, maybe even irreversible, grip on mobile. Imagine every service business providing updates via WhatsApp by integrating with their backend.
I downloaded and installed the desktop version. Created an account with my phone number (okay: if I ever lose my phone, I'll permanently lose access to my account!).
I see how to add contacts. I need their phone number. I don't know my friend's numbers. We use facebook, xmpp, email, lots of shit, but nobody still relies on SMS nowadays, and my phonebook is literally under 10 entries long (and I'm sure mum and dad won't be using Telegram).
This reliance on old networks really kills it for me. IMHO, linking an account to a device that can get stolen or lost is also something I'll never really understand.
Seems MTProto is the same as its always been
https://news.ycombinator.com/item?id=6931457
http://www.cryptofails.com/post/70546720222/telegrams-crypta...
Telegram is slightly better in that it at least has a client API, but you're still locked to a single provider (the official Telegram server).
I guess it's not that simple when you're alone, but getting people to switch with a few people is fairly simple.
In our company, we recently switched from Jabber to Telegram.
Telegram is easier to use on multiple devices (it synchronized automatically and you don't have to worry that if you leave one device open, you won't get the message elsewhere), has both a usable mobile app and a usable web/desktop app, it has the "private" chat that's much easier to use than OTR (Pidgin, Gadjim and Adium each implement OTR differntly and it never works right cross-client), and, as one co-worker noted, it finally looks like something from 21st century.
TextSecure/Signal/what's the name now has - in addition to confusing branding cross-OS - strange SMS reliance and no working desktop app. I would prefer it to Telegram though, if they had some reliable destop application, but they don't.
Of course companies should use whatever is most cost effective to run their private communications. But when running a public communication channel restricting to a centralized service should not be an option.
XMPP supports this, but regrettably, almost no clients implement these features. It's a huge shame that so many dev create brand new protocols+clients instead of implementing these features for existing XMPP clients. But I do admit that as-is, users can't pick up any existing XMPP client that supports this. :(
> OTR (Pidgin, Gadjim and Adium each implement OTR differently
I've been using this daily for a few years now. I've always used pidgin, while almost none of my peers have. OTR is also standard, so I'm really not sure what you're talking about.
Multiple devices should be a non-issue today, really. Usable web and desktop apps is quite subjective, I think? I do admit that the Telegram desktop app looks slick.
The OTR problems seem weird, because as far as I'm aware Pidgin and Adium share the very same implementation for example?
It sounds like you were mostly unlucky to me. On the other hand: Maybe that's already another blow against XMPP, if it doesn't "just work".
I would love to get your coworkers feedback on something like this [1] - because 'looks like something from the 21st century' is not something I get immediately.
1: https://play.google.com/store/apps/details?id=eu.siacs.conve...
Also federated services have their disadvantages, so I wouldn't necessarily say that's better.
Compared to the benefit of not restricting one-self to a platform, I would say federated is better.
Matrix project is an interesting effort to replace XMPP: http://matrix.org/
I guess then it's all a matter of waiting for it to happen.
Then you would have loved Japan before 2006. SMS was not a "thing" (although available hidden in the interface) and the phones would default to email.
What surprises me is how lazy and clueless mobile network operators seem to be despite the power they still hold. They have all the power they need to develop or implement modern messaging protocols. Granted they can't charge for it. Still seems a better option than pushing SMS, MMS and letting new players enter their yard.
I am all up for letting mobile network operators just provide internet services. Surely the trend seems to be to flush everything down the Internet tubes and if that's the future, we need something better than a couple of companies that do not respect free choice.
Looking at the source the libraries contain AES code, libjpeg, libwebp and libyuv to handle image decoding, some image blur algorithms and video NV21-YUV conversion routines.
Nothing out of the ordinary for an Android app - offloading CPU intensive stuff to C/C++ where it's almost always noticably slower.
Can you please, PLEASE, check your facts before jumping the gun next time?
Here's Telegram FAQ [0]
Q: Why not open source everything?
All code will be released eventually. We started with the
most useful parts — a well-documented API that allows developers to build new Telegram apps, and open source clients that can be verified by security specialists.
Edit: Also, the maintainer of the Android app is making all his changes locally and then submits all of them in one giant commit. There are pull requests, but he just includes these in his giant commits.
People do have complained about this [1][2], but he obviously doesn't (want to) understand git.
0: https://github.com/slp/Telegram-FOSS/issues
What's in this thing? This isn't just some build optimization thing they're doing? Nobody's picked it apart yet?
And they do, at least here in europe: https://gigaom.com/2014/02/20/oranges-libon-messaging-app-le...
But the moment we tried Telegram, we just didn't want to move back.
I think I misread this as saying there was a paid-for version available for install, but I have no idea how I got that, since it's clear that it's the SMS charge he doesn't want to pay for.
I'll bite. If i would be a non-techie the things i would notice are:
* What's Jabber / XMPP? I don't know what that is. Why should it be in the title?
* All the screenshots (there are many!) basically look the same. I don't understand the conversations in the screenshots.
* It's not free.
* The first line "Conversations is an open source Jabber/XMPP client for Android 4.0+ smart phones.". What's open source? What's Jabber/XMPP? What's a 'client'? The only words i understand in this sentence are 'Android' and 'smart phone'.
* "Design principles" is not something i care about. Simply tell me what this product does.
* Clicking on 'Read more' gives me a text that is so technical i don't understand a single word of it ("XEP-0065: SOCKS5 Bytestreams - or rather mod_proxy65"?)
Again, comparing to Telegram [1] (see disclaimer in my previous post: I use that as well):
* Jabber/XMPP is a weird point. You wouldn't need Conversations if you wouldn't have a server to use. You pick up Conversations because a) some friend tells you to install it and connect it to their server or b) you have a server of your own. If you don't know what XMPP is, then yes - this client is not for you.
* Really? Can you look at the Telegram screenshots? Let me bite this time:
Hey Lucy, got a second?
As in the duration of 551557906200 periods of the radiation corresponding between the two superfine levels of the ground state of the caesium 133 atoms? Yes, I might.
We need some data extracted from a secret chat…
* It's free. [2, GPL] I know, Joe User isn't going to build it, but again: You need a server for this to work. If you care about that, I'd say you have ways to save the 2.38 EUR if necessary.
The rest of your points are certainly valid (marketing for XMPP sucks), but again entirely different problems. I highly doubt that most people read the description of the Telegram or WhatsApp apps. Friends recommend it, people install it, use it, done. XMPP is a different case, because it requires a friendly server (and the post installation configuration step where you select one), but that's not quite relevant for the 'looks like something from the 21st century' discussion, is it?
I was trying to make the point that there are ~new~ and current clients for XMPP as well, even if Pidgin looks like shit.
1: https://play.google.com/store/apps/details?id=org.telegram.m...
Taking my paranoid glasses off, I'd guess they're checked in so contributors don't have to deal with setting up NDK to compile the app.
You're trading convenience for increased security.