Tdesktop: Better install path for Windows

[beerisgood]

With current version (0.10.1) the install version try to install Telegram to this path:
_C:\Users\%username%\AppData\Roaming\Telegram Desktop_
But of security reasons the official windows program paths are more secure. So please move to
_C:\Program Files (x86)_ or for 64Bit version to _C:\Program Files_

I'm sure using _\AppData\Roaming_ is because the updater works without UAC requests, etc but this is a bad workaround.

Tested under Win 7 Home & Pro SP1 x64

[john-preston]

@beerisgood And what is a good workaround for updating the app without UAC requests?

[beerisgood]

Using the UAC is the only workaround.
Why in hell not using it?

[john-preston]

@beerisgood The other reason is to install the app for the current user with no impact on other users of the same computer, who can have their own Telegram installed if they want to.

[john-preston]

@beerisgood Because installing each update with an UAC request will disturb the user and some users won't be able to install and use the app without notifying their system admin etc.

If you want, you still can install the app to the program files folder and use it with UAC request on every update.

[beerisgood]

Just put the userdata and settings to the folder, Windos provides.
C:\Users\%username%\AppData\Roaming & C:\Users\%username%\AppData\Local

Then only one install is needed but all users can use it.

[beerisgood]

Telegram stands for security, doesn't it?

So not using the UAC is not secure.
The user know that a update can require a UAC dialog. So just show the user a notification for new updates, ask to update and if yes, the UAC comes.
No problems

[punk-t]

I support @beerisgood's request - programs to their programs folders, user data to their respective users. Building a Windows App should also mean to make use of the conventions of that system. This means using the registry, accept the folder regulations, GUI conventions and so on. When you develop a linux app at least it has to support LSB, Chrome / Android --> Material et al.
And as an administrator I have another point of view concerning the question "UAC - good or evil": On a single user Windows (at home for instance) the user should be able to pimp his system so that UAC won't annoy him - or he want's to have it, like me.
On a multi user environment unprivileged users shouldn't be able to patch software. There are lots of other mechanisms to patch on domain level, WSUS / SCCP, Package Publisher and much more. So there's only one conclusion: program to program folder, data to user data!

[T3rminat0r]

To show a possible path through this: offer both, like chrome does. Regular Chrome Installer installs into the AppData/Roaming for the current user. But there's a Chrome for Business MSI Installer installing systemwide, including a windows Service that'll run updates, UAC free, independent of User interaction. Best of both worlds....

[john-preston]

@T3rminat0r Looks rather complicated.

[T3rminat0r]

@john-preston never said it wasn't. Merely wanted to show others had that issue brought up and solved it in the past :) And I do agree there's more important stuff to fix at the moment :/ (TD keeps crashing on me when waking up from sleep/hibernate on Win10, Build 1607)

[john-preston]

@T3rminat0r Do you have a crash report tag of the happening crashes? Or you mean freezing or smth else?

[T3rminat0r]

I meant freezing, see issue #2386 for some wild guessing on why it happens :/

[beerisgood]

So whats your decision now?

[christianromeni]

How about a Windows 10 App.. Just place it in the windows Store and your done. ;)

[beerisgood]

Please don't use my thread for your question. Make your own thread.

[christianromeni]

This was supposed to be a solution, not a question.

[jhasse]

The Python installer is using this location when installed without administrator privileges: %LocalAppData%\Programs

[Zenexer]

It's worth noting that Microsoft does officially support a per-user installation context on Windows; even their own installers provide native support for that context. Yes, there is an inherent trade-off between security and compatibility being made here. Installers often let the user choose which context is right for them.

[xelra]

I only stumbled across this issue while researching something completely different, but I'll leave my 2 cents.

As @Zenexer and @jhasse pointed out, the install path is context-dependent. There are two types of context, ALLUSERS=1 and ALLUSERS="".

For the first one, the machine-wide installation, the install path is %ProgramFiles(x86)% for 32-bit or %ProgramFiles% for 64-bit.

For the second one, the user-wide installation, the install path is %LocalAppData%\Programs for both 32-bit and 64-bit.

If Telegram is going to remain user-context installable only, it should at least adhere to the latter install path.

[beerisgood]

push
Whats the status about that problem?

[john-preston]

@beerisgood You can install it to a path you like, for example in "Program Files". For now the AppData is still used and will be for some time, because it allows an easy install and autoupdate even for users who don't have the admin rights.

I can't imagine any real world scenario in which a binary in AppData will be a security flaw while a binary in ProgramFiles will defend from that scenario.

[beerisgood]

Because of ransomware, users protect the system which also means AppData.
And AppData isnt designed to run programs. Its a folder to only - like the name say, store app/ program data.

