DO NOT Change Install Directories When Previously Selected

[UnrealDrumpf]

Problem Description

Program version: 7.10 Undesired behavior: Prior version was installed in a specified folder. Update required an uninstall (from a 6.x version), but the install automatically went to a subfolder in the \user hierarchy.

I NEVER ALLOW PROGRAMS TO RUN FROM THE \USER HIERARCHY. It's bad security practice. I don't allow multiple logins on my machines, so ALL non-system-level executables run off either \Program Files or dedicated, root-level folders.

Please DO NOT hardcode installation folders, or block users from selecting installation folders. That is: Don't be Google or Adobe.

What version of VidCoder are you running?

7.10 SquirrelInstaller

Encode Log

No response

[RandomEngy]

You can also manually install VidCoder by unzipping to wherever you want. The archive is listed on each GitHub release, for example: https://github.com/RandomEngy/VidCoder/releases/download/v7.10/VidCoder-7.10.zip .

I want to provide an easy install for the majority of users, but still accommodate people who are particular with the zip archive.

[steff75]

First of all, thank you for the constant development of VidCoder, which I've been using for a few years now!

I also do not want to run programs from AppData. My Windows runs with Software Restriction Policies, avoiding such installation locations and preferring the Program folders.

I can't speak for everyone, but I suspect that people who run an installer like to take the opportunity to influence the installation path. I see the portable file then more for the reverse case.

[RandomEngy]

@steff75 I'm glad you are making good use of it! You can extract the zip file to whatever folder you like.

[UnrealDrumpf]

I perhaps wasn't clear enough in the original description.

Yes, I'm aware that one can manually set up to any folder using the .zip file. Which is what I had done, long ago.

The problem was that the update to 7.10 automatically (1) uninstalled the existing 6.xx from the preferred folder and (2) despite having had to "know" that preferred folder's location to do the uninstall, charged right ahead with no user input and installed into ...\Appdata . This is new (mis)behavior — no previous update has done this, since version 3 point something.

It's not an inability to choose folders on a fresh install. It's the mindless change of the install folder on a major-version-number update with no warning and no user input.

[RandomEngy]

I acknowledge that you find it frustrating that the program changed the install location. With the new installer platform it was impossible to keep the same install location. The upgrade was done to minimize hassle for the common-case user.

This is a one-time change that will most likely never happen again.

[Wrong-Code]

Unfortunately running applications from user space is a big NO-NO nowadays, and it's not just me saying that: you can read about against this practice almost everywhere there is a talk on security.

I understand your motivation, but the majority of software requires administrative privileges for their installation, and with a reason. Whoever has a PC at home has already the access to his/her own system, so it is not a big hassle to install the software under Program Files. And if they are not administrators and/or they are using a company PC's, there is probably a policy in effect which (again with a reason) prohibits running a software out of the authorized paths.

I would suggest to please reconsider your decision and to make it the other way around: the installer installs your application in the sanctified places, and those users that do not have the proper privileges could use either the portable or the zip solutions.

BTW: thank you for your application, well deserved.

[RandomEngy]

Can you link to an authoritative source? Microsoft's ClickOnce installer platform does the same thing and they have not deprecated it. Also, I am actually not sure what this policy of never running executables from user space is supposed to accomplish, and nobody has reported an actual security breach due to this. And with such a policy wouldn't you be unable to even run installers from the Downloads directory?

[cmcasey79]

I have to agree with the others here that this "new" installation method is very annoying and against best practices. Chrome used to install in AppData to avoid security prompts, but even Google eventually realized this was a terrible idea and reverted back to installing in standard locations a couple years ago. On top of just the default install folder, let power users pick the install location. The general dumbing down of installers is a terrible trend. Do NOT force me to install your app where you want it. If your installer platform is that locked down, find an alternative. I'll try the .zip, but strangely that method isn't mentioned on the main website, so I assume it's unsupported, won't auto-update itself, etc. I'm really disappointed that I may have to search for a new encoding now program because of this.

