I wouldn't mind, but there needs to be a way to remove the "training wheels".
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.
These days, most things that I run that aren't from my distro's repos get their own bubblewrap. On top of this, I use opensnitch. Even if I trust the application (uncommon), I never trust npm, pypi, etc. any longer. It's tedious to set this up and OSes should be helping make this easy.
The problem is, peoples files are too valuable - even to the OS vendors - and also, there are simply too many valuable people on the Internet without the willpower to know how to manage their own filesystem.
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?
Among the old school desktop OSes it's one of the better options, but it still has a long way to go compared to mobile OSes.
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.
Not if I have anything to say about it. I want programs on my computing device to be able to access files and roam the internet at free will. In fact, I insist on it.
Agreed. I mean, AppArmor and SELinux exist to control file access, perhaps OSes should put more effort into user-friendly overlays to control processes and have audits to warn users when a piece of software has full system access.
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.
One of the challenges with Telegram is - they regularly re-enable settings inside the app/account that you had specifically disabled. So at any point you don't know what is happening and what is not. Meaning, even if you didn't see a thing, a malicious file might be sitting all warm and fuzzy on your computer - among possible other things. I used to like the snappiness of this app (and it is still snappier than almost all other IM apps combined, by a margin), but after a while I realised it was a ticking time-bomb (to keep it installed on the desktop) and possibly a scammer safe haven, nothing else.
A lot of companies do this but I always get a ton of hate for saying this: Telegram is the worst offender I've seen. If you start digging through their apps, you see a ton of security practices that are anything but secure. And one of the hundreds of reasons I treat Telegram as the plague: get it away from me and burn it with fire.
Maybe that's regional but here in Spain it's very popular for clubs. We use it for our makerspace and also for several other clubs. The moderation and access tools are way better than WhatsApp's.
It's not end to end encrypted but for big group channels that anyone can join that doesn't really matter.
Here it's all WhatsApp and Telegram. iMessage isn't really a thing at all except for expats.
My family uses it to communicate on devices that don't support iMessage (mainly Windows and Linux installs) because it's one of the precious few cross-platform messengers that doesn't treat desktop users as second class or as an afterthought.
Signal is legit. The entire stack is open source, and messages are E2EE.
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.
The phone number is only required to create an account, and is never used again IIRC. The rationale for it was to prevent abuse/spam, but I believe there is now an option to purchase an account for a small fee without needing a phone number.
Purchase can be done only through Apple/Google Pay which require a phone number and a bank card on top of that. Do not be deceived by marketing people.
There's a few communities that use Telegram because it seems to be one of the few that is both generally usable by the average person and by default has at least a little respect for separating your online identity from your real life identity. Which is sad because I agree it's a bit of a dumpster fire when it comes to security and privacy beyond that.
All big companies pull these kind of tricks. Another variation is to retire the old setting and introduce a new one with a deceptive name that is default on again.
Can you please tell me what settings get auto re-enabled? I use Telegram as my primary messenger app. I just want to make a more informed decision if I should switch to Signal or something.
Note there’s no info on that page on which settings get reenabled, only general list of grievances with telegram, mainly from a privacy/security perspective.
Is not Signal inferior? In Telegram you can communicate with strangers without disclosing a phone number, in Western messengers until recently you had to disclose it so that your contacts can conveniently find you and punch you in the face if you are a man or just annoy you with indecent messages if you are a woman (probably not scary in a country where everyone has a gun and every home is a castle, but not all world is like this). What Western genius thought of such a feature, displaying a phone number in a group chat?
Telegram also allows to delete any chat in one click. Telegram has support for HTTP, SOCKS, MTPROTO and WEB proxies to evade censorship, Western messengers do not. Telegram is written in C++. Although it is a piece of proprietary garbage and might be connected to the government, at least it is well made piece.
Also it became difficult to register in Telegram, it often asks for 1 euro when trying to register with a fake number. And with a real number the OTP code simply doesn't get delivered to Russia.
I am not sure what you mean by "Western messengers" exactly. If it's Whatsapp, then I don't think it's any better than Telegram, even though Whatsapp claims to provide E2EE. The entire stack is closed source, and in any case it leaks huge amounts of metadata.
And no, Signal is not inferior. If you are really concerned about the phone number issue, use a burner eSIM or purchase a Signal account. Last time I checked though, payment was tied to Apple/Google, inexplicably.
> What Western genius thought of such a feature, displaying a phone number in a group chat?
Well, most of those apps try to inject themselves in between you and the rest of the world, by "helpfully" offering to be your SMS handler and phone call replacement.
In the distant past this meant more. Vendors shipped one option for everyone. Now with things like A/B testing and other application 'smart' behavior which ends up meaning we all have different experiences.
Flatpak has "classic mode" which means no sandbox, which you will never guess if you did not read the docs, because why tell the users the truth when you can use marketing speak. Also, Flatpak allows reading identifiers from /proc and /sys.
Not on Linux. But if that is a safe variant then yeah great. Also, I see https://flatpak.org (is this the one you meant?) has Telegram has one of the showcases apps on the homepage so I guess they would have done their due dilligence.
Yes. I'm constantly annoyed by the dark patterns Zoom and Slack use to trick you into downloading their desktop apps. The web experience is practically indistinguishable and much more secure.
> The web experience is practically indistinguishable
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.
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.
Not OP, but: You can definitely do encryption in the browser, no problem.
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’.
Theoretically you can download a single HTML file and open it in the browser. However many web features require HTTPS (including JS Modules, yes) so this would be poor developer experience. I want to write simple apps and prototypes in local HTML files but W3C does not let me.
I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
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).
> Isn't this the exact same security posture as a native app with automatic updates turned on?
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.
> 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
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
> but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them),
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.
> I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
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.
* 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.
> it's just that the web browser never chose to provide that.
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.
> 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.
It would, but at this point, do you need a browser really? Like the big advantage of the web is that users load the latest version of whatever you serve, and they don't have to care about updates. In many cases that's desirable. But it fundamentally doesn't work for E2EE.
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".
I wouldn't really say that the advantage of the web is that users load the latest version, there's plenty other real advantages of the web.
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).
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.
> I dislike the fact that they force me to have a modern browser at all
Yeah that's true
> 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
I personally hate Kotlin, but yeah it's one more option ;)
It depends on how the automatic updates are handled.
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.
E2EE fundamentally exists for situations where we don't want to trust the server. That's the whole idea of E2EE, right?
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.
Because when you load a page in your browser, you fundamentally trust that the server is giving you what you expect. And the whole point of end-to-end encryption is that you don't trust the server.
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.
Whether E2EE is implementable or operational has nothing to do with whether you trust the code to actually facilitate it. E2EE can also be trivially circumvented by someone looking over your shoulder. This is not a coherent segmentation for whether E2EE is possible and engaged.
I am not sure what you are trying to say. Let me try an example.
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.
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.
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, I'm used to it :-). I just wish eloquent people used their skill to help me convey my point (if they agree with me, obviously) rather than to make it sound like my point is worthless.
In a sense I am. We kind of both are, I'd say, for reasons we each think are important.
For example:
- you may wish to protect the trust in / reputation of E2EE, and so you might gonna have an axe to grind with in-browser implementations, and thus you may feel compelled to segment this subject accordingly
- I kind of have an axe to grind with E2EE exactly because of how little it can actually guarantee to begin with, so rather than protecting the trust and reputation of E2EE, I feel drawn to correct the popular record, and spread the word about the very serious limitations of this thing, making me segment accordingly (although I do think that even beyond this, I am right to bikeshed this)
I'm speculating on your part obviously, though not on mine. I think of E2EE as a bare minimum, not something to be particularly proud of and market, and the more I learn about how we secure our devices over the years and decades, the more distraught I feel about these technological measures. It's a lot more smoke than fire.
At the same time, I could also apologize for the bikeshedding, but then I'd hope it's clear that it's not like I did it to annoy you or anything, I just have a different perspective, and find different things salient. What's a perfectly acceptable and even a justified high level categorization to you, is a bending-of-reality category error for me, and vice versa. Happens when people from arbitrarily different walks of lives from arbitrarily different points in their life cross paths. No way around it as far I'm aware, and it's not like I don't see your point either. Like yes, loading up a random website is obviously way more of a gamble than pulling up an app you may very well even manually update biweekly, no doubt about it. It's just a difference in the overarching narrative suggested that I'm hung up on.
> I kind of have an axe to grind with E2EE exactly because of how little it can actually guarantee to begin with
Well then I think this is just wrong. If you do E2EE right, then you have the guarantee that no one in the middle (including the server) can read the data. It does have value, and saying "anyway cryptography is worthless because everything can be hacked" is not a productive argument IMO. Some people do rely on it, and it is important that those people understand when they can and when they cannot.
I don't really care so much about nomenclature and categorisation. I care about the fact that people who need it must understand when they can rely on it. And nitpicking on the wording is not making it clearer for them.
See, perspectives. ¯\_(ツ)_/¯ Ensuring that people have the right idea is why I do care about correct categorization, attribution, and phrasing. People readily twist way clearer things than what you wrote.
E2EE can technically exist on a web app, but it would be stupid to rely on it, so, yeah, I'd just be careful when using the term for web apps, since you get something way less secure than what the term evokes.
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.
Don't let yourself be fooled into thinking this is enough. Plenty of examples of, especially through wasm, being able to reach far beyond what they're supposed to.
It gets buttoned up fast and is always getting better, but its absolutely not a silver bullet.
If you enable lockdown mode on your iPhone and Mac, WASM is disabled through Safari. If absolutely needed, an alternative browser like Firefox can be used for those sites.
Don't most things people use day-to-day for both work and entertainment require use of the actual app these days, or at least make it very difficult to do so?
Look at who is on the board of Dropbox and ask yourself what the value of a file syncing service having accessibility (and previously kernel extension) privileges on your machine are.
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.
I don't use Telegram Desktop or Windows. But that's exactly the reason why I run Firefox in a firejail sandbox on Linux. The browser has only access to my Downloads folder. I know that it's considered untrusted and don't keep any files there for a long time.
Is "firejail" a white list (only these things allowed) or black list solution (everything not explicitly disallowed is allowed)? I glanced through the issues and it seemed to me it is very hacky and feels amateur-ish and doesn't make me trust it, so I am starting writing my own, white-list based sandboxes. For example, No-net Sandbox will not allow a single packet out, including DNS query, unless allowed, Proc Sandbox will restrict access to /proc etc.
Or the reason to run Firefox in a FreeBSD jail to get server-grade security. But the question is can an attacker get access to the Firefox profile data? Because you cannot block that from Firefox, obviously.
Sure, to some degree you must trust your browser. In the extreme case you could open a new, non-persistent browser session for every page you visit. Could be slightly inconvenient...
> In the extreme case you could open a new, non-persistent browser session for every page you visit.
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.
You mean a website A can have login/auth cookies of website B, D, Z, HK… etc? SOP doesn't work? Or is there some sort of exploit on top of third party cookies? (Just curious. I don't know anout browser dev/etc).
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.
Yes, it has access to the internal storage mechanisms of the browser.
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...
Personally I only open Firefox on Linux booted from a read only usb. In theory there could be a firmware vulnerability in the CPU that could let it write persistent data to the UEFI firmware, but I hope the possibility is small.
I dont write off software because where the person that made it was born. I personally think thats the same thing as refusing to eat at a black owned resturaunt because of the owners skin color.
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.
Telegram is a double threat: the company is Russian and the founder was arrested then mysteriously released without any charges in France. Given why France wanted him and arrested him, the fact they released him a few days later with no charge annihilated the little shred of trust I had in this Russian piece of software, personally.
I don't know why anyone is using telegram when there is signal. Also with all the issues around telegram and their founder, you'd probably be safer using whatsapp even... :/
Telegram has way, way more features than Signal. First-class clients on every OS, much better behavior for large groups, far more sophisticated and granular permissions system for admins in groups, voice and video messages, folders for chats, etc.
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.
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.
>>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.
This may be clearer from a product point of view. Your apparent viewpoint, and that of Signal etc, seems to be that protection from the server (and admittedly whoever can coerce whoever owns the server) is the only thing that matters, no matter what other features you have to throw out to get it.
What I am calling out is that this is a fundamentally ideological point of view. You can believe that and act according to it if you want, but general readers should be aware of what they are losing in order to enact this ideology with benefits that seem to be a bit dubious in the real world.
It is well known that Meta is happy to hand over to any legitimate law enforcement agency any content they have. To the best of my knowledge, Telegram never has, and neither has Signal. The fact that Telegram potentially could someday seems more theoretical to me. Again, to the best of my knowledge, all actual leaks of messaging group content have been by various authorities compromising individual devices and/or their owners, which works equally well against Telegram and Signal.
Meanwhile, Telegram gives you a lot more practical security regarding what information to share with other users, and how to manage what other users can do in large chat groups, which seems like a much more real-world concern regarding actual dangers to users than what the company that owns it might potentially do at some future date.
I think for real security, it's better to pay attention to the business model of the company that runs it. Meta's business model is indeed to basically sell your data to advertisers. Telegram does not do this, and shows no signs of wanting to. Instead, you can pay for premium, and they allow advertising as messages in public channels, and they're doing some semi-dubious stuff with cryptocurrency. Signal seems a little weird, they are apparently funded by some sort of donations from unknown parties. It seems to work okay for now, I guess, but is their financial future any more secure?
>>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.
I wasn't talking about that, but about the ability to de-auth your mobile device (the one probably most likely to someday get lost) from another device, since no one device is the "primary". Yes, an attacker could potentially lock you out if they get into your Telegram on the compromised device before you get on one of your other devices. But on Signal, you're screwed if it's your mobile, and fine if it's any other device.
Though since you mentioned backups, I think Telegram's way is arguably more secure. Individual user backups, even encrypted, means all your communication security is at the mercy of whoever in your group has the weakest encryption keys and backup storage location. With a centralized system like Telegram, it's never anywhere but their servers.
No I mean between your smartphone and desktop clients.
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.
Telegram has channels, which are a one-to-many (thousands or millions of people) chat feature letting you have basically your own social feed.
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.
The onboarding experience with Telegram is extremely easy, which is useful when dealing with non-technical audiences who might not even have a social media account (but do have smart phones).
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.
No it doesn't. Matrix has large groups, but they are limited:
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.
Matrix clients do not allow to even select several messages to delete them at once. Matrix is a superior concept to proprietary Signal, Whatsapp, Telegram etc but the implementation needs some help yet and UI is far behind.
You're sure you're replying to the right message? It doesn't mention any country or nationality...
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.
The main reason I consider it suspicious is that they are so adamant about not needing end-to-end encryption.
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.
Telegram hoards messages of over 1,000,000,000 users as of now. Anyone not realizing major nation states have long since pwned the servers to spy on those users is a fool. Even if if the zero days cost 100 BILLION dollars, that access costs like 1-2 hours of intelligence contractor's hourly wage per target. The bang for buck is insane. Telegram is one of the world's biggest intelligence operations, wittingly, or unwittingly.
>I dont write off software because where the person that made it was born.
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.
interesting you mention. because Firefox doesn't have a way to disable the single instance functionality which was used on this telegram vulnerability.
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.
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.
being a single instance === having a port open somehow (firefox is dbus) that allows full control of the initial process under the assumption the user space is secure.
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.
That only one instance of Telegram can run at any time.
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).
Because I do know what this vulnerability was about, and it had nothing to do with Firefox (and I know that you specifically probably didn't mean that Firefox was involved, but even Telegram's desire to be single instance was not what caused the vulnerability).
I don't like Telegram and don't think it should be considered a "secure messenger" in the sense end-to-end encrypted messengers are, but I don't think there's all that much to learn from basic clientside coding failures like this. All applications have these kinds of bugs.
It's not strictly-speaking a Telegram-specific vulnerability. It's a vulnerability of all modern desktop operating systems allowing any user process to read/write any user file. Ideally all programs should be isolated from the underlying filesystem and be able to read only their own files and files from per-program data directory (like downloads for a browser or Telegram-client).
At the same time the mobile operating systems are vulnerable to vendor lock-in due to the absence of this functionality. It is clearly a worse problem that a user can't give their backup system access to the photos stored by other applications (often social media), or for instance reliably capture media streams to use in for instance a remixing application. Bringing custom clients when the software originally used to create the interesting files starts acting against the users by introducing subscriptions or being abandoned is another example of the user dictating what software accesses what files is critical to secure the users operations. Consumers need security against commercial interests infinitely much more than commercial interests need protections against consumers, and it would be unethical to enable commerce at the expense of individuals like the mobile operating systems do.
> It's not strictly-speaking a Telegram-specific vulnerability. It's a vulnerability of all modern desktop operating systems allowing any user process to read/write any user file.
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.
If you don't believe it's a vulnerability, then you must believe that tricking Telegram into uploading your messages database to the attacker, leaking all your private conversations, is A-OK? Telegram owns that file, after all.
I didn't say it's not a vulnerability. It is clearly one. But allowing such vulnerabilities to deal damage beyond data of its host application is an OS vulnerability.
Yes, and there are many ways for apps to opt into this, to limit their own blast radius in a case like this.
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?
That's broadly-speaking a vulnerable design of all OSes, but strictly speaking it is a bug in Telegram that is now fixed at the app level. Though sandboxes / app isolation solutions exist even in the broadly vulnerable OSes, so apps could use them already today to avoid such issues in the future?
Looking at the flatpak manifest it has `share=ipc` but no directories shared.. I'm not sure on flatpaks defaults for what it would actually have access to on the host.
> Ideally all programs should be isolated from the underlying filesystem and be able to read only their own files and files from per-program data directory
So how will you spam all the group chats you're on with meme gifs downloaded from facebook then? :)
Download an image from Facebook into browser's private downloads directory, copy it using a file-manager application (one of the exceptional applications having full filesystem access) into Telegram's private directory, upload it into chats you need to post it.
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.
Sounds like effort, people don't like effort when spreading memes, so would be enraged if this would be the default now, or nobody would activate it.
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.
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.
> Not all user processes upload those files somewhere surreptitiously.
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.
No, that kind of audit is neither necessary nor sufficient. (A firewall works without application source code, and trusting trust means we can hand wave anything even with source.)
Ok, at least if it has network access, but can you recognize that this was a vulnerability, and that you're talking of something only tangential to it?
> The primitive stays the same throughout: arbitrary file read. What changes is what you read: an SSH private key, a browser password store, a cloud credentials file, or a configuration holding an API token.
So in the hindsight it was a right thing for me to put it into a sandbox without any SSH keys and tokens. Also, I didn't bother registering tg:// scheme in the OS which also turned out to be good - clicking such a link in the browser does nothing for me, and as a side effect, websites cannot detect presence of Telegram or send command to it though registered scheme handler.
Also, I was surprised that Telegram uses passcode (an on-device password that is required to access the app) to encrypt user data. I thought they just keep the hash of a passcode and check it.
Also I assume Telegram can block this attack on the server, as groups are not E2EE and the server can find and delete files needed for successful exploitation. And links too. If someone has a spare account they can check if posting such type of files or links works.
When criticizing Telegram, I wish people focused on the actual smoking guns and didn't include random fluff one has to cut through.
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.
Signal's current UX seems pretty good to me, and it's not even that easy to lose the account
> open source
I'd just stress that at least for the Android 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.
> I'd just stress that at least for the Android 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.
One thing I don't know is whether these delayed source releases are enough to validate releases published to app stores. If they are, this means Telegram is building up reputation and would have to burn it to publish a release with a backdoor not present in the source.
The other thing this allows is for a third party to maintain a fork without having too much trouble keeping up with new features.
Telegram and security don't really belong in the same sentence anyways. Say what you will about Signal but they at least have better cryptography and more transparency about what software they're running.
Still we are using it, because UX kills any other app and people that are (probably) behind it will cause almost no harm to casual, not-interesting people :)
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.
What a bizarre threat model. Why would you rather have your data with who knows who than just your metadata?
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.
> and I haven’t found anything lacking in the latter, UX wise
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.
I use them daily, so we might just have different priorities.
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.
I lost access to my WhatsApp history multiple times. This never happened to me anywhere else. This is admittedly an example of WhatsApp UX being terrible, not Telegram UX being great.
For me it isn't the UX really. I was sold on it NOT being WhatsApp, etc, and then I stayed for the unlimited free storage for life (have a virtual FS built on it). Definitely ain't nobody else offering that.
"will cause almost no harm to casual, not-interesting people"
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.
Well, it makes sense from a threat modeling perspective. If you're Russian, you should use Whatsapp because it is unlikely Whatsapp will cooperate with the Russian dictatorship, but in Western countries, you can assume that anything from Meta, Google or Apple that's in any way useful (and even if it's just metadata) can and will end up in the data lakes at the NSA.
False dichotomy. Nobody's forcing you to use proprietary messaging app like WhatsApp in the West. FOSS tools like Signal are the norm in privacy circles.
Well for a Russian I think there's barely a chance that Russia manages to compromise any of the US giants at large scale, so Meta is a better choice than VK, Telegram or any of the Chinese services.
It was, but most people will believe what their peers (real or parasocial) say over the collective screams of every security researcher on the planet, so here we are.
It has this feature where it tells you about other users that are on the platform. I mean it's not a huge leak, but right off the bat it's pretty poor security posture. For an app that competes with other chat apps on supposedly being more secure and privacy aware, it does worse than whatsapp on that end.
"For an app that competes with other chat apps on supposedly being more secure and privacy aware"
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).
This!! Signal also had this back in the day, very bizarre for an app thats privacy focussed… sadly have to use it because some contacts refuse to use anything meta etc. Sadly it is only big corp stuff that works reliably where i am somehow..
Does its official desktop client support "Secret Chats" (E2EE) yet? Last time I used Telegram before moving to more reliable IM platforms that feature was officially unsupported on desktop and there was even some community effort¹ to make a pull request with paid contributions totally ignored by Pavel Durov and his team
This link has already been posted with https://news.ycombinator.com/item?id=50019667 , but that post's title ("Telegram Desktop: one-click account takeover") doesn't say that the vulnerability allowed also any user-accessible file on the disk to be stolen.
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.
This is really good to know. Telegram is my primary means of communication, and a bunch of other things, and even though I'm not exactly exposed (I have password set, and only a few people can yank me into a group), I'm running a bit of a custom-method install that I don't update much.
Yeah, something like that would not have prevented the account takeover part, though, which relies on Telegram's own files; or the access to cached files.
Imagine if you forgot to update your phone number with your personal bank, and then some random guy was given full access to your account and all of its contents.
And even if you dug through the account options and set a 2FA password (normally disabled) he could still just delete your account outright.
Last I checked, that's exactly how Telegram works by default. It's laughable to consider a service tied to a phone number secure.
You would still get a notification inside Telegram that someone else logged in (plus it sends the login code to your session first before you can fallback to SMS) and you can log them out. The "attacker" can't delete your account or log out your sessions because he can't use certain features on a fresh login, there is a downtime. But yeah, he can read all your chats. Same should be true for any app that uses phone number login. That's why there is a password feature.
You can delete an account if you have the phone number but not the password, it's on a 7-day timer before the account gets deleted. It can be canceled by a logged-in instance.
That still means you have to check it every 7 days.
You still get notified of a login and multiple times for the deletion request. Opening a chat app once in a week is not something rare and by that time you already changed your phone number inside Telegram.
I guess that’s the idea with phone number based services. Imagine if you could not sign up for telegram/ WhatsApp/ whatever because someone used your number before you.
The main spy feature that is Telegram collecting 100% of content and metadata is the main feature for every intelligence agency who bothers to ask Mythos to find zero days to pwn the servers.
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.
Wow, that's pretty bad, but imagine if 50% of software allowed this to happen at any time, and it was discovered on December 1st, 2026. What would happen?
I once read The Bugs We Have to Kill: https://www.usenix.org/publications/login/aug15/bratus and one particular thing that has stuck with me forever:
“Any sufficiently complex input format is indistinguishable from bytecode; the code receiving it is indistinguishable from a vir- tual machine.”
Did you really name your son Robert'); DROP TABLE Students;-- ?
Ah yes little Bobby tables.
Related: could we please stop, by default, allowing software to:
That was somewhat OK in the 80s, but it hasn't been since.I wouldn't mind, but there needs to be a way to remove the "training wheels".
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.
Ironically, the closed and restrictive iOS and Android go then out of their way to make restricting Internet access hard
Hard for you to restrict access of third parties. Easy for you to restrict your own.
That would make all the spying and surveillance harder and thereby reduce profits. And profit reduction is really the worst attack risk of all.
Of course, I was just saying "by default". You should be able to allow any access as you want, give it your old socks or granny. Just not by default.
These days, most things that I run that aren't from my distro's repos get their own bubblewrap. On top of this, I use opensnitch. Even if I trust the application (uncommon), I never trust npm, pypi, etc. any longer. It's tedious to set this up and OSes should be helping make this easy.
Agreed. Programs like Zoom, Steam, and other closed source "apps" should always run either in a separate user account or in a bubblewrap.
The problem is, peoples files are too valuable - even to the OS vendors - and also, there are simply too many valuable people on the Internet without the willpower to know how to manage their own filesystem.
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?
I am in agreement. I am always curious as to the solution because VMs are not the solution and zero knowledge is helpful but not quite there.
VMs can help a lot, see what Qubes OS does
In 2026, we still don't have a major OS that sandboxes everything.
Googlebooks, which start shipping this month, will run a fork of Android 17, which sandboxes every app.
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?
macOS does it pretty well, right ?
Among the old school desktop OSes it's one of the better options, but it still has a long way to go compared to mobile OSes.
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.
Yes, this is exactly how Qubes OS works.
Not if I have anything to say about it. I want programs on my computing device to be able to access files and roam the internet at free will. In fact, I insist on it.
Agreed. I mean, AppArmor and SELinux exist to control file access, perhaps OSes should put more effort into user-friendly overlays to control processes and have audits to warn users when a piece of software has full system access.
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.
SELinux is what Android uses internally anyway.
One of the challenges with Telegram is - they regularly re-enable settings inside the app/account that you had specifically disabled. So at any point you don't know what is happening and what is not. Meaning, even if you didn't see a thing, a malicious file might be sitting all warm and fuzzy on your computer - among possible other things. I used to like the snappiness of this app (and it is still snappier than almost all other IM apps combined, by a margin), but after a while I realised it was a ticking time-bomb (to keep it installed on the desktop) and possibly a scammer safe haven, nothing else.
A lot of companies do this but I always get a ton of hate for saying this: Telegram is the worst offender I've seen. If you start digging through their apps, you see a ton of security practices that are anything but secure. And one of the hundreds of reasons I treat Telegram as the plague: get it away from me and burn it with fire.
I've never seen a legit good hearted person ever use Telegram. It's usually what grifters and scammers prefer to use. Or Signal.
Maybe that's regional but here in Spain it's very popular for clubs. We use it for our makerspace and also for several other clubs. The moderation and access tools are way better than WhatsApp's.
It's not end to end encrypted but for big group channels that anyone can join that doesn't really matter.
Here it's all WhatsApp and Telegram. iMessage isn't really a thing at all except for expats.
My family uses it to communicate on devices that don't support iMessage (mainly Windows and Linux installs) because it's one of the precious few cross-platform messengers that doesn't treat desktop users as second class or as an afterthought.
Signal is legit. The entire stack is open source, and messages are E2EE.
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.
Signal requires a phone number and does not want anonymous users, so I do not want it too.
The phone number is only required to create an account, and is never used again IIRC. The rationale for it was to prevent abuse/spam, but I believe there is now an option to purchase an account for a small fee without needing a phone number.
Purchase can be done only through Apple/Google Pay which require a phone number and a bank card on top of that. Do not be deceived by marketing people.
so does Telegram
But Matrix does not. I wish they removed email requirement too though.
There's a few communities that use Telegram because it seems to be one of the few that is both generally usable by the average person and by default has at least a little respect for separating your online identity from your real life identity. Which is sad because I agree it's a bit of a dumpster fire when it comes to security and privacy beyond that.
Counterpoint: I have. Although Telegram is less popular in the US. I try to get all my friends using Signal.
I prefer to keep the contents of my message secure from the panopticon.
> Or Signal
It's kind of hard to hash out what you're saying here
There's at least millions of such persons
> I've never seen a legit good hearted person ever use Telegram. It's usually what grifters and scammers prefer to use. Or Signal.
TIL I'm not a legit good hearted person.
Guess I'll remove myself from the organ donation registry.
All big companies pull these kind of tricks. Another variation is to retire the old setting and introduce a new one with a deceptive name that is default on again.
Can you please tell me what settings get auto re-enabled? I use Telegram as my primary messenger app. I just want to make a more informed decision if I should switch to Signal or something.
>if I should switch to Signal or something.
Yes
https://news.ycombinator.com/item?id=48923935
Note there’s no info on that page on which settings get reenabled, only general list of grievances with telegram, mainly from a privacy/security perspective.
Which privacy/security aficionados think everyone is obsessed about.
Some of us aren't paranoid and don't care, and instead just enjoy a messenger that works and doesn't throw bullshit limitations at you.
You absolutely should use Signal instead.
Is not Signal inferior? In Telegram you can communicate with strangers without disclosing a phone number, in Western messengers until recently you had to disclose it so that your contacts can conveniently find you and punch you in the face if you are a man or just annoy you with indecent messages if you are a woman (probably not scary in a country where everyone has a gun and every home is a castle, but not all world is like this). What Western genius thought of such a feature, displaying a phone number in a group chat?
Telegram also allows to delete any chat in one click. Telegram has support for HTTP, SOCKS, MTPROTO and WEB proxies to evade censorship, Western messengers do not. Telegram is written in C++. Although it is a piece of proprietary garbage and might be connected to the government, at least it is well made piece.
Also it became difficult to register in Telegram, it often asks for 1 euro when trying to register with a fake number. And with a real number the OTP code simply doesn't get delivered to Russia.
I am not sure what you mean by "Western messengers" exactly. If it's Whatsapp, then I don't think it's any better than Telegram, even though Whatsapp claims to provide E2EE. The entire stack is closed source, and in any case it leaks huge amounts of metadata.
And no, Signal is not inferior. If you are really concerned about the phone number issue, use a burner eSIM or purchase a Signal account. Last time I checked though, payment was tied to Apple/Google, inexplicably.
You can pay money to register without a phone number https://support.signal.org/hc/en-us/articles/11197884108826-...
Requires Apple or Google Pay, linked to a phone number and a bank card, crypto not accepted.
> What Western genius thought of such a feature, displaying a phone number in a group chat?
Well, most of those apps try to inject themselves in between you and the rest of the world, by "helpfully" offering to be your SMS handler and phone call replacement.
No thanks.
This hasn’t happened to me absolutely ever in 10+ years.
In the distant past this meant more. Vendors shipped one option for everyone. Now with things like A/B testing and other application 'smart' behavior which ends up meaning we all have different experiences.
Presumably the risk is mitigated somewhat with the Flatpak version (`org.telegram.desktop`)?
Flatpak has "classic mode" which means no sandbox, which you will never guess if you did not read the docs, because why tell the users the truth when you can use marketing speak. Also, Flatpak allows reading identifiers from /proc and /sys.
Not on Linux. But if that is a safe variant then yeah great. Also, I see https://flatpak.org (is this the one you meant?) has Telegram has one of the showcases apps on the homepage so I guess they would have done their due dilligence.
For example?
I think it is one of the reasons why I am always hesitant to install any software on my windows pc. Web versions are often more than good enough.
Yes. I'm constantly annoyed by the dark patterns Zoom and Slack use to trick you into downloading their desktop apps. The web experience is practically indistinguishable and much more secure.
> The web experience is practically indistinguishable
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.
What is “sth”?
An abbreviation for "something"
For me I just refuse to run another damn browser for each app. You can have a tab. That is it.
Slack web app experience on mobile phones is abysmal.
They are talking about desktop apps.
Both are being talked about actually
> Web versions are often more than good enough.
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.
You should be more specific about what you mean here because you can absolutely do E2EE in the browser.
Not OP, but: You can definitely do encryption in the browser, no problem.
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’.
Theoretically you can download a single HTML file and open it in the browser. However many web features require HTTPS (including JS Modules, yes) so this would be poor developer experience. I want to write simple apps and prototypes in local HTML files but W3C does not let me.
I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
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).
> Isn't this the exact same security posture as a native app with automatic updates turned on?
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.
> 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
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
> but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them),
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.
> No, there is an app called "AppVerifier" actually. That's the one I mean
https://github.com/soupslurpr/AppVerifier , right? It only checks the signature (the certificate)
> And yet another reason to use GrapheneOS, of course.
Which always recommended to use the Play Store, though
> Which always recommended to use the Play Store, though
But supports alternative stores nicely.
Most of my apps I can get through the Play Store. It's not like I need end-to-end encryption on my banking app.
This can be solved by a nobus backdoor.
> I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
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.
Exactly, to me there are two requirements:
* 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.
> it's just that the web browser never chose to provide that.
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
Yep! Just nitpicking here, but...
> 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.
It would already be a huge improvement if browsers warned you when a web app has been modified, and gave you its hash
It would, but at this point, do you need a browser really? Like the big advantage of the web is that users load the latest version of whatever you serve, and they don't have to care about updates. In many cases that's desirable. But it fundamentally doesn't work for E2EE.
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".
I wouldn't really say that the advantage of the web is that users load the latest version, there's plenty other real advantages of the web.
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).
> I'm actually not a fan of web apps
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.
> I dislike the fact that they force me to have a modern browser at all
Yeah that's true
> 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
I personally hate Kotlin, but yeah it's one more option ;)
Now I'm curious: what is your favourite modern language to write a desktop app?
I wouldn't mind if it was Rust, but the KMP story seems a lot more mature in that regard, IMO. And Compose is my favourite way of doing UI.
Automatic updates should be read as "automatic backdoors".
> Isn't this the exact same security posture as a native app with automatic updates turned on?
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.
It depends on how the automatic updates are handled.
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.
E2EE fundamentally exists for situations where we don't want to trust the server. That's the whole idea of E2EE, right?
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.
Why couldn't they?
Because when you load a page in your browser, you fundamentally trust that the server is giving you what you expect. And the whole point of end-to-end encryption is that you don't trust the server.
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.
Whether E2EE is implementable or operational has nothing to do with whether you trust the code to actually facilitate it. E2EE can also be trivially circumvented by someone looking over your shoulder. This is not a coherent segmentation for whether E2EE is possible and engaged.
I am not sure what you are trying to say. Let me try an example.
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.
> I am not sure what you are trying to say.
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.
> hence why this is an incoherent segmentation
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, I'm used to it :-). I just wish eloquent people used their skill to help me convey my point (if they agree with me, obviously) rather than to make it sound like my point is worthless.
In a sense I am. We kind of both are, I'd say, for reasons we each think are important.
For example:
- you may wish to protect the trust in / reputation of E2EE, and so you might gonna have an axe to grind with in-browser implementations, and thus you may feel compelled to segment this subject accordingly
- I kind of have an axe to grind with E2EE exactly because of how little it can actually guarantee to begin with, so rather than protecting the trust and reputation of E2EE, I feel drawn to correct the popular record, and spread the word about the very serious limitations of this thing, making me segment accordingly (although I do think that even beyond this, I am right to bikeshed this)
I'm speculating on your part obviously, though not on mine. I think of E2EE as a bare minimum, not something to be particularly proud of and market, and the more I learn about how we secure our devices over the years and decades, the more distraught I feel about these technological measures. It's a lot more smoke than fire.
At the same time, I could also apologize for the bikeshedding, but then I'd hope it's clear that it's not like I did it to annoy you or anything, I just have a different perspective, and find different things salient. What's a perfectly acceptable and even a justified high level categorization to you, is a bending-of-reality category error for me, and vice versa. Happens when people from arbitrarily different walks of lives from arbitrarily different points in their life cross paths. No way around it as far I'm aware, and it's not like I don't see your point either. Like yes, loading up a random website is obviously way more of a gamble than pulling up an app you may very well even manually update biweekly, no doubt about it. It's just a difference in the overarching narrative suggested that I'm hung up on.
> I kind of have an axe to grind with E2EE exactly because of how little it can actually guarantee to begin with
Well then I think this is just wrong. If you do E2EE right, then you have the guarantee that no one in the middle (including the server) can read the data. It does have value, and saying "anyway cryptography is worthless because everything can be hacked" is not a productive argument IMO. Some people do rely on it, and it is important that those people understand when they can and when they cannot.
I don't really care so much about nomenclature and categorisation. I care about the fact that people who need it must understand when they can rely on it. And nitpicking on the wording is not making it clearer for them.
See, perspectives. ¯\_(ツ)_/¯ Ensuring that people have the right idea is why I do care about correct categorization, attribution, and phrasing. People readily twist way clearer things than what you wrote.
E2EE can technically exist on a web app, but it would be stupid to rely on it, so, yeah, I'd just be careful when using the term for web apps, since you get something way less secure than what the term evokes.
The lack of TOFU in browsers is an extreme pain point.
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.
The way I see it, it's just different.
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.
When I really need to run an app on my Linux laptop, it always gets its own bubblewrap container.
This, especially commercial apps like Zoom, Steam and others. Sometimes a separate user profile is easier though.
Don't let yourself be fooled into thinking this is enough. Plenty of examples of, especially through wasm, being able to reach far beyond what they're supposed to.
It gets buttoned up fast and is always getting better, but its absolutely not a silver bullet.
If you enable lockdown mode on your iPhone and Mac, WASM is disabled through Safari. If absolutely needed, an alternative browser like Firefox can be used for those sites.
Don't most things people use day-to-day for both work and entertainment require use of the actual app these days, or at least make it very difficult to do so?
Even on Mac, where apps like Dropbox showed you a FAKE DIALOG to STEAL YOUR ADMIN PASSWORD:
https://news.ycombinator.com/item?id=12463338
Look at who is on the board of Dropbox and ask yourself what the value of a file syncing service having accessibility (and previously kernel extension) privileges on your machine are.
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.
Is this a fake dialog, or just the standard system sudo dialog, which used to allow app developers to show an arbitrary reason string?
If it was the standard macOS dialog, an app wouldn't have been able to snoop the password
Why do you think it snooped the password? Top comment says:
> - We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
Something about reading this blog post knowing every letter and screenshot done manually with no LLM gave me the chills
You can't be sure. Maybe an AI from the future went back in time Skymet-style and wrote everything there
I don't use Telegram Desktop or Windows. But that's exactly the reason why I run Firefox in a firejail sandbox on Linux. The browser has only access to my Downloads folder. I know that it's considered untrusted and don't keep any files there for a long time.
Is "firejail" a white list (only these things allowed) or black list solution (everything not explicitly disallowed is allowed)? I glanced through the issues and it seemed to me it is very hacky and feels amateur-ish and doesn't make me trust it, so I am starting writing my own, white-list based sandboxes. For example, No-net Sandbox will not allow a single packet out, including DNS query, unless allowed, Proc Sandbox will restrict access to /proc etc.
Or the reason to run Firefox in a FreeBSD jail to get server-grade security. But the question is can an attacker get access to the Firefox profile data? Because you cannot block that from Firefox, obviously.
Sure, to some degree you must trust your browser. In the extreme case you could open a new, non-persistent browser session for every page you visit. Could be slightly inconvenient...
Or you could have 2 (or 3) separate browser sessions, one for only important stuff, and one for fun.
Or Firefox containers.
Not sure how that partitions the files on disk though, would probably need some code changes to work with some kind of firejail setup.
> In the extreme case you could open a new, non-persistent browser session for every page you visit.
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.
Not really sure that’s safe. There has been at least 1 Qubes OS specific VM escapes this year and 2 KVM guest->host control ones.
There were only two VM escapes from Qubes OS in the last 20 years [0]. How is this not sufficiently secure?
[0] https://forum.qubes-os.org/t/qsb-116-multiple-xen-issues-xsa...
I guess it also has access to the cookies for all your logins.
You mean a website A can have login/auth cookies of website B, D, Z, HK… etc? SOP doesn't work? Or is there some sort of exploit on top of third party cookies? (Just curious. I don't know anout browser dev/etc).
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.
Yes, it has access to the internal storage mechanisms of the browser.
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...
Personally I only open Firefox on Linux booted from a read only usb. In theory there could be a firmware vulnerability in the CPU that could let it write persistent data to the UEFI firmware, but I hope the possibility is small.
What makes it doubly funny is that the OP is not even about any browser vulnerability, it's a hole in desktop client IPC
The little I have to run Telegram Desktop for, I run in a VM. I'd never let the little oligarch's code touch my desktop OS.
I dont write off software because where the person that made it was born. I personally think thats the same thing as refusing to eat at a black owned resturaunt because of the owners skin color.
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.
Telegram is a double threat: the company is Russian and the founder was arrested then mysteriously released without any charges in France. Given why France wanted him and arrested him, the fact they released him a few days later with no charge annihilated the little shred of trust I had in this Russian piece of software, personally.
I don't know why anyone is using telegram when there is signal. Also with all the issues around telegram and their founder, you'd probably be safer using whatsapp even... :/
Telegram has way, way more features than Signal. First-class clients on every OS, much better behavior for large groups, far more sophisticated and granular permissions system for admins in groups, voice and video messages, folders for chats, etc.
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.
>Telegram has way, way more features than Signal.
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.
>>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.
This may be clearer from a product point of view. Your apparent viewpoint, and that of Signal etc, seems to be that protection from the server (and admittedly whoever can coerce whoever owns the server) is the only thing that matters, no matter what other features you have to throw out to get it.
What I am calling out is that this is a fundamentally ideological point of view. You can believe that and act according to it if you want, but general readers should be aware of what they are losing in order to enact this ideology with benefits that seem to be a bit dubious in the real world.
It is well known that Meta is happy to hand over to any legitimate law enforcement agency any content they have. To the best of my knowledge, Telegram never has, and neither has Signal. The fact that Telegram potentially could someday seems more theoretical to me. Again, to the best of my knowledge, all actual leaks of messaging group content have been by various authorities compromising individual devices and/or their owners, which works equally well against Telegram and Signal.
Meanwhile, Telegram gives you a lot more practical security regarding what information to share with other users, and how to manage what other users can do in large chat groups, which seems like a much more real-world concern regarding actual dangers to users than what the company that owns it might potentially do at some future date.
I think for real security, it's better to pay attention to the business model of the company that runs it. Meta's business model is indeed to basically sell your data to advertisers. Telegram does not do this, and shows no signs of wanting to. Instead, you can pay for premium, and they allow advertising as messages in public channels, and they're doing some semi-dubious stuff with cryptocurrency. Signal seems a little weird, they are apparently funded by some sort of donations from unknown parties. It seems to work okay for now, I guess, but is their financial future any more secure?
>>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.
I wasn't talking about that, but about the ability to de-auth your mobile device (the one probably most likely to someday get lost) from another device, since no one device is the "primary". Yes, an attacker could potentially lock you out if they get into your Telegram on the compromised device before you get on one of your other devices. But on Signal, you're screwed if it's your mobile, and fine if it's any other device.
Though since you mentioned backups, I think Telegram's way is arguably more secure. Individual user backups, even encrypted, means all your communication security is at the mercy of whoever in your group has the weakest encryption keys and backup storage location. With a centralized system like Telegram, it's never anywhere but their servers.
Just a small nitpick,
> 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.
No I mean between your smartphone and desktop clients.
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.
Ah well yes; the chat is also bound to an individual device, it's not even possible to export it without root
The only purpose of the private chats feature at this point is to be able to claim that Telegram can do E2EE
Telegram has channels, which are a one-to-many (thousands or millions of people) chat feature letting you have basically your own social feed.
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.
The onboarding experience with Telegram is extremely easy, which is useful when dealing with non-technical audiences who might not even have a social media account (but do have smart phones).
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.
Matrix also has that.
No it doesn't. Matrix has large groups, but they are limited:
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.
Matrix clients do not allow to even select several messages to delete them at once. Matrix is a superior concept to proprietary Signal, Whatsapp, Telegram etc but the implementation needs some help yet and UI is far behind.
It's just extremely scamming or disinformation friendly
At that's the point. People are not choosing to use anything, they're using what they have to in order to communicate with people.
It's less about what they have but what the people they want to communicate are using.
You're sure you're replying to the right message? It doesn't mention any country or nationality...
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...
The main reason I consider it suspicious is that they are so adamant about not needing end-to-end encryption.
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.
Telegram hoards messages of over 1,000,000,000 users as of now. Anyone not realizing major nation states have long since pwned the servers to spy on those users is a fool. Even if if the zero days cost 100 BILLION dollars, that access costs like 1-2 hours of intelligence contractor's hourly wage per target. The bang for buck is insane. Telegram is one of the world's biggest intelligence operations, wittingly, or unwittingly.
> 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
Can you give more details, please? I'm using telegram a lot and want to know if there is something...
Also Durov has visited Russia over 60 times
https://kyivindependent.com/kremlingram-investigation-durov/
despite endless claims he's in exile
https://www.google.com/search?q=durov+exile
https://texty.org.ua/articles/112347/eight-signsof-danger-te... , https://medium.com/@anton.rozenberg/pavel-durov-sued-senior-...
Calling him an oligarch, it was implied
Russians are not the problem. Russian oligarchs building apps spying over billion people are. You trying to frame this as Russophobia is a Kremlin talking point https://www.files.ethz.ch/isn/195236/pw_56_ang_russophobia_n...
So I'm just gonna assume you work for Internet Research Agency and tell you to maybe bugger off.
There are oligarchs in other countries like USA (Musk)
>I dont write off software because where the person that made it was born.
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.
interesting you mention. because Firefox doesn't have a way to disable the single instance functionality which was used on this telegram vulnerability.
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.
> removing every part of the --noremote option
What's this now? I'm using that to handle multiple profiles and haven't noticed anything breaking
they patched multiprofile to work WITH remote!
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.
Which Firefox functionality was used in the Telegram vulnerability? Isn’t this all about the desktop app?
being a single instance === having a port open somehow (firefox is dbus) that allows full control of the initial process under the assumption the user space is secure.
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.
It doesn't.
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.
None, I'm not sure what the other user was talking about
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.
What does "being single instance" mean here?
That only one instance of Telegram can run at any time.
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).
> not sure
so why answer?
Because I do know what this vulnerability was about, and it had nothing to do with Firefox (and I know that you specifically probably didn't mean that Firefox was involved, but even Telegram's desire to be single instance was not what caused the vulnerability).
I don't like Telegram and don't think it should be considered a "secure messenger" in the sense end-to-end encrypted messengers are, but I don't think there's all that much to learn from basic clientside coding failures like this. All applications have these kinds of bugs.
It's great that this writeup was published, but unfortunately the text is full of claudisms and made me close the tab pretty quickly.
It's annoying, yes, but I think in this case, the information is important enough that people should jump over their shadow and read it.
You wouldn't ignore a zero-day announcement either because the formatting is ugly.
I'm just a bit jaded from Claude's tone of voice, so it made me not want to read it.
I did skim over the important bits though.
Yeah, no objections there at all...
It is? I did suspect it could have been written and maybe found with AI, but I didn't notice many claudisms
Yes, just close your eyes, don't worry! Close the tab...
It's not strictly-speaking a Telegram-specific vulnerability. It's a vulnerability of all modern desktop operating systems allowing any user process to read/write any user file. Ideally all programs should be isolated from the underlying filesystem and be able to read only their own files and files from per-program data directory (like downloads for a browser or Telegram-client).
At the same time the mobile operating systems are vulnerable to vendor lock-in due to the absence of this functionality. It is clearly a worse problem that a user can't give their backup system access to the photos stored by other applications (often social media), or for instance reliably capture media streams to use in for instance a remixing application. Bringing custom clients when the software originally used to create the interesting files starts acting against the users by introducing subscriptions or being abandoned is another example of the user dictating what software accesses what files is critical to secure the users operations. Consumers need security against commercial interests infinitely much more than commercial interests need protections against consumers, and it would be unethical to enable commerce at the expense of individuals like the mobile operating systems do.
There is a lot of middle ground between “every app can do anything as the user” and “no shared file system, no user access to app ‘owned’ files”.
Any time big corp implements strong sandboxing they'll inevitably put the user inside of the sandbox.
That's a valid concern, but not an argument against sandboxing, in my opinion.
> It's not strictly-speaking a Telegram-specific vulnerability. It's a vulnerability of all modern desktop operating systems allowing any user process to read/write any user file.
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.
If you don't believe it's a vulnerability, then you must believe that tricking Telegram into uploading your messages database to the attacker, leaking all your private conversations, is A-OK? Telegram owns that file, after all.
I didn't say it's not a vulnerability. It is clearly one. But allowing such vulnerabilities to deal damage beyond data of its host application is an OS vulnerability.
Yes, and there are many ways for apps to opt into this, to limit their own blast radius in a case like this.
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?
> vulnerability of all modern desktop operating systems allowing any user process to read/write any user file
not true on macos.
Not true for apps installed via AppStore. A lot of popular apps aren’t in AppStore, Chrome/FF for example.
I would argue one of the main purposes of OSs is securing files between different users. All modern OSes do this securely if set up properly.
Or Linux with Flatpaks.
Or Windows Store as long as the proper integrity is used
That's broadly-speaking a vulnerable design of all OSes, but strictly speaking it is a bug in Telegram that is now fixed at the app level. Though sandboxes / app isolation solutions exist even in the broadly vulnerable OSes, so apps could use them already today to avoid such issues in the future?
Telegram is available sandboxed from the Mac App Store on macOS.
It could easily sandbox itself in the non-store distribution as well, yet the developers apparently choose not to.
It is also sandboxed in Flatpak.
Looking at the flatpak manifest it has `share=ipc` but no directories shared.. I'm not sure on flatpaks defaults for what it would actually have access to on the host.
That is not the same app.
Telegram Desktop is also on the app store though.
I know, it's (slightly) better
> Ideally all programs should be isolated from the underlying filesystem and be able to read only their own files and files from per-program data directory
So how will you spam all the group chats you're on with meme gifs downloaded from facebook then? :)
Download an image from Facebook into browser's private downloads directory, copy it using a file-manager application (one of the exceptional applications having full filesystem access) into Telegram's private directory, upload it into chats you need to post it.
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.
Sounds like effort, people don't like effort when spreading memes, so would be enraged if this would be the default now, or nobody would activate it.
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.
Clicking upload opens an OS file picker that lets the user select a file outside the app sandbox. At least flatpak and Android do it that way.
MacOS sandboxes user folders by default. The user need to explicitly give a permission for every application.
It sandboxes some use folders. ~/projects won’t be sandboxed for example.
> It's a vulnerability of all modern desktop operating systems
Uhm, OpenBSD would like a word, buddy.
https://man.openbsd.org/unveil
And Linux would like to present you bubblewrap [1][2][3][4] or the infamous SELinux.
[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
That has the caveat that it only works as far as apps opt into it
Chromium and Firefox have unveil on OpenBSD, which is a good start.
It is.
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.
> Not all user processes upload those files somewhere surreptitiously.
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.
No, that kind of audit is neither necessary nor sufficient. (A firewall works without application source code, and trusting trust means we can hand wave anything even with source.)
Ok, at least if it has network access, but can you recognize that this was a vulnerability, and that you're talking of something only tangential to it?
> The primitive stays the same throughout: arbitrary file read. What changes is what you read: an SSH private key, a browser password store, a cloud credentials file, or a configuration holding an API token.
So in the hindsight it was a right thing for me to put it into a sandbox without any SSH keys and tokens. Also, I didn't bother registering tg:// scheme in the OS which also turned out to be good - clicking such a link in the browser does nothing for me, and as a side effect, websites cannot detect presence of Telegram or send command to it though registered scheme handler.
Also, I was surprised that Telegram uses passcode (an on-device password that is required to access the app) to encrypt user data. I thought they just keep the hash of a passcode and check it.
Also I assume Telegram can block this attack on the server, as groups are not E2EE and the server can find and delete files needed for successful exploitation. And links too. If someone has a spare account they can check if posting such type of files or links works.
When criticizing Telegram, I wish people focused on the actual smoking guns and didn't include random fluff one has to cut through.
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.
>But I'm not aware of a messenger that provides a good UX for that
WhatsApp is the largest messaging app in the world (3B MAU) and does E2EE by default across private chats and groups.
WhatsApp's UX is awful, not to mention that its E2EE is irrelevant when most users back up to Google Drive.
Signal's current UX seems pretty good to me, and it's not even that easy to lose the account
> open source
I'd just stress that at least for the Android 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.
> I'd just stress that at least for the Android 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.
One thing I don't know is whether these delayed source releases are enough to validate releases published to app stores. If they are, this means Telegram is building up reputation and would have to burn it to publish a release with a backdoor not present in the source.
The other thing this allows is for a third party to maintain a fork without having too much trouble keeping up with new features.
It looks very bad that Telegram took almost 3 months to fix this vulnerability.
Reported 25 June
Fixed 16 September
I wonder why it took them so long?
It was reported to a third party platform which the author says is likely clogged up.
They are restructuring their companies regularly and keep the core company small.
Telegram and security don't really belong in the same sentence anyways. Say what you will about Signal but they at least have better cryptography and more transparency about what software they're running.
I thought telegram was flagged as insecure like a decade ago, it's never really been "very secure"
Like any number of articles like this: https://hackernoon.com/7-reason-why-telegram-is-insecure-by-...
Still we are using it, because UX kills any other app and people that are (probably) behind it will cause almost no harm to casual, not-interesting people :)
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.
What a bizarre threat model. Why would you rather have your data with who knows who than just your metadata?
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.
> and I haven’t found anything lacking in the latter, UX wise
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.:
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.I use them daily, so we might just have different priorities.
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.
I agree with maxgashkov about the UX. Just wanted to add that the list of good UX features is much, MUCH longer than the one maxgashkov provided.
I lost access to my WhatsApp history multiple times. This never happened to me anywhere else. This is admittedly an example of WhatsApp UX being terrible, not Telegram UX being great.
For me it isn't the UX really. I was sold on it NOT being WhatsApp, etc, and then I stayed for the unlimited free storage for life (have a virtual FS built on it). Definitely ain't nobody else offering that.
"will cause almost no harm to casual, not-interesting people"
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.
Well, it makes sense from a threat modeling perspective. If you're Russian, you should use Whatsapp because it is unlikely Whatsapp will cooperate with the Russian dictatorship, but in Western countries, you can assume that anything from Meta, Google or Apple that's in any way useful (and even if it's just metadata) can and will end up in the data lakes at the NSA.
False dichotomy. Nobody's forcing you to use proprietary messaging app like WhatsApp in the West. FOSS tools like Signal are the norm in privacy circles.
Assuming you think Meta can write secure proprietary software and trust them to do so.
Well for a Russian I think there's barely a chance that Russia manages to compromise any of the US giants at large scale, so Meta is a better choice than VK, Telegram or any of the Chinese services.
It was, but most people will believe what their peers (real or parasocial) say over the collective screams of every security researcher on the planet, so here we are.
Absolutely, but mostly for their protocols, statements, people and infrastructure.
A file exfiltration vulnerability is still noteworthy.
Here's one from Filippo
The Most Backdoor-Looking Bug I’ve Ever Seen - https://words.filippo.io/telegram-ecdh/
It has this feature where it tells you about other users that are on the platform. I mean it's not a huge leak, but right off the bat it's pretty poor security posture. For an app that competes with other chat apps on supposedly being more secure and privacy aware, it does worse than whatsapp on that end.
"For an app that competes with other chat apps on supposedly being more secure and privacy aware"
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).
This!! Signal also had this back in the day, very bizarre for an app thats privacy focussed… sadly have to use it because some contacts refuse to use anything meta etc. Sadly it is only big corp stuff that works reliably where i am somehow..
I wonder how much of Apple's announcement around disallowing full system disk access was from this as opposed to Muse, et al.
Does its official desktop client support "Secret Chats" (E2EE) yet? Last time I used Telegram before moving to more reliable IM platforms that feature was officially unsupported on desktop and there was even some community effort¹ to make a pull request with paid contributions totally ignored by Pavel Durov and his team
[1] https://github.com/marcovelon/tdesktop/blob/NoSecretChats/RE...
I heard Telegram client from aur repository on Arch Linux supports secret chats.
This link has already been posted with https://news.ycombinator.com/item?id=50019667 , but that post's title ("Telegram Desktop: one-click account takeover") doesn't say that the vulnerability allowed also any user-accessible file on the disk to be stolen.
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.
That is such a JiaTan grade feature because it’s an insane way to implement it but also plausibly deniable.
Telegram is worse than WhatsApp. No E2EE by default in 2026 is insane and Telegram's marketing is so deceptive.
This is really good to know. Telegram is my primary means of communication, and a bunch of other things, and even though I'm not exactly exposed (I have password set, and only a few people can yank me into a group), I'm running a bit of a custom-method install that I don't update much.
doas jexec -U opengrass tellyjail env DISPLAY=:0 Telegram
Yeah, something like that would not have prevented the account takeover part, though, which relies on Telegram's own files; or the access to cached files.
I use Signal btw.
Imagine if you forgot to update your phone number with your personal bank, and then some random guy was given full access to your account and all of its contents. And even if you dug through the account options and set a 2FA password (normally disabled) he could still just delete your account outright.
Last I checked, that's exactly how Telegram works by default. It's laughable to consider a service tied to a phone number secure.
You would still get a notification inside Telegram that someone else logged in (plus it sends the login code to your session first before you can fallback to SMS) and you can log them out. The "attacker" can't delete your account or log out your sessions because he can't use certain features on a fresh login, there is a downtime. But yeah, he can read all your chats. Same should be true for any app that uses phone number login. That's why there is a password feature.
You can delete an account if you have the phone number but not the password, it's on a 7-day timer before the account gets deleted. It can be canceled by a logged-in instance.
That still means you have to check it every 7 days.
You still get notified of a login and multiple times for the deletion request. Opening a chat app once in a week is not something rare and by that time you already changed your phone number inside Telegram.
I guess that’s the idea with phone number based services. Imagine if you could not sign up for telegram/ WhatsApp/ whatever because someone used your number before you.
if the user values security and privacy would not be using Telegram
It's not a bug it's a feature.
was a feature.
technically, this is one agency burning the feature of another agency.
The main spy feature that is Telegram collecting 100% of content and metadata is the main feature for every intelligence agency who bothers to ask Mythos to find zero days to pwn the servers.
this is about controlling the host running the client... do people even read the articles?
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.
I am shocked......
I mean it's pretty obvious these things (Signal, et. al) are just honeypots for the three letter agencies, right?
Show us the backdoor https://github.com/signalapp/Signal-Android
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.
well duh
> Telegram Desktop vulnerability allowed any user's file to be stolen
Wait till they find out about web browsers. /s
Russian social media app has backdoor. Who would have thought?
(Yes, I know they're technically Dubai based now)
Yet the oligarch who supposedly lives in exile has visited Russia over 60 times since https://kyivindependent.com/kremlingram-investigation-durov/
Wow, that's pretty bad, but imagine if 50% of software allowed this to happen at any time, and it was discovered on December 1st, 2026. What would happen?
is that a threat or an ai doomsday whataboutism