Thank you
@WiseVector,
1. When adding a file (no matter it's safe or not) in the Exclusions of WVSX, it means all the behavior (including network connection) of the file is trusted by WVSX. "Exclusions" has more elevated permissions than personalized rules and "Rules" has more elevated permissions than the HIPS( it will block network connection when a program is suspicious) .
Finally, now is clear.
And unfortunately that's a problem!... because I was right.
In real world, running a file is one thing, and its network connection is another thing. They're two very different functions, complementary, independent, never subordinated.
If I allow an exclusion file to run, it doesn't (necessarily) mean that I allow its network connections.
Hope you receive my interpretation as a possible future WV upgrade, allowing WV firewall (rule) functions to work as a complement, never as a subordination of other WV functions.
It's not a matter of hierarchy. It's a matter of different functions. It's wrong to subordinate "firewall (rule) functions" to "running functions".
2. If you want to run an unsafe program, please try to disable the realtime protection of WVSX, but not add it in the Exclusions.
With all due respect, this is not a solution, this is a bad workaround.
The "unsafe" category is determined by WV, not by the user. So, if WV determines that a file is "unsafe", and the user wants to run it, then there is no choice, the user is forced to create a WV exclusion. And if by chance the user has lots of "unsafe" files determined by WV, well, then in this case is ridiculous to disable the WV realtime protection, lowering security level for the whole device.
Your suggestion is a particular workaround, negatively affecting the general solution.
But I feel curious that why you need to run an unsafe program? It was alerted as malicious by WVSX? Or you think it is a FP?
Bingo! Excellent question.
I can think about several examples where a user needs to create a WV exclusion (allowing an unsafe file to run), but same user at same time wants to block its (particular) network connections.
One example is "average Joe" (user) dealing with "unsafe" files. When WV determines that a file is unsafe, and average Joe needs this file running, the common (wrong) behavior is to allow this file to run. If this file is just a FP, no problem with network connections. But if WV is right, and the file indeed is unsafe, then blocking networking connection (rule) may reduce damage.
Another example is "advanced Joe" (user) dealing with FPs. I have at least 20 files that WV identified them as "unsafe" and I'm 99% sure they're FPs. So I allow them to run. But for many reasons, I want to block their network connections. Unfortunately, that can't be done with WV, I need a separated Firewall program to block WV "unsafe" (allowed exclusions) network connections. And no, reporting FPs to WV won't help when these FPs are constantly changed due to frequent updates/upgrades (also, if FPs detected by WV as unsafe are portable software, at any location change (drive, folder etc) WV always will block this FP again an again as a new unsafe file).
Please, let me be clear, I love current WV simplicity and minimalism. And I don't want to see WV bloated with endless options.
But in this case, will be very useful a simple option inside the exclusion function, asking the user if the exclusion should include "internet connections", "hips" etc (category of rules). It can be done by adding simple check boxes inside exclusion popup (for category rules). Unchecked boxes will mean actual WV default behavior, 100% allowing an unsafe file to run (overwriting all WV rules). And checked boxes will mean allowing to run the unsafe file, but subordinated to WV category rules (firewall, hips etc).
Thank you once again.
EDIT:
3. Please maximize the rule edit window when you need a longer space for "Program path exclusions".
IMHO this is bad UI.
I understand that normal or maximized WV window will affect the visualization of excluded paths. No problem with that!
But at normal WV window, if user copies/pastes a long exclusion path, then the long path is not only hidden, but worse, is cut (automatically reedited) by WV (without user knowing that).
