Hacker News Reader

Comment by shp0ngle | Hacker News Reader

This article is good.

Telegram is really weird and sketchy; the rants Durov posts on his channel against WhatsApp usually make no sense; and their claims of security are dubious. And TON was a disaster.

On the other hand. If I did any social organizing today, I would definitely use Telegram. Signal is fine, but nobody is using it and the UX is just worse. I don't trust Facebook to randomly not shut everything down because some outsourced content moderator in New Delhi had a bad sleep.

Durov might be sketchy and weird libertarian, but damn, his developers can deliver good and working product really fast. (And from what I understand, it's a really small team.) Credit where it's due.

I still think Telegram will plainly run out of money in a few years (you can use it to host unlimited amount of data and share it with unlimited number of people!! that is not sustainable), but well, I will use them before they do.

View on HN

Telegram is ridiculously smooth, runs on everything, doesn’t treat any platform as an afterthought (despite having the electron thing, Signal is still very mobile oriented), and isn’t Facebook. It’s about as good as you’re going to get without making big sacrifices somewhere.

Yeah, it’s ridiculously well made. I’m not disputing that. The protocol is weird but they built a great app on top of that.

They just cannot be sustainable long term. There is literally no restriction size-wise on data you can save on their servers. For free. And they have basically no income. They have some new ad program with basically no tracking (which is good for users, sure, but nobody will pay that much for that). They get 0 commissions from payment (and I never heard anyone using their payment thing). TON went nowhere.

I'd pay double what I pay for things like media streaming services for Telegram if they had a supporter tier. It's easily the best service I use.

The restriction is done trough throttling in speed. It only looks like you have unlimited space but lets say you would actually want to upload a TB of stuff it would take very very long unless you use multiple accounts and then if you ever would need to download it it would again take very very long.

It also seems like files that are not downloaded by many people for a while get moved to slow servers and downloading these is really really really slow. If you have a few GB and want an additional online backup sure you could abuse it for that but realistically the potential to abuse it is low as it simply makes no sense as a could storage + they simply delete accounts from people who abuse the network. "Spam" is very lose defined and if you spam upload/download I'm sure they consider that to be spam and delete your account. Kinda pointless "backup" if you can lose access the moment you use the backup.

>And they have basically no income.

How would you know? They launched ads in public channels.

>TON went nowhere.

TON exists and seems functional just doesn't have anything to do with Telegram anymore due to the SEC.

protocol is weird

You’re repeating weird, but working with both bot api and tg api weekly or so (tg api through a wrapper, but I’ve read about lower level calls and used these in gramjs) I can’t see what do you mean by that.

Maybe they are referring to the fact that Telegram rolled their own cryptographic protocol that had a vulnerability that was fixed with a cryptic message [1] and still has some dubious choices [2]. I am not a cryptographer by any measure, so I don't whether there was a reason why they didn't pick an existing protocol like OTR. But, it doesn't make sense to me that they didn't switch to another protocol that is audited several times but released a second version of their protocol with the same criticisms.

[1]: https://words.filippo.io/dispatches/telegram-ecdh/ [2]: https://crypto.stackexchange.com/questions/31418/signal-vs-t...

Meaning MTProto. Not the bot API.

So, crypto part or mtproto in general? I’m not a fanboy who is going to defend tg crypto, and personally I wonder why they didn’t use the same security stack e.g. my browser uses for gmail access. But apart from that it feels to me like a regular rpc protocol, clumsy sometimes, but nothing particularly weird. Working also with many stock exchanges protocols, I can tell these are sometimes weird af, despite being mostly over-https. E.g. bitfinex and iirc bitmex are funny ones, not to mention FIX/FAST or large exchanges native protocols.

Telegram is the only platform that "works" on Jolla. WA/Signal are both proprietary and will not work outside the Google-Apple "pleb sandbox".

Pffft. Signal is proprietary?

it is on https://Github.com/SignalApp

and i’ve got my own variant of Signal server and client running. and runs on not only mobile but Linux too.

...except that for nearly a year you didn't have access to any updates to the Signal server code on their public repo while they were secretly adding Mobilecoin to it.

of course. it a necessary submarine method to a rollout if not enough developers are on hand. Bad move, IMHO. but it is easily excised.

Out of curiosity why do you run your own Signal server when there is no federation?

a study of Signal protocols.

The reason Telegram is able to easily outclass WA and Signal in the UX department is due to the lack of E2EE.

If you don't need/want that it is clearly superior, but if you do...

What does UX\UI has to do with E2EE?

Sure, Telegram team used more human resources elsewhere while WA and Signal where doing their E2EE magic, but once they where done - what stopped them from investing into everything else?

Zero-knowledge E2EE makes it difficult or impossible to implement certain "quality of life" features that users have come to expect from cloud-based services.

The most salient of these is that, if you lose your keys, you may never be able to recover your data.

On signal you will get various security related messages, like person x changed is key (because they reinstalled).

That stuff confuses every non IT person.

Not caring about it, allows for a more simple UI and UX to provide a easy way for person A to message B. Where B can be a group of thousands of people.

(a really secure way of posting a message to a big group would be way more complicated, even signal makes compromises)

If you have true e2ee, you can't enter your login/password and see all your chats right there, instantly.

Are you sure? You can do what good password managers do:

- Hash the password client-side

- Send the hash to the server. The server treats it as a password, and gives you your blob of encrypted data

- Decrypt the data client-side using the original password

That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages.

Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.

> That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages.

That's a different, further goalpost - we were talking about E2E encryption, weren't we? I.e. the server should not need to decrypt your data to provide it.

Obviously if you want to be able to recover your history from storage with just a password, that does mean the password is the only protection over that history, tautology. So storing your history should be optional, if you're seriously worried about brute-force attacks on data encrypted at rest (indeed, even WhatsApp makes it optional to have a backup of your data!).

In any case, that doesn't compromise future secrecy - i.e. gaining access to the history still doesn't give you access to future messages.

> Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.

Off the top of my head, it doesn't have to be a single blob for all your data. You could split the blob into tiny equal-sized chunks, and then have a separate encrypted index file which stores the information of which chunks hold which chats (plus just enough metadata, e.g. chat titles and last messages, to display your homepage properly). The index file is the only one downloaded on first login, then when you want to open a chat it moves the corresponding chunks to the top of the download list.

> we were talking about E2E encryption, weren't we?

Exactly, and what is described is not e2ee at all.

How is it not E2EE? Are you going by a stricter definition than commonly used?

> End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. [..] End-to-end encryption is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves.

Which requirement do you believe is failed by such a system?

It is incorrect to refer to encrypted backups as e2ee. See the wikipedia article on the subject [0], at the bottom of the "Modern usage" section.

[0] https://en.wikipedia.org/wiki/End-to-end_encryption

> Some encrypted backup and file sharing services provide client-side encryption. The encryption they offer is here not referred to as end-to-end encryption, because the services are not meant for sharing messages between users[further explanation needed]. However, the term "end-to-end encryption" is sometimes incorrectly used to describe client-side encryption.[23]

This is reasonable, but it's not describing any weakness of encrypted backups. It merely points out that "E2E" isn't the right term to use when there are not two E[nds], but rather only one client and their files.

However, our conversation was about storing chat history. There are two parties to the conversation in that case.

The key property of E2E is that only those parties can read those messages, and nobody else, in particular not the agents running the server. That property is not affected by the existence of backups, as long as those backups are client-side encrypted, because third parties cannot access them.

Therefore, it is possible to have both cloud-stored chat histories and true E2EE. QED.

The wording there has no effect on security, it's semantics. E2EE being an application of client-side encryption for messaging.

Most of that time is spent on downloading the data, which you have to do with any synchronization.

This is wrong, see Element/Matrix, which practically does that

Ok. After all, what do I know about encryption? I only directed the development of communication products that had OTR, OMEMO and PGP/GPG encryption in them.

Please, enlighten me how exactly Element/Matrix practically do that. Thank you in advance.

It backups your keys encrypted with a password only you know at server side (opt in)

When you login, you provide that password, and Element can use that to decrypt the keys and use these to decrypt the messages stored in the cloud

Alternatively, you can solely rely on syncing keys between verified devices.

That is not 'true e2ee' at all, and more of a security theater.

How is that?

Only you as a recipient can decrypt the messages, because they are sent e2ee to you.

And this stays true if you use the backup, as only you know that password.

Encrypted backups are just that, encrypted backups. They are called end-to-end encrypted backups only by people who are ignorant of correct terminology. Even the Wikipedia entry on e2ee addresses this.

Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols.

But then again, most users do not need real security, they are fine with a warm comforting feeling of safety, provided by a sincere promise that everything is really safe, as demonstrated by Telegram users.

I have nowhere called them end-to-end encrypted Backups, that's a straw man.

> Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols.

How, so? Are you aiming weak passwords? (One is provided for you ("security key"), however you can opt into a custom one that is not directly used for encryption ("security passphrase"))? Or are you referring to PFS, which isn't a property of all popular e2e protocols either, and "far" would be quite a stretch.

How does all that disprove that Element uses true e2ee?

It is proven beyond doubt that whatever Element fetches from their own servers and decodes on application launch are not messages encrypted using e2ee protocols. It is also completely clear that it does reduce the privacy of user messages. I don't know what else to argue about here.

Element does not fetch any message from their servers in general. If you use a server hosted by Element and don't disable encryption, e2ee encrypted messages will be fetched from their servers.

What is "it" that in your opinion should reduce the users privacy?

> I don't know what else to argue about here.

I don't know what you are arguing about right now. What I know, is that I have disproven your original thesis (visible messages right after login through a password is not possible with e2ee) by explaining how it works and providing an example that has put that concept into practice.

If you feel there is anything to discuss, or if you have any further questions, don't hesitate to respond though.

I'll add link that adds technical Implementation details, in case you are interested: https://matrix.org/docs/guides/implementing-more-advanced-e-...

Maybe what people like to know is how Matrix's backup encryption is different from WhatsApp encrypted backups:

https://www.whatsapp.com/security/WhatsApp_Security_Encrypte...

Thanks for the link. Actually, didn't even know that WhatsApp changed their backup mechanism, which previously used a mechanism that allowed e.g. google to obtain the messages.

Overall, the concept seems to be the same: use a secret, only known to the client to secure data stored at a untrusted location.

The major differences include:

- closed vs open source (it's easy to validate the mechanism in the implementation whereas you pretty much need to trust WhatsApp that they don't leak the key)

- WhatsApp uses a third party provider for storing the data whereas with Matrix your Homeserver is responsible for messaging and the backup

- only the main app can access the backup whereas with Matrix any of your clients can independently read and write to the backup (because there is no main client)

- WhatsApp stores everything in the backup, a Matrix client only the keys, because the messages are stored somewhere else

This wikipedia entry? So client-side encrypted backups are not called end-to-end encrypted, because the backup service is not a messenger?

>Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols.

Hmm? How so? Surely this depends on the strength of your password.

All messages are encrypted with one key. Break one key, and all messages will be accessible to an attacker. Proper encryption protocols rotate encryption keys and compromising one message will not compromise the rest.

The situation is a bit more nuanced, given the large feature set that Matrix is trying to implement.

> Break one key, and all messages will be accessible to an attacker.

How do you propose breaking that one key, though? The attacker also needs to somehow acquire access to the key backup and to the encrypted messages, so it's a multi-step process.

The encryption protocol does rotate message keys. In fact it uses the same cryptographic primitives as Signal, that is the double ratchet algorithm.

I think you're conflating the message encryption protocol with cold storage, which is the purpose the key backup serves. It's completely typical for backups to be encrypted with a single symmetric key.

Finally, the key backup is completely optional and can be disabled.

So PGP and the encryption protocol of Threema aren't proper encryption protocols?

Then, how do you break the key?

Brute force? If you break one key that way, it's likely you could break equally secure keys as well.

Access to the device? Well then you have access to everything anyways

WhatsApp just recently added E2E and before that was still outclassed by telegram.

'Recently' is 2016.

Isn't the big sacrifice with Telegram security?

I get that people like its UX, but if you're sacrificing security for UX then basically anything becomes fine?

For most people the said security is not a big issue. Esp. in countries where police can come for you and make you talk by any means. E2EE won't help you if they want you.

"Encryption isn't useful because you can be tortured" is a bizarre and ridiculous argument.

The police can only make you talk if they know who to make talk in the first place.

Reading your messages tells them who to interrogate, where to find them, who else is involved, etc.

Encryption is important especially in such countries.

It is encrypted, just not e2ee.

The police need to crack the encryption protocol (not impossible, telegram use non-standard crypto), or somehow gain access to telegram's server farm.

Wasn't it fixed? It was almost e2ee, but not really due to a bug as it trusted the server, but it was fixed save for key verification, but AFAIK, key verification is an open problem in e2ee.

That's not true. Nobody needs to crack any encryption. Check my other comment with 3 links.

I'm sorry but as someone from Russia - you are wrong.

>Reading your messages tells them who to interrogate, where to find them, who else is involved, etc.

Why read my messages if they can start from me? Or that other guy who posted something on twitter? Or any other place? Or talked to someone.

I'm not saying encryption is unimportant. I'm saying that it really only matters as long as all parties involved keep their business secure in the first place.

Not to mention that they police don't really work with that kind of precision here.

It's not a binary thing.

If you can choose secure communication vs. insecure communication you're better off choosing secure. You're right of course this doesn't protect you 100%, but it's a lot better than not having secure communication.

Does that mean even with Signal your friend could be compelled to unlock their phone and reveal the comms? Sure. It's still better to have that be the requirement than access to all comms by default. It requires more specific and high effort targeting. It makes it harder to just query keywords generally to find people. It's the better default state.

Is having a "seciurity" for vast majority of people that just do a little chit-chat with they friends and family a big thing suddenly?

If you want to exchange your private keys, you better not do it using any chat platform.

What countries do you people live in that needs such hiding from the police/state?

In my country they bought Pegasus and what can I do about it? If they want to trace me they can do it.

I took a look, but apparently you can't use the web app unless you already have an account, and you can only create an account in a mobile app. Is this an afterthought?

Found out the same thing. I guess they started from mobile, moved to web and git something better to do :)