And if the program is stored in "Program Files" (for 64bit) or "Program Files (x86)" (for 32bit) then the binarys are protected by Windows and the UAC.
If Telegram need a update, a UAC ist then fine.

Think about that

[john-preston]

@beerisgood Current default path and non-UAC installer allows user without admin rights on the Windows PC to use the app with autoupdating, if we change the default path — it wouldn't allow that.

What exactly is the way for the attack being performed that is possible for the binary in the AppData and is not possible for the binary in Program Files? Assuming that the attacker can just plant a _new_ malicious binary somewhere (in AppData for example) and a shortcut on desktop.

[beerisgood]

As i wrote Program Files are protected by Windows. AppData not
If you want change files in Program Files you need to confirm the UAC- not so for files in AppData

Because of that, Microsoft say Program Files is the recommend path for programs - the path name say that already, while AppData stands for only program settings and are not protected by UAC. Why should they?

So Telegram use by default a unsecure path for the executable and any software can change all telegram binarys without UAC & without any prompt.

If you would protect your PC against ransomware you know that binarys from AppData cant start because of policy rules.
And because of that i open this issue here. Its not a simple request, its a big security problem with Telegram

[jhasse]

And AppData isnt designed to run programs. Its a folder to only - like the name say, store app/ program data.

%LocalAppData%\Programs is though and it also doesn't require UAC.

[beerisgood]

No, just no.
Read what i talking about

[jhasse]

No, just no.
Read what i talking about

You should also read what I'm talking about:

Because of that, Microsoft say Program Files is the recommend path for programs - the path name say that already, while AppData stands for only program settings

Only for Per-Machine installations. For Per-User installations, the recommend path for programs is %LocalAppData%\Programs not %ProgramFiles%. Official Microsoft source for this: https://msdn.microsoft.com/en-us/library/windows/desktop/dd765197(v=vs.85).aspx

[beerisgood]

This is as a option at install, but telegram doesnt provide that option.

Also i dont care any longer here about my request. The dev dont give a fu** about security.
Close this request, eat it, do what you want. I dont expect a fix

[Zenexer]

@beerisgood You probably shouldn't close it. There are still other people (like me) who care.

[Zenexer]

@john-preston There are very specific attacks in wide use that rely Windows' special treatment of program directories. Unlike other platforms, Windows first searches libraries and executables in the current working directory or the program launch directory. Here's an example of how this can be abused, in a generic form:

1. ProgramA.exe is downloaded by the user to the Downloads folder.
2. The user visits a malicious site.
3. The site drive-by downloads a malicious kernel32.dll file, assuming that most programs will load it.
4. The user launches ProgramA.exe directly from the Downloads folder.
5. ProgramA.exe loads the malicious kernel32.dll.
6. Because the user trusts ProgramA.exe, the user grants it UAC elevation.
7. The malicious site has now successfully performed RCE and privilege escalation attacks.

Even when a program isn't being run from the Downloads folder, this vulnerability is still present whenever a program is installed to a writable directory. The RCE attack can no longer be performed, but privilege escalation is still possible. Malicious DLLs can piggyback on the user's trust of Telegram to trick users into granting UAC elevation. In very specific cases, this vulnerability can also be used to escape sandboxes.

There are related privilege escalation and sandbox escape vulnerabilities that abuse the user's trust of Telegram. The easiest way for Telegram to ensure its integrity on a system is to require UAC elevation to modify libraries and executables. It's also advisable to verify the integrity of all DLLs that are loaded, though Telegram might already do this--I haven't checked.

This is not some obscure vulnerability. It's been used by the CIA to compromise privacy and security in at least one high-profile incident. This incident was published on WikiLeaks, and, unlike some of the claims WikiLeaks makes, poses a real threat. It's been used by both state and non-state actors for decades: it's simple to exploit, works on wide variety of environments, and is nearly impossible for even the most prudent end-user to mitigate. Offering the ability to install to a UAC-protected path is the absolute minimum you can do to protect against this--there are other steps you should take, too, as described by the Notepad++ team.

[john-preston]

@Zenexer Yes, I know about the .dll planting and it was discussed (and fixed) for some time now. If you can write a .dll to users appdata folder you can the same way write a malicious executable there and place a shortcut to that executable on his desktop, he will just launch your malicious executable.

[Zenexer]

In sandbox escape exploits, the directories or files to which the malicious app can write is limited. If Telegram's directory were ever writable by a sandboxed app for whatever reason, it could potentially escape the sandbox by replacing the executable. This is a bit of an obscure vulnerability, but it does come up from time to time.

