“Any sufficiently complex input format is indistinguishable from bytecode; the code receiving it is indistinguishable from a vir- tual machine.”
Telegram Desktop vulnerability allowed any user's file to be stolen (beaksec.github.io)
farhanhubble 8 hours ago
goodmythical 6 hours ago
Forgeties79 6 hours ago
bita_nidir 6 hours ago
a) access all your files, and
b) roam the internet at will.
That was somewhat OK in the 80s, but it hasn't been since.pizzafeelsright 6 hours ago
g-b-r 3 hours ago
celsoazevedo 5 hours ago
I don't want my computer to always be as closed and restrictive as an iPhone. That's good sometimes and perfect for some users, but not for everyone or all the time.
bita_nidir 5 hours ago
g-b-r 3 hours ago
classified an hour ago
MomsAVoxell 5 hours ago
If the OS vendors are motivated to harvest peoples data, why on Earth would they be motivated to make sure nobody can harvest peoples data?
zargon 4 hours ago
drnick1 2 hours ago
fsflover 2 hours ago
unethical_ban 2 hours ago
As far as network control... We have open-source blacklists for various malicious websites. Perhaps we should also have "known-good" site whitelists and have OS-level blocking for that by default. Like, OSes running DNS-sinkholing of StevenBlack malware lists, and the option to enable "known-good" whitelists as well. Having a hosts file of 450,000 entries to sinkhole can bog down an interface coming up reliably... that process needs optimized.
There's a lot of money in the enterprise world doing similar things.
jonathanstrange 2 hours ago
aucisson_masque 41 minutes ago
cosmic_cheese 8 minutes ago
Half the problem is that too many people rely on commercial software that will crap itself if it doesn't have access to what it wants whenever it wants. If, say, Adobe CC stops working after a new macOS release because macOS won't allow it to litter the filesystem any more, the one taking the heat won't be Adobe (which shouldn't have been doing that in the first place) but rather Apple.
nikolay 24 minutes ago
hollerith 21 minutes ago
Also, some people use an iPad Pro connected to a USB hub connected to a monitor, keyboard, etc, as their daily driver.
Also, doesn't MacOS sandbox most apps?
crossroadsguy 9 hours ago
bluebarbet 9 hours ago
crossroadsguy 6 hours ago
jminnl 8 hours ago
axegon_ 8 hours ago
MajorTakeaway 3 hours ago
esseph 3 hours ago
It's kind of hard to hash out what you're saying here
g-b-r 3 hours ago
BeetleB 3 hours ago
TIL I'm not a legit good hearted person.
Guess I'll remove myself from the organ donation registry.
unethical_ban 2 hours ago
I prefer to keep the contents of my message secure from the panopticon.
drnick1 30 minutes ago
Telegram is connected to Eastern European and the Middle Eastern countries and not in a good way, and the server-side components are closed source. There is no E2EE by default.
boltzmann64 5 hours ago
maqp an hour ago
Yes
drnick1 24 minutes ago
gvfsa 4 hours ago
pixl97 3 hours ago
g-b-r 3 hours ago
SpacePortKnight 14 hours ago
modeless 14 hours ago
miroljub 14 hours ago
gvfsa 13 hours ago
feeeeeany 12 hours ago
freehorse 13 hours ago
The web experience is actually better, as eg there I can do web searches when right clicking sth with my default search engine without slack highjacking the options to force me onto google.
nkrisc 10 hours ago
jdrek1 10 hours ago
sdcfgy 9 hours ago
Eueudhsbsj32 13 hours ago
drnick1 5 hours ago
Razengan 13 hours ago
Kwpolska 12 hours ago
Razengan 11 hours ago
Kwpolska 8 hours ago
> - We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
yard2010 12 hours ago
Razengan 11 hours ago
radicaldreamer 4 hours ago
Not to mention that Dropbox has never been E2E protected and had that Lenovo credential free access bug on web not too long ago.
Dropbox should be considered untrustworthy at this point, especially since iCloud Drive offers E2E encryption and so do other competitors.
monster_truck 13 hours ago
It gets buttoned up fast and is always getting better, but its absolutely not a silver bullet.
Fethbita 12 hours ago
palata 10 hours ago
Except when you want actual end-to-end encryption, in which case web versions fundamentally cannot guarantee it today (and there are no plans to get there).
People using Telegram don't care so much about end-to-end encryption, so there maybe it makes sense to use the web version indeed.
perching_aix 9 hours ago
palata 6 hours ago
If you download an install a program on your OS, you can e.g. check the hash of that downloaded archive and compare it to others, ideally making sure that you are running an audited version of the program. You don't have that guarantee when loading code in a browser: the server could totally serve you a modified version of the code, and you don't have a practical way to check that. Not that the laws of physics prevent it; it's just not how a browser works.
perching_aix 4 hours ago
palata 2 hours ago
Say you have a device that projects the screen on a skyscraper in Manhattan, visible by tens of thousands of people in real time. You can do all the cryptography you want, I would argue that you fundamentally cannot achieve "privacy" on that device, because "thousands of random people seeing it" means it is not private, by definition. Sure, you can run Signal on that device, and it does actually run sound E2EE maths. But it is not an "end-to-end encrypted deployment", it is a public deployment that happens to be running E2EE cryptography.
What I say is that running E2EE in a browser has that kind of nuance (as far as the comparison goes, obviously). In that the browser is indeed running E2EE cryptography, but it is not an "end-to-end encrypted deployment", because the user has to trust the server.
> This is not a coherent segmentation for whether E2EE is possible and engaged.
I would argue that it is. Just like E2EE is not "possible and engaged" on the skyscraped in Manhattan, I argue that it cannot be in a browser. The browser is running sound cryptographic code, but what the user gets is not an end-to-end encrypted experience.
perching_aix 2 hours ago
That "trusting the code that runs in your browser when you load the website of a messaging webapp to actually facilitate E2EE" is out of scope for the question "is E2EE in a browser possible".
> I would argue that it is.
This is what I very directly disagree with. In both your Manhattan example, your browser example, or in my very own shoulder surfing example, it's not that E2EE isn't in place, it's that it is rendered useless by the circumstances. That is a distinct matter. The same applies to your heavily audited, reproducibly built, hash and signature checked, native, installed application. Worth jack if your phone itself, or the virtual keyboard you're typing on, etc, is compromised.
If this is how you segment things, E2EE cannot exist, hence why this is an incoherent segmentation; it selects for nothing that can actually exist, the label never truly applies. It's a category mistake.
g-b-r an hour ago
palata 4 minutes ago
Agree to disagree, I guess.
But I feel like you are just nitpicking on the wording. When I say "you cannot have E2EE in the browser", I mean "you don't get what you expect if you expect that you don't have to trust the server". And the reason I say it is that many products advertise themselves as "E2EE", and many users believe that what they get from it is that they don't have to trust the server.
So I feel like the message I am trying to convey is "be careful people, you get less security than you think".
Similarly, I feel like the message you are trying to convey is "your wording is subpar". Sure, I'm not good with words, and I'm usually not taken seriously because of that. I am sorry about it. Story of my life :-).
olalonde 9 hours ago
thadt 7 hours ago
What you can’t do is make sure the server giving you the code that does the encryption doesn’t change it out with code that also sends your secret messages to Siberia. Unless you control the server giving you the web page. And you trust DNS.
At that point your trust model is simpler with an auditable local application. It could even be an Electron app - so almost exactly doing E2EE in the ‘browser’.
johnecheck 7 hours ago
If your thought is just "disable automatic updates", there's no reason you couldn't do the same by declining new versions of a web app. Unless you built it yourself (as a web app or native app), you need to include the servers and DNS in your trust model.
To me, it seems entirely isomorphic. The only material difference I see is whether automatic updates are on by default (an OS/browser vendor issue, not anything inherent to the tech).
Perseids 7 hours ago
Mostly. But the alternative shouldn't be a native app that updates itself, but rather a native app that is updated by a package manager. The big difference is traceability and auditability: With a trusted package manager (and even in good app stores) the company can only decide to push an update to everyone or to no-one. There is no way to push an update just to the pesky journalist or whistle blower. A covert attack is really hard to accomplish this way.
palata 5 hours ago
* The cryptography must be sound. That's the obvious one, if it's not encrypted then it's not "end-to-end" encrypted.
* There must be a practical way for the user to "verify" (with some definition of verifying) the client they are running.
A web browser doesn't provide that at all. It does not mean that everything else provides it: there are many ways to provide a Desktop app that break E2EE, but that is a different discussion. My point is that fundamentally, the web browser does not provide that. It's not that the laws of physics prevent it, it's just that the web browser never chose to provide that.
thadt 5 hours ago
Yes, this exactly. If we wanted ‘verifiable’ app distribution via browser, then we’d need browsers to implement some way to cross check the code downloaded vs a publicly published list somewhere - similar to certificate transparency or what WhatsApp is trying to do with an extension [1]. Without that, web apps are left working with a weaker threat model.
[1] https://engineering.fb.com/2022/03/10/security/code-verify
palata 3 hours ago
> or what WhatsApp is trying to do with an extension
I remember looking into it, and while it is interesting, I think what it allows to verify is that the intermediary (Cloudflare, I believe) didn't tamper with the code being served. Which in the end allows the user to verify that the code they run comes... from the server they trust.
And even that is not super practical, I find.
g-b-r 2 hours ago
palata 2 hours ago
I am not trying to say "browsers should not exist, everything should be a desktop app". I guess I am more defending "some use-cases work better in a browser, others work better as desktop apps". And I have the strong feeling that over the last years (decades?) there has been a very strong push by web people to say "everything should run in the browser".
g-b-r an hour ago
A browser allows you to run an app on any device (to a degree), so it definetely seems useful to me.
I'm actually not a fan of web apps, JavaScript and anything that came after XHTML, but it sure is/would be convenient to be able to run the same software on every device, without even having to recompile it.
The single reason I dislike browser "apps" is what we've been discussing here, that you can't check what you're running (well, also that it's hard to control their internet access).
palata 10 minutes ago
Same here, I personally like to load "websites" in my browser, and to download "apps"... like as "desktop apps".
> but it sure is/would be convenient to be able to run the same software on every device
Oh yeah that's for sure. I can't help but to think that with a fraction of the resources that went into supporting webapps in browsers, it could have improved native systems a lot.
But even then, Kotlin MultiPlatform (KMP) is making me optimistic. With Compose MultiPlatform (CMP) I am hoping that it will make its way to desktop apps, too.
> without even having to recompile it.
If recompiling is the price to pay to have diversity, I'm fine with it. If 100% of the computers ran the exact same OS, it would simplify many things, but that one OS would certainly not be what I want to run.
> The single reason I dislike browser "apps" is what we've been discussing here, that you can't check what you're running (well, also that it's hard to control their internet access).
I dislike the fact that they force me to have a modern browser at all. I like having control over my OS, it's not for being forced to run everything in Google Chrome.
wat10000 6 hours ago
App updates can be cryptographically signed with a key that’s kept offline and only held by a few people. Your trust in the app can be equal to your trust in those people, multiplied by your trust in the technology that keeps those offline keys safe from compromise.
Your trust in a web app will be equal to your trust in the people running the server multiplied by your trust that the server isn’t compromised. Since the server is necessarily always online, that trust will be much lower.
palata 6 hours ago
It's not, I don't think so. For instance, if you install Signal on your Android, the apk was signed by Signal, sent to Google and distributed by Google. Google cannot modify it, because Signal has to sign it. So in order to make you install a "malevolent" version of Signal, Google has to collude with Signal.
Of course you can download and install the apk from Signal's website, in which case Signal may give you personally a malevolent version. But you can easily compare that file to someone else's. On Android there are verifier apps that allow you to check that.
Finally if E2EE does matter a lot to you, you can compile Signal yourself from the sources, and even go as far as auditing those sources yourself.
You don't get to do any of that on the web. When you load ProtonMail in your browser, you don't have any practical way to verify that the code your browser is running is the same as everybody else who is running it around that time. You have to trust Proton that they give you code that prevents them from reading your emails. It is better than nothing or course, but it still means that you have to trust Proton.
GoblinSlayer 2 hours ago
g-b-r an hour ago
I'd stress that for specifically Signal this seems to indeed still be true, but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them), and even customized by Google for your specific system.
Google requires it for all apps created after August 2021. *
---
> On Android there are verifier apps that allow you to check that.
If you mean Accrescent, it only checks the app's signature, not the hash of the individual versions.
I only know APK redistributors such as apkmirror that might let you check the individual app version, but they don't have API access and only host some apps.
And again, now almost apps on Google Play are signed by Google and customized on the fly for your device, so you typically can't really confront them.
---
* Except that apparently, since a couple months ago Google allows you to use their HSMs?
Even this magnanimous concession though is “strictly for enterprise organizations with mandatory compliance, regulatory, or policy requirements to retain key custody in an external Google Cloud KMS instance” (https://developers.google.com/android-publisher/api-ref/rest...).
There's some chance that they can't access these keys; but the app needs to be compiled on their servers, so yeah, plenty of ways for them to meddle with it, and probably even to issue signing requests.
This seems to have been introduced in July, it's the first time I hear of it
palata 18 minutes ago
Yes! Google's goddamn "bundles" seem to be enforced to everybody. I guess part of Google "not being evil" and all. Another reason why initiatives like EU's Digital Markets Act are needed, I guess.
And yet another reason to use GrapheneOS, of course.
> If you mean Accrescent, it only checks the app's signature, not the hash of the individual versions.
No, there is an app called "AppVerifier" actually. That's the one I meant.
g-b-r 2 hours ago
Inconvenient truth, but it is so to a degree. I am disturbed by the lack of attention to that by many security gurus.
One difference is that with web apps you're practically updating them every single time you launch them.
palata 5 hours ago
Of course it's not black or white, security is a gradient. But if you want to check today that you are running the legit client of ProtonMail in your browser, you do not have a practical way to do it. It is theoretically feasible, I guess (?), but far from practical. But I can walk you through the steps needed to do it today with Signal, for instance.
I think I put my limit there: it's not enough to run cryptography. Verifying the client has to be practical for the user. The way ProtonMail works in the browser is a nice way for Proton to minimise the data they collect, but it's not E2EE, because even as an advanced user I cannot practically verify the client they serve me. In other words, E2EE means (to me) that there can be some kind of guarantee if you put a reasonable amount of effort into verifying it. The browser doesn't provide that at all.
Interestingly, shipping a webapp in ElectronJS (which is terrible in terms of software, IMO) is different: you can have E2EE in an ElectronJS app.
And I'm assuming that's why Signal has a Desktop app (which I believe is ElectronJS) and not a web (as in, "loads in the browser") version.
emilfihlman 7 hours ago
I'm going to go out on a limb and say that it is on purpose, and not a good purpose. The trust model of the web is fundamentally broken.
palata 6 hours ago
IMHO, the web should be to load websites (obviously) and small webapps that don't require E2EE or any kind of auditing. As soon as those are desirable, it shouldn't be a webapp anymore.
I find it nice to be able to load websites in my browser, instead of installing one program per website.
But sometimes I want a program.
prophesi 10 hours ago
usr1106 16 hours ago
iririririr 16 hours ago
one long time Firefox contributor have been for a couple years now removing every part of the --noremote option. even botching (Ooops!) the console notice that the flag was no-op some time ago.
yjftsjthsd-h 15 hours ago
What's this now? I'm using that to handle multiple profiles and haven't noticed anything breaking
iririririr 3 hours ago
try it, start with --noremote. you will get the vulnerable rpc/dbus listener. start another "firefox --noremote https://example.com" and it will open on the previous process. ha!
yeah, and you never got a warning about that option going way uh? that's why I'm 80% sure it was malicious. too many convenient mistakes.
lxgr 14 hours ago
g-b-r 12 hours ago
Telegram wanting to be single instance means that it has to use some serialization, and it not escaping semicolons enables a part of the attack.
lxgr 12 hours ago
g-b-r 12 hours ago
And if you open a Telegram link it will open in the existing instance.
Windows uri handlers actually always create a new process, though; so if you want this single instance behavior, you have to do some check at the start of the process and communicate the uri to the previously running process (as explained in the article).
iririririr 3 hours ago
so why answer?
g-b-r 29 minutes ago
iririririr 3 hours ago
this is the pattern that was abuses in the telegram hack. and this is what security conscious people implemented --notemote in firefox to close this vector. which is gone.
g-b-r 35 minutes ago
If you only want to make a software single-instance, you typically simply use a named mutex on Windows.
In general it only requires *a way* of communicating *some* information, not to "fully control" the other process or to have a port open.
What was abused in the Telegram hack is a hidden feature that shouldn't have existed, and it was even only vulnerable because of a lack of escaping.
freebsd_lovefes 15 hours ago
usr1106 15 hours ago
bmacho 12 hours ago
jcul 8 hours ago
Not sure how that partitions the files on disk though, would probably need some code changes to work with some kind of firejail setup.
fsflover 10 hours ago
This is seamless on Qubes OS: You just click a link and a new empty VM with Firefox opens. You close the browser, and the VM is destroyed. Can't recommend it enough.
eddythompson80 8 hours ago
fsflover 3 hours ago
[0] https://forum.qubes-os.org/t/qsb-116-multiple-xen-issues-xsa...
barrkel 15 hours ago
usr1106 15 hours ago
I used to use Cookie Auto Delete for years. But when I last checked it seemed unmaintained. I log out of all somewhat important services anyway every time I am done.
For important stuff like banking I use Firefox containers.
Yeah, all of them could have their weaknesses and vulnerabilities. I just hope no attacker hits exactly the stack I use...
eddythompson80 14 hours ago
ShinyLeftPad 12 hours ago
crossroadsguy 9 hours ago
By the way, they don't have just one web apps. They have A, they have K, and apparently a Z – subdomain is webz, or maybe that's actaully A. Not sure.
maqp 15 hours ago
lifeisloving 15 hours ago
Seems like many people do this when it comes to russian tech. Im American and I certainly trust my data in the hands of a foriegn government/entity (which is not even the case for telegram), than my own. Even if it was a russian op (its not the Ukrainian military literally used telegram for years), the russian government cant touch me.
ornornor 14 hours ago
snek_case 9 hours ago
bluebarbet 8 hours ago
dylan604 7 hours ago
writtenone 7 hours ago
Lots of people follow channels for on the ground news reporting, especially since it's not censored or "advertiser friendly" like social media companies are incentivised to be.
Zancarius 4 hours ago
My Bible study class has grown enough that standard SMS/MMS group texts are hitting up against Verizon's carrier limit (I think we have only two people who use Verizon), and RCS isn't an option. Telegram wasn't my first choice, but it was a lot easier for everyone, and it supports tablets out-of-the-box.
fsflover 2 hours ago
writtenone 31 minutes ago
1. You must join a group to see its contents. This puts a stupid "{user} joined the room" message in the room for everyone to see. Channel membership is anonymous.
2. Channels generate a public feed that doesn't require any special software to read from (see Durov: https://t.me/s/durov). Matrix requires a client of some kind, all clients are clunky at best and none have a public view.
3. Channels support millions of readers. Matrix rooms literally cannot do this, and rooms frequently get out of sync due to federation.
g-b-r 43 minutes ago
ufmace 3 hours ago
It also has way more security features too, such as the ability for any session to de-auth any other session, while on Signal, only one mobile device is your "primary", so you're screwed if you lose that. Also tons of detailed permissions for who is allowed to see what information of yours and add you to groups. The only thing Signal actually does better is E2EE for groups. I think it's simplistic and short-sighted that many tech people seem to think that "security" means E2EE and absolutely nothing else.
maqp an hour ago
Except when you enable E2EE, you lose a lot of the features like stickers.
Also, enabling E2EE manually leaks additional metadata about intent to hide content from the service provider. That's insanely valuable even if you can't see the content.
Telegram treats E2EE like a door wreath hung from a nail. Practically all private messengers like Signal treat it like the foundations of the building.
>much better behavior for large groups
Telegram leaks a group as large as the size of 3 members, to the server, always, with ZERO way to opt-out. That's not better behavior. Whatever seasoning you apply on top of a turd, won't change what you're eating.
>far more sophisticated and granular permissions system for admins in groups
Yeah when you remove the "server has no ability to control the group" security feature you can do all sorts of things really easily.
>It also has way more security features too, such as the ability for any session to de-auth any other session
Way more in this case is clearly one. And this is a trade-off. Any of your devices gets stolen and the attacker can lock you out.
>so you're screwed if you lose that.
No you can keep backups in the cloud these days to recover your account. Unlike Telegram, the backups are actually encrypted so that the service provider can't read them.
>Also tons of detailed permissions for who is allowed to see what information of yours and add you to groups.
You mean, it allows you to control to whom the service provider yields the data. But the main privacy issue with Facebook, Telegram and any other surveillance capitalistic platform is the service provider. And Telegram isn't fixing Telegram learning everything about you.
>The only thing Signal actually does better is E2EE for groups.
Signal does EVERY thing better because every feature is private by design. Even if there's UX stuff to fix. You wouldn't claim some Trojan horse malware is really good because the game crack works and you can play a 30 dollar game while it steals your entire digital life or demands random or whatever.
>I think it's simplistic and short-sighted that many tech people seem to think that "security" means E2EE and absolutely nothing else.
In private messaging apps security begins with E2EE. Then you add tons of other features, like forward secrecy (Signal does it better than Telegram), future secrecy (Signal does it better than Telegram), Post-quantum security (Signal has it and Telegram doesn't), cross-platform messages usage (Telegram has no cross-platform E2EE), default security (Telegram has none), and that's just content. There's much more private tools for metadata protection, and on top of that you have advanced issues like endpoint security to deal with. E2EE is the bare minimum for e.g. PrivacyGuides app recommendations, and Telegram can't even cross that bar.
g-b-r an hour ago
> Telegram has no cross-platform E2EE
If you mean between an Android and an Apple device, that is supported, to my knowledge.
Telegram's E2EE is acceptable only for limited use cases, though, it's crippled beyond belief.
maqp 13 minutes ago
When you can't continue the secret chat on your desktop device, you'll eventually get tired of having to dig your phone from your phone, unlock it, open telegram, navigate to chat, reply, lock phone, put it back to pocket continue work; the alternative of ditching security and just alt-tabbing to insecure chat on desktop client wins.
This is what a modern backdoor would look like. Vendor can't be blamed about introducing a backdoor, when using the backdoor feature is your own fault.
And this is just DMs where E2EE is possible in the first place.
g-b-r 14 hours ago
Anyhow, people don't write off Telegram because it's Russian, but for many legitimate reasons.
There are indications that it could be much closer to the Russian government than they pretend, but that matters not because Russians are bad people, but because the current government of Russia is an aggressive dictatorship.
The Ukrainian military literally used Telegram for years and now literally banned it.
Maybe in part for this Ukrainian article: https://texty.org.ua/articles/112347/eight-signsof-danger-te...
lxgr 14 hours ago
Even assuming they are fully legitimate today, if this ever changes and somebody gets access to their infrastructure, they immediately get a treasure trove of historical messages.
maqp an hour ago
feelamee 13 hours ago
> There are indications that it could be much closer to the Russian government than they pretend
Can you give more details, please? I'm using telegram a lot and want to know if there is something...
g-b-r 12 hours ago
maqp an hour ago
https://kyivindependent.com/kremlingram-investigation-durov/
despite endless claims he's in exile
lifeisloving 12 hours ago
ShinyLeftPad 12 hours ago
maqp an hour ago
So I'm just gonna assume you work for Internet Research Agency and tell you to maybe bugger off.
maqp 2 hours ago
That's fine. I write it off because it by default leaks all of your content and metadata to the server, and then I ask why, and who is learning all that information and I do not like the answer.
>Seems like many people do this when it comes to russian tech
Yeah as a Finn it's not very hard to distrust Russia.
> Even if it was a russian op (its not the Ukrainian military literally used telegram for years)
You didn't prove anything with this, if anything, the fact that Ukraine banned using Telegram on the state officials devices, speaks the exact opposite: https://www.bbc.com/news/articles/c78dwepw95do
>the russian government cant touch me
If it's a Russian op, they're collecting your entire life, your political opinions, your relationship issues, everything, in search of kompromat that they'd use to coerce you during recruiting.
Kinrany an hour ago
As a Telegram user, my current impression of the platform is that they are a tiny elite team, they focus very heavily on creating a polished product, and are somewhat arrogant about all of that.
The most common criticism that I see and understand is the lack of E2EE by default. But I'm not aware of a messenger that provides a good UX for that. For most people, losing access to the account is a much greater risk. (The trade-off has changed somewhat now that everyone is getting hacked by AI and thus Telegram's whole dataset leaking becomes a concern.)
The criticism that I agree the most with is phone numbers being used for authentication. Even if Telegram still wants to know everyone's phone numbers for growth reasons, as far as I'm aware for authn phone numbers are strictly worse than emails.
On the positive side, they still have a proper API, open source their clients and allow third-party clients. All of which seem non-optional for any messenger that claims to prioritize security.
g-b-r 19 minutes ago
> open source
I'd just stress that at least for the Telegram client it's open source with some degree of quoting: the real git history is not shared (each release typically consists of a single huge commit), and the source is often published weeks after a release of the official client.
The server is also not open source, but that's not very relevant for security.
Narushia 11 hours ago
xg15 11 hours ago
You wouldn't ignore a zero-day announcement either because the formatting is ugly.
jcul 8 hours ago
I did skim over the important bits though.
xg15 7 hours ago
victor_pudeyev 6 hours ago
g-b-r 26 minutes ago
Panzerschrek 17 hours ago
g-b-r 17 hours ago
Not all user processes upload those files somewhere surreptitiously.
Of course operating systems should support that isolation (hopefully in some better way than the hell that smartphones are), but it's not like Telegram can blame the OS for this vulnerability.
Panzerschrek 16 hours ago
Only if you have access to full source code, can audit it (including each update) and somehow can prove that it has no vulnerabilities. Otherwise one should assume that any application is potentially-harmful and/or vulnerable.
g-b-r 16 hours ago
yjftsjthsd-h 15 hours ago
nvme0n1p1 16 hours ago
Panzerschrek 16 hours ago
eviks 16 hours ago
penskymaterial 16 hours ago
Uhm, OpenBSD would like a word, buddy.
yjftsjthsd-h 8 hours ago
ptidhomme 8 hours ago
ciupicri 7 hours ago
[1]: https://github.com/containers/bubblewrap#usage
[2]: https://man.archlinux.org/man/bwrap.1
[3]: https://wiki.archlinux.org/title/Bubblewrap#Usage_examples
[4]: https://wiki.archlinux.org/title/Bubblewrap/Examples#p7zip
saagarjha 16 hours ago
zorked 15 hours ago
Saris 10 hours ago
gvfsa 14 hours ago
saagarjha 13 hours ago
ubercow13 11 hours ago
lxgr 13 hours ago
simonra 16 hours ago
lxgr 14 hours ago
debazel 10 hours ago
lxgr 9 hours ago
yjftsjthsd-h 15 hours ago
No, it's definitely a Telegram specific vulnerability. It might be worse because of poor defense in depth, but without Telegram itself being vulnerable it wouldn't matter.
nottorp 15 hours ago
So how will you spam all the group chats you're on with meme gifs downloaded from facebook then? :)
Panzerschrek 14 hours ago
The file-manger application managed above is a single point of failure, of course. So, it should be allowed to use only one provided by OS vendor.
lukan 12 hours ago
There is a lot of middle ground, like having a shared folder for access. "Downloads" might be a good default, if clearly communicated, that anything in there, is accessible by any app.
yjftsjthsd-h 8 hours ago
lxgr 14 hours ago
Does Telegram do that, or do they consider themselves beyond bugs, just like they consider themselves too clever and untouchable by anyone to need end-to-end encryption?
ShinyLeftPad 12 hours ago
not true on macos.
BoppreH 12 hours ago
lostmsu 10 hours ago
alt227 11 hours ago
parampampam 7 hours ago
miohtama 10 hours ago
parampampam 7 hours ago
robertlane0 6 hours ago
RachelF 12 hours ago
Reported 25 June
Fixed 16 September
I wonder why it took them so long?
k__ 12 hours ago
miohtama 10 hours ago
erelong 17 hours ago
Like any number of articles like this: https://hackernoon.com/7-reason-why-telegram-is-insecure-by-...
g-b-r 17 hours ago
A file exfiltration vulnerability is still noteworthy.
phoronixrly 16 hours ago
The Most Backdoor-Looking Bug I’ve Ever Seen - https://words.filippo.io/telegram-ecdh/
misiek08 15 hours ago
And yes, I know that by default chats are not E2E, that phone number has way too many effects on accounts etc. Still, UX and agencies interested in important people are more welcome than data selling, ad-based companies.
maqp 15 hours ago
Yeah same can be said for Facebook and WhatsApp that Durov vehemently claims should not be trusted with user's data. Maybe it's a ploy for the Mark Zuckerberg of Russia to get the data of people.
Also, Telegram doesn't have to sell it's users if it's an FSB honeypot.
mschuster91 13 hours ago
tannertech 11 hours ago
mschuster91 8 hours ago
maqp an hour ago
lxgr 13 hours ago
And what UX problems exactly is Telegram solving that its many competitors aren’t? I hear this all the time, but I use both Telegram and WhatsApp and I haven’t found anything lacking in the latter, UX wise.
maxgashkov 12 hours ago
I'm sorry if I'll sound condescending, but you probably don't use either frequently enough. With telegram it's the little (and sometimes not so little) things, e.g.:
- voice message transcription
- you can select part of the message via long-press and use it as a quote when responding
- massively more complex formatting possible
- bots as the first class citizens not gated behind some bullshit 'Business' KYC/subscription
- is not crippled by prohibiting system-level phonebook access like whatsapp
- extreme flexibility in managing large groups, mostly due to the bot point above
- and many more
All of the above does not excuse lack of e2e by default, this is almost embarrassing in 2026 now, but Telegram is the most polished IM experience of all the apps I have tried.lxgr 12 hours ago
Bot access is definitely better in Telegram; that’s what I sometimes use it for.
WhatsApp has voice message transcription now, but fortunately I don’t receive many. (I consider it pretty rude to put the effort of messaging on the recipient because the sender can’t be bothered to type or transcribe on their side.)
Everything else you mentioned is a minor inconvenience to me. Knowing the provider can’t mine my message data more than makes up for that.
skeledrew 10 hours ago
zahrevsky 9 hours ago
Kinrany an hour ago
TZubiri 15 hours ago
lukan 12 hours ago
It mainly competes against facebook and other social media plattforms. The privacy is clearly wrong and only believed by non technical people (which can be amusing, when on TG someone posts a link to FB, or a WhatsApp group and people chime in and lecturing others that they should not use that as it is insecure and owned by a big company who will sell them out).
thenthenthen 9 hours ago
lxgr 13 hours ago
itsmeduncan 6 hours ago
wrcoro 11 hours ago
[1] https://github.com/marcovelon/tdesktop/blob/NoSecretChats/RE...
fsflover 10 hours ago
Cider9986 8 hours ago
g-b-r 19 hours ago
This aspect is also not highlighted much in the article, which weirdly mostly focuses on the account takeover.
To me it seems something remarkable enough to warrant reposting the link with a different title.
Somewhat astonishingly, the core of the vulnerability comes from an internal url scheme added to Telegram to... help them publish their releases on their channel.
The Telegram developers saw no better way to do that than adding an internal tool which uploads any file it's told to.
Everyone else publishing their app on Telegram is able to do that with a script, but they had to do it that way.
It's true that it was exploitable only in a somewhat convoluted way, but still, it's an obviously dangerous feature.
Anyhow, yes, clicking on a link in Telegram Desktop was enough to have any user's file exfiltrated and to access or take over their account.
arjie 16 hours ago
skeledrew 10 hours ago
sehw 6 hours ago
opengrass 17 hours ago
g-b-r 16 hours ago
anon_cow1111 16 hours ago
Last I checked, that's exactly how Telegram works by default. It's laughable to consider a service tied to a phone number secure.
msh 15 hours ago
sunaookami 13 hours ago
anon_cow1111 9 hours ago
That still means you have to check it every 7 days.
sunaookami 2 hours ago
syngrog66 10 hours ago
KingOfCoders 17 hours ago
iririririr 16 hours ago
technically, this is one agency burning the feature of another agency.
maqp 15 hours ago
iririririr 3 hours ago
yeah fsb et al have access to what you post, but they also had access to any file you Don't post. Which was the feature they closed now.
buckle8017 10 hours ago
ramesh31 6 hours ago
maqp an hour ago
With Telegram it is very easy: NOTHING is end-to-end encrypted by defaults, and group / desktop chats can't be end-to-end encrypted. So operating a honeypot server that gets access to billion users' data, is the most obvious honeypot out there.
colordrops 15 hours ago
hulitu 12 hours ago
Wait till they find out about web browsers. /s