Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? From what I know, encrypted messengers almost never implement that. At least in Wire I noticed reordering at some point and it uses an implementation of what is now called the Signal protocol.
And that's the most severe vulnerability from the article. The second one is "mostly of theoretical interest" according to the researchers themselves, the third requires "an attacker [to] send many carefully crafted messages to a target, on the order of millions of messages", and the fourth "requires sending billions of messages to a Telegram server within minutes". So while this is not bad research, not at all (it's really great that people take this close a look!), the title sounds rather more severe and people will obviously jump to the conclusion that "See, MTproto is bad like we said all along!" without reading anything. Good research, bad article?
«Obligatory notice in Telegram comment threads: the real issue in Telegram is that end-to-end encryption is optional and made extremely inconvenient to use: no implementation at all in TDesktop, can't use it across multiple devices, doesn't work for group chats at all... That is the main reason Telegram isn't secure: they can read all your chats except when you use this stupid inconvenient mode.»
> Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? From what I know, encrypted messengers almost never implement that. At least in Wire I noticed reordering at some point and it uses an implementation of what is now called the Signal protocol.
If I'm reading this right, the issue is that a network MITM can reorder the messages in the client to server connection (without being able to read them). This would likely reorder messages in the chat transcript too, but that's a different issue.
TLS or Noise protocol are open alternatives here, and IIRC both require that you have received all previous packets in order to validate a new packet, which means either you've received all the packets in order or the MITM has compromised the handshake.
Signal protocol is the end to end protocol between clients; those messages do not require reception in order. Because the messages go through a server and may be retried, there's lots of ways things could go wrong and some messages may be dropped or delayed and can arrive out of order. You could refuse to display message N until you've displayed N - 1, but if the server dropped N for whatever reason, you need to get the sender to resend it, and that depends on availability of the sender which is limited (their phone may be off, out of coverage, or execution may be denied/delayed by the OS, or the user may have removed the app by the time the receiving app notices the message is missing, etc).
Given how bashing on MTProto is a favourite cryptographers' activity from the day-0, I'm actually kinda encouraged by the fact that's all they found. It's especially nice, that htey could fix all of them without breaking back-compatibility, which isn't really a given for crypto protocols. Would appreciate more technical and less dumbed down responses from the Telegram team, though. I have no idea what the fuck "counting grains in the bags of sound" is supposed to mean.
(Also, it's funny, but being accustomed to SMS and such I always somehow assumed Telegram messages can be reordered by chance too, if I send them fast. I never really thought about it, obviously, but simply didn't expect it to be otherwise.)
That's my takeaway here as well - no serious issues found, and Telegram actively worked with them to fix their minor theoretical issues, and did all of the fixes before the paper was published and without breaking any clients.
>I have no idea what the fuck "counting grains in the bags of sound" is supposed to mean.'
They have been doing this since the beginning. Their strategy of downplaying every attack against their protocol serves to mask the fact their team has absolutely no qualifications to implement cryptography. Like the original article stated, Telegram did not even file for CVEs, simply because they look bad. CVEs have been filed for much smaller things than these.
Their security game isn't on the side of secure-by-design, but grass-roots-damage-control to justify protocol designed by the owner's brother (who is a geometrician, not a cryptographer) and insecure-by-default. The nepotism and Russian pride should never go before the users' security. But they've never cared about it.
Slightly related, you should see /r/telegram on Reddit, that outright censors articles that criticizes the app or discuss its vulnerabilities. From the looks of it, Telegram is more a cult these days than a collective of users. Its users are willing to spend hours arguing over semantics, and Telegram shamelessly makes use of them having no life, by recruiting them to something known as Telegram Support Force https://tsf.telegram.org/
While bashing on Telegram is basically HNs favorite past time, there aren't many other alternatives that work just as well in the area that I care the most about: being a great chat app. Telegram is fast, has native clients instead of a garbage web ui (or electron based app), has better stickers than the alternatives, is easy to write bots for and has a larger user base where I'm at than any of the alternatives other than WhatsApp.
It's fast because it's insecure. Would they deploy end-to-end encryption for their groups, it would be as slow as the competition.
>has native clients instead of a garbage web ui
The "native clients" are used to manage data stored on remote server over an encrypted tunnel. The data that sits on Telegram servers is plaintext. The security benefits of the native clients (e.g. handling E2EE in a secure way) don't really play out when the desktop application doesn't feature end-to-end encryption at all, not even for 1:1 chats.
>has better stickers than the alternatives,
My Signal client has 1:1 match of my Telegram sticker packs. This is a non-issue. Porting them is trivial.
>has a larger user base
Sure, which means, larger amount of your data is hoarded by the Mark Zuckerberg of Russia who will take zero responsibility if his servers are hacked.
Just a thought: You should probably refrain from advertising features of an app the glaring security issues of which you can ignore out of your privilege. There's a LOT of oppressive regimes in the world, and people living there shouldn't take your advice.
Most of Telegram's advantages come from it not being end to end encrypted by default. They've proven that simply claiming to be the most secure app is better for most users than actually being the most secure. Because true security comes with drawbacks, and users don't like drawbacks.
This, seriously. I've switched to mostly Matrix chat (with bridges for backwards compatibility) and I seriously miss the Telegram experience. The official client is your run-of-the-mill Electron chat app, which comes with the standard lag and slowness. Alternative clients either lack features (notably, E2EE), are based on other terrible frameworks (Flutter, QML+Python, etc.) or don't work on the platforms I want to run them on.
Spectral looks promising, and so does Fractal in a sense. I've had trouble getting E2EE to work on Nheko, and everything that does work is slow and laggy compared to native chat clients.
One day I will probably get frustrated enough to hack the Matrix protocol into the Telegram app, if someone hasn't done that already by then. The lack of anything better annoys me to no end!
It is tiring that this keeps happening. These media outlet publish misleading titles and abstracts implying that Telegram is not secure, knowing very well that most people don't even read the articles. I assumed good faith for the first ~100 times, but it is always the same :D
Anyway, wouldn't it be better to link to the academic source ( https://mtpsym.github.io/ ), or at least to remove click bait titles?
It's tiring to see people claim Telegram is Secure e.g. "because it hasn't been hacked yet" :D These people don't realize Telegram is front doored by design, it leaks 100% of your chats to Mark Zuckerberg of Russia, just like Facebook Messeger leaks 100% of its messages to Mark Zuckerberg of USA.
Being in the academia and kn knowing it's culture I will help to translate. The cryptographers studied the Telegram protocol and did not find practical vulnerabilities. So to pay their "academic debts" they published a paper on a vulnerability which can mess up senders messages in a random way.
It doesn't matter much what vulnerabilities there are when a large chunk of your users don't even use e2e encryption. For a while recently I had used Telegram to communicate with a few people, and as an experiment I did not turn on e2e myself. Well, neither did any of my counterparts (even the more security conscious ones). I suspect people are inclined to use it only in special cases, as the UX rather gives off the vibe of pulling your counterpart into the cover of a dark side alley at night (rather than being the default of a presumably secure messenger).
When you really think about it, almost nobody can be sure that their conversations are end-to-end encrypted. The only way you can be is to verify the fingerprint on both ends, provided you have exchanged fingerprints over a medium known to be secure or in person. Nobody does that.
They don't seem to go into technical details, relying on analogies like bags of sand - maybe this is comforting enough to the general public, but I'm skeptical.
I didn't read the technical details of the exploits though, so Telegram might be entirely in the right to be so dismissive.
> The researchers also highlighted several traits of MTProto that were changed as the result of our discussions before the paper was published. This document provides an accessible overview of these changes. For more technical details, see here.
I would like you, or someone more knowledgeable in the field to argue that the response is not accurate:
> Re-ordering
Exposed no information about the plaintext and needs additional work to become a fully fledged exploit, patched anyway.
> Re-sending: This is a purely theoretical point that has no bearing on the security of messages but is inconvenient for researchers who want to formally analyze the protocol.
Researchers being able to analyze the protocol to find faults - good thing. But can't this also work against people trying to break the protocol?
> Implementation problems - "For an analogy, imagine a door with multiple locks, one of which could be unlocked — the door to your messages could still not be opened because it had more than one lock"
I think this contradicts with the summary above, which is "recover some plaintext", which does not make sense given the analogy. Can someone explain? Possibly the only serious issue found.
> RSA Decryption: "This may sound scary but was not possible in practice"
If it's not possible in practice that seems like a bunch of other well established crypto protocols I know where it's just infeasible to brute force with currently available non state resources.
I don't like the way they communicate regarding security, but for context: So far there has been an extreme amount of FUD thrown their way from people who pushed WhatsApp and Signal.
I would avoid Telegram even not having read this. Their homegrown encryption and secretive nature of the back-end creep me out. The irrational part of me is also wary of the developers' background.
At the same time I also can not bring myself to trust the other popular options either. Whatsapp should be a pretty obvious case of facebookiness, and signal suffers from the same lack of back-end transparency and decentralization as Telegram. And, believe me I don't want to bring this up, but Moxie is just such an incredibly untrustworthy figure I wouldn't be able to sleep at night trusting his thing.
The only option with any real adoption (still not at the scale of the previously mentioned though) is Matrix. Having familiarized myself with Olm and their implementation of it for the purpose of building clone for educational purposes, I feel safe trusting it. You can't go much more open and transparent than Matrix does.
Maybe this reddit comment will make you less worried /s
>The lead Telegram dev is a 3x International Math Olympiad gold medalist, won another gold in the informatiks olympiad, went on to earn two Ph.D.'s in algebraic geometry, all while working full-time as a programmer?
>Him rolling his own encryption algorithm is not the same as your copy-paste StackOverflow code monkey who scraped by with C's at his community college rearranging the alphabet letters in a caesar cipher.
People here failed to realize Telegram made a clear choice between usability and security. Cloud messages make it very useful and their groups are awesome.
And you can always turn on E2E if you really want to use it. It works only on smartphones (probably they should add an option...) but it's there and works pretty fine.
And let's not forget. People are studying their encryption protocol and they're not finding anything special. It's not like you can actually decrypt messages.
Reading just the article and going out on a limb, it sounds like they are exploiting the window of valid sequence numbers in a session to enable out of order delivery.
I'd speculate the basic problem in the protocol is that session sequence numbers (counters) can be incremented by sending invalid messages, and there is a window of n plus or minus x, where x is how much the counter/sequence number on a valid message can be off-by and still be processed.
Flooding the session to increment the counter above the valid window would yield undefined behavior in a few ways. When a peer gets desynched, either the client or server may kill the session and require a new negotiation handshake with the peer (a DoS vulnerability) - or it attempts to recalculate the window of counter values it will accept based on its last known good message, which sounds like it effectively causes the valid messages in that chain to "fold" back on themselves in their order.
I'd suspect this was a design decision and understood by the protocol architects.
If you aren't using an CMAC, a ratchet function (or a kdf based on hashing) which proves deterministically what the current sequence of messages is, instead of using a sliding window, you are going to have a similar or analogous sequence number "window" problems in your protocol.
Some message sequence schemes use an obfuscated counter where instead of say, integers, you use some function over a field. (hence GCM, as I loosely apprehend it) But even the seed for that function just becomes another secret to manage (imo), so protocols that depend on counters earn extra scrutiny.
The reason to use sequence numbers (counters) instead of ratcheting or hashing is because sometimes you're just substituting the managability of a sequence number counter window problem with another key management problem that has has a different set of known vulnerabilities, and you make the call based on your threat model.
Perhaps the researchers' actual findings are more complex than this, and it isn't just a gotcha criticism of a design decision that had clear trade offs, which few are equipped to object to.
Who would possibly care that their instant messages might be made to arrive out of order? You could even claim it as some sort of feature. If you get confronted about something you said just claim that you said it in a different order. Plausible deniability though forgeable ordering. Which strikes me as sort of funny because deniability is something that often gets promoted as a critical feature but has no practical implications for anyone either.
I often wonder if it’s just easier to crack at the phone level and just get data from memory as it’s unencrypted on the device rather than the quite good protocols that may have some problems. Are we all looking in the wrong place? Personally I’m sure if state actors want they can read your messages, one way or another.
I'm really curious how Telegram makes money. Signal had (has?) their crypto thing, Whatsapp snarfs up the user graph / interactions, but Telegram just supposedly shows adds on large groups.
I really don't know how that is enough to support half a billion users, just in terms of hardware cost.
Are they spying on some group of crypto whales to get insider info?
Here's a source from TC. TL;DR Non-targeted ads in channels, which are like RSS feeds or blogs, no ads anywhere else. Also considering "premium" animated stickers:
> The service, which topped 400 million active users in April this year, will introduce its own ad platform for public one-to-many channels — “one that is user-friendly, respects privacy and allows us to cover the costs of server and traffic,” he wrote on his Telegram channel.
> “If we monetize large public one-to-many channels via the Ad Platform, the owners of these channels will receive free traffic in proportion to their size,” he wrote. Another way Telegram could monetize its service is through premium stickers with “additional expressive features,” he wrote. “The artists who make stickers of this new type will also get a part of the profit. We want millions of Telegram-based creators and small businesses to thrive, enriching the experience of all our users.”
But that's just the thing now is it. It's NOT secure, that's the problem.
* It leaks 100% of messages to server by default.
* It leaks 100% of Win/Linux desktop chats with no chance to opt out
* It leaks 100% of group message content with no chance to opt out.
* It leaks 100% of metadata with no chance to opt out.
* It always leaks the intention to hide messages from telegram chats, Telegram knows with whom you are sending secret chats, it knows when, it knows the message size etc. This metadata is extremely valuable
Telegram is not in the process of fixing these, thus its security isn't reaching the bare minimum. Thus every feature it is implementing is another way for the company to collect data about you.
It's just another Facebook, masquerading itself as "private app for the people". It's run by the man who is literally called "The Mark Zuckerberg of Russia". That man has military education on information warfare / disinformation: He knows how to create a literal cult around his product.
There's almost nothing we know about the company like who it employs, how it makes money, what it does with its data. Journalists who tried to get an interview with Durov travelled to Dubai, only to find empty offices. The office workers next door said they had never seen anyone enter Telegram offices. They suspected Telegram was using the office for tax evasion, which is not a good sign. Telegram's been very enthusiastic about a story where they're evading foreign intelligence. If that's the threat model, why is their security strategy "store all messages on one server" (like the NSA et. al. didn't have zero day exploits);
The claims about how the data stored on servers is protected, are outright lies a first year computer science student whose taken Computer Organization 101 can disprove[0]
Telegram is a dumpster fire and I'd LOVE to be able to say it's security is getting better, but it's NOT. They just implemented group video calls, are those end-to-end encrypted? No, they f'n aren't. Not even NEW features in Telegram are secure by default. You know, the features no-one asked for, that they were in no rush to deploy. It's especially condemnable as the major competition like Zoom, Signal and Jitsi all have end-to-end encrypted group video chats. Telegram staff don't care about me, you or any other user one bit. The only thing they seem to be interested in is "move fast break things" or "move fast f** security".
No matter how you put it, Schneier is right when he says data is a toxic asset[1]. Telegram can't give any guarantees data that sits in their server is forever protected, so they shouldn't be collecting it in the first place. WhatsApp is in the process of deploying client-side encrypted cloud backups. This completely shreds Durov's BS claim that Telegram has to have access to your data. There can only be two reasons they collect it: Either they don't care about your security, or they are actually interested in your data.
[+] [-] lucb1e|4 years ago|reply
And that's the most severe vulnerability from the article. The second one is "mostly of theoretical interest" according to the researchers themselves, the third requires "an attacker [to] send many carefully crafted messages to a target, on the order of millions of messages", and the fourth "requires sending billions of messages to a Telegram server within minutes". So while this is not bad research, not at all (it's really great that people take this close a look!), the title sounds rather more severe and people will obviously jump to the conclusion that "See, MTproto is bad like we said all along!" without reading anything. Good research, bad article?
«Obligatory notice in Telegram comment threads: the real issue in Telegram is that end-to-end encryption is optional and made extremely inconvenient to use: no implementation at all in TDesktop, can't use it across multiple devices, doesn't work for group chats at all... That is the main reason Telegram isn't secure: they can read all your chats except when you use this stupid inconvenient mode.»
[+] [-] toast0|4 years ago|reply
If I'm reading this right, the issue is that a network MITM can reorder the messages in the client to server connection (without being able to read them). This would likely reorder messages in the chat transcript too, but that's a different issue.
TLS or Noise protocol are open alternatives here, and IIRC both require that you have received all previous packets in order to validate a new packet, which means either you've received all the packets in order or the MITM has compromised the handshake.
Signal protocol is the end to end protocol between clients; those messages do not require reception in order. Because the messages go through a server and may be retried, there's lots of ways things could go wrong and some messages may be dropped or delayed and can arrive out of order. You could refuse to display message N until you've displayed N - 1, but if the server dropped N for whatever reason, you need to get the sender to resend it, and that depends on availability of the sender which is limited (their phone may be off, out of coverage, or execution may be denied/delayed by the OS, or the user may have removed the app by the time the receiving app notices the message is missing, etc).
[+] [-] stryan|4 years ago|reply
Rooms in Matrix are directed graphs[0], so if I'm understanding right, transcript consistency should be the default.
[0] https://matrix.org/docs/spec/#id14
[+] [-] krick|4 years ago|reply
(Also, it's funny, but being accustomed to SMS and such I always somehow assumed Telegram messages can be reordered by chance too, if I send them fast. I never really thought about it, obviously, but simply didn't expect it to be otherwise.)
[+] [-] ufmace|4 years ago|reply
[+] [-] WilTimSon|4 years ago|reply
This document seems like a better response to the theoretical problems the researchers found.
[+] [-] NicolaiS|4 years ago|reply
Telegram protocol defeated. Authors are going to modify crypto-algorithm: https://news.ycombinator.com/item?id=6948742
[+] [-] Siira|4 years ago|reply
[+] [-] maqp|4 years ago|reply
They have been doing this since the beginning. Their strategy of downplaying every attack against their protocol serves to mask the fact their team has absolutely no qualifications to implement cryptography. Like the original article stated, Telegram did not even file for CVEs, simply because they look bad. CVEs have been filed for much smaller things than these.
Their security game isn't on the side of secure-by-design, but grass-roots-damage-control to justify protocol designed by the owner's brother (who is a geometrician, not a cryptographer) and insecure-by-default. The nepotism and Russian pride should never go before the users' security. But they've never cared about it.
Slightly related, you should see /r/telegram on Reddit, that outright censors articles that criticizes the app or discuss its vulnerabilities. From the looks of it, Telegram is more a cult these days than a collective of users. Its users are willing to spend hours arguing over semantics, and Telegram shamelessly makes use of them having no life, by recruiting them to something known as Telegram Support Force https://tsf.telegram.org/
[+] [-] isatty|4 years ago|reply
[+] [-] maqp|4 years ago|reply
It's fast because it's insecure. Would they deploy end-to-end encryption for their groups, it would be as slow as the competition.
>has native clients instead of a garbage web ui
The "native clients" are used to manage data stored on remote server over an encrypted tunnel. The data that sits on Telegram servers is plaintext. The security benefits of the native clients (e.g. handling E2EE in a secure way) don't really play out when the desktop application doesn't feature end-to-end encryption at all, not even for 1:1 chats.
>has better stickers than the alternatives,
My Signal client has 1:1 match of my Telegram sticker packs. This is a non-issue. Porting them is trivial.
>has a larger user base
Sure, which means, larger amount of your data is hoarded by the Mark Zuckerberg of Russia who will take zero responsibility if his servers are hacked.
Just a thought: You should probably refrain from advertising features of an app the glaring security issues of which you can ignore out of your privilege. There's a LOT of oppressive regimes in the world, and people living there shouldn't take your advice.
[+] [-] Andrew_nenakhov|4 years ago|reply
[+] [-] jeroenhd|4 years ago|reply
Spectral looks promising, and so does Fractal in a sense. I've had trouble getting E2EE to work on Nheko, and everything that does work is slow and laggy compared to native chat clients.
One day I will probably get frustrated enough to hack the Matrix protocol into the Telegram app, if someone hasn't done that already by then. The lack of anything better annoys me to no end!
[+] [-] baby|4 years ago|reply
[+] [-] Laarlf|4 years ago|reply
[+] [-] shapefrog|4 years ago|reply
[+] [-] tyrion|4 years ago|reply
Anyway, wouldn't it be better to link to the academic source ( https://mtpsym.github.io/ ), or at least to remove click bait titles?
[+] [-] maqp|4 years ago|reply
[+] [-] JanisErdmanis|4 years ago|reply
[+] [-] strogonoff|4 years ago|reply
[+] [-] noxer|4 years ago|reply
[+] [-] c7DJTLrn|4 years ago|reply
[+] [-] raziel2p|4 years ago|reply
They don't seem to go into technical details, relying on analogies like bags of sand - maybe this is comforting enough to the general public, but I'm skeptical.
I didn't read the technical details of the exploits though, so Telegram might be entirely in the right to be so dismissive.
[+] [-] capableweb|4 years ago|reply
Linked in the third paragraph of the submission:
> The researchers also highlighted several traits of MTProto that were changed as the result of our discussions before the paper was published. This document provides an accessible overview of these changes. For more technical details, see here.
[+] [-] isatty|4 years ago|reply
> Re-ordering
Exposed no information about the plaintext and needs additional work to become a fully fledged exploit, patched anyway.
> Re-sending: This is a purely theoretical point that has no bearing on the security of messages but is inconvenient for researchers who want to formally analyze the protocol.
Researchers being able to analyze the protocol to find faults - good thing. But can't this also work against people trying to break the protocol?
> Implementation problems - "For an analogy, imagine a door with multiple locks, one of which could be unlocked — the door to your messages could still not be opened because it had more than one lock"
I think this contradicts with the summary above, which is "recover some plaintext", which does not make sense given the analogy. Can someone explain? Possibly the only serious issue found.
> RSA Decryption: "This may sound scary but was not possible in practice"
If it's not possible in practice that seems like a bunch of other well established crypto protocols I know where it's just infeasible to brute force with currently available non state resources.
[+] [-] mirekrusin|4 years ago|reply
[+] [-] eitland|4 years ago|reply
[+] [-] gerdesj|4 years ago|reply
[+] [-] martinralbrecht|4 years ago|reply
We give a high-level overview of what we found here: https://mtpsym.github.io/
We also include a discussion of how to interpret our attacks.
[+] [-] kiryin|4 years ago|reply
The only option with any real adoption (still not at the scale of the previously mentioned though) is Matrix. Having familiarized myself with Olm and their implementation of it for the purpose of building clone for educational purposes, I feel safe trusting it. You can't go much more open and transparent than Matrix does.
[+] [-] tester756|4 years ago|reply
>The lead Telegram dev is a 3x International Math Olympiad gold medalist, won another gold in the informatiks olympiad, went on to earn two Ph.D.'s in algebraic geometry, all while working full-time as a programmer?
>Him rolling his own encryption algorithm is not the same as your copy-paste StackOverflow code monkey who scraped by with C's at his community college rearranging the alphabet letters in a caesar cipher.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] traveler01|4 years ago|reply
And you can always turn on E2E if you really want to use it. It works only on smartphones (probably they should add an option...) but it's there and works pretty fine.
[+] [-] traveler01|4 years ago|reply
[+] [-] motohagiography|4 years ago|reply
I'd speculate the basic problem in the protocol is that session sequence numbers (counters) can be incremented by sending invalid messages, and there is a window of n plus or minus x, where x is how much the counter/sequence number on a valid message can be off-by and still be processed.
Flooding the session to increment the counter above the valid window would yield undefined behavior in a few ways. When a peer gets desynched, either the client or server may kill the session and require a new negotiation handshake with the peer (a DoS vulnerability) - or it attempts to recalculate the window of counter values it will accept based on its last known good message, which sounds like it effectively causes the valid messages in that chain to "fold" back on themselves in their order.
I'd suspect this was a design decision and understood by the protocol architects.
If you aren't using an CMAC, a ratchet function (or a kdf based on hashing) which proves deterministically what the current sequence of messages is, instead of using a sliding window, you are going to have a similar or analogous sequence number "window" problems in your protocol.
Some message sequence schemes use an obfuscated counter where instead of say, integers, you use some function over a field. (hence GCM, as I loosely apprehend it) But even the seed for that function just becomes another secret to manage (imo), so protocols that depend on counters earn extra scrutiny.
The reason to use sequence numbers (counters) instead of ratcheting or hashing is because sometimes you're just substituting the managability of a sequence number counter window problem with another key management problem that has has a different set of known vulnerabilities, and you make the call based on your threat model.
Perhaps the researchers' actual findings are more complex than this, and it isn't just a gotcha criticism of a design decision that had clear trade offs, which few are equipped to object to.
[+] [-] upofadown|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] andy_ppp|4 years ago|reply
[+] [-] Amin699|4 years ago|reply
[+] [-] templarchamp|4 years ago|reply
[+] [-] egberts|4 years ago|reply
That’s like an intentional weakening of “secured-ness”.
[+] [-] _huayra_|4 years ago|reply
I really don't know how that is enough to support half a billion users, just in terms of hardware cost.
Are they spying on some group of crypto whales to get insider info?
[+] [-] owlbynight|4 years ago|reply
[+] [-] WilTimSon|4 years ago|reply
> The service, which topped 400 million active users in April this year, will introduce its own ad platform for public one-to-many channels — “one that is user-friendly, respects privacy and allows us to cover the costs of server and traffic,” he wrote on his Telegram channel.
> “If we monetize large public one-to-many channels via the Ad Platform, the owners of these channels will receive free traffic in proportion to their size,” he wrote. Another way Telegram could monetize its service is through premium stickers with “additional expressive features,” he wrote. “The artists who make stickers of this new type will also get a part of the profit. We want millions of Telegram-based creators and small businesses to thrive, enriching the experience of all our users.”
[+] [-] ilrwbwrkhv|4 years ago|reply
[+] [-] IntelMiner|4 years ago|reply
But let's not mistake ease of use for security
[+] [-] atatatat|4 years ago|reply
[+] [-] eingaeKaiy8ujie|4 years ago|reply
[+] [-] maqp|4 years ago|reply
* It leaks 100% of messages to server by default.
* It leaks 100% of Win/Linux desktop chats with no chance to opt out
* It leaks 100% of group message content with no chance to opt out.
* It leaks 100% of metadata with no chance to opt out.
* It always leaks the intention to hide messages from telegram chats, Telegram knows with whom you are sending secret chats, it knows when, it knows the message size etc. This metadata is extremely valuable
Telegram is not in the process of fixing these, thus its security isn't reaching the bare minimum. Thus every feature it is implementing is another way for the company to collect data about you.
It's just another Facebook, masquerading itself as "private app for the people". It's run by the man who is literally called "The Mark Zuckerberg of Russia". That man has military education on information warfare / disinformation: He knows how to create a literal cult around his product.
There's almost nothing we know about the company like who it employs, how it makes money, what it does with its data. Journalists who tried to get an interview with Durov travelled to Dubai, only to find empty offices. The office workers next door said they had never seen anyone enter Telegram offices. They suspected Telegram was using the office for tax evasion, which is not a good sign. Telegram's been very enthusiastic about a story where they're evading foreign intelligence. If that's the threat model, why is their security strategy "store all messages on one server" (like the NSA et. al. didn't have zero day exploits);
The claims about how the data stored on servers is protected, are outright lies a first year computer science student whose taken Computer Organization 101 can disprove[0]
Telegram is a dumpster fire and I'd LOVE to be able to say it's security is getting better, but it's NOT. They just implemented group video calls, are those end-to-end encrypted? No, they f'n aren't. Not even NEW features in Telegram are secure by default. You know, the features no-one asked for, that they were in no rush to deploy. It's especially condemnable as the major competition like Zoom, Signal and Jitsi all have end-to-end encrypted group video chats. Telegram staff don't care about me, you or any other user one bit. The only thing they seem to be interested in is "move fast break things" or "move fast f** security".
No matter how you put it, Schneier is right when he says data is a toxic asset[1]. Telegram can't give any guarantees data that sits in their server is forever protected, so they shouldn't be collecting it in the first place. WhatsApp is in the process of deploying client-side encrypted cloud backups. This completely shreds Durov's BS claim that Telegram has to have access to your data. There can only be two reasons they collect it: Either they don't care about your security, or they are actually interested in your data.
[0] https://security.stackexchange.com/questions/238562/how-does...
[1] https://www.schneier.com/blog/archives/2016/03/data_is_a_tox...
[+] [-] 0xdeadb00f|4 years ago|reply