I guess they want to know your phone number, or want to limit accounts to one per phone number.

Edit: but even so, they could verify a phone number by SMS, no need to make anyone install an app.

I take issue with your description of Telegram as "really weird and sketchy". You don't give any evidence other than Durov's personal opinions. And he's certainly entitled to them, given all the weird, often totally illogical beliefs everyone else in the world holds.

You toss out another statement in "TON was a disaster" without explanation. If you're going to make really big statements like this, please go into detail otherwise you're just shooting from the hip.

TON was a disaster because the SEC got involved. TON, as a technical solution to decentralizing Telegram, was a great idea and I'm sad Telegram was forced into a position of paying for all that infrastructure another way, with ads (opt-in, non-tracking, and only in one-to-many channels but still, ads).

> his developers can deliver good and working product really fast. (And from what I understand, it's a really small team.)

People keep insisting that electron is chosen for productivity yet telegram delivers more features with more efficiency in C++/QtWidgets (for the desktop) with a smaller team than so many electron stuff

You get efficiency basically for free with C++/Qt, unlike all of the Electron trash that gets pushed out. It's such a selfish way of thinking - "I don't care if my users can use efficient software, I just care about shoehorning Javascript into everything I touch!"

>his developers can deliver good and working product really fast. (And from what I understand, it's a really small team.)

Fun fact, their Android code [0] (haven't seen iOS) is unmaintainable mess and on the surface just looks like a complete disaster. I find it baffling how Telegram Android not only hasn't fallen to bits requiring a full rewrite, but has continued to deliver brilliant UX and features.

0. https://raw.githubusercontent.com/DrKLO/Telegram/master/TMes...

> Telegram is really weird and sketchy; the rants Durov posts on his channel against WhatsApp usually make no sense; and their claims of security are dubious. And TON was a disaster.

Oh yes, definitely. Whenever I read them it feels strange, understanding the technical context of Telegram. He never mentions that WhatsApp is actually end-to-end encrypted. He does continue to talk about 'encryption', though. It's very very misleading. It just seems to be bashing WhatsApp without talking about Telegram's shortcomings too. He obviously isn't going to be non-partisan but it would be nice if he would be a little more honest.

The funniest thing is that Telegram's group management tools blow anything FB has out of the water by a nautical mile.

If you only need the one channel and you need to manage a 100+ people, Telegram is by far the best tool. For "communities" Discord is a bit better, since you can split stuff to multiple channels. Anyone with basic knowledge of the internet can also install bots on both to manage dozens of different things.

Signal on the other hand is SUPER SECURE (although you will be giving your phone number to everyone), but no bots and no real ways to manage hundreds of possibly unruly people on a single channel.

> If you only need the one channel and you need to manage a 100+ people, Telegram is by far the best tool.

Even better than Element? In my experience it does well with hundreds of people as well. And it allows to group channels as well, or use bots

And you can use E2EE everywhere you think you want it

Element is still an UX clusterfuck.

I've been on IRC since its inception in the 90's and I've used ircII and BitchX etc. I'm no stranger to janky clients for communication tools.

Element is still in its death by a thousand cuts phase. There's nothing hugely wrong with it, but everything is a bit wonky. Just enough to be consistently annoying enough for me not to bother.

Summary: Matrix mostly good, Element bad. They should just copy Discord's UX 1:1, change the colour theme and work from there.

While I can't make Element copy Discords UX (not sure I'd even want that), I can show you a young client that seems to do that: https://cinny.in/

Cinny is close, but it still lacks a few features. For example it understands spaces, but can't create them.

It's okay for desktop use but frustrating on mobile.

Does anyone need e2ee on group chats anyway?

Nope.

If you're managing a 100+ user channel, encryption matters fuck-all unless your invitation process is 100% airtight and every user has all their devices encrypted and locked up at all times.

Data will leak anyway so E2EE won't bring any real advantages.

That was a rhetorical question, of course, but thank you for confirming my opinion.

Political parties typically do, and some are known to use Telegram for their internal groups.

Any leakage of secret knowledge shared only through these groups could be detected as treason by one of the participants in that channel. Having several channels with fewer and fewer members, closer to the party's leadership, is a typical configuration to maintain control of the most secret information.

> I still think Telegram will plainly run out of money in a few years (you can use it to host unlimited amount of data and share it with unlimited number of people!! that is not sustainable), but well, I will use them before they do.

FYI they recently got an ad platform https://promote.telegram.org/

And then they will start selling all the personal data they gathered in all these years. They have all the data, except for the tiny amount that passed through secret chats (but they also have the metadata for these, tied to accounts and all the non-secret stuff).

The kind of data Signal can't sell even if Moxie turns evil, simply because Signal does not have it.

When Telegram eventually fails, I expect there to be a Matrix client of similar quality and will just start using it.

> On the other hand. If I did any social organizing today, I would definitely use Telegram. Signal is fine, but nobody is using it and the UX is just worse. I don't trust Facebook to randomly not shut everything down because some outsourced content moderator in New Delhi had a bad sleep.

I don't see how Telegram is any different to say, Signal. It may have better apps, UX, features and more which that alone makes it a compelling competitor but its optional E2EE support is quite damning.

The great thing about regulations is that it stops such suspicious projects like TON dead in their tracks. After the ICO madness in 2017, unregistered ICOs have become illegal and TON fell in that category.

But who knows, maybe when the terrorists, extremists, scammers and fraudsters realise that Telegram is not E2EE by default or layman terms 'not secure', perhaps they would run to Signal and chat amongst themselves about using a private untraceable cryptocurrency like MobileCoin to fund and plan their operations. [0] [1].

[0] https://www.theverge.com/22249391/signal-app-abuse-messaging...

[1] https://foreignpolicy.com/2021/03/13/telegram-signal-apps-ri...

>I don't see how Telegram is any different to say, Signal. It may have better apps, UX, features and more which that alone makes it a compelling competitor

You have answered your own question there. Humans naturally chose paths that they find convenient, not necessarily safest or otherwise "better" paths.

Also, out of the "popular" IM networks (network effect is a real thing), Telegram is the only one that has a sensible API to interface with your own systems.

> Durov might be sketchy and weird libertarian, but damn, his developers can deliver good and working product really fast. (And from what I understand, it's a really small team.) Credit where it's due.

The UX is great. The Telegram clients are quite nice to use. They're open-source, too. Well, 'open-source' as in they dump a huge diff into the source tree now and again, and they never interact with outside developers submitting Feature Requests and Issues.

// On the other hand. If I did any social organizing today, I would definitely use Telegram //

Don't, unless it's for a BBQ or friendly partying.

[1] https://www.wired.com/story/brazil-hacker-bolsonaro-car-wash...

[2] https://www.reuters.com/article/us-iran-cyber-telegram-exclu...

[3] https://www.haaretz.com/israel-news/tech-news/.premium-exclu...

C'mon, it's not even E2E. It's as good as Facebook Messenger when it comes to security.

Reply on news.ycombinator.com