You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature request is in extension to my earlier Issue about Notifier.exe Death Battles (I don't know how to link to it, but here's the url: #28 )
When WFN 'Firewall Settings' is in "Block & Prompt" mode, the Windows Task Scheduler will launch Notifier.exe for each connection attempt, to determine whether a user prompt is necessary. When the setting is in "Block Silently" mode, then WFN's Notifier is not launched and no CPU resources are utilized.
I find that 99% of the time, I am quite contented to leave WFN in this latter mode, to silently block all connection attempts that are not already approved. It's only when I install a new piece of software that I will proactively switch WFN to "Block & Prompt" briefly so that I can receive notification of the requested connection(s). Once I have sorted out which connections are needed to make the software work, I switch WFN back to "Block Silently" for the next long while.
The problem here is that I have to manually tick six radio buttons from "Block Silently" to "Block & Prompt", then tick the six radio buttons to set it back to "Block Silently" again. I would like to request two things:
1: Make these six clicks simplified to a 1 click minimalist solution. I believe most people maintain only a single set of firewall rules, applicable across whichever profile(s) they incidentally use. So, apply rules to all 3 profiles in unity by default, for least amount of confusion. And also monitor requests for both Inbound and Outbound connections in tandem, with the same one click.
2: Make this a temporary / momentary feature that is quickly accessible from a right-click systray icon menu, rather than GUI navigation. Enabling "Block & Prompt" for only as long as necessary until it times out and switches back to "Block Silently."
The text was updated successfully, but these errors were encountered:
Notifier can now be started, closed or minimized on demand - no need anymore to switch back an forth. Systray and right-click menu has also been implemented. Think we can close the issue.
This feature request is in extension to my earlier Issue about Notifier.exe Death Battles (I don't know how to link to it, but here's the url: #28 )
When WFN 'Firewall Settings' is in "Block & Prompt" mode, the Windows Task Scheduler will launch Notifier.exe for each connection attempt, to determine whether a user prompt is necessary. When the setting is in "Block Silently" mode, then WFN's Notifier is not launched and no CPU resources are utilized.
I find that 99% of the time, I am quite contented to leave WFN in this latter mode, to silently block all connection attempts that are not already approved. It's only when I install a new piece of software that I will proactively switch WFN to "Block & Prompt" briefly so that I can receive notification of the requested connection(s). Once I have sorted out which connections are needed to make the software work, I switch WFN back to "Block Silently" for the next long while.
The problem here is that I have to manually tick six radio buttons from "Block Silently" to "Block & Prompt", then tick the six radio buttons to set it back to "Block Silently" again. I would like to request two things:
1: Make these six clicks simplified to a 1 click minimalist solution. I believe most people maintain only a single set of firewall rules, applicable across whichever profile(s) they incidentally use. So, apply rules to all 3 profiles in unity by default, for least amount of confusion. And also monitor requests for both Inbound and Outbound connections in tandem, with the same one click.
2: Make this a temporary / momentary feature that is quickly accessible from a right-click systray icon menu, rather than GUI navigation. Enabling "Block & Prompt" for only as long as necessary until it times out and switches back to "Block Silently."
The text was updated successfully, but these errors were encountered: