Telegram Login for Websites | Hacker News Reader

Telegram Login for Websites

telegram.org

173 pointsjfroma138 comments

By building a phenomenal chat app and gradually (deliberately) building features around it to create a complete WeChat-like ecosystem, Telegram will probably improve people's uptake of chat-centric utilities in the markets they're targeting.

I think the fundamental component to their success is just how snappy and 'live' their chat conversations feel. Everything including their backend perf, chat bubble animations, etc seems to be finely tuned to make conversations feel alive and active.

It is super performant and stable though. I'm often surprized how easily it works through a shaky slow connection while others end up in an endless loading icon.

and then they say that Qt isn't able to do pretty animations :p

Who says? I've never heard this.

just look in other threads about qt on this website or proggit :p

I wish Keybase Chat supported mobile.

https://keybase.io/blog/keybase-chat

Keybase chat does support mobile, I use it all the time

Keybase chat works with both direct messages and team messages on mobile

Using it on iOS without issues.

Works fine on mobile. Can't say the UX is as good as Telegram though

Interesting that the official Telegram client gets mocked a lot for how bloated its code is.

And it absolutely is, from a 2 minutes look at their code :

- their chat activity is 12000 lines of code : https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

- it looks like they have copy pasted tons of Android library like exoplayer directly in their repo

It does work very well though !

I guess that they have an extremely small team (or just one persone) and it is their first Android project.

It looks like they have acqui-hired a competing chat client (Telegram X), so it looks like they have a solution to clean this mess.

That sounds like a disturbingly huge attack surface...

Woah, that's some lazy code in ChatActivity.java. Functions with 30+ conditionals depending on tons of external state. That must be a nightmare to debug and impossible to test.

I've seen some huge Android java functions where everything gets stuffed into the Fragment creation/update/etc API functions... but this is one just stuffed everything in them.

It's just asking for bugs and security issues.

Edit: the commit history all comes the same developer, each titled with a generic "Bug fixes" commit and no description of the changes. Seems like a single guy is just cowboying the whole App, it's not a team project at Telegram. Which explains the above... https://github.com/DrKLO/Telegram/commits/master/TMessagesPr...

However it feels very good to use. Cases in which something gets weirdly stuck (happens in other apps) are virtually non existent. It is fast and quite reliable. Perhaps surprisingly so.

I'd be more concerned about the developer side, particularly new developers and OSS contributors, the wide attack surface introduced by such complexity, long-term inflexibility, impossible to track down bugs, etc more than anything. I'm sure they have plenty of people to QA from the user perspective, just clearly not the code.

Maybe the developer was pressured to focus on releasing quickly over code quality...yada yada. The typical startup developer story. But not a story that I like to find in my security-focused software.

I guess the point is that you can get away with such sloppy code as long as it is a solo project of a relatively small size.

I am not sure at which point it becomes too big and new features and bugs are just impossible to handle.

It might have been the right choice for Telegram though. Their app feels snappy, so the 'only' big downside is that now it looks like they are going to have to thrown away this entire code base and replace it with the one from Telegram X (a third party client they bought)

Don’t worry, most current message apps have code that horrible.

Be it matrix simply writing a HashMap into a file as "database" replacement https://github.com/matrix-org/matrix-android-sdk/blob/master...

Or Signal simply taking apart Android system structs with JNI, to get a file descriptor’s owner https://github.com/signalapp/Signal-Android/blob/master/jni/...

There’s lots of suboptimal code in messaging apps. All of them.

Why do you need a database over a serialized object like a hashmap file if there is only one user and one device?

Because writing the entire dataset back out on every addition or removal is extremely wasteful.

The existing database implementations in the system do much less writes.

Doing such large, constant writes not only is slower, it also degrades the NAND.

Thank you

That's the reason they are working on the next-gen mobile client now, code-named Telegram X [1] [2]. In my tests it appears to be faster and lighter, I can't speak for the code though as it hasn't been released yet.

1. https://itunes.apple.com/us/app/telegram-x/id898228810?mt=8 2. https://play.google.com/store/apps/details?id=org.thunderdog...

Curious why typecast if instanceof is checked already ? Wont the compiler know of this already ?

  if (view instanceof ChatMessageCell) {
  .......                    
   ChatMessageCell cell = (ChatMessageCell) view;
  ....
  }

It's essentially just how Java works, and isn't that uncommon in statically typed procedural languages.

The `view` variable is still a reference of the parent type (Say `MessageCell` for now, can't be bothered to find that part in the code), and `MessageCell` references can only do certain things.

It's possible to check what the type of the underlying object is with `instanceof`, but that doesn't change the type of the reference.

If you want to do things that only a `ChatMessageCell` can do, you need to make a new reference of that type.

It's Java, so no.

the java compiler does not do that unfortunately,

Kotlin would do what they call a 'smartcast' : ie if you did an instanceof if the if, in the corresponding {}closure you know the type of this object.

The whole code is probably unmaintanable for anybody other than it's original writer (and even for him, there must be a limit to how much code you can fit in your head).

I would love to work for Telegram, it is one of the products I use daily .. but if I had to handle this codebase, it would be a rare case of 'total rewrite or I am out'.

Incidentally, it looks like they are going to do this full rewrite. Telegram seems to have acqui-hired the creators of Telegram X and are prepping it up as a replacement.

I believe this is called “type narrowing”, and no, Java doesn’t have this.

I don't use WhatsApp. I use Telegram almost always and am impressed with the speed of development and introduction of new features. In my limited trials with Wire and Signal, Telegram just blows them out of the water in features, reliability and speed. I know the background about its crypto being criticized, but until other apps catch up, I can't move to them. I've already spent a lot of capital to push a few people to use Telegram and haven't regretted that move from an user experience point of view.

On topic, I don't like these third party login systems much. Yes, they could provide better security compared to what smaller websites with less competent teams could, but associating a login with a provider also means I'm putting more eggs in one basket, so to speak. I also don't like the privacy implications, regardless of what Telegram states. It's sad that Mozilla Persona didn't take off and was shelved. It seemed like the best solution for this requirement.

> In my limited trials with Wire and Signal, Telegram just blows them out of the water in features, reliability and speed.

When you say features, which ones do you mean? Do you mean the user interface?

They certainly can't mean the security.

But comparing to e.g. Line or WeChat maybe the entire social & stickers & attending services thing. Signal is a pretty bare-bones chat client, and WhatsApp only slightly less so.

I personally love their bot API and the option to create custom stickers.

Although not "features", having an open API for writing clients for whatever platform I choose and the fact that their official clients are open source are also a big plus.

So you use an encrypted messenger, but your choice on encrypted messenger is influenced not by the quality of the crypto implementation but rather by the ability to add bots and custom stickers.

Why don't you just use Snapchat?

To be fair telegram is probably better than snapchat as a messenger.

In my case, these are some of them: 1.Many utility bots(including those admin bots to manage large groups if you have groups). Some examples of these bots are @gif @imdb @bing etc to instantly share gifs, movie ratings and images respectively. 2.No sharing of phone numbers with unknown people. Username handles will help to connect with anyone. Can chat with any of the members in the group (among 100000 people) without fearing lose of your number unless you chose to share. 3.Can download movies, songs, and videos from different channels and groups where they are shared. There are bots which can aggregate the search results from many channels to get them at one place. 4.I get those hackernews posts which gets more than 100 points in a channel. 5.Feed reader bots which get me feeds from my favourite websites. 6.Unlimited cloud storage. You could save movies,songs, pdfs,apps or anything you want there unless they don't exceed 1.5gb size per file. 7.Global search among the chats you have including groups, bots, channels and personal chats. 8. There are many niche groups or channels. Like programming, web development, crypto, reddit, regional, and not to mention porn too.

@daredevil_kohai has already mentioned several. What I most like about Telegram, though it does require a phone number to get started, is that it allows messaging anyone else without revealing one's phone number with the use of usernames. For me my phone number is a precious piece of information that I guard (despite the fact that I still get spam SMS and such) because it's increasingly used in many contexts as a unique person identifier for behavior profiling and surveillance (which I'm against). With Telegram, I do have to trust the platform on not leaking my number, but that's the extent of my worry.

Wire went two steps further and allows a) signing up with email addresses (without revealing phone number to Wire) and more recently b) multiple accounts for a person. Telegram has just started catching up on multiple accounts, but is still tied to a phone number.

A minor feature in Telegram that I use a lot is to edit my messages after sending them. No more re-typing messages with corrected typos prefixed with an asterisk. This either doesn't exist or came much later in other platforms I've listed in my comment (including WhatsApp).

This is anecdotal, sharing photos in Telegram means it gets through with the same resolution instead of being re-compressed and losing detail. I've heard from some others that re-compression happens on other platforms, but I don't recall on which ones right now.

Speed of message delivery, which is the most basic thing for any messaging platform. While Telegram has slowed down over time (it used to be almost instantaneous a few years ago), it still seems faster than the other platforms. This may just be my experience, since there are multiple factors that affect this.

