-
-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Wildcard Paths" enhancements #142
Comments
To improve the "wildcard paths" handling, I'm going to:
@Emi-Emi-Emi What do you think? |
As I understood, you want to go with the AppGroups but then Programs to whitelist individual apps? Not against this approach, but I think the problem is how both are in total different places, so managing them is not as good as it can be. So while I am not saying Programs have to be re-done, AppGroups should be closer or part of it or something, like there should be a way to make them work better and more seamlessly together. I mean there is already "Application Group" and "Use Enable State" in Programs, so they are meant to work together too. Because for my example, I could have added Store to Programs, that would work (not thinking about the wildcard here), but then I would have to manage them in two places, so I wanted to stay in AppGroups, because it is easier to copy and paste a line than keep going to Programs for it. I mean, the simplest improvement I can think about this is to add a I think with My Fort addition, is still there for future organization of things, and don't have everything in Options, but still have Statistics and Programs and Zones in different windows (I guess similar issue might exist with IP addresses not belonging to Options though but that's another topic.). At least Groups in Programs, makes more sense than Options, especially if the approach is to make them work more together to 'fix' these kind of situations. So it sounds good, but I think Groups should be closer to Programs. |
This flag will be removed, when I'll extract "Speed Limit" groups to own window. |
I want to just extend Programs window to have wildcard paths too. So you can individually configure wildcard paths to Allow/Block, Collect blocked conns etc. |
I like this idea. Added #143. |
Implemented by de1ad75. |
Implemented in v3.10.3. |
It already works as expected. Maybe my previous test was mistaken..
Implemented.
Implemented.
Not implemented. Prefix wildcards (PATH/**) are collected to one sorted list to binary search. But I've changed the driver to first search by complex wildcard paths, and then by prefix wildcards.
Implemented. |
Nice! thank you, everything sounds great. Just installed and will be testing! Oh, and now I can use Now it will be harder to choose between Programs and AppGroups, but might go back to combine both at some point, just to benefit from both. |
Discussed in #141
Originally posted by Emi-Emi-Emi December 1, 2023
There should be a way to deal with this:
For example, I added
C:\Program Files\WindowsApps\**
In the Block column and thenC:\Program Files\WindowsApps\Microsoft.WindowsStore_*_x64__8wekyb3d8bbwe\WinStore.App.exe
in the Allow.It says it is being blocked, because Block takes priority over Allow.
Well, that's the conclusion in my simple test of adding the same .exe in both columns and it always got blocked.
I was thinking maybe there should be a way to set a priority for each group and one group will take priority? So I can add
WinStore.App.exe
in one group and then in a 'low priority' the whole folder, but then, it seems a little too much for something so rare to use.I don't even know if it possible with how Fort Firewall logic is done for the AppGroups. or if there is a way to set Allow to be priority and not Block inside the AppGroups.
To explain the reason for it:
I am using Programs as a way to see if some apps want to connect to the internet and that way to allow or block them. The problem with using
Ignore, if not blocked or allowed
is that apps that are not allowed or blocked don't even appear in the Statistics -> Blocked Connections, which makes sense. But also disablingCollect New Programs
will not let me see apps in Programs.So using
Block, if not allowed
would add them to Programs/Logger, allowing me to see what is being blocked and the other one will half do what I want with it.I guess I wanted a workaround about FF not having a true notification system for blocked apps, but even with a notification system, there would be the same issue, unless there was a way to ignore specific folders from being 'logged' by Fort, like Ignore mode works but for specific folders.
So maybe there should be a way to exclude folders and work like Ignore mode where
Any new apps will be ignored and will not appear in the 'Programs' window.
but insideBlock, if not allowed
?Maybe like a way to change the Application Group's column from "block" to "Ignore" or a way to show an
ignore
AppGroup column or something like that to take advantage of wildcards and that way folders there will not be logged, or blocked but just ignored.Mainly meant for folders but if people want to use it for individual files it will work like if an Application Group had the
Collect blocked connections
off, so technically there will be no difference.I think this still would be good for the future, because if there was a notification system and Fort asked people if you want to allow or block a connection, it would be good to have a way to ignore certain folders and exes from it, so something that works for both Programs and Application Groups would be good, or just Application Groups.
Of course this idea depends on how AppGroups does its things and how the Block Notification system works in the future, maybe there is no way to work around it and only block everything manually each program is the only option, but with the possibility of using wildcards.
But I even tested wildcard
!
but I don't think it is supported in Fort and documentation says:For now I am blocking them individually but thought I would throw an idea about it and feedback in case anything I said it is useful for the future.
The text was updated successfully, but these errors were encountered: