After a long-running blogpost holywar between Telegram and Signal, I perceive these “security experts” as Signal/Telegram shills depending on their stance
Summary:
- Telegram founder Pavel Durov claimed in an interview that the company only employs “about 30 engineers.”
- Security experts say this is a major red flag for Telegram’s cybersecurity, as it suggests the company lacks the resources to effectively secure its platform and fight off hackers.
- Telegram’s chats are not end-to-end encrypted by default, unlike more secure messaging apps like Signal or WhatsApp. Users have to manually enable the “Secret Chat” feature to get end-to-end encryption.
- Telegram also uses its own proprietary encryption algorithm, which has raised concerns about its security.
- As a social media platform with nearly 1 billion users, Telegram is an attractive target for both criminal and government hackers, but it seems to have very limited staff dedicated to cybersecurity.
- Security experts have long warned that Telegram should not be considered a truly secure messaging app, and Durov’s recent statement may indicate that the situation is worse than previously thought.
proprietary encryption algorithm
Oh God why would you do this.
The quote leaves out the best part.
people have cast doubt over the quality of Telegram’s encryption, given that the company uses its own proprietary encryption algorithm, created by Durov’s brother
Durov’s brother = FSB?
So they can implement their own backdoor
To be fair: someone somewhere has to make algorithms that we use. I honestly don’t know if Telegram’s encryption is strong or how strong based on their white paper, but I’m interested in an unbiased evaluation.
Developers should not design encryption algorithms. They should instead implement algorithms that were designed by a mathematician.
agree with the notion that any homebrew business is questionable but he is a mathematician
Interesting! Did not know that. It’s possible he may be qualified, so I’m still skeptical of closed crypto systems.
To be fair, in a large company, there is usually only about 30 people who are actually good and know what is going on, and hundred of others who are checking in trash.
There’s an aphorism, “give me 10 engineers and I’ll build it in a year, give me a hundred engineers and I can get that down to just five years.”
Even if every employee was equally competent, decision making needs to be consolidated enough that it can be decisive and shared throughout large companies. Complex systems that need to change rapidly gain no benefit from having too many people wanting to make decisions, you only need most of them to be competent enough to complete the work based on the decisions of a small group or the work will end up getting too convoluted and unmaintainable.
There really isn’t a benefit to have everyone understand all of the parts of a large and complex system, if they only have time to work on a portion or to facilitate decisions that take into account the knowledge of the people in the different parts.
It’s not even about the quality of individual people. The organizational structure of large companies encourages pointless work.
Internal mobility and cross department collaboration are frowned upon. So you get many people doing duplicate work, new ideas don’t propagate, and even if someone has an idea it’s quickly shut down.
The only way to achieve anything substantial is to be both: 1. assertive and energetic, and 2. at the correct level of hierarchy. And make no mistake even if you pull a miracle there will be no reward. Maybe a 3% raise at the yearly review.
Sorry for the rant, I currently work in a company like this.
Maybe I’m just lucky in where I am in a FAANG company, because I’ve only been offered mobility in my job, even directly after a promotion! We encourage work across the organization, but we have like 500 devs in this org.
That’s the correct way to do it.
The wrong way to to do it is: moving to another team requires you to go through the full hiring process. Any lateral movement, for example backend engineer -> fronted engineer is treated as if you’re a junior starting a completely new career.
Yeah. The most secure companies I’ve worked at actually only had a small group, of very competent people, who were paid well, treated with respect, and with not presented with a lot of organizational or infrastructural red tape.
I’ve worked with teams of 10 that had shit locked down tight, and teams of hundreds who had software that was exploding and getting exploited left and right.
If someone tells you more head count = security, I would not consider them an expert.
I see this parroted now and then. Often the people I’ve heard it from are the type of folks who would drastically underestimate the complexity and effort needed to make things. I’ve also seen and worked on codebases made by such folks and usually it ain’t pretty, or maintainable, or extensible, or secure, or [insert fav cut corners here].
talking to carlson is a red flag
I’m still waiting for the furries to switch to Matrix.
As a furry, real
Add it to the pile of reasons not to use Telegram.
Engineer to lawyer ratio is the best indicator of how worried to be. What’s the demoninator for telegram?
“Without end-to-end encryption, huge numbers of vulnerable targets, and servers located in the UAE? Seems like that would be a security nightmare,” Matthew Green, a cryptography expert at Johns Hopkins University, told TechCrunch. (Telegram spokesperson Remi Vaughn disputed this, saying it has no data centers in the UAE.)
good job Remi, that was the main concern lmao
The uae is a huge concern. Their terms demand they get to see your code. When the vPBX company I worked for tried to get into the uae, it was a 10mil boondoggle that ended up ruining them.
There was a post about this on lemmy awhile ago, I’m not sure which specific community it was i’m subscribed to a few tech related ones, but it was atleast a week or 2 or more ago about this same story.
I do agree that there should be more workers than 30 on one of the most known encrypted messaging apps.
There are good reasons to dislike Telegram, but having “just” 30 engineers is not one of them. Software development is not a chair factory, more people does not equal more or better quality work as much as 9 women won’t give birth to a baby in a month.
I checked, Telegram has 1342 employees.
Interesting! Out of curiosity, what is the source? Is there a breakdown per role?
I can understand if someone like Google or Microsoft employs lawyers directly, as they have the resources and scale to do so. But someone like Telegram should really not do that. They should use an external legal office when needed. Even keep them on retainer, but definitely not open a legal office inside the company.
30 engineers. You lose half that to people managing the infrastructure alone. That leaves 15 code monkeys. Of 2 are dedicated to deployment and 3 to setting up unit tests (that’s not many btw) you are left with 10 people. If say for a global platform that’s not many at all.
15 engineers for managing infrastructure?? Are they setting up servers by hand?
I would not want you as my boss, that’s for sure.
Try covering a 24/7 global service window. I’d think this is on the low end.
And you als need full infra stack knowledge: Server, database, Network, connectivity.
And probably some of these schmucks will get stuck managing the corporate environment too.
This comment smells of outdated software development practices.
If you have separate developers for writing unit tests, and not every developer writing them as they code, something is already very wrong in your project.
Deployment and infra should also mostly be setup and forget, by which I mean general devops, like setting up CI and infrastructure-as-code. Using modern practices, which lean towards continuous deployment, releasing a feature should just be a matter of toggling a feature flag. Any dev can do this.
Finally, if your developers are ‘code monkeys’, you’re not ready for a project of this scale.
Infra setup and forget… this is a large system with plenty of stuff that cyclicly needs to be deployed updated and such. Even with automation the sheer volume and tech in use requires bredth of knowledge. Sure you could do it with less I guess. But with changes on supplier side etc it’s still much work.
And for tests, sure you do it as you go along, but usually it helps to have people going over this and making sure it all stays functional, meets standards and fix things.
I have never, in my decade as a software dev, seen a role dedicated to “making sure unit tests stay functional, meet standards and fixing them”. That is the developer’s job, and the job of the code review.
The tests must be up to standards and functional before the functionality they’re testing gets merged into main. Otherwise, yes, you may actually need hundreds of engineers just to keep your application somewhat functional.
Finally, 30 engineers can be a vast breadth of knowledge.
So cool that you got to work with teams of devs that where able to do that. Was it for software used in a OT environment? Cause stuff like telegram seems a lot more like that imho.
And the bredth… 30 people can cover it all, yes. Doing that in a 24/7 global environment means 3 of several competences, in shifts, covering timezones. It’s not as if you can just click out at 5 and come back tomorrow.
I have no idea why you’re even bringing up OT. We’re not talking about PLCs or scientific equipment here, we’re talking about glorified web apps.
Web apps that need to be secure and highly available, for sure, but web apps all the same.
A point of pride sure, also a risk. Responding to incidents requires coverage. And the OT comparison was just more on the uptime requirements and redundancies than anything else.
30 engineers is startup-sized. 30 engineers to deal with the needs of a sensitive software being used by millions worldwide, and is a huge target for cyberattacks? That’s way below the threshold needed.
This sounds like the devs are personally, sword and shield in hand, defending the application from attacks, instead of just writing software which adheres to modern security practices, listening to the Security Officer and occasionally doing an audit.
They’re not just writing the software, they’re responsible for the infrastructure it’s running on. And keeping that running and secure IS a full time job.
Right now, you sound exactly like one of those C level execs who looks at IT and asks “We haven’t had an issue in years, what do we need to pay them for?”
Even if you have a full-time role for continuously auditing the infrastructure (which I would say is the responsibility of either a security officer or a devops engineer), you still didn’t show how that needs a 15-person team, and an otherwise-untouched infrastructure should just keep on working (barring sabotage), unless someone really messed something up.
If CI builds or deployments keep randomly failing at your place, that’s not an inescapable reality, that’s just a symptom of bad software development practices.
And lawyers are pretty likely not staff at all.
Someone needs to make a browser extension that hides any article with “experts say” in the title
Someone
We have now selected you to be that person.
The security software I maintained had one engineer.
Your move, sec nerds.
This journalist writes with the same amount of confidence as ChatGPT.
Headline is terrible. The big red flags are that they don’t do end-to-end encryption by default, the servers are in Dubai, and use a proprietary algorithm.
Last part should be clarified further. They didn’t reinvent AES or anything. It’s more like a protocol that puts together existing algorithms. It means they can use transport layers without TLS or anything else that wraps your messages in crypto otherwise.
https://core.telegram.org/mtproto
I’d still say this is a red flag. How you wrap encryption around your messages has several pits you can fall into. It’s not as bad as reinventing AES, though.
Headline is terrible
They do explain though that given how below average their headcount is, it means they’re likely understaffed, overworked, and have zero capacity to respond to intrusion attempts.
The count of engineers means absolutely nothing.
It does for a bridge, but not for software.
No
