pbatard
commented
2 years ago Per https://github.com/pbatard/rufus/wiki/Security#Remote_script_execution:
Finally, because we do understand that, even with all the above safeties in place, some people may still bark at the idea of having an application download and execute a remote PowerShell script, you should note that the ISO download feature is only enabled if the 'Check for updates' is also enabled in the Rufus settings (and on first usage, Rufus prompts the user whether they want to enable the update check or not, rather than default to enable as many other applications do), as we consider that a person who chose not to enable update checks from our servers most likely also doesn't want execution of a remote script. This means that, if 'Check for update' is disabled, the script is never even accessed and none of the above needs to apply.
So, to elaborate on the above, all I can say is: Sorry, but if you choose not to trust Rufus to check and download updates, even though they may contain critical fixes and I, as the developer of the application consider that you should really have it enabled always, I have no choice but to consider that you will also choose not to trust execution of a remote script. As far as I am concerned, it just makes little sense for someone to trust one feature and not the other, especially as the Download feature is potentially much more damaging than a check for updates, on account that, as opposed to the update check, it does not execute static coded content from the executable, that has been set in stone when it was compiled, but a remote script that could potentially be modified at any time to do something malicious (though of course we are taking all the measures required to prevent that from happening).
So, let me give my actual potentially inconvenient views on this:
- It doesn't look like the people who want the download feature but not the update check feature may really understand what happens behind the scenes. As such, I'd rather not have people find out that a feature that they thought was innocuous, such as a download button, is actually tied to a remote script execution, and then complain very vehemently to me that they never would have allowed Rufus to do something like this had they known.
- If people do understand what each feature does, but still want a decoupled Download and check for updates, then it does look to me like they are placing convenience over security, which is very bad practice. Plus, I also kind of take it personally when a user says they won't trust Rufus to perform a simple update check even after they have made the choice to run an application with elevated privileges (and therefore, one that could do whatever it wants to their computer if it really wanted to). So when a user then says that they want to have the option to indicate that they are not okay in trusting the application when it connects to the internet but at the same time also want have the option to say they will happily trust the same application to run a completely remote script with elevated privileges? Pick a side please...
- The suggestion, that is regularly being made, of having a huge blurb trying to explain what each feature does on the first start of Rufus, so that users could fine grain what they want to allow and reject would be both impractical, annoying and, judging by the amount of people who seem to ignore the message that is designed to help them on the ISO vs DD mode choice dialog, most likely ignored by most. Plus, I still fail to see how there can be any logic behind the contradictory choices mentioned in 2.
In summary: Remote executing a script, which Rufus needs to do to provide the Download feature is not something that should be taken likely and I will always consider that, if you indicate that you don't trust Rufus to connect to the internet to check for new versions, then you are certainly not going to trust Rufus to connect to the internet to download and execute a remote script, especially in elevated mode. From a security standpoint, it just doesn't make sense to let a user have it both ways there.
Finally, with regards to portable vs. regular, please be mindful that portability does not equate not leaving stuff behind on the computer (be it in the registry or on the file system). It just mean that if you pick the application files, and use them on a different computer, you will be able to find the same environment/settings as the ones you had on the previous computer. See also this relevant FAQ entry.
And as a matter of fact, it is because people just like you complained that the portable version of Rufus was doing the same thing as the regular version, in keeping some of its dependencies in the AppData Windows folder, that we moved them back to the same folder as the one where the exe resides, since it allows people who want actual portability to, say, keep the Rufus executable on a USB drive and carry that around without having to worry about missing anything from their previous session.
Now, I can appreciate that my tone might be harsh here. But I also hope that you can appreciate that I am often being asked by users, just like yourself, for things that are actually completely contradictory when you look at them objectively and comprehensively, as there is often a lot more behind what one imagines this or that feature is supposed to work.
drogga
@pbatard Would you please untie the "Select" button dropdown option for "Download" in Rufus from the checking for updates ?, because I'm trying to understand the point (and the idea) of why those two haves to be dependant, but I can't, it looks like a very dumb decision, why I have to be restricted or limited of options, just because I don't want it to check and notify me on new updates/versions... it doesn't makes any sense at all, especially with the portable version, which is less portable than the regular one (because it creates fileS in the same place, where the .exe is - say Desktop)...
Thank You in advance ;)