This project has moved. For the latest updates, please go here.

Pop-up frenzy since Windows Update 13.08.2014 (WFN 1.8.0 & 1.9.1.9) + Solution?

Aug 14, 2014 at 6:50 PM
Hello Wokhan,

I only just saw your 3.8.14 reply on my 1.9.0/1.8.0 review from 17.3.14 - I returned to the WFN codeplex page because of a new storm of recurring pop-ups since the last Windows Update (before, 1.8.0 worked fine for me). Thus, I just switched to 1.9.1.9 (beta), as you proposed, and... it's just as bad. :(

However, you commented that "Windows firewall [...] still creates a log entry, which then triggers WFN, while it shouldn't". I now wonder to which one of Win Firewall and WFN the relative pronoun "it" refers: Should the Firewall not write those triggering entries to the log file, or should WFN (or the Scheduler) not process those repeat entries?

If I understand the working principle of WFN correctly, then the Windows Firewall writes log entries for outbound blocked connections to a log file using auditpol.exe - even when it shouldn't (the surplus entries should already be allowed, and thus not be logged to that file). The Windows Task Scheduler reads from the log file and triggers WFN popups, which would ordinarily permit a user to allow the previously blocked connection.

If all of that is correct, the solution seems to be to have the Scheduler trigger the WFN Popup not directly, but only after comparing the triggering log file entry to the list of rules already created (on a per file name base?) and NOT show a popup if there already is a rule for that executable. That is, filter log file entries from existing Firewall rules before showing a popup. Would that be a possibility?
Coordinator
Aug 15, 2014 at 11:34 AM
Hi,

Yes, you're totally right. And your solution is really smart, but... this is the one I already use ;-) When the task scheduler triggers WFN, a first instance checks if it was for a good reason (i.e. if there is any rule telling that it's not), and then shows the popup only if no rule matches.
Unfortunately this process comes with a cost, and sometimes false positives go through (I still have to work on it).

Many people are fed up with such behavior, I'll try to level up a bit and to change the way WFN actually intercepts the blocked connections, using an always-on agent and depper system integration (as all other firewall and security tools do). I wanted to avoid that, but I see this logic has some limits and I need to change that. I'll have to deal with some unmanaged C/C++ code, so it may take some time. I don't know when I'll be able to do that, maybe I'll take one or two days off to be able to focus on a new version.

Regarding your observations, is there a specific application / process involved?

Thanks!
Aug 18, 2014 at 9:38 AM
It is mostly Firefox and Thunderbird (IMAP) as well as "System" - a common denominator might be that the recurring programs are all marked as "Service" (however, un-ticking the "Service" box when allowing also does not help). In some cases, when allowing a service, another pop-up window asks which Service is to be allowed, but offers only one entry to select (or to allow per process, disregarding Services).

No combination of "Service"/"No Service" did help so far.

In any case, it is good to hear that you continue to improve WFN! Many thanks!