Replying separately since this isn't directly related to the issue and it got rather long.
Side note: I have to say the new location is a really, really bad idea
FWIW, it's not a new location. Paragon Chat has been running out of AppData almost the entire time it's been live, since 0.98b released on Aug 1, 2015. It started doing that shortly after it got a self-updater. If launched from elsewhere it would copy itself to AppData (if not already present) and relaunch from there. That was not only to avoid UAC prompts if the COH directory happened to be in Program Files, but also because some of the third party launchers like Tequila kept overwriting it with an older version.
The only thing that changed in 1.0 was the rename (to differentiate it from the betas and avoid accidental overlap) and reorganization of the folder structure. That and the bootstrap was split into a separate program for a smaller initial download. The beta releases were bogged down with design compromises made to get the thing working, so the transition to 1.0 seemed like the best time to fix as many of them as possible.
you should never, ever, have binaries/executables in your Windows profile/data folder.
Tell that to Google, who installs Chrome and other Google apps per-user if you don't have admin rights. Or Microsoft for that matter, since OneDrive installs itself into your local AppData so that it can silently update.
But really, it seemed like the most reasonable choice of the available options. Here's all the ones I can think of.
Program Files: Paragon Chat is under active development and sees very frequent updates. Since it's more or less peer to peer, new features depend on everyone having the latest version. Prompting the user for elevation every time there is a minor patch is a big usability issue. That would also cause some users to simply always run it elevated, which is a security risk and goes against the principle of least privilege. It's especially silly to require elevation for patches since absolutely nothing else that Paragon Chat does requires admin rights.
Programs that demand to be run as an administrator but don't do anything that really
needs it are a huge pet peeve of mine. I run as a limited user for day to day work and do not allow anything to elevate, ever. Instead I swap to a separate account if I really want to install something system-wide.
The workaround is just as terrible -- things like Firefox installing system services that are always running, just so they can update themselves if you're not logged on as an administrator. Imagine if every program did that!
Some system-wide location outside of Program Files: Messy because it's nonstandard. Not guaranteed to work if the filesystem permissions have been changed to not let random non-admin users create folders in the root (which is something I do on every Windows machine I install). Plus it's rude to create a structure that doesn't already exist.
ProgramData: There are a few programs that get installed here and it's not subject to UAC. However, it isn't backwards compatible to Windows XP, and the default file permissions are rather weak, so it could be a security risk on multiuser systems.
User profile: Per-user installs make a lot of sense for paragon chat due to the frequent updates, and also because some people are running a development branch for testing. On a multiuser system, it's quite possible that different users would be running different versions (one launches and updates while another has it open). It also fits well into the self contained model. My preference would actually be a 'Programs' directory under the user profile, which is where I install most of my per-user applications out of habit. However, that doesn't exist by default, and the de-facto standard set by Google and others doing their own per-user installs is AppData.
The COH install directory: This is the worst of all worlds. The COH directory could be literally
anywhere. If it was installed from the ncsoft installer, it would be under Program Files and subject to UAC requirements. Not to mention that COH itself breaks the cardinal rule and tries to write data to its program directory, so it either fails or invokes UAC virtualization which just confuses non-wizards when they go looking for their screenshots and costumes. Or it could be in AppData already if the user downloaded it with one of the third-party launchers. Or it could be in J:\Stuff\Torrents. Or on the user's desktop... Plus, putting stuff here could cause problems if it ever gets used for something else someday. Not very ideal.
Not only does it trip up malware detectors because it's a common malware tactic
I think the stuff that the client does is much more likely to trip them up regardless of where it's installed. PE loading code ("Oh, this looks like an unpacker! Must be bad!"). Dynamic code generation ("Oh, I can't analyze this! Must be bad!"). Lots of memory protect/unprotect calls as part of the codegen and patching. The patching process probably looks like self-modifying code as well ("Oh, this is trying to evade analysis! Must be bad!").
it also makes the program completely unprotected from e.g. virus infection even in a limited user account
I'm sorry, I just can't agree with that at all. My first question would be, "To what end?"
If malware is running under your user account, it can do far worse things. It can steal all your data and encrypt your files. It can turn your machine into a spam-sending zombie as long as you're logged on. It can modify your DLL path or exploit same-user shatter attacks (window hooks, etc) in order to run its code in any process you launch, regardless of whether or not it has write access to the exe file. It can do just about anything except for taking over the machine completely, and affecting other users if it's a multi-user machine.
The days of viruses infecting exe files are long gone. 99% of malware out there is either better classified as a worm or a trojan. With nearly every machine internet connected, there are far better attack vectors than exes on removable media, and old school viruses have mostly died out.
as well as going against all common Windows programming practice.
Microsoft's standards for traditional desktop applications are to install in Program Files, and have been since Windows 95, which was a single-user OS with no security whatsoever. I would argue that view is obsolete.
- UNIX users have been doing per-user installs of software into their home directories for 40 years. It's ideal for something small that doesn't need to be installed system-wide.
- Microsoft tried to add support for per-user installs with MSI 2.0 in Windows 2000. Due to design flaws, they could never get it to work quite right and eventually started recommending that it not be used, but did not remove the feature.
- There is a large demand for per-user installs that do not require admin rights, as evidenced by the explosion of portable apps. Almost every major application that it's feasible to have a portable version made of has one. Some of them are supported by the original author, some are packaged by third parties.
- There's also a big market in the corporate world for application virtualization, in order to automatically make applications that assume they are installed system-wide (installed in Program Files) per-user instead. See also: VMware ThinApp, Microsoft App-V, etc.
- It's clear that Windows is headed this way also. The *current* guidelines from MS say don't install in Program Files at all -- they say to use an AppX package, submit it to the Windows Store, and let the OS decide where to put it. All Windows 10 Universal applications install per-user, not per-machine.
They currently DO end up under Program Files\WindowsApps, but that's another terrible design decision that will come back to bite them IMO. Just think about it for a minute -- any user on a limited account can install an app from the Windows Store WITHOUT being prompted for elevation or entering an admin password. The installation itself silently runs with TrustedInstaller rights and ends up in Program Files... setting off any alarm bells yet? There will be a lot of fallout the first time somebody manages to slip a trojan through the store submission process.
My feeling is that MS will eventually start installing universal apps into the user profile or some other per-user structure instead, which they can do at any time since the OS is in full control of where these packages end up.
I'm a software developer myself (Pale Moon web browser), so if there's any specific concerns that made you decide to do this, maybe I can help?
I think I just about covered it.
I'm interested in hearing your opinions on the subject as a fellow developer.