Impersonation exploits are also an issue. More and more common users are being careful about UAC dialogs. I know a lot of average users--like my mother and grandmother--who know nothing about computers, but know better than to blindly click through random dialogs. If they see a dialog that asks them a question to which they don't know the answer, they ask someone what to do. If I see that the app is Telegram, and I see that the path corresponds with the default Telegram installation directory, I'm probably going to allow it--I'm not about to run a checksum every time someone sees a dialog they don't recognize. This is really only likely to be an issue if a state actor is directly targeting Telegram users--but, should that happen, it's definitely a viable exploit.

It would also allow an attacker to replace the Telegram executable without privilege escalation. This is, again, really only an issue when state actors are involved, but it would be very useful: they could stealthily siphon off message post-decryption, without so much as a UAC dialog. If Telegram were in Program Files, they'd need either a UAC dialog or a privilege escalation exploit.

[jhasse]

By sandbox app you mean a Windows Store app?

[Zenexer]

@jhasse No, any kind of sandbox. That vulnerability assumes Telegram is running alongside untrusted, sandboxed applications (e.g., websites, Flash, Windows Store apps, and an infinite number of other possibilities).

[jhasse]

Wouldn't you say that if any malicious program has write access to %AppData%, you're in much bigger trouble anyway? As @john-preston said:

If you can write a .dll to users appdata folder you can the same way write a malicious executable there and place a shortcut to that executable on his desktop, he will just launch your malicious executable.

[Zenexer]

@jhasse No. It greatly depends on the goals of the malware. For some malware, yes, that would be sufficient. For someone looking to intercept all of Telegram's data, it wouldn't be--if Telegram were installed to Program Files instead of AppData.

[jhasse]

For someone looking to intercept all of Telegram's data, it wouldn't be.

But ... Telegram's data is saved in AppData anyway. So you don't need to replace the exe, because you already have access to the account data.

[Zenexer]

@jhasse

1. It's encrypted
2. Any faults with that encryption are a separate issue. For example, if the credentials used for decryption are stored alongside the encrypted data, that's a separate fault. Technologies such as TPM can be used to mitigate such issues.

[jhasse]

Any faults with that encryption are separate issue. For example, if the credentials used for decryption are stored alongside the encrypted data, that's a separate fault. Technologies such as TPM can be used to mitigate such issues.

As long as those issues exist though, it's useless to move telegram.exe to %ProgramFiles%.

[Zenexer]

@jhasse No it's not:

1. This is a chicken and egg problem. One is useless without the other.
2. Of the two, this one protects against a wider range of common exploits, so it's better to solve this issue first (assuming the other issue even exists).
3. I listed three possible exploits I could think of above; two are still relevant, even if encryption can be defeated.
4. I'm just one person, and I'm not scrutinizing the circumstances. This is a situation that I recognize as "generally vulnerable," but there are people out there with much more time and motivation who could probably find all sorts of creative ways to use this as part of an attack. Just because I can only think of three doesn't mean there are only three.

[jhasse]

This is a chicken and egg problem. One is useless without the other.

I wouldn't say so. It could be implemented that the decryption key could only be accessed by signed .exe files, therefore they can still live inside AppData.

I listed three possible exploits I could think of above; two are still relevant, even if encryption can be defeated.

Which three do you mean? Because the following three are all not fixed by moving Telegram.exe to ProgramFiles:

1. "Telegram's directory were ever writable by a sandboxed app for whatever reason, it could potentially escape the sandbox by replacing the executable."

If a app can replace exe files inside AppData it has already escaped the sandbox and can do other severe (see https://github.com/telegramdesktop/tdesktop/issues/2355#issuecomment-301412659).

1. "Impersonation exploits are also an issue."

Login data is already inside AppData, moving exe to ProgramFiles wouldn't help.

1. "It would also allow an attacker to replace the Telegram executable without privilege escalation. [...] they could stealthily siphon off message post-decryption, without so much as a UAC dialog."

ProgramFiles wouldn't help, as the message data is still inside AppData.

[Zenexer]

1. Not necessarily. I'm not making any assumptions about the sandbox or which files it has access to. Keep in mind that the Roaming AppData folder is often stored on network shares (that's what Roaming means), and specially sandboxed applications are often given access to those. (Think: schools and enterprises with lousy sysadmins) Also, network shares can be used to break out of virtual machines this way: if the VM has network access (even though NAT), it can mount the network share and replace or alter an EXE.
2. I wasn't talking about user impersonation; I was talking about Telegram impersonation, whereby malware pretends to be Telegram. The solution presented here would help some users but not others; it depends how careful the user is or whether they ask more knowledgeable users for assistance. The usefulness of this technique seems to be increasing over time. I think we can agree that this isn't the most important issue at hand, because it would still be possible to trick most users.
3. Then the login and message data should be encrypted with something such as TPM, but that's a separate issue--probably worth opening a ticket for that.

[jhasse]