[cmcasey79]

Just a quick update... the "unzip" method is really unacceptable. In Windows 11, if I unzip to my desired location and try to run vidcoder from there, SmartScreen comes up saying it prevented an unrecognized app from running. Sure, I can do multiple additional clicks to run it, but I'm not going to do that every time. Video encoding is something that is generally done by power users, so I don't understand why you had to make it "easier" for people to install, while taking away the options a lot of power users want to begin with.

[RandomEngy]

Apps that install to Program Files and offer UAC-free auto-updates are running their own code at the machine-level; which presents an attack surface to gain full control of the machine. The Squirrel installer approach that VidCoder uses runs nothing privileged, so only the user space is at risk. Though I'm not a security expert, so I'd want to see an authoritative source from the Windows team address the tradeoffs.

As for SmartScreen on the .zip version, I'm pretty sure it should only ask you about it once. I could also sign the binaries, which would get rid of any SmartScreen prompt. Currently only the portable version and the installer version are signed.

As for making the installer prompt for the install location; I'm not interested in doing that. Most people don't care or won't change it; and there's something just delightful about not having to click through crud or make decisions to download and run the app. I do agree that some people want a different location but having two different installers would be an incredible pain to maintain and would be a confusing choice to present for users.

As for what users want; I don't think you can make the assumption that everyone who uses it is a "power user" or that you even know what "power users" want. I specifically designed VidCoder to hide complexity by default behind the encoding settings window, to accommodate these users; and I have fielded questions from plenty of people who just are trying to figure out enough to get by. My best guess based on download counts is that somewhere north of 100,000 people use VidCoder. I don't put any kind of telemetry in it and I don't send out surveys, so I don't presume to know what all the users want. It's possible you are correct but it's just as likely there's a silent majority of users that actually prefer it.

[RandomEngy]

I worked at Microsoft for 16 years and have some friends there who worked on Windows security; here are some responses:

That last reply is from a current security lead on Chrome.

[UnrealDrumpf]

This is going around and around making bad assumptions. Note what I stated in the very first message:

"I don't allow multiple logins on my machines, so ALL non-system-level executables run off either \Program Files or dedicated, root-level folders."

That is, this isn't a corporate machine-sharing environment from 1993 any more, and especially not for transcoding video materials and other personal-not-corporate activities. The responses from the Microsoft people are coming from the same place that continues to install fully-deprecated Internet Exploder components, floppy-disk drivers (in multiple versions!), and backward-to-1991-standard fax monitors on every machine, running at boot time — that is, the reality orientation is questionable at best, probably based on some marketing genius's memory of his college roommate's griping twenty years ago. (And meanwhile, they're installing Xbox and 3D and "virtual reality" crap on every Windows-10-and-later machine Just Because, also running at boot time.)

To return to my initial point, the installer should look for an existing installation and install any new version there, even for a major-version-number upgrade, if it doesn't directly ask the user for installation instructions. I don't use Squirrel, but I've been informed that there's a packaging-time choice to do precisely that.

Slightly off topic: Bluntly, the "multiple simultaneous users on a single machine" assumption behind some other responses was bad practice concerning executable files even then. (Keeping executables separated by users is for a programming environment only. Data is another matter entirely.) In this day when users are more likely to have more than one personal machine than the converse, it's even less appropriate. And it's certainly easy enough using GPEdit and administrator controls to manage matters when things are in fact being run on shared hardware.

[RandomEngy]

There's no feature in Squirrel to install wherever you want, or to search for the previous install location. It goes in %localappdata%. I would have to ditch the platform entirely. Which I'm not going to do because:

• No-touch installs are genuinely useful
• There seems to be no grounding to the idea that installing to %localappdata% is harmful. Slack, Visual Studio code and many other apps do this, and there appears to be no official security guidance recommending against the ClickOnce/Squirrel installation system.

Use the zip release if you want to install somewhere special. Let me know if you would find it useful to get rid of the SmartScreen warnings for that release.

[UnrealDrumpf]

