Having the firewall setup "Warn if any process connects to the internet unless explicitly allowed" and wanted to check how it works ending up quite surprised in the end ...
I chose vlc.exe process (VLC player) under Network applications and changed it to Block from Allow. Afterwards I had run VLC player and had triggered the update check supposing that VLC wouldn't be able to connect to the internet due to imposed the connection rule to Block. However to my surprise VLC could check for the updates.
Am I missing something as regards the firewall rules?
Is there any way how could I properly check the firewall blocks the blocked processes/applications for the outbound connections?
Thanks & regards,
EDIT: Strange ... I changed the firewall setting to "Warn if any new untrusted process connects to the internet", chose revouninstaller.exe for instance, changed to Block and tried to check updates of Revo Uninstaller what ended up in having the blocked connections message in Revo. So now it worked how I had supposed.
However I am missing an option to add my own process/application to block. Is there any other way how to do that?
Best answer by JimM
Joe explained on the Wilders that such applications (which went on the net even if being blocked) probably use another process for the outbound connection.
It's true that the idea linked to earlier in the thread would result in a more straightforward experience in blocking processes from connecting to the internet.
However, speaking more to the notion that auto-allow after a set time period is not good, I really must stress the point that the last thing you want is for the firewall to auto-block a "new" process. Coming from a background where I supported the 2011 and prior version of our firewall, one of the top complaints was that users would miss the countdown completely. Your computer doesn't necessarily need you to be present for something to connect to the internet. Auto-updaters and certain semi-critical Windows processes would consistently get blocked, which was the intended behavior of the program, but it was not exactly a pleasant user experience to come back to your computer and wonder why you either can't get online at all or wonder why certain programs won't update anymore. What had happened in those types of cases was that the user completely missed the countdown box, and it defaulted to block. Other times, the user thought "Block everything!" and kicked themselves offline in the process. This is particularly onerous, because unless you have support on speed-dial (and nobody should), and if it's your only computer, it might be tricky trying to contact support if you can't find a phone number and can't get online to look for one. To compound things, you might suspect that if you allow an auto-updater, it will work from that point onwards. That's not exactly correct, because as soon as that updater updates itself, it's a new program with a new MD5 value, and the problem repeats itself. I actually wrote about this a while back.
I realize "wait until user interaction" is not the same thing as "block automatically," but you're in the same boat for as long as it takes you to come back to the computer. Imagine you're going on vacation, and it's not at the top of your mind to change your firewall settings before you leave. You come home expecting a bunch of downloads finished, updates completed, etc. You better hope the program you're using to download stuff didn't auto-update. You better hope the updaters didn't update themselves. You better hope svchost didn't get updated by Windows Updates. Pretty much nothing will be getting online if that's the case. Maybe you intended to use a cloud service to remote into your machine while you're away from home. Well, maybe that doesn't work as well as you'd hoped. :( Naturally, the counterpoint is that users need to be responsible for their own settings, but that often leads to a lousy user experience for less tech-savvy users because they don't want to be burdened with that much responsibility.
Speaking only for myself, I would hope that if Webroot decides to implement that kind of feature request that it is surrounded by ominous warnings with red, flashing lights that explain the kind of potential problems I just described, because they are the sort of things that the average user doesn't really think about. I think I know everyone who has commented in this thread well enough by now to know that these kinds of problems are things you would anticipate and not be affected by if such a feature existed, but what about the average user who turns on the feature thinking "the more protection, the better?" I see the benefit of the feature, but I'm not sure if it isn't outweighed by the potential issues it could generate. I'd love to see more comments on this topic to gauge reactions to the potential issues I've brought up.