1. Not necessarily. I'm not making any assumptions about the sandbox or which files it has access to. Keep in mind that the Roaming AppData folder is often stored on network shares (that's what Roaming means), and specially sandboxed applications are often given access to those. (Think: schools and enterprises with lousy sysadmins) Also, network shares can be used to break out of virtual machines this way: if the VM has network access (even though NAT), it can mount the network share and replace or alter an EXE.

For that case moving Telegram to %LocalAppData% should help, shouldn't it?

IMHO Telegram should also not do work-arounds for lousy sysadmins.

[Zenexer]

@jhasse No; many users will want to install to Roaming, as it allows their Telegram installation to persist across workstations.

Again, these are just the exploits I can think of off the top of my head. It's far from an exhaustive list. We've clearly established at this point that it's a vulnerable situation; coming up with mitigating factors or excuses for each scenario is getting a bit ridiculous. There will always be another scenario. Why not just permit installation to Program Files? It's not that difficult. It's not like it needs to be forced: the user can choose. That's how nearly all other modern installers work, and there's a reason for it. The hardest part is the updater, as it requires UAC elevation--but that's the whole point.

[john-preston]

@Zenexer You can install it to program files if you like. You need to launch the setup as admin for that and choose install folder to Program Files, why not.

[jhasse]

No; many users will want to install to Roaming, as it allows their Telegram installation to persist across workstations.

Okay and what does this have to do with this issue? If they want to install to AppData/Roaming, they won't install to ProgramFiles.

We've clearly established at this point that it's a vulnerable situation; coming up with mitigating factors or excuses for each scenario is getting a bit ridiculous.

What? These aren't excuses. Please show me where we've established that there are relevant security issues which would be solved by moving Telegram to ProgramFiles.

[Zenexer]

@john-preston It's been a while since I first looked at this issue, but iirc the idea was to make Program Files the default. Looking back, I think I was mostly concerned about DLL hijacking, but it's still a relevant issue. I suppose it's a matter of whether you're willing to call a UAC dialog during updates "unfriendly."

Typically, Telegram is installed to the global /Applications folder on macOS and /usr/bin on Linux, right? On macOS and often on Linux, that requires entering a password, which is significantly more intrusive than a typical UAC dialog.

It can also be installed from the macOS App Store, which may also require entering a password:

The Free Downloads option allows the password to be saved, but Purchase and In-app Purchases only offers Require After 15 minutes as its most permissive option. I don't remember what the defaults are, but I think a password is normally required for both.

[jhasse]

/usr/bin on Linux, right?

No, it comes as a simple tarball which you extract somewhere and then run the Telegram binary afterwards.

[Zenexer]

@jhasse I meant if you installed it through your distro's repos, which is what I've always done. You wouldn't (well, shouldn't) install something not from your distro's repos to /usr/bin.

[Zenexer]

@jhasse This is what I was thinking of: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=telegram-desktop-bin Looks like it does use /usr/bin.

[jhasse]

You said "typically".
Typically Telegram isn't installed globally on Linux and therefore installation doesn't require a password.

(Installing it on Arch via the AUR isn't typical for most users.)

[Zenexer]

@jhasse I don't know anyone who "typically" installs software on Linux by downloading tarballs. They use GUI package managers, apt-get, dnf/yum, etc. A typical user isn't using Linux anyway, so this is an irrelevant issue. Let's focus on macOS.

[Zenexer]

Note that there is a local, per-user Applications directory on macOS that doesn't require a password/fingerprint:

[jhasse]

Note that there is a local, per-user Applications directory on macOS that doesn't require a password/fingerprint

Just as there is one for Windows: %LocalAppData%/Programs

[Zenexer]

Yes, that's my point. Why use a local directory on Windows, but a global directory on macOS? (Yes, I understand that Telegram doesn't use the "proper" AppData directory, but the directory it chooses has the same effect.) It's even more tedious to install globally on macOS than on Windows.

[john-preston]

@Zenexer By default on macOS it doesn't require anything from user — non the "installing" (copying) to Applications, non the updating.

Linux installations to /usr/bin are all unofficial.

Anyway, it is irrelevant, because most of desktop users are on Windows and this is rather common thing that they have their office machines and don't have admin rights. The idea was to allow them to use a full featured and auto updated Telegram by default.

[Zenexer]

Yeah, I guess it doesn't prompt me to drag into Applications--not sure why I never noticed that. It looks like /Applications has a special mode flag set that permits that.

I'm still in favor of installing to Roaming when the user isn't an admin. However, if they're an admin and not on a domain, it seems like a no-brainer to install to Program Files. I don't see any harm coming from that, and it's a very easy way to protect against a wide range of vulnerabilities, or at least make them more difficult to exploit.

[john-preston]

