For clarification, this goes beyond compression utilities. Basically, any program I have on D partition is affected (ex. Potplayer, NitroPro, Notepad++ and so on). So launching PDFs, videos, graphics files, etc., from Chrome (or my search utility, Everything) results in a notification. I tried Custom Folders and marked the D partition Program Files/Program Files (x86) folders to match those on C partition, but there was no change in notification behavior. It does seem odd though that double-clicking a zip file from Windows Explorer launches 7zip from D partition without a notification, but launching that same file through a program like Chrome (which does reside on C partition) gets flagged.
Thanks for looking into this Dan. I guess I'll have to live with that for now.
Cool, thank you. Yeah, I totally get what you are saying, and if there was a way that I could fix this safely, then I would
. There probably is a way, but it is going to take some time to figure out.
The real issue is when a parent executable is trying to open a child executable, especially when the parent executable is a vulnerable web app. That is... if the parent app is simply trying to open a text file to edit it, there is not an issue. For example, VS will allow powershell to edit a non-whitelisted script, but it will not allow it to execute the non-whitelisted script.
This is why in your last Chrome example from above... Windows Explorer will launch 7 zip, and this is because it is whitelisted. But when you have a risky executable web app like Chrome trying to open a child executable, you have to be very careful, otherwise, the end user will end up in tears, as CS would say.
One very simple quick and dirty test that I always perform on VS is to open Internet Explorer... then go to File | Open | Browse | Change the file filter at the bottom right from web documents to all files | then browse to the Windows\System32 folder, and try to open an executable. I usually use cleanmgr.exe, but you can use most all of them. Anyway, after a couple of Internet Explorer prompts, VS will block the file. If VS did not block this file, I would be deeply concerned.
But yeah, blocks can be a pain, but the whole goal of VS is to provide "Absolute" security, while minimizing the dangerous affirmative user prompt as much as possible, and remaining user friendly. But if there is ever a question, the damn thing needs to be blocked.
As we all know, in cyber security, there is a balance between security and usability / convenience. Well, for the most part this is true... VS blocks a hell of a lot of stuff that some PIA products miss. But in general this is true.
Years ago, before I was self employed, I used to work for Lucent Technologies... and everyone had a saying there. "Do what you can afford."
Some cyber security companies actually believe that they can create a product that is totally silent to the end user, and still block every single attack... like it is FM (freakin magic).
And then others pretty much just block everything and call it a day.
There needs to be a balance. The security industry has a strong tendency to blame the user for not being able to utilize their software properly so that they are sufficiently protected. This is absolutely absurd. If, as a software company, you cannot produce software that 50% (guessing on the % from my experiences) or so of the target user base / market does not understand, then you either designed a crappy product, or you are in the wrong business.
End users are not stupid... they just need user friendly security software. For example, teenagers understand social media apps better than any security dev ever will, but yet, somehow we are unable to understand why they are not able to properly use security products.
Sorry for the rambling... all of these thoughts have been on my mind for a while now... along with many, many more
. Thank you guys!