Like I said, I was "informed that" Squirrel could do that from its own command line. If my informant was wrong, so be it.

VidCoder is extremely useful, and I will continue to use it. I'm just annoyed that the installation system overrode my prior choice without warning. I did successfully reinstall manually (from the .zip file), but lost all of my presets doing so because of the uninstall of the previous version (not the worst thing in the world, it took a whole five minutes to manually rebuild them).

I have said my piece on the installation-directory issue. I will just finally mutter that taking implied security advice from Slack (corporate-environment software) and Visual Studio (programming environment software) is exactly the problem I was talking about earlier today: Those programs make assumptions that are inapplicable to a single-user non-programming environment (for which I have a separate machine, precisely to avoid these problems). Invalid assumptions about user environments are fabulous attack surfaces — and, for that matter, effective bug incubators. That these assumptions are coming from Big Data doesn't make them any better: Just look at the number of Windows Update errors that are "if {a not-unusual hardware setup}, fail, here's the workaround, we're working to fix."

But hopefully this won't be a problem in the future. For any future major-version upgrade, I will just presume that the automatic updater will not work in my far-from-unusual-but-not-default user environment.

[cmcasey79]

I don't want to be too argumentative over this, but I'll just leave one final comment...

"As for making the installer prompt for the install location; I'm not interested in doing that." - This is the exact thing that drives me nuts with a lot of programs today. Choice is being taken away from users because of the developers personal preferences. And yes, Microsoft themselves is a big offender of this with things like Office 365. Just do a google search and see how people have been complaining for years. I guess maybe it's a small minority of users who really care, but it shouldn't be that hard to let users choose an install location. Probably 95% of all apps installers have a small link or button for "advanced" installs if the user wants to change things like the install folder. The fact that VidCoder used to have this option in prior versions shows it's possible (but maybe not with whatever installer is being used now). It doesn't have to be something all users have to click on or anything, so people who don't care where things are installed wouldn't really be bothered by it.

I will also say that the very name of "localappdata" seems to strongly suggest what the purpose of that location is... For application data, not applications themselves. I think developers found the loophole that programs could be put there and not need install/admin privileges to do so and have been kind of exploiting it ever since (yes, even Microsoft). I'm not necessarily saying it's a huge security risk, but I also don't think it's a best practice to put things there.

Finally, as an FYI, the SmartScreen prompt appeared every time I tried to start the .zip version, even after allowing it every single time. I guess I'm just out of luck at this point.

[UnrealDrumpf]

In slight defense of RandomEngy, this appears to be SquirrelInstaller rather than his mandate. I'm not seeing any sign that VidCoder was specifically written, with intent, to run out of AppData only — if it was, my manual install to Program Files wouldn't have worked. (Just try installing Amazon's comic-book encoder somewhere other than AppData...)

And I emphasize that it was only an annoyance to me, and that at least half of that came from the installer's silence and failure to respect the prior installation (and not from VidCoder itself). The usual workaround worked for me: Install from .zip "as portable," move the entire created folder to where it's supposed to go using my Admin privileges on my single-user machine, and make a new shortcut pointing to the new location. (VidCoder is far from the only program with which I've had to do this; if you want to see a real PITA/nightmare, just trying dealing with LibreOffice, in which even portable installations put some executable subprogams in AppData.)

[RandomEngy]

"As for making the installer prompt for the install location; I'm not interested in doing that." - This is the exact thing that drives me nuts with a lot of programs today. Choice is being taken away from users because of the developers personal preferences.

Adding "choice" is not free here. It's more time that I would need to spend developing and maintaining a redundant installer and update system. That is time I could be spending on other features, other projects, or just playing with my kids.

Finally, as an FYI, the SmartScreen prompt appeared every time I tried to start the .zip version, even after allowing it every single time. I guess I'm just out of luck at this point.

You could try asking me to sign the binaries.

[RandomEngy]

Update: the .exe files in the .zip distribution for v8.19 are signed, so they should no longer trigger the SmartScreen warnings.