@Zenexer Perhaps that would work. I'm not sure there is a way to configure InnoSetup installer that way. The installer either requires UAC by default or it does not, AFAIK it can't depend on whether current user is admin or not.

[Zenexer]

Ah, that's a shame. For some reason I thought you were using a custom "frictionless" installer. I suppose Roaming really is the best compromise for now, then.

[john-preston]

@Zenexer With a custom installer perhaps there is a way to start it without UAC, then decide, if Program Files is suggested by default and if so ask for the UAC confirmation at the moment of installation.

[xelra]

I suppose Roaming really is the best compromise for now, then.

%APPDATA% aka AppData\Roaming is for application data that should roam with the user profile. A binary should never roam with the user profile. Software you install is local to a machine or profile.

The UAC-free install path for installation context ALLUSERS="" is %LOCALAPPDATA%\Programs. That path does not roam with the user profile, is local to the user and the machine.
That's from the official Microsoft Windows documentation.

Here is a link to the docs: Installation Context.

[Zenexer]

@xelra I think the point, though, is that the large majority of users want it to roam. For example, if you're a student at a college that has several computer labs, chances are you're going to use many different computers. It'd be a pain if you had to install your favorite apps on each of them, and the domain admins certainly aren't going to do it for you.

[auchri]

@Zenexer I think the majority of the users don't care where programs are installed.

[BlindWolf8]

We can't reopen this can we?

[jhasse]

No. I would advise you to create a new issue with a more specific title, as this one can be split into these two:

• Use ProgramFiles instead of AppData
• Use LocalAppData/Programs instead of AppData

[WilliamStam]

we block all .exe's from the users folder via GPO. kept our network rather nicely clean. very few viruses etc. i do not support the decision to install it to that folder at all. move to program files please. when trying to install telegram to program files we get access denied error from the installer.

[john-preston]

@WilliamStam It won't get this error if you launch the installer with admin rights (right click, Run as Administrator). Perhaps the default would be changed some day, but you can install it there even now.

[BoffinBrain]