Multi-platform and multi-device support with synced conversations across all of them. Telegram did it this way from the beginning. Wire is also similar, and better, since it has end-to-end encryption as well (but it doesn't store all conversations forever, and so newer devices will start with the most recent messages). Signal is way too behind in this department, and doesn't even allow carrying over received messages from one phone to a newer phone (this is true in iOS, and on Android it involves some work by the user). Signal actively prevents data from being backed up from the device!

Telegram's search, both within conversations and across conversations, is very fast and reliable.

Telegram allows chatting with oneself, which was renamed to Saved Messages a little while ago. I use it as a bookmarking feature to store interesting information. Combined with great search, it becomes a reference repository.

I'm sure I'm forgetting some other stuff, but the overall user experience is much better, right from application startup.

> I know the background about its crypto being criticized, but until other apps catch up, I can't move to them.

Security with fewer features is still useful; features without security are unusable.

Seriously, I can't sell this to others. Getting people to use another platform is extremely difficult due to network effects and laziness. As I said above, I spent a lot of my personal capital to move some people to Telegram and they haven't regretted it because of the features (which I also tell them about). Without richer features and without large marketing and advertising budgets, any of these will only be niche platforms.

I'm still waiting for Signal to come closer to being relevant, as per my expectations, before moving to it and pushing some others to move to it. But every time I look at a new release and compare, Telegram still seems about a year or more ahead.

But doesn't this mean you're really logging in with your phone?

It's 2018. Why are we still trusting the phone network for anything related to authentication? Surely companies like Telegram can't use the excuse that they didn't know how horribly insecure SMS and the phone network in general is, no?

I don't know how Telegram does it, but it keeps picking the wrong security options. It's like a gift they have.

I think the main motivation is making it harder to create (many) fake accounts. A phone number is probably the best trade-off between usabilty and verifiability.

Telegram can layer a password on top of your mobile number in a sort of reverse-two-factor way, but it's kind of a bad joke as I've mentioned above.

No, in Telegram the phone number is used only as a sort of username. You can login to Telegram just with a password and the 2FA token gets to you inside the appp itself. Not SMS.

If you don't have a 2FA password enabled and you're not online on another device you can login with your phone number.

A majority of banking, at least in Europe, depends on SMS as authentificiation. As well as most other 2fa services depend on it as last resort fallback.

It's 2018 but this problem is far from solved.

(there is a lengthy rant about that somewhere in my post history)

My bank in NL requires 2 factor using a handheld chip reader that you have to feed your PIN number followed by a random number from the website.

It then calculates a second number that you send back to the bank. No SMS at all!

Thanks, but we don't want another Google knowing and keeping all our data, even websites that we visit.

By that logic, you would be using only Google+ and Allo for messaging.

I think I was clear about my logic: no more monopoly!

Why would you think I'd have to use Allo and G+?

I think that because you've used "all my data", he implied that you should be using their social network and their instant messaging service, so that it would truly be "all the data".

To me the spooky part is that he only thought of two use cases in which one is guaranteed that a random person is not using Google's services (at least, not exclusively).

All of your data? At best, they know the URL of any pages where this widget is visible. Not all websites, and not even a large subset of that site's pages.

This isn't like a Facebook share widget, which is usually so ubiquitous, they really can know all the sites you visit.

That's how every now-ubiquitous thing starts. It used to be other things. Most of them are gone now. Something will take the place of the Twitter and Facebook buttons some day.

While this is very clever, I'm not a fan of the implementation. I wish there was a documented oauth2 option and not just an iframe and some script. Script seems innocuous but Im not a fan of having the iframe on my page, and its hard to control the style. Obviously we can reverse engineer this a bit but I would prefer to just have a more robust API w/ proper docs.

> Telegram Login for Websites

Or in other words: We are ready to sell your private data now. Because that's what actually happens when you login to another website via Telegram login.

That's nonsense.

First, it's you who decide to use telegram to login to a website (as you would login with Facebook / google).

Secondly, you see what informations will be shares with the website.

Lastly, there is no money involved. It's totally free to use.

> First, it's you who decide to use telegram to login to a website (as you would login with Facebook / google).

Yes, this is implicit in what the parent is saying. The point is, your data can be shared if you volunteer it by using this feature.

> Secondly, you see what informations will be shares with the website.

At a minimum, you are sharing the fact that your identity logged into the application. A profile of logins associated with your identity can be built, and a profile of how many Telegram users logged into a particular website can also be built. Both (and particularly the latter) are valuable.

> Lastly, there is no money involved. It's totally free to use.

This has nothing to do with whether or not your data is actually shared or sold with third parties.

I'm not necessarily agreeing with the parent that Telegram is going to start selling user data, but your arguments here do nothing to diminish the fact that they could do so en masse. A graph of your logins should probably be considered "private data."

Of course they could sell all your data to third parties.

But it has absolutely nothing to do with this feature as the parent comment was implying. This feature involves no selling whatsoever.

I don’t follow what you’re arguing. It seems you’re agreeing - yes, Telegram could sell the login data.

The commenter you replied to was expressing a (snarky) hypothesis that Telegram will sell login data. You initially said this was nonsense, but are now saying that they could do so. That’s basically the point.

I'm just saying that implying that this feature would mean telegram start selling user data is nonsense. This is what the first comment was implying.

Ofc telegram can sell user data like any other company, and may be doing it for months for all we know.

Here you have the basic info (not ticking additional boxes) people share with the party your're logging into via Facebook login (for privacy reasons I have reset most fields):

{ PasswordExpirationDate: null, EmailVerified: false, IsActive: true, IsDeleted: false, Uid: null, CustomFields: null, IsEmailSubscribed: false, UserName: null, NoOfLogins: 3, ID: '', Provider: 'facebook', Prefix: null, FirstName: '', MiddleName: '', LastName: '', Suffix: null, FullName: '', NickName: null, ProfileName: '', BirthDate: '3/1/1985', Gender: 'M', Website: '', Email: null, Country: null, ThumbnailImageUrl: '', ImageUrl: '', Favicon: null, ProfileUrl: '', HomeTown: null, State: null, City: 'unknown', Industry: null, About: '', TimeZone: '3', LocalLanguage: 'en-US', CoverPhoto: null, TagLine: null, Language: 'en-US', Verified: 'true', UpdatedTime: '', Positions: null, Educations: null, PhoneNumbers: null, IMAccounts: null, Addresses: null, MainAddress: null, Created: null, LocalCity: null, ProfileCity: 'unknown', LocalCountry: 'France', ProfileCountry: null, FirstLogin: false, IsProtected: false, RelationshipStatus: '', Quota: '', Quote: '', InterestedIn: null, Interests: null, Religion: '', Political: '', Sports: null, InspirationalPeople: null, HttpsImageUrl: '', FollowersCount: 0, FriendsCount: 0, IsGeoEnabled: null, TotalStatusesCount: 0, Associations: null, NumRecommenders: 0, Honors: null, Awards: null, Skills: null, CurrentStatus: null, Certifications: null, Courses: null, Volunteer: null, RecommendationsReceived: null, Languages: null, Projects: null, Games: null, Family: null, TeleVisionShow: null, MutualFriends: null, Movies: null, Books: null, AgeRange: { Min: 21, Max: 0 }, PublicRepository: null, Hireable: false, RepositoryUrl: null, Age: '31', Patents: null, FavoriteThings: [], ProfessionalHeadline: null, ProviderAccessCredential: { AccessToken: '', TokenSecret: null }, RelatedProfileViews: null, KloutScore: null, LRUserID: null, PlacesLived: null, Publications: null, JobBookmarks: null, Suggestions: null, Badges: null, MemberUrlResources: null, TotalPrivateRepository: 0, Currency: 'EUR', StarredUrl: null, GistsUrl: null, PublicGists: 0, PrivateGists: 0, Subscription: null, Company: null, GravatarImageUrl: null, ProfileImageUrls: { Small: '', Square: '', Large: '', Profile: '' }, WebProfiles: null }

Telegram's security is a joke. They show the first and last letter of your password and the length (the number of asterisks they put in the middle changes) when you sign in. Next to some pretty bad implications (do they store the password in cleatext or just the length and two letters?) , that password is down to about 1/5 of its original entropy. Told them a year ago, they don't seem to care.

EDIT: Yes, Telegram uses passwords if you enable them. This is what the questionable query looks like: https://i.imgur.com/BAnddlg.png

Telegram doesn't use passwords...

Fine. They call it a passcode:

https://telegram.wiki/desktop/tdesktoppasscode

Wait, how are they turning the passcode into a 2048-bit key? Is this an RSA key? How do they ensure it's not factorable, etc.?

They probably just create the key and then encrypt it with the pass code, as people usually do in these cases.

They do? On which login do they show that information? I've only seen the kind-of two-factor one where you have to enter a code sent in a text message or with a telegram message to a different device.

Took a while for me to reinstall it, this is what it looks like (just after SMS auth):

https://i.imgur.com/BAnddlg.png

I counted the asterisks, they do in fact reveal the length of the password.

Isn't that a user-defined hint? Mine shows text that I manually entered the last time I changed my password.

Hint is a text field that you fill in when creating a new cloud password. The hint text is generated based on password if you did not fill it yourself.

> The hint text is generated based on password if you did not fill it yourself.

That... is a problem.

Reminder: Telegram’s crypto is bogus, and use of this app should be continually and consistently discouraged.

It is a car with seatbelts that don’t work; a car without any seatbelts is better.

Are there known vulnerabilities or do you mean the missing audits and security through obscurity approach? Because bogus in this context is a very strong word.

It’s not binary; home-brewed original cryptosystems can be bogus without a known vulnerability published.

All of the peer review by qualified professionals has been negative. Don’t take my word for it, go look it up.

For the lazy: https://security.stackexchange.com/a/49802/43688

Be sure to check the links and dates, and also read the comments to that answer before forming an opinion too fast.

As an aside this is a very bad SE answer as SE policy is to include conclusive information within the answer itself, and here the only relevant part is merely being linked to.

It’s not end to end encrypted by default. This is the baseline standard for an encrypted messenger in 2018.

Its not if you focus on searchability and group chatting (Stripe, Discord, WeChat) so literally the biggest 3 players if you ignore the Facebook stack (And Facebook hasnt mastered encryption either, plus took very long to even try).

I think this is a valid critisism given that their selling point has been security, but as a practical matter is WhatsApp's encryption any better?

Yes.

Very much so. It uses the Signal Protocol.

WhatsApp had a severe vulnerability for groups disclosed not so long ago. Telegram has had no such vulnerabilities as far as I'm aware. This reinforced my impression that HN's mantra that "Telegram's encryption is bad" is more a personality cult to moxie than an informed opinion.

> WhatsApp had a severe vulnerability for groups disclosed not so long ago.

It had a vulnerability, but not a severe one, and certainly not one that could be exploited silently or lead to retroactive message decryption.

The vulnerability was: If you pwn the server, you can join a group without being invited, which means subsequent messages would be plaintext to you. However, everyone gets notified of a new arrival.

> Telegram has had no such vulnerabilities as far as I'm aware.

That's because Telegram doesn't encrypt groups or channels at all.

> This reinforced my impression that HN's mantra that "Telegram's encryption is bad" is more a personality cult to moxie than an informed opinion.

I don't particularly like Moxie, personally, but his work stands on its own merits.

EDIT: Because the wording was ambiguous, I want to clarify: I don't particularly dislike Moxie, either. I'm neutral to his personality, largely due to a lack of personal interaction with the man.

> The vulnerability was: If you pwn the server, you can join a group without being invited, which means subsequent messages would be plaintext to you. However, everyone gets notified of a new arrival.

If to you owning server => accessing group is not severe, then you should be happy with Telegram's default encryption: it's run of the mill SSL by default, just not E2E. If you own their servers you can read people's conversations too.

Accessing the group means:

1. Announcing your intrusion

2. Only being able to read what people say after you joined

That's a far better security proposition than server operators being able to silently spy on everything you ever send.

> I don't particularly like Moxie, personally, but his work stands on its own merits.

I hear you. What I meant is that although I know the guy has an excellent reputation, I know that because I heard other people say. I don't really have the technical knowledge to evaluate it myself, and I suspect 99% of the people in HN are in the same position. Therefore, if I were to say "Signal's security is excellent" I would be falling for the cult of Moxie myself, not an informed opinion.

Wait a second. No. You just said, one message upthread, that a reason to pick Telegram was that WhatsApp had a "severe vulnerability for groups" that Telegram didn't have. Forget about the fact that the vulnerability might not have been "severe". Scott points out that you're offering security advice about what group messenger to use despite the fact that you're unaware --- like many people --- that Telegram doesn't encrypt group messages.

Please acknowledge that this happened before continuing to offer more opinions about this subject.

They do encrypt group messages to their servers, just not E2E.

> you're offering security advice

I'm not offering security advice.

> They do encrypt group messages to their servers, just not E2E.

Transport-layer encryption that leaves messages totally readable to the service operator should not be classified as "they do encrypt". It muddies the water and will confuse users.

For the sake of communicating risk effectively, only E2E should count when we talk about encryption. Lack of transport-layer security (TLS, Noise, etc.) simply demonstrates severe negligence and/or incompetence.

> I'm not offering security advice.

Above you said:

> WhatsApp had a severe vulnerability for groups disclosed not so long ago. Telegram has had no such vulnerabilities as far as I'm aware.

A casual observer might read this and think, "Wow, WhatsApp is vulnerable and Telegram isn't. I should use Telegram" despite being even more at risk by choosing Telegram.

Whether it was your intention or not, it will have the same effect on HN readers as formal security advice from any other commenter.

> Transport-layer encryption that leaves messages totally readable to the service operator should not be classified as "they do encrypt".

In that case, you should consider WhatsApp's group security issue as severe.

I don't know how many different ways I can explain why this conclusion is false, but I suspect none of them would sink in.

Maybe the question to your "true or false?" comment to 'tptacek will elucidate adequately why the worst case of the WhatsApp vulnerability is still miles above what Telegram offers in terms of privacy, and even aside from Telegram, would be most generously a sev:medium (but by most measurements a sev:low).

By that definition, AOL Instant Messenger was encrypted too, just not E2E.

It's fine not to keep up with this stuff and not to have solid answers for basic questions about it. I just think you should use a lot more question marks when you write about it.

Whatever definition. Telegram leaves messages exposed to the operator, and so did WhatsApp's group security flaw.

True or not?

Not remotely true; practically a non-sequitur.

> Whatever definition. Telegram leaves messages exposed to the operator, and so did WhatsApp's group security flaw.

No, WhatsApp did not.

Messages are not exposed to the operator. If you exploited this vulnerability, you could not read messages that had already been sent.

Instead, what happens is, everyone is notified of a new arrival, and then can decide whether or not to keep communicating through that channel.

That is NOT the same thing as "leave messages exposed to the operator" in any stretch of the imagination.

> I don't really have the technical knowledge to evaluate it myself, and I suspect 99% of the people in HN are in the same position. Therefore, if I were to say "Signal's security is excellent" I would be falling for the cult of Moxie myself, not an informed opinion.

Sure, but that's not what's happening when people whose day-to-day involve applied cryptography and/or application security are commenting on MTProto and Telegram.

Here's a good read on why Telegram's "contest", which is a challenge meant to create the illusion of resilience, is totally bogus in the context of real-world cryptography: http://www.cryptofails.com/post/70546720222/telegrams-crypta...

The things that the Signal Protocol does well:

1. It maximizes forward secrecy,

2. while working for mobile devices that may be offline or unreachable,

3. and uses authenticated encryption.

https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...

https://paragonie.com/blog/2015/05/using-encryption-and-auth...

Disclaimer: The last link (the paragonie.com one) was my writing on the subject.

> It had a vulnerability, but not a severe one

The problem I have with WhatsApp is not a question of vulnerabilities, it's a problem of trust in ownership of the app's code. There's no way I would ever trust Facebook with anything sensitive enough to require the Signal protocol because the endpoints might be compromised at some point straight from the app itself.

What is the scenario in which Facebook subverts end-to-end encryption on WhatsApp by pushing out a malicious update?

Facebook decides that "their users are better served" by scanning messages locally on the client device and requesting ads based on that content, thereby introducing a privacy and information leak and potentially opening the door to other problems.

I don't necessarily think that's likely, but it's also not entirely implausible that they would do something, intentionally or not, that subverts the threat model/privacy assumptions of its users.

Facebook's interests are not aligned with users when it comes to privacy.

But in that scenario, the change would be announced. I'm asking about the malicious case.

Does Facebook always detail their tracking and analytics platform updates? In any case, my point is that it doesn't need to be malicious for FB to invalidate the privacy expectations that users of encrypted messaging might have.

If it was malicious, they already control the client code and therefore have access to the plaintext anyway.

As a theoretical matter, it's not even close; WhatsApp's Signal Protocol is literally decades more sophisticated than Telegram's, which traces back to just after the phlogiston era of cryptography. No practicing cryptographer or crypto engineer would ever select Telegram's protocol over WhatsApp's.

As a practical matter, it's even starker. WhatsApp messages are end-to-end encrypted by default, forward secure so that losing your phone doesn't let adversaries retroactively decrypt sniffed messages, and, most importantly, encrypted for groups.

Telegram's messages are plaintext by default --- you have to opt conversations in to encryption! --- and don't encrypt group messages at all. Telegram plays a sneaky game where they tell users that all messages are encrypted because they use TLS. But, of course, so was AOL Instant Messenger.

>should be continually and consistently discouraged

If you need top security - maybe. If you need features - not. I'd consider using something else if other apps have same features or similar features done better.

It’s marketed as a secure messenger. People using it casually for non-secure things may be mislead to believe by their marketing communications that it’s safe to use, when it isn’t. Its use should be discouraged in all cases as a result.

>for non-secure things

People are using for many things. Channels and groups are two main features that other IM's either do not have or have nothing but poor substitutes.

>it’s safe to use

It is safe to use. As safe as any other method as long as you are not stupid enough to share sensible information. Using any IM for this task is a stupid move to begin with.

>Its use should be discouraged in all cases as a result.

This is like saying that kitchen knife usage should be discouraged in all cases. You can hurt or kill yourself or an other person.

However they are not subject to national security letters. You can have all the best crypto in the world but if the vendor is forced to catch keystrokes by a government it won't help you.

By law, NSLs can request only non-content information, for example, transactional records and phone numbers dialed, but never the content of telephone calls or e-mails.

https://fas.org/sgp/crs/intel/RL33332.pdf

NSLs don't break well-designed and well-implemented E2E encryption. They can obtain metadata, which can still be harmful, but that's it.

If you want metadata on Telegram users, just hack Telegram's ISP. If the NSA hasn't already done so, I'd be surprised.

NSLs cannot compel people to write original software, thank fuck.

> It is a car with seatbelts that don’t work; a car without any seatbelts is better.

This is a wrong comparison.

Furthermore:

As an early enthusiastic Whatsapp user I'd love to use Whatsapp if it had continued developing into what Telegram is now instead of selling out and start feeding data Facebook.

Right now

-one side has sketchy crypto (according to world leading cryptographers AFAIK) and correct incentives

while the other side has

-- good crypto,

-- incentives stacked towards tracking me (contrary to their previous promises)

-- and a track record of doing exactly that

I don't think it is an obvious choice without trade-offs either way.

But it's not like "just use Whatsapp" is an obvious alternative.

(Signal seems to be a completely different story but most of my contacts don't use it.)

I wonder what the people who are railing about Kaspersky think about this development.

Sure, since you asked: It's bad. Don't use this.

Would love to see this added to Firebase.

EDIT: For clarity, the comment below has nothing to do with Telegram Login, but Telegram itself.

Telegram gets a lot of hate on HN, but I have to say that of all large messaging apps Telegram has by far the best UX. That said, I can see it slowly turning into a walled garden. For example, in public channels (distinct from groups, they're broadcast only) it should be possible to link to their content from the outside. Instead if you try that they force you to download the app to see the content. EDIT2: As someone noted you can link each individual post on a channel, but you can't see and scroll through a list of posts as you can from inside the app.

I wish we had a messaging app with a market as large as WhatsApp's, UX as good as Telegram, security as good as Signal, run by an organization like Mozilla.

Agreed. I love the UX. And it's also a less evil choice compared to many US centric alternatives.

Edit:// Evil might is the wrong word. But if you have the choice between a self enforced world police with a history of using information against people in foreign countries and a country that is mostly involved in their own shit and area the choice is IMO easy

>a country that is mostly involved in their own shit and area

https://en.wikipedia.org/wiki/Russian_military_intervention_...

https://en.wikipedia.org/wiki/Russo-Georgian_War

By using telegram you are directly supporting the Kremlin.

You realize there is a difference between reclaiming land and claiming or fighting wars in foreign land.

Not that i think any of both is right. But only one directly changes _my_ life.

Ah, so Signal devs are aligned with the US government in the same manner that the Durovs are working for the Russian government?

See, for me it makes sense to link Telegram to Kremlin, as it's very obviously ran by Putins buddies.

If Signal devs are in a similar situation, it's certainly not nearly as obvious as with Telegram.

Its a day later but i did some reading.

Essentially:

> By using Facebook/Whatsapp you are directly supporting the U.S.

is just as valid isnt it? Because you know Zuck has been to the White House and has followed requests by U.S. gov agencies.

Thats my whole point. If you have to choose between 2 evils, you choose that that is less threatening to yourself.

PS: I dont compare with Signal as they have neither spread nor common features.

> See, for me it makes sense to link Telegram to Kremlin, as it's very obviously ran by Putins buddies.

Do you have any reason to believe this, other than the guy's nationality?

Durov was the founder of VK (Russia's version of Facebook). He was approached by the Krelim and "forced" to sell his stake (nice social network you have there, it would be a shame if something happened to it)

https://www.theverge.com/2014/1/31/5363990/how-putins-cronie...

I would imagine if there's someone who hates the Kremlin, it's Durov.

So I'll ask again, do you have any evidence to support your claim? Because if it all hinges on his nationality you're sounding a bit biggoted.

>Because if it all hinges on his nationality you're sounding a bit biggoted.

lol.

>Do you have any reason to believe this, other than the guy's nationality?

It seems bigoted to assume that his nationality would have anything to do with this.

Durovs have spent years cultivating this lie of them having been forced to "exile" from Russia, despite being a regular sight in Saint Petersburg.

Pavel even went as far as assaulting someone and taking their phone after he was spotted in a local mall. https://lenta.ru/news/2017/03/20/durov/

>https://www.theverge.com/2014/1/31/5363990/how-putins-cronie...

>I would imagine if there's someone who hates the Kremlin, it's Durov.

Well then you probably wouldn't imagine that Telegram is being developed in the VKontakte HQ building, but nonetheless that is the case.

https://tjournal.ru/52954-durov-back-in-ussr

Maybe Durovs genuinely do hate the Kremlin, maybe not. It doesn't make a difference. They've spent years cultivating their false image as dissidents while remaining extremely close to Putin, whether or not they do so by choice makes little difference.

>See, for me it makes sense to link Telegram to Kremlin, as it's very obviously ran by Putins buddies.

Pavel literally fled the country and bought himself a different citizenship only to be best Putin buddy, yeah.

> wish we had a messaging app with a market as large as WhatsApp's, UX as good as Telegram, security as good as Signal, run by an organization like Mozilla.

This would be ideal. Until then I still feel Signal gives me the best balance and I haven't had too much issue with friend/family adoption.

I feel like Firechat could take this role if they gained a large market share.

https://www.opengarden.com/firechat.html

Your last paragraph is a tall order. Too many conflicting priorities.

The only way I could see this happening is some open/decentralized chat protocol takes hold and private companies build nice UX on top of that.

Sadly, strong UX is not the strength of opensource/foundation driven development. (For the love of god someone please prove me wrong on this)

Yes – if Mozilla owned a "WeChat of the West", that would make me very happy.

The impression of a walled garden hardens for me when it comes to interoperability. For instance, instead of providing gateways to standards such as XMPP or IRC, as a developer I am confronted with an absurdely complex API. It is rich and versatile, but impossible to implement a client in a couple of hours (not talking about their bot API, this is not a full client).

Even worse, one can only participate in their network with a mobile phone number. In my country, land line numbers do not even work.

With their recent release of tdlib, implementing clients should be easier than before. Still a pain, but easier.

>it should be possible to link to their content from the outside

But you can link the content, no? (example: https://t.me/dailyeng/1402). You see the full post, you don't have to donwload Telegram for this.

You can't see the list of posts. I had in mind something a la Twitter.

But you're right. I'll edit above.

Compared to e.g. KakaoTalk the UX is fairly poor

Edit: To perhaps stem the downvote tide: The impulse for my comment is that OP probably hasn't tried it, even though Telegram and KakaoTalk have similarly sized userbases and the emotion-inspiring stuff in the Telegram client app is mostly a timid knock-off of better Asian messengers (the Telegram team faces the challenging task of slowly acclimatizing Western audiences to features it knows will eventually be popular, by example). The West-centricness of such statements is grating to me.

The reason my comment doesn't substantiate the UX difference further is that I can't think of a single feature or screen that isn't better realized in Kakao's Android app than in Telegram's. General performance, group management, galleries / archive retrieval stuff, cross sharing, search, stickers, etc. It's available with a full English UI, go have a look. (From a privacy/security/freedom POV Kakao is terrible, though.)

Well I don't put much hope in Mozilla lately - they really seem to have lost direction. We had Persona and they dropped it far too quickly. Then they tried to offload Thunderbird.

To my mind Mozilla should have had, and kept, a set: Firefox, Thunderbird, instant messaging, Persona. Not forgetting Lightning etc.

It is possible to embed posts from public channels in web pages. In fact, if your group is public, you can even embed conversations in your web page. Try the announcement link here https://t.me/telegram/83

> I wish we had a messaging app with a market as large as WhatsApp's, UX as good as Telegram, security as good as Signal, run by an organization like Mozilla.

An open protocol is a prerequisite. There's a 2018 IETF proposal for interoperable E2E messaging, initiated by Cisco, Google, Facebook and Wire:

Architecture: https://datatracker.ietf.org/doc/draft-omara-mls-architectur...

Protocol: https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/?...

"Messaging Layer Security (MLS) ... is not intended as a full instant messaging protocol but rather is intended to be embedded in a concrete protocol such as XMPP [RFC3920]. In addition, it does not specify a complete wire encoding, but rather a set of abstract data structures which can then be mapped onto a variety of concrete encodings, such as TLS [I-D.ietf-tls-tls13], CBOR [RFC7049], and JSON [RFC7159]. Implementations which adopt compatible encodings should be able to have some degree of interoperability at the message level, though they may have incompatible identity/authentication infrastructures."

It's not a good plan. They propose to design, de novo, in an open standards group, a cryptographic secure group messaging protocol based on a design that has never been deployed at any scale. The underlying design is cool --- it's basically Asynchronous Ratcheting Trees, which was presented in a paper at RWC just a few weeks ago. That's how de novo this particular "standards" effort is: the underlying theory is just 28 days old.

Already, in the starting point draft, it's been crudded up: it has "ciphersuites", and comes with support for the NIST P-256 curve --- despite the fact that the underlying design wants to take byte strings to curve points, which is tricky to do on the P-curve. It will only get worse from here. They'll figure out some reason to bolt a PAKE onto it soon enough.

Signal Protocol is exceedingly well-documented (and even before those documents were written, it was open enough for Wire to lift the protocol wholesale).

The IETF is bad at cryptography. Your default position should be distrust of IETF crypto standards.

Can Signal contribute to the IETF design, discussion and documentation?

Since the underlying standard is really a political maneuver meant to thwart Signal, this seems unlikely.

(I like my source on this, but can't share it; I expect to be able to this year, though. In the meantime:

0e49002152a374d9c11251cf856a7ccf25ef9bd0db54c3e97bef2a4109dad4f0)

Isn't Facebook (Messenger and Whatsapp) already using Signal Protocol at scale?

Yes.

Why would Facebook by trying to thwart the open Signal protocol that they are already using? In a standards discussion like IETF, wouldn't they be more likely to specify Signal interoperability (i.e. Facebook Messenger and WhatsApp interoperability) as a requirement on any proposed standard? That would be good for Signal.

1. Facebook is a big place.

2. Facebook's interests in the standard are not necessarily what drives the standard; Facebook can just be along for the ride.

I think what's going to happen with this is what happens to all de novo IETF designs other than TLS, the one that the market requires actually work: it's going to fail. That's also the outcome that I'm hoping for.

In the meantime, if Millican wants to get together with Katriel Cohn-Gordon and do a Facebook-only ART protocol design for Facebook Messenger, with an eye towards replacing Signal Protocol in WhatsApp, that would be a great development. So would a Cisco-only ART messenger, or maybe even a Mozilla ART messenger (though Mozilla's motives are the ones I trust least here).

What does not make sense is for a protocol whose service model we barely understand even in theory to be designed from scratch in an open standards group. The IETF motto used to be "loose consensus and working code". Now it's "take an RWC paper, add the P-curves to it, and use it to fuck over the most successful secure messaging protocol".

We shouldn't be cheerleading this. It's capture, not progress.

> I wish we had a messaging app with a market as large as WhatsApp's, UX as good as Telegram, security as good as Signal, run by an organization like Mozilla.

I would donate some money for such an initiative if it also had strong privacy protections from the start.

> our widget asks for your phone number

I'm good.

Reply on news.ycombinator.com