This is such a misrepresentation. Telegram could at-will feed the cloud-2FA password to password hashing function like Argon2 to derive a client-side encryption key. Everything could be backed up to the cloud in encrypted state only you can access. Do they do that? No.
So it's not as much as trade-off, as it is half-assed security design.
Telegram currently has very intuitive and snappy search, even in very active groups with years of content. That's because the heavy lifting is done by the server. Think that'd still be possible if there was no way for the server to process the data?
Grep is inefficient search engine, because it needs to scan through whole content (and Telegram uses search indexes). Also, grep cannot deal with words forms and inflections (you type "foot" and you also want to find "feet"). Inflections are not very important in English, but you need to deal with them in other languages where the word can have many forms.
I'm not trying to claim Telegram uses grep or whatever. My point is even very active chats on telegram generate somewhat small amount of text data and I dont believe that searching through it require massive complex search engine with super-fast backend.
I basically participate in hundreds of chats and message history doesn't take 10 of GBs. And I also know that search in history of such chats isn't so snappy on older Android phone.
Not at all. Try searching 500/1000 sources (maximum number of conversations any free/premium user can be part of), each with potentially millions of messages, and providing the results in under a second.
AFAIK telegram dont have any super-advanced search features neither it instantly return you results for all these years. Also if you search less common terms it's usually take longer than less than second.
And if you just run client on device without a lot of this history cached search wouldn't be anywhere as fast as you expect. So I pretty sure there no server-side magic there, but instead very good UX.
Also I can tell for certain that with right index grepping tons of JSONs can be very effective on any modern devices.
Can't say there aren't others who've used my search terms, but some things I search for are pretty unique. And I do a lot of searching. And search speed is consistently sub-second. There's no trickery seeing years-old results from VERY heavily used chats appear instantly. There's heavy optimization happening for search, and I'm very certain default e2ee would destroy that experience. Unless you can point to 1 e2ee service working at that scale with comparable UX. I won't even touch on the local aspect as the amount of storage needed to just store the data is waaaay beyond anything I'm even interested in owning, much less the compute to make it so accessible.
Yeah, try searching anything older than a year, the amazing snappy search grinds to halt. Meanwhile I'm storing years worth of stuff on Signal with no issues, and it searches ridiculously fast offline with no seconds long pause for buffering.
So interesting. I just did a search for mentions of someone I know in multiple Telegram groups and channels, and got all the results, going back 5 years, instantly. And these groups and channels have millions of messages. All media is also perpetually available (unless deliberately deleted), and take a couple seconds to load. I don't see any other platform having that kind of convenience.
Apple could also use E2E for their cloud backups by default, but they don't (and if you enable E2E, it doesn't apply to contact list and calendar backup anyway). Why do you demand more from Telegram than from Apple or Google?
Cryptography is nightmare magic math that cares about the color of the pencil you write it with.
It's not enough you know how to design a cipher that is actually secure, you need to know how to implement it so that the calculator you run it on consumes exactly the right amount of time, and in some cases power, per operation.
Then you need to know how to use the primitives together, their modes of operation, and then you get to business, designing protocols. And 10% of your code is calling the libraries that handle all that stuff above, 90% is key management.
There's a good amount of misuse resistant libraries available, but Nikolai was too proud to not look into how the experts do this, and he failed even with trivial stuff: He went with SHA-1 instead of SHA-256. He didn't implement proper fingerprints. His protocol wasn't IND-CCA secure. He went with weird AES-IGE instead of AES-GCM which is best practice. He used the weird nonces with the FF-DH, instead of going with more robust stuff like x25519.
One thing you learn early in academia, is that expertise is very narrow. I bet he knows a lot about geometry. Maybe even quite a bit about math in general. But it's clear he doesn't know enough to design cryptographic protocols. The cobbler should have stuck to his last.
EDIT, to add, the real work with cryptographic protocols starts with designing everyday things that seem easy on the paper, with cryptographic assurance. Take group management that the server isn't controlling.
For Telegram it's a few boolean flags for admin status and then it's down to writing the code that removes the user from the group and prevents them from fetching group's messages.
This is ultimately what separates the good from the bad, figuring out how to accomplish things with cryptography that first seem almost impossible to do.
Sure, but cryptography is its own subfield of advanced math (and also a bunch of more CS and UX based implementation challenges like avoiding side channels).
So it's not as much as trade-off, as it is half-assed security design.