Can we please get this reopened? I just wasted my time filing another bug report about this (#3903) and it really should be addressed.

As I wrote in that thread, "Just open it as admin and it works" is not good enough. How would the user ever discover that? There needs to be an explicit question in the installer to choose whether to install it for the current user, or all users (and all users should be the default). At that point, you can ask for admin privileges with a UAC prompt.

[jhasse]

How would the user ever discover that?

He wouldn't. Just as he doesn't know what "C:\Program Files" is.

[john-preston]

@BoffinbraiN Yes, asking for them while installing would be good. I'm not sure I can do that with InnoSetup, but perhaps it supports such scenario.

[rindeal]

And what is a good workaround for updating the app without UAC requests?

Apart from the updater service, you can add a custom task to the Task Scheduler (using its CLI utility), which allows you to run the updater with any priviliges you want.

[BoffinBrain]

Yep. That's the usual way to do it. Firefox, Chrome and Adobe all have their own. You can find them using Autoruns or in the bottom panel of Task Scheduler.

[BoffinBrain]

Additionally, I thought I'd mention that when I uninstalled Telegram and attempted to reinstall to Program Files by running as Admin from the start, the install location still defaulted to appdata/roaming, so I think the advice I was given is incorrect or it's a bug.

[BoffinBrain]

Can we get this ticket reopened please?

I've installed the latest tdesktop 1.2.6 on a new machine by right-clicking and running as an administrator. The proposed install directory is still AppData! I've run the exe with /? and there don't appear to be any flags that you can use to suggest Telegram should install to Program Files.

[IVBela]

Been using Telegram on my phone for ages, used Web interface on my PC till now, as I thought I'd give a try to the app and see if it's any better. Just to realise it tries to install to AppData. Seriously?

Looked up the issue, reached this page, registered on GitHub to ask: please reopen this issue. Programs should go to Program Files, application data to AppData. It's a matter of good coding, not a matter of developer's personal preference about not liking UAC.

Tried to manually change the install location to Program Files, as a result Telegram's application data also went to Program Files. Back to using web interface until this is resolved...

[jhasse]

Programs should go to Program Files, application data to AppData.

There's also %LocalAppData%/Programs where programs can go (without requiring UAC).

[IVBela]

There's also %LocalAppData%/Programs where programs can go (without requiring UAC).

That's OK too. But %AppData% is not OK for several reasons already stated above. Just the same way it would be not OK to put it to %temp% or D:\ or any other arbitrary location for the sole reason of trying to circumvent UAC.

[WilliamStam]

i kinda stopped using telegram cause of this total BS. "we are security focused" but then they have the install path to there lol wtf????

[Fieel]

This is still an issue in 2019 wow. Really?

Can someone open this issue again? @beerisgood pls. Also why are devs ignoring this..?

[BoffinBrain]

Maybe someone should just make a new issue, since they seem to be deliberately ignoring this one.

[beerisgood]

@BoffinbraiN they wouldn't care and just mark it as dublicate issue

[rbertoche]

So you really care nothing for having your app protected against ramsonware and other security issues? I can't believe it, you fooled me all along with your "security concerns". This makes me rethink using Telegram at all.

Edit:
After reading all comments here it's quite clear that the only safe option for installing Telegram is in a write-protected folder. That's the case for any system and it's usually how the app is installed in most GNU/Linux systems, where Telegram is mantained as a package usually in official repositories.

So while installing in roaming or other user-owned folder is probably useful on some instances, there is no clear reason why it should be the default option in either Mac or Windows - As i've already said, in Linux it's already usually installed on a system path.

Having Telegram binaries on a user owned path will always be a security issue and for admin users it provides no advantage to having it on a write-protected path since it's possible to implement updates without having to issue an UAC dialog, as it's currently done on most browsers.

Other important thing that's been said here is that it is already a custom and a protocol on both Mac and Windows to ask an admin user for elevated credentials while installing an app, so UAC or asking for root password clearly isn't an usability issue, in fact it's the other way around - what's unusual or strange is not asking for it and installing on the users's home, and certainly most users will find it strange

[beerisgood]

I reopen the issue in hope that something will change

[kotauskas]

Why can't Telegram create a service (a good Windows-ish name would be TGUpdaterSvc) which would check updates on a customizable schedule, informing the main executable with some form of IPC that a new version is out, which, in turn, would inform the user as it is now? The only UAC elevation case would be when the user installs Telegram.

That said, giving the user a per-user vs machine-wide choice for installation _is THE correct Windows way_, and I see no reason why would doing otherwise have any reason. There's as well no real problem in having the old updater code in the main executable for per-user installations and the service for machine-wide ones. They even might share the functionality using a DLL.

Once again, every Windows app should have a machine-wide option for installation, simply because MS suggests so. Telegram and Discord remain the only programs on my PC which don't have a machine-wide installer.

[beerisgood]

@kotauskas their is no need to increase attack surface with a service. Just checking the version against server is enough and also the download works without.

[kotauskas]

@beerisgood

Just checking the version against server is enough and also the download works without

The service would install the update. Because it's ran with admin privileges, it can write to Program Files without the UAC prompt.

[beerisgood]

@kotauskas I know. Same with Firefox and Thunderbird and I highly don't recommend that as solution. It's only more attack surface and need maintained well or it can be abused because of the high privilege rights.

Also a easy UAC yes/ no isn't hard isn't it

[rbertoche]

There is also a suggestion above from rindeal suggesting the use of a CLI utility to schedule updates that would run with privileges without needing further UAC. I don't know it, but it looks like the best choice on windows, unless you want to issue an UAC every update

Glad to see that the issue seems to be going forward, at last. Cheers!

And what is a good workaround for updating the app without UAC requests?

Apart from the updater service, you can add a custom task to the Task Scheduler (using its CLI utility), which allows you to run the updater with any priviliges you want.

[Neustradamus]

It is possible to install the software in "Program Files" by default for Windows?

[beerisgood]

It is possible to install the software in "Program Files" by default for Windows?

Yes. I use Telegram a long time now in "C:Program Files (x86)" and it works. A Update ask for UAC and that's it.
No security problems with %appdata%

So i still wonder why the dev here is so ignorant to not implement this.
Also "Program Files" (for 64Bit programs) and "Program Files (x86)" (for 32Bit programs) are Windows standards for a very long time. So using %appdata% for Binarys is not only a security problem, it's bad coding too!

[Aokromes]

maybe the way to go is this https://docs.microsoft.com/en-us/windows/win32/msi/user-account-control--uac--patching?redirectedfrom=MSDN

[beerisgood]

@Aokromes no that doesn't work how you think.
If user set UAC to maximum (sadly not default since windows 7 but highly recommend) then the UAC always popup.
Also why make it so hard? A UAC prompt isn't bad nor should avoided

[Aokromes]

according the source from where i got that link digitally signed msi patches allows to update without uac prompt.
https://serverfault.com/questions/485323/how-to-allow-program-updates-without-prompting-uac

[beerisgood]

Please read my post again

[bluikko]

The way other apps, such as Slack handle this is:

• Provide an "installer" that "installs" to the user's profile for "user-specific" installation. User can then install and update application without local admin rights/UAC. Of course in a managed environment in this path would not be allowed to execute anything.
• Provide MSI file for proper "machine-wide" installer that installs to Program Files, intended for managed environments. Usually these are pushed out by the IT, and MSI format installer makes this easy.

In my opinion the above is the "right" way to do it.

And I would really like to see the "machine-wide" MSI installer!

[beerisgood]

The right way is to follow Microsoft guide for more then 20 years: use program files folder!

No matter if a company or normal user use it. Program files always work without any problems, without security problems and without any malicious behavior for try to circumstances windows security like UAC.

[kotauskas]

Provide an "installer" that "installs" to the user's profile for "user-specific" installation. User can then install and update application without local admin rights/UAC. Of course in a managed environment in this path would not be allowed to execute anything.

Why bother? Just install the client into Program Files and update it via an elevated cron Task Scheduler job with time-based or manual activation, that's it. I don't understand why such a simple updating system isn't applied while being proposed for more than 3 years.

[kotauskas]

Also why make it so hard? A UAC prompt isn't bad nor should avoided

It's an annoyance. If the user, as an administrator, gave consent to the installer and let it install the software into a UAC-protected location, he must've also implicitly allowed it to update automatically by installing a TS task with administrative privileges.

[beerisgood]

It's even more easy: just use UAC. No elevated task needed. Using UAC doesn't need any work.

Just use Windows security with install the Programm in Profil Files. Done
Windows do the rest

[bluikko]

In a managed environment the user does not have administrator rights. Hence cannot write to Program Files folder.

"Installing" to AppData / user profile does not work in most properly managed environment because execution from user-writable locations is forbidden.

Edit: this is why there should be separate installers for user-specific and machine-wide.

[kotauskas]

In a managed environment the user does not have administrator rights. Hence cannot write to Program Files folder.

Users should not install software in managed environments, that's how MS built the entire thing. If they need Telegram, they either have to ask their administrator, use the mobile app/Telegram Web/Opera browser's sidebar client or use Portable Telegram.

[bluikko]

@kotauskas exactly, and this is why an MSI installer would be great...

[beerisgood]

But a MSI installer isn't the topic here and should be a own issue.

Anyway it doesn't looks like anything will change here. After more then 3 years

[bluikko]

But a MSI installer isn't the topic here and should be a own issue.

Not really if there would be 2 options (the "user-specific" and "machine-wide") that I outlined earlier.

This way the current installer would stay user-specific, installing to the user profile; and those who want to have system-wide installation to Program Files would use the machine-wide MSI.

Best of both worlds instead of trying to please two totally different audiences/use cases that simply cannot be both satisfied at the same time!

[beerisgood]

No. %appdata% isn't for binarys, nor solve problems. It make problems and is no solution.
Even enduser can have higher security settings like SRP which would problems here too

@john-preston doesn't give a f* here. And this is a security related messenger. Wow! Just misinformation and nothing more

[abatishchev]

UAC is an annoyance
LOLWHUT

[Neustradamus]

All good softwares when we install use by default "Program Files" (or recently "Program Files (x86)" for 32 bit apps in 64 bit system.
Bad softwares do not use it.

It is since Windows 95 and maybe before, no?

[bluikko]

All good softwares when we install use by default "Program Files" (or recently "Program Files (x86)"

Indeed, back in Windows 95 everyone had administrator rights so everyone could install and update the programs. Then later security caught up and users no longer have the permission to write to those folders. But developers want users without admin rights to be able to install and update their programs, right or wrong, and they found a way around it by installing to user profile.

[beerisgood]

All good softwares when we install use by default "Program Files" (or recently "Program Files (x86)"

Indeed, back in Windows 95 everyone had administrator rights so everyone could install and update the programs. Then later security caught up and users no longer have the permission to write to those folders. But developers want users without admin rights to be able to install and update their programs, right or wrong, and they found a way around it by installing to user profile.

.. use UAC?! It doesn't change anything for dev's nor for user. The user now only need to click on a yes/ no button.
Is this so hard? Can't believe the comments here

[kotauskas]

UAC is an annoyance

LOLWHUT

Don't you hate when you wake up in the morning and the only thing that greets you is Skype with a dumbass UAC prompt distracting you from whatever you were doing? If you had to use it a lot, you'd understand how annoying it was. Luckily, Skype is dead so we can forget about that piece of garbage that once was thriving and move on to modern messengers... Oh, we're proposing the exact same behavior in Telegram now. Uh-oh.

users without admin rights to be able to install and update their programs, right or wrong-

Wrong. Again, MS insists that users without administrative privileges do not install new software at all, or use things like PortableApps.com, and, by the way, that exact platform already offers Portable Telegram Desktop that works without elevation.

It is since Windows 95 and maybe before, no?

Windows Vista introduced UAC prompts which broke 70% of software back then. MS implemented compatibility auto elevation and UAC virtualization, but these are for legacy software written >15 years ago.

[beerisgood]

Microsoft provide guides how to do that things right. If the devs - like here, are not smart enough to use that, then it's not Microsoft fault.

I close this issue now again. Looks like nobody here care about security and only cry about simple yes/ no UAC buttons which is hilarious.

Telegram doesn't care about security. It only spread misinformation.
Bye

[kotauskas]

Looks like nobody here care about security and only cry about simple yes/ no UAC buttons which is hilarious.

Mostly so because somehow I live without any antivirus software at all for 7 years (with Windows Defender and Firewall disabled via group policies, I don't need that useless laggy bloatware on a 2011 CPU) and somehow never had malware. It's users' dumbness for downloading scamware at Softonic, really. A simple VirusTotal scan if you're not sure is sufficient in that case. While developers should still care about complicating malware development if the entire theme of their software is security, correctness and consistency is the only thing I actually came here for. Not because binaries in AppData are automatically insecure, but because the fact that apps don't install themselves into where they should install themselves is upsetting me. Truth is, if I could, I'd stop using Windows at all entirely because of the retarded developers who don't value consistency. The only thing that stops me is imperfectness of Wine. If it worked in 100% cases, I'd use Linux for all tasks for a long time.

[Neustradamus]

It is managed by admins not by users in company or a father at home if there is no rights for family.

And if an user needs to install, it is in personal folder instead of Program Files, easy.

Default -> Program Files

Please do not close this ticket, it is not solved.

[abatishchev]

Don't you hate when you wake up in the morning and the only thing that greets you is Skype with a dumbass UAC prompt distracting you from whatever you were doing?

I think it's a very small price (if any) to pay for the security it provides. So does any other security concerned software engineer or just computer user.

[abatishchev]

Mostly so because somehow I live without any antivirus software at all for 7 years

If so do you it doesn't matter than others do it today or should do in the future. It's called "anecdotal evidence" and no serious analysis would take it into consideration. Basically it's a non-argument.

It's users' dumbness

The attitude like 'Look how smart am I and how dumb are others' actually displays exactly the opposite. By saying so you nullify the rest of your argument.

Truth is, if I could, I'd stop using Windows at all entirely because of the retarded developers

So do it. Stop using Windows. You're free to do whatever you want. Nobody is holding you off, nor is seeking your opinion. Leave now and never look back but remember you won't be missed.

[Neustradamus]

It is not possible to stop to use Windows because some applications only exist for Windows.

But if all developpers do not respect install folders... It is not good.

[rbertoche]

Can a patch be proposed? I can't find any .iss files for InnoSetup in this repo. Is it anywhere on gitgub? Is anyone able to give me this pointer? As soon as I have some free time I could try to get a proof of concept working
Maybe that greases things up

[john-preston]

@rbertoche It is in tdesktop/Telegram/build/setup.iss

Proof of which concept?

[rbertoche]

Proof of concept of a well designed user interface for the installer that
installs to the right place when the user has admin rights and still allows
installation on some user owned directory, preferably one that Microsoft
recommends for installing binaries.

I get you may not pass any pull request directly but maybe after seeing a
solution done it'll be less work for you to get telegram to do whatever you
decide. I just hope you decide for something better than current solution
as I'm tired of the web app.

As for updates, if it needs UAC or not I think is still up to debate. What
I think is established here is that currently Telegram is not installed on
a proper Microsoft recommended path.

On Tue, 14 Jan 2020 at 08:04, John Preston [e-mail] wrote:

@rbertoche https://github.com/rbertoche It is in
tdesktop/Telegram/build/setup.iss

Proof of which concept?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/2355?email_source=notifications&email_token=AADTOLT7F3MUUDYXC3PPTGTQ5WL3TA5CNFSM4CMPSEJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4GPGI#issuecomment-574121881,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADTOLWEZ4UNJ3GJXZTSCUTQ5WL3TANCNFSM4CMPSEJQ
.

[jhasse]

[...] and still allows installation on some user owned directory, preferably one that Microsoft
recommends for installing binaries.

That would be %LocalAppData%\Programs.

[beerisgood]

Please do not close this ticket, it is not solved.

The issues was open long enough and no dev care. So what sense would it be to let it open?

For users here which care about security, i can highly recommend Unigram which is a Telegram WindowsStore build and also run with low AppContainer permission which is important.

The official Telegram version from WindowsStore doesn't run with AppContainer rights!
(WindowsStore apps run with lower rights then normal programs so they're more secure. If they're run with recommend AppContainer permission, even better)

[xelra]

I'll say it once more.

Please add the option in the installer, like it is common practice, to install for all users or to install for the current user.
The proper paths then are for all users %ProgramFiles(x86)% for 32-bit or %ProgramFiles% for 64-bit.
And for the current user it's %LocalAppData%\Programs for both 32-bit and 64-bit.

The current install path for the user-wide installation of Telegram is simply wrong and needs to be changed, even if no install option for all users is added.